正文

Deployment認為，一個應用的所有 Pod，是完全一樣的。所以，它們互相之間沒有順序，也無所謂運行在哪臺宿主機上。需要的時候，Deployment 就可以通過 Pod 模板創(chuàng)建新的 Pod；不需要的時候，Deployment 就可以“殺掉”任意一個 Pod。

但是，在實際的場景中，并不是所有的應用都可以滿足這樣的要求。

尤其是分布式應用，它的多個實例之間，往往有依賴關系，比如：主從關系、主備關系。

還有就是數據存儲類應用，它的多個實例，往往都會在本地磁盤上保存一份數據。而這些實例一旦被殺掉，即便重建出來，實例與數據之間的對應關系也已經丟失，從而導致應用失敗。

所以，這種實例之間有不對等關系，以及實例對外部數據有依賴關系的應用，就被稱為“有狀態(tài)應用”（Stateful Application）。

容器技術誕生后，大家很快發(fā)現，它用來封裝“無狀態(tài)應用”（Stateless Application），尤其是 Web 服務，非常好用。但是，一旦你想要用容器運行“有狀態(tài)應用”，其困難程度就會直線上升。而且，這個問題解決起來，單純依靠容器技術本身已經無能為力，這也就導致了很長一段時間內，“有狀態(tài)應用”幾乎成了容器技術圈子的“忌諱”，大家一聽到這個詞，就紛紛搖頭。

得益于“控制器模式”的設計思想，Kubernetes 項目很早就在 Deployment 的基礎上，擴展出了對“有狀態(tài)應用”的初步支持。這個編排功能，就是：StatefulSet。

StatefulSet 的設計理解

StatefulSet 的設計其實非常容易理解。它把真實世界里的應用狀態(tài)，抽象為了兩種情況：

• 拓撲狀態(tài)。這種情況意味著，應用的多個實例之間不是完全對等的關系。這些應用實例，必須按照某些順序啟動，比如應用的主節(jié)點 A 要先于從節(jié)點 B 啟動。而如果你把 A 和 B 兩個 Pod 刪除掉，它們再次被創(chuàng)建出來時也必須嚴格按照這個順序才行。并且，新創(chuàng)建出來的 Pod，必須和原來 Pod 的網絡標識一樣，這樣原先的訪問者才能使用同樣的方法，訪問到這個新 Pod。
• 存儲狀態(tài)。這種情況意味著，應用的多個實例分別綁定了不同的存儲數據。對于這些應用實例來說，Pod A 第一次讀取到的數據，和隔了十分鐘之后再次讀取到的數據，應該是同一份，哪怕在此期間 Pod A 被重新創(chuàng)建過。這種情況最典型的例子，就是一個數據庫應用的多個存儲實例。

所以，StatefulSet 的核心功能，就是通過某種方式記錄這些狀態(tài)，然后在 Pod 被重新創(chuàng)建時，能夠為新 Pod 恢復這些狀態(tài)。

在開始講述 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，它會把請求轉發(fā)到該 Service 所代理的某一個 Pod 上。這里的具體原理，我會在后續(xù)的 Service 章節(jié)中進行詳細介紹。

第二種方式，就是以 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 地址?？梢钥吹剑@里的區(qū)別在于，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 被創(chuàng)建后并不會被分配一個 VIP，而是會以 DNS 記錄的方式暴露出它所代理的 Pod。

而它所代理的 Pod，依然是采用 Label Selector 機制選擇出來的，即：所有攜帶了 app=nginx 標簽的 Pod，都會被這個 Service 代理起來。

當你按照這樣的方式創(chuàng)建了一個 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 的拓撲狀態(tài)的呢？

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 的唯一區(qū)別，就是多了一個 serviceName=nginx 字段。

這個字段的作用，就是告訴 StatefulSet 控制器，在執(zhí)行控制循環(huán)（Control Loop）的時候，請使用 nginx 這個 Headless Service 來保證 Pod 的“可解析身份”。

所以，當你通過 kubectl create 創(chuàng)建了上面這個 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 的創(chuàng)建過程，我們不難看到，StatefulSet 給它所管理的所有 Pod 的名字，進行了編號，編號規(guī)則是：-。

而且這些編號都是從 0 開始累加，與 StatefulSet 的每個 Pod 實例一一對應，絕不重復。

更重要的是，這些 Pod 的創(chuàng)建，也是嚴格按照編號順序進行的。比如，在 web-0 進入到 Running 狀態(tài)、并且細分狀態(tài)（Conditions）成為 Ready 之前，web-1 會一直處于 Pending 狀態(tài)。

當這兩個 Pod 都進入了 Running 狀態(tài)之后，你就可以查看到它們各自唯一的“網絡身份”了。

我們使用 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 里把這兩個“有狀態(tài)應用”的 Pod 刪掉,然后，再在當前 Terminal 里 Watch 一下這兩個 Pod 的狀態(tài)變化，就會發(fā)現一個有趣的現象

$ 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 會按照原先編號的順序，創(chuàng)建出了兩個新的 Pod。并且，Kubernetes 依然為它們分配了與原來相同的“網絡身份”：web-0.nginx 和 web-1.nginx。

通過這種嚴格的對應規(guī)則，StatefulSet 就保證了 Pod 網絡標識的穩(wěn)定性。

比如，如果 web-0 是一個需要先啟動的主節(jié)點，web-1 是一個后啟動的從節(jié)點，那么只要這個 StatefulSet 不被刪除，你訪問 web-0.nginx 時始終都會落在主節(jié)點上，訪問 web-1.nginx 時，則始終都會落在從節(jié)點上，這個關系絕對不會發(fā)生任何變化。

所以，如果我們再用 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 的拓撲狀態(tài)（比如：哪個節(jié)點先啟動，哪個節(jié)點后啟動），按照 Pod 的“名字 + 編號”的方式固定了下來。此外，Kubernetes 還為每一個 Pod 提供了一個固定并且唯一的訪問入口，即：這個 Pod 對應的 DNS 記錄。

這些狀態(tài)，在 StatefulSet 的整個生命周期里都會保持不變，絕不會因為對應 Pod 的刪除或者重新創(chuàng)建而失效。

不過，相信你也已經注意到了，盡管 web-0.nginx 這條記錄本身不會變，但它解析到的 Pod 的 IP 地址，并不是固定的。這就意味著，對于“有狀態(tài)應用”實例的訪問，你必須使用 DNS 記錄或者 hostname 的方式，而絕不應該直接訪問這些 Pod 的 IP 地址。

以上就是k8s編排之StatefulSet知識點詳解一的詳細內容，更多關于k8s編排StatefulSet的資料請關注腳本之家其它相關文章！

最新評論