PetSet首次在K8S1.4版本中，在1.5更名為StatefulSet。除了改了名字之外，這一API物件並沒有太大變化。

注意：以下內容的驗證環境為CentOS7、K8S版本1.5.2，並部署SkyDNS。

http://blog.csdn.net/liyingke112/article/details/76685794

https://blog.csdn.net/liyingke112/article/details/76914754

https://kubernetes.io/docs/concepts/storage/volumes/

概念

在雲原生應用的體系裡，有下面兩組近義詞；

第一組是無狀態（stateless）、牲畜（cattle）、無名（nameless）、可丟棄（disposable）；

第二組是有狀態（stateful）、寵物（pet）、有名（having name）、不可丟棄（non-disposable）。

無狀態：ReplicationController （最初的），ReplicaSet（下一代ReplicationController），Deployment（最新的，更好的管理ReplicaSet和pod） ，具體看（https://blog.csdn.net/Michaelwubo/article/details/80759388）主要是控制無狀態服務，Pod的名字是隨機設定的，重建後新的Pod名字變了，名字和部署在哪兒都不重要，重要的只是Pod總數。

有狀態：PetSet/StatefulSet

應用場景

有狀態服務：資料庫服務MySQL和PostgreSQL

叢集化管理服務Zookeeper、etcd等有狀態服務。

作為一種比普通容器更穩定可靠的模擬虛擬機器的機制。傳統的虛擬機器正是一種有狀態的寵物，運維人員需要不斷地維護它，容器剛開始流行時，用容器來模擬虛擬機器使用，所有狀態都儲存在容器裡，而這已被證明是非常不安全、不可靠的。使用PetSet/StatefulSet，Pod仍然可以通過漂移到不同節點提供高可用，而儲存也可以通過外掛的儲存來提供高可靠性，PetSet/StatefulSet做的只是將確定的Pod與確定的儲存關聯起來保證狀態的連續性。

特性

pod穩定的唯一網路標識

擁有固定的：pod名稱、主機名、DNS域名等。注意pod的IP地址會變化的。

如果PetSet/StatefulSet名是web，replicas為2，則pod命名：web-0，web-1。並擁有固定的主機名和域名，完整域名格式為pod名.service名.namespace名.svc.域名。

當pod被遷移重新啟動後，將保持原有的pod名稱重新啟動。例如web-0的Pod失敗後，K8s將在叢集中重啟一個同名為web-0的pod。

該域名在叢集內可用。這與k8s service的域名有所區別，帶主機名的域名能定位到某一個pod主機，而service級別的域名只能定位到某一個服務。

通過一種叫HeadlessService的特殊Service來實現的。和普通Service相比，Headless Service沒有Cluster IP，用於為一個叢集內部的每個成員提供一個唯一的DNS名字，用於叢集內部成員之間通訊。

不部署HeadlessService的話，不是使用訪問，但可以使用IP地址訪問。

pod擁有穩定的持久儲存

PetSet/StatefulSet內每一個pod都擁有各自的pvc持久化儲存。具體詳情https://blog.csdn.net/Michaelwubo/article/details/80759605

該特效能更好的支援分散式叢集應用的資料同步，如類似etcd叢集這樣的有狀態應用，節點間是需要進行資料同步的，當etcd叢集的某個pod節點重啟後，依然能夠重新掛載原有的節點資料，重新保持資料複製、同步。

有序啟動pod

PetSet/StatefulSet啟動pod時，按固定的順序去啟動的，其總是優先啟動數字編號更小的Pod。例如：web-0優先於web-1啟動，web-1優先於web-2啟動。

對於啟動順序有要求的有狀態服務來說，該特性是非常重要的。

使用限制

必須部署PV和PVC

    為了讓pod擁有穩定的持久儲存，必須使用持久化儲存PV和PVC，增加了複雜性。詳情請見：https://blog.csdn.net/Michaelwubo/article/details/80759605

若PV使用nfs等無法通過呼叫API來建立儲存的網路儲存，PVC要在建立PetSet/StatefulSet1前靜態建立，如果先建立PetSet/StatefulSet1，而沒有建立PVC的話，將會自動建立PVC，但相關引數無法修改；

若為aws-ebs、vSphere、openstack Cinder等可以通過API呼叫來動態建立儲存的虛擬儲存，PVC除了可以通過靜態的方式建立外，還可以通過StorageClass進行動態建立。

需要注意的是，動態創建出來的PV，預設的回收策略是delete，及在刪除資料的同時，還會把虛擬儲存卷刪除。

