入門 | K8S服務之StatefulSets

StatefulSets在v1.5時仍是個beta特性,它取代了v1.4的PetSets特性。PetSets的用戶能夠參考v1.5的升級指導,將正在運行的PeetSets升級到StatefulSets。 

html

StatefulSet是一個給Pod提供惟一標誌的控制器,它能夠保證部署和擴展的順序。node

使用StatefulSet

當應用有如下任意要求時,StatefulSet的價值就體現出來了。 nginx


   ● 穩定的、惟一的網絡標識。 
   ● 穩定的、持久化的存儲。 
   ● 有序的、優雅的部署和擴展。 
   ● 有序的、優雅的刪除和中止。 

web

上面提到的點中,在Pod調度時,穩定性和持久化是同一個意思。若是一個應用不須要任何穩定的標識或順序的部署、刪除和擴展,那麼你應該使用提供無狀態備份的控制器來部署你的應用。諸如Deployment或者ReplicaSet可能更適合你的無狀態服務需求。api

限制

   ● 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來提供穩定的存儲。app

---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節點上。less

次序索引

對於有N個副本的StatefulSet,StatefulSet的每一個Pod都被分配了一個數字序號,序號在[0,N)的範圍內,而且在Set中是惟一的。dom

穩定的網絡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 DomainService (ns/name)StatefulSet (ns/name)StatefulSet DomainPod DNSPod Hostnamecluster.localdefault/nginxdefault/webnginx.default.svc.cluster.localweb-{0..N-1}.nginx.default.svc.cluster.localweb-{0..N-1}cluster.localfoo/nginxfoo/webnginx.foo.svc.cluster.localweb-{0..N-1}.nginx.foo.svc.cluster.localweb-{0..N-1}kube.localfoo/nginxfoo/webnginx.foo.svc.kube.localweb-{0..N-1}.nginx.foo.svc.kube.localweb-{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纔會被終止。

相關文章
相關標籤/搜索