K8s StatfulSet使用总结

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

• 稳定且唯一的网络标识符；
• 如: Redis集群, 在Redis集群中，它是通过槽位来存储数据的，假如:第一个节点是0~1000,第二个节点是1001~2000,第三个节点2001~3000...等等，这就使得Redis集群中每个节点要通过ID来标识自己，如: 第二个节点宕机了，重建后它必须还叫第二个节点，或者说第二个节点叫R2，它必须还叫R2，这样在获取1001~2000槽位的数据时，才能找到数据，否则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:
    name: web
  clusterIP: None
  selector:
    app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp
  replicas:
    selector:
       matchLabels:
          app: myapp-pod
    template:
      metadata:
        labels:
            app: myapp-pod
      spec:
        containers:
        -  name: myapp
           image: ikubernetes/myapp:v1
           ports:
           - containerPort:
             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，，
    #在k8s 1.13.5中测试时，发现：
    #  删除时，似乎没有顺序:
    kubect  get  pod  -w   -l  app=myapp-pod
        myapp-   /   Terminating        31s
        myapp-   /   Terminating        34s
        myapp-   /   Terminating        28s
        myapp-   /   Terminating        33s
        myapp-   /   Terminating        31s
        myapp-   /   Terminating        37s
        myapp-   /   Terminating        41s
        myapp-   /   Terminating        41s
        myapp-   /   Terminating        47s
        myapp-   /   Terminating        47s
        myapp-   /   Terminating        41s
        myapp-   /   Terminating        41s

终端1:
 kubectl   apply  -f   pod-statefulset.yaml   #查看创建Pod的过程是否为先0，，
   #此测试是正常的:
    myapp-   /   Pending        0s
    myapp-   /   Pending        0s
    myapp-   /   ContainerCreating        0s
    myapp-   /   Running        3s
    myapp-   /   Pending        0s
    myapp-   /   Pending        0s
    myapp-   /   ContainerCreating        0s
    myapp-   /   Running        3s
    myapp-   /   Pending        0s
    myapp-   /   Pending        0s
    myapp-   /   ContainerCreating        0s
    myapp-   /   Running        2s

 kubectl  describe  pods  myapp-  #查看myapp-2是否依然绑定PV-,而且当你删除pod后，kubectl  get  pv，也会发现,Retain策略是不会释放绑定关系的.

#statefulSet的域名结构为:
pod_name.service_name.namespace_name.svc.cluster.local
如:
    上例中创建了三个Pod,其中一个叫myapp-
    myapp-.myapp.default.svc.cluster.local

#对statefulSet做扩缩容:
#扩容:
  kubectl  scale  sts  myapp  --replicas=
    #注意:
    #   在定义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-                           87m
    pv03   5Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-                           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-                           87m
    pv07   1Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-                           87m
    pv08   2Gi        ROX,RWX        Retain           Bound       default/myappdata-myapp-                           87m

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

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

终端2:
    kubectl  get  pods  -w          #依然查看其缩容的过程，在缩容时,竟然是按顺序的，，，
    myapp-   /   Terminating        5m41s
    myapp-   /   Terminating        5m43s
    myapp-   /   Terminating        5m53s
    myapp-   /   Terminating        5m53s
    myapp-   /   Terminating        5m56s
    myapp-   /   Terminating        5m57s
    myapp-   /   Terminating        5m58s
    myapp-   /   Terminating        5m58s
    myapp-   /   Terminating        8m41s
    myapp-   /   Terminating        8m43s
    myapp-   /   Terminating        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:            desired |  total
    Update Strategy:    RollingUpdate
      Partition:
    .......
 #但通过kubectl  get  sts  myapp  -o  yaml  查看，就可以看到，已经修改为4了。
    .........
      updateStrategy:
        rollingUpdate:
          partition:
        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的关系图:

　　

另外，最好的学习平台是githup，它上面有很多别人做好的清单文件，可作为学习的参考。