K8s StatfulSet使用总结 - HelloWorld开发者社区

StatefulSet:
在1.3以前K8s中StatefulSet叫PetSet(宠物集)，由此也可看出StatefulSet是关注个体，而非群体。
StatefulSet要满足以下几点:

稳定且唯一的网络标识符；
如: Redis集群, 在Redis集群中，它是通过槽位来存储数据的，假如:第一个节点是0~~1000,第二个节点是1001~~2000,第三个节点20013000...等等，这就使得Redis集群中每个节点要通过ID来标识自己，如: 第二个节点宕机了，重建后它必须还叫第二个节点，或者说第二个节点叫R2，它必须还叫R2，这样在获取10012000槽位的数据时，才能找到数据，否则Redis集群将无法找到这段数据。
稳定且持久的存储
有序、平滑的部署和扩展；如 MySQL集群,要先启动主节点, 若从节点没有要求,则可一起启动,若从节点有启动顺序要求，可先启动第一个从节点，接着第二从节点等；这个过程就是有顺序，平滑安全的启动。
有序、平滑的终止和删除；即: 我们先终止从节点,若从节点是有启动顺序的，那么关闭时，也要按照逆序终止，即启动时是从S1~S4以此启动，则关闭时，则是先关闭S4,然后时S3，依次关闭，最后在关闭主节点。
有序的滚动更新；如： MySQL在更新时，应该先更新从节点，全部的从节点都更新完了，最后在更新主节点，因为新版本一般可兼容老版本，但是一定要注意，若新版本不兼容老版本就很很麻烦!

创建一个StatefulSet控制器的示例: vim pod-statefulset.yaml apiVersion: v1 kind: Service metadata: name: myapp labels: app: myapp spec: ports:
- port: 80 name: web clusterIP: None selector: app: myapp-pod
apiVersion: apps/v1 kind: StatefulSet metadata: name: myapp spec: serviceName: myapp replicas: 3 selector: matchLabels: app: myapp-pod template: metadata: labels: app: myapp-pod spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - containerPort: 80 name: web volumeMounts: - name: myappdata mountPath: /usr/share/nginx/html volumeClaimTemplates: #注意: 它是statefulset.spec.volumeClaimTemplates.
- metadata: name: myappdata spec: accessModes: ["ReadWriteOnce"]
  #storageClassName: “gluster-dynamic” #这是定义存储类的。 resources: requests: storage: 2Gi

#实验中问题总结:
accessModes: [ “ReadWriteOnce” ]
　　#这里需要注意: 你指定模式为RWO，那么你使用kubectl get pv时,必须有RWO权限的pv，因为本例是要创建3个StatefulSet的Pod，因此就需要3个RWO权限的pv，但我测试时，就只有一个pv是RWO的，因此导致创建Pod一直处于Pending状态，而且只有一个！使用kubectl describe pvc PVC_NAME 查看时提示: no persistent volumes available for this claim and no storage class is set（此声明没有可用持久卷,也没有存储类），其实问题已经说的很白了，但没有经验，所以这点要特别注意！！
　　#第二个问题：我后来新增了3个RWO权限的pv，但在NFS上，忘记创建对应的目录了，使用exportfs -avr 也提示了，目录没有找到，但我没仔细看，结果导致我创建Pod时，一直处于ContainerCreating，查看kubectl describe pod myapp-0 看到mount.nfs: mounting 192.168.111.83:/data/volumes/v6 failed, reason given by server: No such file or directory 这样的错误，最后才想到可能是目录没有创建。
　　#第三个问题：我在创建PV时，使用的是k8s集群外部的域名nfs.zcf.com 来指定NFS Server是谁，但我K8s集群内还不能解析集群外域名，也导致了访问超时的问题。
　　#第四个问题：创建serive时总提示ClusterIP是无效值:
　　解决步骤：
　　　　1. 检查配置清单中clusterIP是否有写错.
　　　　2. 检查是否有service同名冲突:
　　　　　　kubectl get svc

