Kubernetes服務之StatefulSets簡介

StatefulSets在v1.5時還是個beta特性，它取代了v1.4的PetSets特性。PetSets的用戶可以參考v1.5的升級指導，將正在運行的PeetSets升級到StatefulSets。
　　StatefulSet是一個給Pod提供唯一標志的控制器，它可以保證部署和擴展的順序。

使用StatefulSet

　　當應用有以下任意要求時，StatefulSet的價值就體現出來了。
　　　● 穩定的、唯一的網絡標識。
　　　● 穩定的、持久化的存儲。
　　　● 有序的、優雅的部署和擴展。
　　　● 有序的、優雅的刪除和停止。
　　上面提到的點中，在Pod調度時，穩定性和持久化是同一個意思。如果一個應用不需要任何穩定的標識或順序的部署、刪除和擴展，那么你應該使用提供無狀態備份的控制器來部署你的應用。諸如Deployment或者ReplicaSet可能更適合你的無狀態服務需求。

限制

　　　● StatefulSet還是beta版本，Kubernetes v1.5之前不可用。
　　　● 和所有的alpha/beta資源一樣，可以將--runtime-config選項傳遞給apiserver，來禁止StatefulSet。
　　　● 給定Pod的存儲必須是：基於請求存儲等級（Storage Class）的PersistentVolume Provisioner，或者是由管理員預先配置。
　　　● 刪除和（或）減少StatefulSet副本，不會刪除StatefulSet相關的卷。這樣做是為了保證數據安全，比自動的清除StatefulSet相關資源更有價值。
　　　● 當前StatefulSet需要Headless服務來負責Pod的網絡一致性。你需要創建該服務。
　　　● 當前，更新已經存在的StatefulSet需要手動執行。

組件

　　下面的示例演示了StatefulSet的組件。
　　　● 一個Headless服務，名為nginx，用來控制網絡域。
　　　● StatefulSet，名為web，在同一個Pod中起3個nginx容器的副本。
　　　● volumeClaimTemplates使用PV供應商的PV來提供穩定的存儲。

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: gcr.io/google_containers/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
      annotations:
        volume.beta.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Pod一致性

　　StatefulSet Pod有着唯一的一致性，該一致性包含次序（啟動和停止次序）、穩定的網絡一致性，和穩定的網絡。該一致性和Pod緊密相關，無論Pod被調度到哪個node節點上。

次序索引

　　對於有N個副本的StatefulSet，StatefulSet的每個Pod都被分配了一個數字序號，序號在[0，N)的范圍內，並且在Set中是唯一的。

穩定的網絡ID

　　StatefulSet中每個Pod都從StatefulSet的名稱和Pod的序號派生其主機名。組成的hostname的模式為$(statefulset名稱)-$(序號)。上面的例子會創建名為web-0，web-1，web-2。StatefulSet可以以使用Headless服務來控制Pod的域，這個域使用的格式為：$(service name).$(namespace).svc.cluster.local，其中，“cluster.local”指的是集群域。Pod被創建后，每個Pod都會得到一個匹配的DNS子域，格式為$(podname).$(governing service domain)，其中的“governing service”是在StatefulSet中通過serviceName字段來定義的。
　　這里有幾個示例，可以展示StatefulSet的Pod的DNS組成。

Cluster Domain	Service (ns/name)	StatefulSet (ns/name)	StatefulSet Domain	Pod DNS	Pod Hostname
cluster.local	default/nginx	default/web	nginx.default.svc.cluster.local	web-{0..N-1}.nginx.default.svc.cluster.local	web-{0..N-1}
cluster.local	foo/nginx	foo/web	nginx.foo.svc.cluster.local	web-{0..N-1}.nginx.foo.svc.cluster.local	web-{0..N-1}
kube.local	foo/nginx	foo/web	nginx.foo.svc.kube.local	web-{0..N-1}.nginx.foo.svc.kube.local	web-{0..N-1}

　　注意：除非另外的配置，集群域就會被設置為cluster.local。

穩定的存儲

　　Kubernetes為每個VolumeClaimTemplate創建一個PV。在上面的nginx例子中，每個Pod會得到一個PV，該PV的存儲等級(storagee class)為anything，大小為1Gb。當Pod被調度到其他node節點上時，volumeMounts會重新映射對應的PVC。注意，當Pod或者StatefulSet被刪除時，對應的PV和PVC不會被刪除，這個刪除操作必須手動來執行。

部署和擴展

　　　● 對於擁有N個拷貝的StatefulSet，當部署Pod時，它們會被順序地創建（從0到N-1）。
　　　● 當Pod被刪除時，它們被終止的順序是從N-1到0。
　　　● 當對Pod執行擴展操作時，它前面的Pod必須都處於Running和Ready狀態。
　　　● 當Pod被終止時，它所有的successors都必須被完全地關閉。
　　不應該將StatefulSet的pod.Spec.TerminationGracePeriodSeconds值設置為0，因為該操作不安全，強烈不建議使用。若需要更深層次的解釋，請參考強制刪除StatefulSet Pod。
　　當創建了上面的nginx示例后，會按順序部署三個Pod，名字依次為web-0、web-1和web-2。web--1在web-0變為Running and Ready之后才會再部署，同理，web-2也會等web-1變為Running and Ready狀態后才部署。如果在web-1變為Running and Ready之后，但web-2還沒有啟動之前，此時web-0運行失敗了，那么直到web-0再次成功啟動並變為Running and Ready之前，web-2都不會啟動。
　　如果用戶希望改變上面例子中Pod的個數，比如修改replicas=1，那么web-2首先被終止。直到web-2完全被關閉和刪除后，web-1才會被終止。如果在web-2被終止和完全關閉后，但web-1還沒有被終止之前，此時web-0運行出錯了，那么直到web-0再次變為Running and Ready狀態之后，web-1才會被終止。