Linux：kubernetes（k8s）有状态的服务部署（14）

之前我都是对无状态进行的一个操作，我们想扩容就扩容，想缩容就缩容，根本不用去考虑他的一个网络环境，本地储存环境啥的一个状态

当我们做有状态的服务的操作，肯定要申请一个持久化的一个空间，以及网络，确保我数据的一个稳定性和安全性

本章我还是使用nginx进行一个演示，nginx的网页是储存在/usr/share/nginx/html/ 中，这个目录在容器内是一个不可靠的东西，所以我要把他存储到容器外，通过一个voluem进行一个存储，并且可以通过服务名进行一个访问

创建

我这里准备了一个配置文件用于等会的使用

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet       # 类型资源
metadata:
  name: web     # statefulSet 对象的名字
spec:
  serviceName: "nginx"  # 使用哪个 service 来管理dns
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:  # 容器卷内部要暴露的端口
        - containerPort: 80     # 具体暴露的端口号
          name: web     # 该端口配置的名字

kubectl create -f web.yaml

这样我就创建好一个了

去访问一下试试，我们需要再去搞一个容器再去访问主机

run -it --image busybox:1.28.4 dns-test /bin/sh

这个意思是搞一个 busybox，这个容器他里面包含着很多的工具，然后耐心等待他的下载

这样就成功进入了

进入测试一下

扩容缩容

kubectl get sts

可以看到这里有2个

scale sts web --replicas=5

可以看到他的一个详细信息

如果要是缩容也是一样的

kubectl scale sts web --replicas=2

可以看到他又缩减下来的一个信息

镜像更新

kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.9.1"}]'

使用json格式进行一个修改

kubectl rollout history sts web

可以看到历史的一个更新记录

查看一下第二个

可以看到就是更新的镜像

他是倒叙的更新方式

他更新也有两种方式一种是RollingUpdate 另外一种是OnDelete

RollingUpdate是什么：StatefulSet 也可以采用滚动更新策略，同样是修改 pod template 属性后会触发更新，但是由于 pod 是有序的，在 StatefulSet 中更新时是基于 pod 的顺序倒序更新的

OnDelete：只有在 pod 被删除时会进行更新操作

灰度发布（金丝雀发布）

我们在发布项目到线上的时候，没法确保他的一个安全性以及测试覆盖性达到一个非常补充的状态，我们使用灰度发布的目的就是确保产品上线后对产品的影响降到最低

当我们在更新的时候，大部分采用滚动更新，一下把所有的容器全更新完，确实可以让用户无法察觉到更新，但是如果遇到bug那么全部的容器都将收到牵连，当我们使用了金丝雀发布，他只会对其中的一个或者一半的容器进行更新

当有问题的时候直接回滚一小部分，这对我们的损失还是降到很小了

利用滚动更新中的 partition 属性，可以实现简易的灰度发布的效果

例如我们有 5 个 pod，如果当前 partition 设置为 3，那么此时滚动更新时，只会更新那些序号 >= 3 的 pod

利用该机制，我们可以通过控制 partition 的值，来决定只更新其中一部分 pod，确认没有问题后再主键增大更新的 pod 数量，最终实现全部 pod 更新