刪除或縮容PetSet/StatefulSet不會刪除對應的儲存卷容量。這是為了保證資料的安全，因為對待PetSet/StatefulSet的資料普通的做法比自動回收資源更實用。

必須部署Headless Service

和普通Service相比，Headless Service沒有Cluster IP，在PetSet/StatefulSet中起到pod域名解析功能。

如果沒有部署HeadlessService的話，PetSet/StatefulSet下的pod，無法通過域名進行訪問。

必須手動更新pod

只能通過手動的方式升級PetSet/StatefulSet。

無法使用kubectl edit方式、類似與deployment（kubectl set image）和RC方式升級。能正常使用kubectledit編輯線上yaml檔案，即使重啟pod所在的node節點，也無法生效。

建立時命名規則有要求

    如下面的例子：

        StatefulSet：StatefulSet名稱為lykops-sfs，卷名為pvc

        PV：pv-lykops-sfs-{0,1}

        PVC：pvc-lykops-sfs-{0,1}

    規則如下：

        PVC和PV的命名規則為：資源型別-StatefulSet名稱-副本數序號（從0開始）

建立時PV和PVC的yaml規則有要求

    除了命名規則外，還需要保證訪問accessModes、resources這兩個一樣

    按照以上規則建立後，可以看到PV和PVC能關聯起來

擴容難

    在擴容前，需要先部署好對應的PV和PVC

節點宕機，pod無法切換

當pod所在節點出現宕機，無法切換到其他node上執行。解決辦法是恢復該節點工作。

建立範例

https://blog.csdn.net/Michaelwubo/article/details/80763586

PV

1. cat << EOF > pv-lykops-sfs-0.yaml  
2. apiVersion: v1  
3. kind: PersistentVolume  
4. metadata:  
5.  name: pv-lykops-sfs-0  
6.  labels:  
7.    type: nfs  
8.    app: pv  
9.    version: v1  
10. spec:  
11.  capacity:  
12.    storage: 1Gi  
13.  accessModes:  
14.    - ReadWriteMany  
15.  persistentVolumeReclaimPolicy: Recycle  
16.   nfs:  
17.    path: /mysql/data 
18.    server: 10.30.30.128  
19.    readOnly: false  
20. EOF  
21. kubectl create -f pv-lykops-sfs-0.yaml  

PVC

1. cat << EOF > pvc-lykops-sfs-0.yaml  
2. apiVersion: v1  
3. kind: PersistentVolumeClaim  
4. metadata:  
5.  name: pvc-lykops-sfs-0  
6.  labels:  
7.    type: nfs  
8.    app: pvc  
9.    version: v1  
10. spec:  
11.  accessModes:  
12.    - ReadWriteMany  
13.  resources:  
14.    requests:  
15.      storage: 1Gi  
16. EOF  
17. kubectl create -f pvc-lykops-sfs-0.yaml  

Headless Service

1. cat << EOF >lykops-sfs-headlessservice.yaml  
2. apiVersion: v1   
3. kind: Service   
4. metadata:  
5.  name: lykops-sfs  
6.  labels:  
7.    software: apache  
8.    project: lykops  
9.    app: lykops-sfs  
10.    version: v1  
11. spec:   
12.  ports:   
13.  - port: 80   
14.    name: apache   
15.  clusterIP: None   
16.  selector:   
17.    software: apache  
18.    project: lykops  
19.    app: lykops-sfs  
20.    version: v1  
21. EOF  
22. kubectl create -f lykops-sfs-headlessservice.yaml  

StatefulSet

1. cat << EOF > lykops-sfs.yaml  
2. apiVersion: apps/v1beta1   
3. kind: StatefulSet   
4. metadata:  
5.  name: lykops-sfs  
6.  labels:  
7.    software: apache  
8.    project: lykops  
9.    app: lykops-sfs  
10.    version: v1  
11. spec:  
12.  serviceName: lykops-sfs  
13.  template:  
14.    metadata:  
15.      labels:  
16.        software: apache  
17.        project: lykops  
18.        app: lykops-sfs  
19.        version: v1  
20.        name: lykops-sfs  
21.    spec:  
22.      containers:  
23.      - name: lykops-sfs  
24.        image: hub.c.163.com/library/nginx:latest
25.        ports:  
26.        - containerPort: 80  
27.          name: apache  
28.        volumeMounts:  
29.        - name: pvc  
30.          mountPath: /mnt
31.  volumeClaimTemplates:  
32.   -metadata:  
33.      name: pvc  
34.    spec:  
35.      accessModes:  
36.      - ReadWriteMany  
37.      resources:  
38.        requests:  
39.          storage: 1Gi  
40. EOF  
41. kubectl create -f lykops-sfs.yaml