k8s之StatefulSet介绍（六）

复制有状态的Pod

replicaSet通过一个pod模版创建多个pod副本。这些副本除了它们的名字和IP地址不同外，没有别的差异。如果pod模版里描述了一个关联到特定持久卷声明的数据卷，那么ReplicaSet的所有副本都将共享这个持久卷声明，也就是绑定到同一个持久卷声明。

因为是在pod模版里关联持久卷声明的，又会依据pod模版创建多个副本，则不能对每个副本都指定独立的持久卷声明。所以也不能通过一个ReplicaSet来运行一个每个实例都需要独立存储的分布式数据存储服务，至少通过单个ReplicaSet是做不到的。老实说，之前你学习到的所有API对象都不能提供这样的数据存储服务，还需要一个其他的对象--StatefulSet

 

我们先看不使用StatefulSet的情况下有没有方法实现多个副本有自己的持久卷声明。

三种取巧的方法。

第一种方法，不使用ReplicaSet，使用Pod创建多个pod,每个pod都有独立的持久卷声明。需要手动创建它们，当有的pod消失后（节点故障），需要手动创建它们。因此不是一个好方法。

第二种方法，多个replicaSet ，每个rs只有一个pod副本。但这看起来很笨重，而且没办法扩缩容。

第三种方法，使用同一个ReplicaSet，大家也都挂载同一个持久卷声明，应用内部做好互斥，创建多个data数据目录，每一个pod用一个标记为在用，后面应用不能选被标记为在用的目录。这样做很难保证协调的一点没问题，同时大家用同一个持久卷，读写io将成为整个应用的瓶颈。

 

除了上面的存储需求，集群应用也会要求每一个实例拥有生命周期内唯一标识。pod可以随时被删掉，然后被新的pod替代。当一个ReplicaSet中的pod被替换时，尽管新的pod也可能使用被删除pod数据卷中的数据，但它却是拥有全新主机名和IP的崭新pod.在一些应用中，当启动的实例拥有完全新的网络标识，但还使用旧实例的数据时，很可能引起问题，比如etcd存储服务。

当然也可以创建多个service ,每一个replicaset对应一个service，那么一样很笨重，且显得很低级。辛运的是，Kubernetes为我们提供了这类需求的完美解决方案--StatefulSet.

 

了解StatefulSet

可以创建一个StatefulSet资源代替ReplicaSet来运行这类pod.它们是专门定制的一类应用，这类应用中每一个实例都是不可替代的个体，都拥有稳定的名字和状态。

对比StatefulSet 与 ReplicaSet 或 ReplicationController

RS或RC管理的pod副本比较像牛，它们都是无状态的，任何时候它们都可以被一个全新的pod替换。然后有状态的pod需要不同的方法，当一个有状态的pod挂掉后，这个pod实例需要在别的节点上重建，但是新的实例必须与被替换的实例拥有相同的名称、网络标识和状态。这就是StatefulSet如何管理pod的。

StatefulSet 保证了pod在重新调度后保留它们的标识和状态。它让你方便地扩容、缩容。与RS类似，StatefulSet也会指定期望的副本数，它决定了在同一时间内运行的宠物数。也是依据pod模版创建的，与RS不同的是，StatefulSet 创建的pod副本并不是完全一样的。每个pod都可以拥有一组独立的数据卷（持久化状态）。另外pod的名字都是规律的（固定的），而不是每个新pod都随机获取一个名字。

 

提供稳定的网络标识

StatefulSet 创建的pod的名称，按照从零开始的顺序索引，这个会体现在pod的名称和主机名称上，同样还会体现在pod对应的固定存储上。

有状态的pod与普通的pod不一样的是，有状态的pod有时候需要通过其主机名来定位，而无状态的不需要，因为无状态的都一样，随机选一个就行，但对于有状态的来说，每一个pod都不一样，通常希望操作的是特定的一个。基于这个原因，一个StatefulSet要求你创建一个用来记录每个pod网络标记的headless Service。通过这个Service，每个pod将拥有独立的DNS记录，这样集群里它的伙伴或者客户端就可以通过主机名找到它。比如说一个属于default命名空间，名为foo的控制服务，它的一个pod名称为A-0，那么完整域名为：a-0.foo.default.svc.cluster.local。而在ReplicaSet是行不通的。

