Kubernetes ---- Pod控制器之StatefulSet

StatefulSet

cattle: 关注群体
pet: 关注个体

特性:
  1. 稳定且需要有唯一的网络标识符;
  2. 稳定且持久的存储设备;
  3. 有序、平滑的部署和扩展;
  4. 有序、平滑的终止和删除;
  5. 有序的滚动更新;
StatefulSet必备的三个组件:
  1. headless Service
  2. StatefulSet
  3. volumeClaimTemplate

 

  StatefulSet中的headless Service的作用:

  StatefulSet控制的服务集群中,启动服务,顺序启动,停止服务,逆序启动;当集群中有Pod要重新启动时,Pod的名称必须要与第一次启动时的Pod的名称一致,Pod名称是作为识别Pod唯一性的标识符(必须稳定、持久、有效)
使用headless Service确保解析的名称是直达后端Pod IP地址的,并确保给每个Pod配置一个唯一的名称;

  StatefulSet中的volumeClaimTemplate:

  在分布式系统当中,数据分别存储的数据是不一致的,每个节点应该有自己专用的存储卷,创建每一个Pod时会自动生成一个pvc,从而请求绑定一个pv,然后拥有自己单独的存储卷;

创建StatefulSet:

1. 创建pv,pv与pvc内容见博客另一篇文章;

$ vim pv-demo.yaml
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv001
    labels:
      name: pv0001
    spec:
      accessModes: ["ReadWriteOnce","ReadWriteMany"]
      capacity:
      storage: 5Gi
      nfs:
        path: /data/volumes/v1
       server: 192.168.222.103
  ---
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv002
    labels:
      name: pv0002
    spec:
      accessModes: ["ReadWriteOnce"]
      capacity:
      storage: 5Gi
    nfs:
      path: /data/volumes/v2
      server: 192.168.222.103
  ---
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv003
    labels:
      name: pv0003
    spec:
      accessModes: ["ReadWriteOnce","ReadWriteMany"]
      capacity:
      storage: 5Gi
    nfs:
      path: /data/volumes/v3
      server: 192.168.222.103
  ---
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv004
    labels:
      name: pv0004
    spec:
      accessModes: ["ReadWriteOnce","ReadWriteMany"]
      capacity:
      storage: 10Gi
      nfs:
        path: /data/volumes/v4
        server: 192.168.222.103
  ---
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv005
    labels:
      name: pv0005
    spec:
      accessModes: ["ReadWriteOnce","ReadWriteMany"]
      capacity:
        storage: 10Gi
    nfs:
      path: /data/volumes/v5
      server: 192.168.222.103

  $ kubectl apply -f pv-demo.yaml   $ kubectl get pv NAME   CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv001   5Gi    RWO,RWX    Retain     Available               78m pv002   5Gi    RWO       Retain     Available               78m pv003   5Gi    RWO,RWX    Retain     Available               78m pv004   10Gi   RWO,RWX    Retain     Available               78m pv005   10Gi   RWO,RWX    Retain     Available               78m

2. 创建statefulSet应用

$ vim state-demo.yaml
  apiVersion: v1
  kind: Service
  metadata:
    name: myapp
    namespace: default
      labels:
        app: myapp
    spec:
      clusterIP: None
      ports:
      - name: web
        port: 80
      selector:
        app: myapp
  ---
  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: myapp
    namespace: myapp
  spec:
    serviceName: myapp
    replicas: 3
    selector:
      matchLabels:
        app: myapp-pod
    template:
      metadata:
      labels:
        app: myapp-pod
      spec:
        containers:
        - name: myapp
          image: ikubernetes/myapp:v5
          imagePullPolicy: IfNotPresent
        ports:
        - name: web
          containerPort: 80
        volumeMounts:
        - name: myappdata
          mountPath: /usr/share/nginx/html
    volumeClaimTemplates:
    - metadata:
        name: myappdata
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi
$ kubectl apply -f state-demo.yaml

3. 成果

## 下面的三个Pods的名称有规律性的,不像deployment控制器创建出来的随机名称,因为当我们删除其中一个Pod之后,K8s还会创建出来之前那个一样名称的Pod;

$ kubectl get pods
NAME     READY STATUS RESTARTS   AGE
myapp-0   1/1   Running   0      44m
myapp-1   1/1   Running   0      44m
myapp-2   1/1   Running   0      44m