#创建statefulset:
#执行创建statefulSet前，需要先手动创建出符合条件的PV，若你已经实现了动态供给存储卷，
#则可不用手动事先创建好PV。
　　kubectl apply -f pod-statefulset.yaml

#查看:
　　kubectl get svc
　　kubectl get [statefulset |sts]
　　kubectl get pvc 　　 #volumeClaimTemplates可动态创建Pod内部的PVC，然后再创建名称空间级的PVC
注:
Pod内容器挂载PV的过程或层级是这样的:
　　容器要挂载网络磁盘---->Pod中要有对应的PVC---->Pod所在的名称空间中要有对于的PVC----->
　　K8s集群中要有对应的PV---->要有输出共享存储的后端服务器上的共享空间
　　而volumeClaimTemplates它可自动创建Pod 和名称空间中的PVC。
　　kubectl get pv
　　kubectl get pods

终端2:
 kubectl  get  pods  -w

终端1:
 kubectl  delete  -f  pod-statefulset.yaml          #删除后,查看终端2上，删除Pod的顺序是否为先删除2，1，0
    #在k8s 1.13.5中测试时，发现：
    #  删除时，似乎没有顺序:
    kubect  get  pod  -w   -l  app=myapp-pod
        myapp-1   1/1   Terminating   0     31s
        myapp-0   1/1   Terminating   0     34s
        myapp-2   1/1   Terminating   0     28s
        myapp-1   0/1   Terminating   0     33s
        myapp-2   0/1   Terminating   0     31s
        myapp-0   0/1   Terminating   0     37s
        myapp-1   0/1   Terminating   0     41s
        myapp-1   0/1   Terminating   0     41s
        myapp-0   0/1   Terminating   0     47s
        myapp-0   0/1   Terminating   0     47s
        myapp-2   0/1   Terminating   0     41s
        myapp-2   0/1   Terminating   0     41s
                        
终端1:
 kubectl   apply  -f   pod-statefulset.yaml   #查看创建Pod的过程是否为先0，1，2
   #此测试是正常的:
    myapp-0   0/1   Pending   0     0s
    myapp-0   0/1   Pending   0     0s
    myapp-0   0/1   ContainerCreating   0     0s
    myapp-0   1/1   Running   0     3s
    myapp-1   0/1   Pending   0     0s
    myapp-1   0/1   Pending   0     0s
    myapp-1   0/1   ContainerCreating   0     0s
    myapp-1   1/1   Running   0     3s
    myapp-2   0/1   Pending   0     0s
    myapp-2   0/1   Pending   0     0s
    myapp-2   0/1   ContainerCreating   0     0s
    myapp-2   1/1   Running   0     2s


 kubectl  describe  pods  myapp-2  #查看myapp-2是否依然绑定PV-2,而且当你删除pod后，kubectl  get  pv，也会发现,Retain策略是不会释放绑定关系的.
 
#statefulSet的域名结构为:
pod_name.service_name.namespace_name.svc.cluster.local
如:
    上例中创建了三个Pod,其中一个叫myapp-0
    myapp-0.myapp.default.svc.cluster.local

#对statefulSet做扩缩容:
#扩容:
  kubectl  scale  sts  myapp  --replicas=5
    #注意:
    #   在定义StatefulSet时，Pod的模板中指定自动创建pvc，并关联可用PV时，选择可用大小为1Gi，我期望时,它自动关联时,选择最匹配的，但事实似乎并非如此。
    #   查看
    # kubectl get pv
    NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                       STORAGECLASS   REASON   AGE
    pv01   1Gi        RWO,RWX        Retain           Available                                                       87m
    pv02   2Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-3                           87m
    pv03   5Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-4                           87m      #明明有一个1Gi的，它没有选择，而是选择了5Gi的
    pv04   10Gi       ROX,RWX        Retain           Available                                                       87m
    pv05   20Gi       ROX,RWX        Retain           Available                                                       87m
    pv06   1Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-0                           87m
    pv07   1Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-1                           87m
    pv08   2Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-2                           87m
            