此外我们可以在容器中通过dig foo.default.svc.cluster.local对应的SRV记录，获取一个StatefulSet中所有pod的名称.

 

StatefulSet扩缩容的特点

扩容，会按照索引进行

缩容，也会按照索引，删除索引值最大的 pod

缩容StatefulSet任何时候只会操作一个pod实例，所以会很慢，不是因为索引要顺序进行，而是为了避免数据丢失。举例来说，一个分布式存储应用副本数为2，如果同时下线两个，一份数据记录就会丢失。

基于以上原因，StatefulSet在有实例不健康的情况下是不允许进行缩容操作的。一个不健康，你又缩容一个这样相当于两个同时下线。

持久卷的创建和删除

扩容Statefulset增加一个副本，会创建两个或更多的API对象（一个pod和一个与之关联的持久卷声明）。但对于缩容来将，只会删除一个pod，而遗留下之前创建的声明。因为当一个声明被删除后，与之绑定的持久卷就会被回收或删除，其上面的数据就会丢失。基于这个原因，你需要释放特定的持久卷时，需要手动删除对应的持久卷声明。

 

StatefulSet的保障机制。

一个有状态的pod总会被一个完全一致的pod替换（两者相同的名称，主机名和存储等）。这个替换发生在kubernetes发现旧pod不存在时（例如手动删除这个pod）.

那么当Kubernetes不能确定一个pod的状态呢？如果它创建一个完全一致的pod，那系统中就会有两个完全一致的pod在同时运行。这两个pod会绑定到相同的存储，所以这两个相同标记的进程会同时写相同的文件。

为了保证两个拥有相同标记和绑定相同持久卷声明的有状态的pod实例不会同时运行，statefulset遵循at-most-one语义。也就是说一个StatefulSet必须在准确确认一个pod不再运行后，才会去创建它的替换pod。这对如何处理节点故障有很大帮助。具体实现，内部的，暂不深入。

讲了那么多StatefulSet实现有状态pod的好处，下面看看如何创建。

 

我们假设使用gec创建三个pv

 

kind: list
apiVersion: v1
item:
-   apiVersion: v1
　　kind: PersistenVolume
　　metadata:
　　　　name: pv-a
　　spec:
　　　　capacity:
　　　　　　storage: 1Mi
　　　　accessModes:
　　　　-    ReadWriteOnce
　　　　persistenVolumeReclaimPolicy: Recycle  卷被声明释放后，空间会被回收再利用
　　　　gcePersistentDisk:
　　　　　　poName: pv-a
　　　　　　fsType: nfs4
-   apiVersion: v1
　　kind: PersistenVolume
　　metadata:
　　　　name: pv-b
...

 

准备好pv后，我们接下来创建statefulset

 

如我们之前将到的，在部署一个StatefulSet之前，需要创建一个用于在有状态的pod之间提供网络标识的headless Service

 

