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: 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的关系图:
另外，最好的学习平台是githup，它上面有很多别人做好的清单文件，可作为学习的参考。