终端2:
    kubectl  get  pods  -w          #当执行扩容Pod后, 会看到先创建myapp-3,然后是myapp-4

#缩容:
    kubectl  patch  sts  myapp  -p  ‘{"spec":{"replicas":2}}’

终端2:
    kubectl  get  pods  -w          #依然查看其缩容的过程，在缩容时,竟然是按顺序的，4，3，2
    myapp-4   1/1   Terminating   0     5m41s
    myapp-4   0/1   Terminating   0     5m43s
    myapp-4   0/1   Terminating   0     5m53s
    myapp-4   0/1   Terminating   0     5m53s
    myapp-3   1/1   Terminating   0     5m56s
    myapp-3   0/1   Terminating   0     5m57s
    myapp-3   0/1   Terminating   0     5m58s
    myapp-3   0/1   Terminating   0     5m58s
    myapp-2   1/1   Terminating   0     8m41s
    myapp-2   0/1   Terminating   0     8m43s
    myapp-2   0/1   Terminating   0     8m49s

#statefulSet的更新策略:
　　kubectl explain sts.spec.updateStrategy.rollingUpdate
　　　　partition: 这种更新策略的含义是, 若当前statefulSet的副本数为5个，则Pod名为pod-0~pod-4，那么此时
　　　　　　定义partition=4, 就意味着我要更新大于等于4的Pod，而只有pod-4的ID 4 是大于等于4的，所以
　　　　　　只有pod-4会被更新，其它不会，这就是金丝雀更新。若后期发现pod-4更新后，工作一切正常，
　　　　　　那么就可以调整partition=0，这样只要大于等于0的pod ID都将被更新。

#修改滚动更新策略，查看效果
　　kubectl patch sts myapp -p ‘{"spec":{"updateStrategy":{"rollingUpdate":{"partition":4}}}}’
　　 #注:
　　在打补丁时，若对象为list类型，则需要使用"[]",来指明其下标，如: containers[0],就是第一个容器.

kubectl  describe  sts  myapp      #查看其滚动更新策略中partition的值是否修改为4了。
#在k8s 1.13.5中查看如下:
    .......
    Replicas:           824638453880 desired | 5 total
    Update Strategy:    RollingUpdate
      Partition:        824638454284
    .......
 #但通过kubectl  get  sts  myapp  -o  yaml  查看，就可以看到，已经修改为4了。
    .........
      updateStrategy:
        rollingUpdate:
          partition: 4
        type: RollingUpdate
   .......

#以上statefulSet的更新策略已经修改好了，接着来修改pod的镜像为新版镜像，来查看其滚动更新的
　　kubectl set image sts/myapp myapp=ikubernetes/myapp:v2

#查看:
　　kubectl get sts -o wide 　　 #查看statefulSet控制器层面的容器镜像是否修改成功了。

　　kubectl get pods myapp-4 -o yaml 　　 #查看statefulSet控制器下myapp-4这个容器的state(当前运行状态信息)中image是否修改成功了.
　　kubectl get pods myapp-3 -o yaml 　　 #查看其image应该是没有改变的

终端2:
　　kubectl get pods -w 　　 #当修改更新策略后，这里将可以看到滚动更新的效果了。

终端1:
　　kubectl patch sts myapp -p ‘{"spec":{"updateStrategy":{"rollingUpdate":{"partition":0}}}}’
　　#由于上面已经跟新了镜像，当这里修改了更新策略后，马上就会触发滚动更新！！需要注意！！
　　注意:
　　　　statefulSet在实际使用中还是需要谨慎！

附上一张PVC和PV的关系图:

　　 K8s StatfulSet使用总结