目錄
- 正文
- StatefulSet 的設計理解
- Service 如何被訪問
- Headless Service 對應的 YAML文件
- StatefulSet 的 YAML 文件
- 解析一下 Pod 對應的 Headless Service
正文
Deployment認為，一個應用的所有 Pod，是完全一樣的。所以，它們互相之間沒有順序，也無所謂運行在哪臺宿主機上。需要的時候，Deployment 就可以通過 Pod 模板創建新的 Pod；不需要的時候，Deployment 就可以“殺掉”任意一個 Pod。
但是，在實際的場景中，并不是所有的應用都可以滿足這樣的要求。
尤其是分布式應用，它的多個實例之間，往往有依賴關系，比如：主從關系、主備關系。
還有就是數據存儲類應用，它的多個實例，往往都會在本地磁盤上保存一份數據。而這些實例一旦被殺掉，即便重建出來，實例與數據之間的對應關系也已經丟失，從而導致應用失敗。
所以，這種實例之間有不對等關系，以及實例對外部數據有依賴關系的應用，就被稱為“有狀態應用”（Stateful Application）。
容器技術誕生后，大家很快發現，它用來封裝“無狀態應用”（Stateless Application），尤其是 Web 服務，非常好用。但是，一旦你想要用容器運行“有狀態應用”，其困難程度就會直線上升。而且，這個問題解決起來，單純依靠容器技術本身已經無能為力，這也就導致了很長一段時間內，“有狀態應用”幾乎成了容器技術圈子的“忌諱”，大家一聽到這個詞，就紛紛搖頭。
得益于“控制器模式”的設計思想，Kubernetes 項目很早就在 Deployment 的基礎上，擴展出了對“有狀態應用”的初步支持。這個編排功能，就是：StatefulSet。
StatefulSet 的設計理解
StatefulSet 的設計其實非常容易理解。它把真實世界里的應用狀態，抽象為了兩種情況：
- 拓撲狀態。這種情況意味著，應用的多個實例之間不是完全對等的關系。這些應用實例，必須按照某些順序啟動，比如應用的主節點 A 要先于從節點 B 啟動。而如果你把 A 和 B 兩個 Pod 刪除掉，它們再次被創建出來時也必須嚴格按照這個順序才行。并且，新創建出來的 Pod，必須和原來 Pod 的網絡標識一樣，這樣原先的訪問者才能使用同樣的方法，訪問到這個新 Pod。
- 存儲狀態。這種情況意味著，應用的多個實例分別綁定了不同的存儲數據。對于這些應用實例來說，Pod A 第一次讀取到的數據，和隔了十分鐘之后再次讀取到的數據，應該是同一份，哪怕在此期間 Pod A 被重新創建過。這種情況最典型的例子，就是一個數據庫應用的多個存儲實例。
所以，StatefulSet 的核心功能，就是通過某種方式記錄這些狀態，然后在 Pod 被重新創建時，能夠為新 Pod 恢復這些狀態。
在開始講述 StatefulSet 的工作原理之前，我就必須先為你講解一個 Kubernetes 項目中非常實用的概念：Headless Service。
我在和你一起討論 Kubernetes 架構的時候就曾介紹過，Service 是 Kubernetes 項目中用來將一組 Pod 暴露給外界訪問的一種機制。比如，一個 Deployment 有 3 個 Pod，那么我就可以定義一個 Service。然后，用戶只要能訪問到這個 Service，它就能訪問到某個具體的 Pod。
Service 如何被訪問
那么，這個 Service 又是如何被訪問的呢？
第一種方式，是以 Service 的 VIP（Virtual IP，即：虛擬 IP）方式。比如：當我訪問 10.0.23.1 這個 Service 的 IP 地址時，10.0.23.1 其實就是一個 VIP，它會把請求轉發到該 Service 所代理的某一個 Pod 上。這里的具體原理，我會在后續的 Service 章節中進行詳細介紹。
第二種方式，就是以 Service 的 DNS 方式。比如：這時候，只要我訪問“my-svc.my-namespace.svc.cluster.local”這條 DNS 記錄，就可以訪問到名叫 my-svc 的 Service 所代理的某一個 Pod。
而在第二種 Service DNS 的方式下，具體還可以分為兩種處理方法：
第一種處理方法，是 Normal Service。這種情況下，你訪問“my-svc.my-namespace.svc.cluster.local”解析到的，正是 my-svc 這個 Service 的 VIP，后面的流程就跟 VIP 方式一致了。
而第二種處理方法，正是 Headless Service。這種情況下，你訪問“my-svc.my-namespace.svc.cluster.local”解析到的，直接就是 my-svc 代理的某一個 Pod 的 IP 地址。可以看到，這里的區別在于，Headless Service 不需要分配一個 VIP，而是可以直接以 DNS 記錄的方式解析出被代理 Pod 的 IP 地址。
那么，這樣的設計又有什么作用呢？ 想要回答這個問題，我們需要從 Headless Service 的定義方式看起。
Headless Service 對應的 YAML文件
下面是一個標準的 Headless Service 對應的 YAML 文件：
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
可以看到，所謂的 Headless Service，其實仍是一個標準 Service 的 YAML 文件。只不過，它的 clusterIP 字段的值是：None，即：這個 Service，沒有一個 VIP 作為“頭”。這也就是 Headless 的含義。所以，這個 Service 被創建后并不會被分配一個 VIP，而是會以 DNS 記錄的方式暴露出它所代理的 Pod。
而它所代理的 Pod，依然是采用 Label Selector 機制選擇出來的，即：所有攜帶了 app=nginx 標簽的 Pod，都會被這個 Service 代理起來。
當你按照這樣的方式創建了一個 Headless Service 之后，它所代理的所有 Pod 的 IP 地址，都會被綁定一個這樣格式的 DNS 記錄，如下所示：<pod-name>.<svc-name>.<namespace>.svc.cluster.local
這個 DNS 記錄，正是 Kubernetes 項目為 Pod 分配的唯一的“可解析身份”（Resolvable Identity）。
有了這個“可解析身份”，只要你知道了一個 Pod 的名字，以及它對應的 Service 的名字，你就可以非常確定地通過這條 DNS 記錄訪問到 Pod 的 IP 地址。
那么，StatefulSet 又是如何使用這個 DNS 記錄來維持 Pod 的拓撲狀態的呢？
StatefulSet 的 YAML 文件
為了回答這個問題，現在我們就來編寫一個 StatefulSet 的 YAML 文件，如下所示：
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9.1
ports:
- containerPort: 80
name: web
這個 YAML 文件，和我們在前面文章中用到的 nginx-deployment 的唯一區別，就是多了一個 serviceName=nginx 字段。
這個字段的作用，就是告訴 StatefulSet 控制器，在執行控制循環（Control Loop）的時候，請使用 nginx 這個 Headless Service 來保證 Pod 的“可解析身份”。
所以，當你通過 kubectl create 創建了上面這個 Service 和 StatefulSet 之后，就會看到如下兩個對象：
$ kubectl create -f svc.yaml $ kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None <none> 80/TCP 10s $ kubectl create -f statefulset.yaml $ kubectl get statefulset web NAME DESIRED CURRENT AGE web 2 1 19s
查看StatefulSet 的 Events 這些信息
$ kubectl get pods -w -l app=nginx NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 19s web-1 0/1 Pending 0 0s web-1 0/1 Pending 0 0s web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 20s
通過上面這個 Pod 的創建過程，我們不難看到，StatefulSet 給它所管理的所有 Pod 的名字，進行了編號，編號規則是：-。
而且這些編號都是從 0 開始累加，與 StatefulSet 的每個 Pod 實例一一對應，絕不重復。
更重要的是，這些 Pod 的創建，也是嚴格按照編號順序進行的。比如，在 web-0 進入到 Running 狀態、并且細分狀態（Conditions）成為 Ready 之前，web-1 會一直處于 Pending 狀態。
當這兩個 Pod 都進入了 Running 狀態之后，你就可以查看到它們各自唯一的“網絡身份”了。
我們使用 kubectl exec 命令進入到容器中查看它們的 hostname：
$ kubectl exec web-0 -- sh -c 'hostname' web-0 $ kubectl exec web-1 -- sh -c 'hostname' web-1
可以看到，這兩個 Pod 的 hostname 與 Pod 名字是一致的，都被分配了對應的編號。接下來，我們再試著以 DNS 的方式，訪問一下這個 Headless Service:
$ kubectl run -i –tty –image busybox dns-test –restart=Never –rm /bin/sh
解析一下 Pod 對應的 Headless Service
通過這條命令，我們啟動了一個一次性的 Pod，因為–rm 意味著 Pod 退出后就會被刪除掉。然后，在這個 Pod 的容器里面，我們嘗試用 nslookup 命令，解析一下 Pod 對應的 Headless Service：
$ kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh $ nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-0.nginx Address 1: 10.244.1.7 $ nslookup web-1.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-1.nginx Address 1: 10.244.2.7
從 nslookup 命令的輸出結果中，我們可以看到，在訪問 web-0.nginx 的時候，最后解析到的，正是 web-0 這個 Pod 的 IP 地址；而當訪問 web-1.nginx 的時候，解析到的則是 web-1 的 IP 地址。
這時候，如果你在另外一個 Terminal 里把這兩個“有狀態應用”的 Pod 刪掉,然后，再在當前 Terminal 里 Watch 一下這兩個 Pod 的狀態變化，就會發現一個有趣的現象
$ kubectl get pod -w -l app=nginx NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2s web-1 0/1 Pending 0 0s web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 32s
可以看到，當我們把這兩個 Pod 刪除之后，Kubernetes 會按照原先編號的順序，創建出了兩個新的 Pod。并且，Kubernetes 依然為它們分配了與原來相同的“網絡身份”：web-0.nginx 和 web-1.nginx。
通過這種嚴格的對應規則，StatefulSet 就保證了 Pod 網絡標識的穩定性。
比如，如果 web-0 是一個需要先啟動的主節點，web-1 是一個后啟動的從節點，那么只要這個 StatefulSet 不被刪除，你訪問 web-0.nginx 時始終都會落在主節點上，訪問 web-1.nginx 時，則始終都會落在從節點上，這個關系絕對不會發生任何變化。
所以，如果我們再用 nslookup 命令，查看一下這個新 Pod 對應的 Headless Service 的話：
$ kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh $ nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-0.nginx Address 1: 10.244.1.8 $ nslookup web-1.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-1.nginx Address 1: 10.244.2.8
我們可以看到，在這個 StatefulSet 中，這兩個新 Pod 的“網絡標識”（比如：web-0.nginx 和 web-1.nginx），再次解析到了正確的 IP 地址（比如：web-0 Pod 的 IP 地址 10.244.1.8）。
通過這種方法，Kubernetes 就成功地將 Pod 的拓撲狀態（比如：哪個節點先啟動，哪個節點后啟動），按照 Pod 的“名字 + 編號”的方式固定了下來。此外，Kubernetes 還為每一個 Pod 提供了一個固定并且唯一的訪問入口，即：這個 Pod 對應的 DNS 記錄。
這些狀態，在 StatefulSet 的整個生命周期里都會保持不變，絕不會因為對應 Pod 的刪除或者重新創建而失效。
不過，相信你也已經注意到了，盡管 web-0.nginx 這條記錄本身不會變，但它解析到的 Pod 的 IP 地址，并不是固定的。這就意味著，對于“有狀態應用”實例的訪問，你必須使用 DNS 記錄或者 hostname 的方式，而絕不應該直接訪問這些 Pod 的 IP 地址。
以上就是k8s編排之StatefulSet知識點詳解一的詳細內容，更多關于k8s編排StatefulSet的資料請關注其它相關文章！