## 下面的myapp就是我们创建的statefulSet类型的控制器

$ kubectl get sts
NAME READY AGE
myapp 3/3 45m

## 我们发现,当创建Pod的时候,Pod会自动拥有一个pvc,然后这个pvc再去系统上找寻与之规则匹配的pv进行绑定,从而使每个Pod都能单独挂载在某个pvc上,且pvc的名字都隐含了Pod的名字,所以就使得他们能够
持续的为同一个Pod而使用,这就是VolumeClaimTemplates的功能;

$ kubectl get pvc
NAME         STATUS VOLUME CAPACITY ACCESS    MODES STORAGECLASS AGE
myappdata-myapp-0 Bound pv002   5Gi      RWO 51m
myappdata-myapp-1 Bound pv003   5Gi      RWO,RWX             49m
myappdata-myapp-2 Bound pv004   10Gi     RWO,RWX             49m

注:
  当我们手动删除Pod时,pvc并不会被删除,且Pod的删除顺序是倒序删除的,从2 --> 0逐一删除;
  创建时则是正序创建,从0 --> 2;
  每一个Pod的名称都可以被解析为IP地址;
  pod_name.service_name.ns_name.svc.cluster.local
  myapp-0.myapp.default.svc.cluster.local
  myapp-1.myapp.default.svc.cluster.local
  myapp-2.myapp.default.svc.cluster.local

扩展副本:

# 将副本扩展至5个,k8s会先扩展4,再扩展5.
$ kubectl patch -f state-demo.yaml -p '{"spec":{"replicas":5}}'

# 查看一下pvc,发现所有pvc都已经被绑定了;
$ kubectl get pvc
NAME         STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myappdata-myapp-0 Bound  pv002   5Gi     RWO              69m
myappdata-myapp-1 Bound  pv003   5Gi     RWO,RWX              67m
myappdata-myapp-2 Bound  pv004   10Gi    RWO,RWX           67m
myappdata-myapp-3 Bound  pv005   10Gi    RWO,RWX           2m50s
myappdata-myapp-4 Bound  pv001   5Gi     RWO,RWX           2m36s

缩减副本:

# 将副本再次缩减至3个,监控Pod变化顺序,会先删除4,再删除3,直至副本数量满足要求;
$ kubectl get pods -o wide -w
$ kubectl patch -f state-demo.yaml -p '{"spec":{"replicas":3}}'

myapp-4 1/1 Terminating 0 5m21s 10.244.1.127 node3  
myapp-4 0/1 Terminating 0 5m22s 10.244.1.127 node3  
myapp-4 0/1 Terminating 0 5m28s 10.244.1.127 node3  
myapp-4 0/1 Terminating 0 5m28s 10.244.1.127 node3  
myapp-3 1/1 Terminating 0 5m41s 10.244.2.160 node2  
myapp-3 0/1 Terminating 0 5m44s 10.244.2.160 node2  
myapp-3 0/1 Terminating 0 5m45s 10.244.2.160 node2  
myapp-3 0/1 Terminating 0 5m45s 10.244.2.160 node2  

 

滚动升级:

  金丝雀升级:

    自定义更新策略:
    sts.spec.updateStrategy.rollingUpdate
    partition: N
    意味着>=N的Pod会被更新
    partition: 2
    myapp-0 不会更新
    myapp-1 不会更新
    myapp-2 会更新

  演示:

# 将partition设为4,那么Pod中大于等于4的Pod才会更新;
$ kubectl patch sts/myapp -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":4}}}}'

# 更换镜像
$ kubectl set image sts/myapp myapp=ikubernetes/myapp:v2

# 验证,发现只有myapp-4的镜像变化了;
$ kubectl describe pod myapp-4
....
10.244.1.129
....
$ kubectl describe pod myapp-0
....
Image: ikubernetes/myapp:v5
....

 

正式升级:
当发现金丝雀升级后的其中一个Pod运行没有任何异常的状况,可以将所有Pod都升级,监控升级过程,发现是从大到小进行升级的;

$ kubectl get pods -o wide -w
$ kubectl patch sts/myapp -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}'

# 所有的Pod的镜像都已经改变了
$ kubectl describe pod myapp-0
....
Image: ikubernetes/myapp:v2
....

 

你可能感兴趣的:(Kubernetes ---- Pod控制器之StatefulSet)