apiVersion: v1
kind: Service
metadata:
　　name: kubia
spec:
　　clusterIP: None        (StatefulSet的控制Service必须时None即headless模式）
　　selector:
　　　　app: kubia
　　ports:
　　-   name: http
　　　　port: 80

 

创建StatefulSet详单

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
　　name: kubia
spec:
　　serviceName: kubia
　　replicas: 2
　　template:
　　　　metadta:
　　　　　　labels:
　　　　　　　　app: kubia
　　　　spec:
　　　　　　containers:
　　　　　　-   name: kubia
　　　　　　　　image: luksa/kubia-pet
　　　　　　　　ports:
　　　　　　　　-   name: kubia
　　　　　　　　　　containerPort: 8080

             volumeMounts:

　　　　　　　　-   name: data

　　　　　　　　     mountPath: /var/data
　　volumeClaimTemplates:
　　-   metadata:
　　　　name: data
　　　　spec:
　　　　　　resources:
　　　　　　　　requests:
　　　　　　　　　　storage: 1Mi
　　　　　　accessModes:
　　　　　　-    ReadWriteOnce

 

创建：

kubectl create -f kubia-statefulset.yaml

 

列出pod:

kubectl get pod

Name READY

kubia-0 0/1 ...

看到会一个个进行

kubectl get pod

Name READY

kubia-0 1/1 ...

kubia-1 0/1 ...

 

查看pvc

kubectl get pvc

Name STATUS VOlUME

data-kubia-0 Bound pv - c ...

data-kubia-1 Bound pv - a ...

 

可以看到生成的持久卷声明的名称由 volumeClaimTeplate 字段中定义的名称和每个pod的名称组成。

 

现在你的数据存储集群节点都已经运行，可以开始使用它们了。因为之前创建的Service处于headless模式，所以不能通过service来访问你的pod。需要直接连接每个单独的pod来访问（或者创建一个普通的Service，但是这样还是不允许你访问指定的pod）

 

我们来创建一个普通的service如下：

apiVersion: v1
kind: service
metadata:
　　name: kubia-public
spec:
　　selector:
　　　　app: kubia
　　ports:
　　-   port: 80
　　　　targetPort: 8080

 

 

StatefulSet 已经运行起来了，那么我们看下如何更新它的pod模版，让它使用新的镜像。同时你也会修改副本数为3.通常会使用kubectl edit命令来更新StatefulSet

kubectl edit statefulset kubia

你会看到新的pod实例会使用新的镜像运行，那已经存在的两个副本呢？通过他们的寿命可以看出它们没有更新。这是符合预期的。因为，首先StatefulSet更像ReplicaSet，而不是Deployment,所以在模版被修改后，它们不会重启更新，需要手动删除这些副本，然后StatefulSet会根据新的模版重新调度启动它们。

kubectl delete po kubia-0 kubia-1

注意： 从Kubernetes1.7版本开始，statefulSet支持与Deployment和DaemonSet一样的滚动升级。通过kubectl explain 获取StatefulSet的spec.updateStrategy 相关文档来获取更多信息。

 

前面我们提到StatefulSet的保障机制，那么当一个节点故障了，会出现什么情况。

statefulset在明确知道一个pod不再运行之前，它不能或者不应当创建一个替换pod。只有当集群的管理者告诉它这些信息时候，它才能明确知道。为了做到这一点，管理者需要删除这个pod，或者删除整个节点。

当手动停止一个node的网卡，使用kubectl get node，会显示Status notReady

因为控制台不会再收到该节点发送的状态更新，该节点上吗的所有pod状态都会变为Unknown。

当一个pod状态为Unknown时会发生什么

若该节点过段时间正常连接，并且重新汇报它上面的pod状态，那这个pod就会重新被标记为Runing。但如果这个pod的未知状态持续几分钟后（这个时间是可以配置的），这个pod就会自动从节点上驱逐。这是由主节点（kubernetes的控制组件）处理的。它通过删除pod的资源来把它从节点上驱逐。

当kubelet发现这个pod标记为删除状态后，它开始终止运行该pod。在上面的示例中，kubelet已不能与主节点通信（因为网卡断了），这意味着这个pod会一直运行着。查看

kubectl describe po kubia-0

发现status一直为Terminating，原因是NodeLost,在信息中说明的是节点不回应导致不可达。

这时候你想要手动删除pod

kubectl delete po kubia-0

执行完成后，你的想法是会再次运行一个kubia-0

但是kubectl get po会发现kubia-0 状态为 Unknown 并且还是之前那个旧pod ,因为启动时长没变。

为什么会这样？因为在删除pod之前，这个pod已经被标记为删除。这是因为控制组件已经删除了它（把它从节点驱逐）。这时你用kubectl describe po kubia-0 查看状态依然是Terminating。

这时候只能进行强制删除

kubectl delete po kubia-0 --force --grace-period 0

你需要同时使用--force和 --grace-period 0两个选项。然后kubectl 会对你做的事发出

警告信息。如果你再次列举pod，就可以看到一个新的kubia-0 pod被创建出来。

警告： 除非你确认节点不再运行或者不会再可以访问（永远不会再可以访问），否则不要强制删除有状态的pod.