Kubernetes筆記（五）：了解Pod（容器組）

Kubernetes 中， 容器總是以 Pod（容器組）的方式進行調度與運行。因此對 Pod 的理解與掌握是學習 Kubernetes 的基礎。

理解 Pod

Pod（容器組）是 Kubernetes 中最小的調度單元，每一個Pod都是某個應用程序的一個運行實例。以前我們的 Web 應用都是以 Tomcat 等 Web 容器進程的形式運行在操作系統中，在 Kubernetes 中，我們需要將 Web 應用打成鏡像，以容器的方式運行在 Pod 中。

Kubernetes 不會直接管理容器，而是通過 Pod 來管理。一個Pod包含如下內容：

1. 一個或多個容器， 一般是一個，除非多個容器緊密耦合共享資源才放在一個 Pod 中；
2. 共享的存儲資源（如數據卷），一個 Pod 中的容器是可以共享存儲空間的；
3. 一個共享的 IP 地址，Pod 中容器之間可以通過 localhost:port 彼此訪問；
4. 定義容器該如何運行的選項。

Pod 中的容器可包括兩種類型：

1. 工作容器：就是我們通常運行服務進程的容器
2. 初始化容器：完成一些初始化操作的容器，初始化容器在工作容器之前運行，所有的初始化容器成功執行后，才開始啟動工作容器

管理 Pod

創建 Pod

在 Kubernetes 中，我們一般不直接創建 Pod，而是通過控制器來調度管理（Deployment，StatefulSet，DaemonSet 等），這里為了便於了解，先通過 yaml 配置文件的方式定義 Pod 來直接創建 Pod。定義配置文件 pod-test.yaml 如下，

apiVersion: v1
kind: Pod
metadata:
  name: pod-test  # pod 名稱
  namespace: default # pod 創建的 namespace
spec:
  containers:     # pod 中容器定義
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
      hostPort: 8081
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  restartPolicy: OnFailure # 重啟策略
  volumes:                 # 數據卷定義
  - name: workdir
    hostPath:
      path: /tmp
      type: Directory

其中 spec 部分的 containers 定義了該 Pod 中運行的容器，從 containers 的復數形式也可以看出一個 Pod 中是可以運行多個容器的。

執行 kubectl create 或 kubectl apply 命令創建 Pod，

[root@kmaster test]# kubectl create -f pod-test.yaml

或

[root@kmaster test]# kubectl apply -f pod-test.yaml

該 Pod 創建后將會拉取一個最新的 nginx 鏡像，運行一個 nginx 容器，並將容器的 80 端口映射到宿主機的 8081 端口。

查看 Pod

可使用 kubectl get pods 命令查看當前 namesapce 下的所有 Pod，加 Pod 名稱查看具體某個 Pod。 如果需要查看 Pod 調度到了哪個節點，可加 -o wide 選項，如果查看 yaml 文件信息則可加 -o yaml 選項， 如下所示

[root@kmaster test]# kubectl get pods
NAME                           READY   STATUS    RESTARTS   AGE
pod-test                       1/1     Running   0          116s

[root@kmaster test]# kubectl get pods pod-test -o wide
NAME                           READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod-test                       1/1     Running   0          2m19s   10.244.1.42   knode2   <none>           <none>

[root@kmaster test]# kubectl get pods pod-test -o yaml

如果要查看更多的信息，可使用 kubectl describe 命令，

[root@kmaster test]# kubectl describe pod pod-test

該命令輸出內容如下圖，

各部分說明：

1. Status: Pending， 表示 Pod 的整體狀態，當前處於 Pending 狀態；
2. State: Waiting，Pod 中每個容器都有一個自己的狀態 State， 當前容器 nginx 處於 Waiting 狀態，Reason: ContainerCreating 表示容器還處於創建中，Ready：False 表明容器還未就緒，還不能對外提供服務；
3. Conditions， 這部分聚合了一些狀態，第一個 Initialized：True，表明已經完成了初始化；而第二個 Ready：False，表明 Pod 還未就緒；ContainersReady：False，表明容器還未就緒； PodScheduled：True，表明 Pod 已經被調度到某個具體的節點上了；
4. 3中不同的狀態之間的轉換都會發生相應的事件，事件類型包括 Normal 與 Warning 兩種， 從上圖可看到一個 Pulling image 的 Normal 事件，表示當前正在拉取 Pod 中容器的鏡像。

當 Pod 在調度或運行中出現問題時，我們都可以使用 kubectl describe 命令來進行排查，通過其中的狀態及事件來判斷問題產生的可能原因。

進入 Pod 容器

通過 kubectl exec 命令可進入 Pod， 類似於 docker exec， 如

# 如果 Pod 中只有一個容器
[root@kmaster test]# kubectl exec -it pod-test bash
root@pod-test:/#

# 如果 Pod 中有多個容器
kubectl exec -it pod-name -c container-name /bin/bash

如果一個 Pod 中有多個容器，則需要通過 -c 指定進入哪個容器。

更新/刪除 Pod

Kubernetes 對 Pod 的更新做了限制，除了更改 Pod 中容器（包括工作容器與初始化容器）的鏡像，以及 activeDeadlineSeconds （對 Job 類型的 Pod 定義失敗重試的最大時間）， tolerations （Pod 對污點的容忍），修改其它部分將不會產生作用，如我們可以嘗試在前面 Pod 定義文檔 pod-test.yaml 中將宿主機端口 8081 改為 8082，重新執行 kubectl apply， 將提示如下錯誤，

[root@kmaster test]# kubectl apply -f pod-test.yaml
The Pod "pod-test" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or `spec.tolerations` (only additions to existing tolerations)

通過 kubectl delete 命令可刪除一個 Pod

[root@kmaster test]# kubectl delete pod pod-test

在 Kubernetes 中，一般不直接創建，更新或刪除單個 Pod，而是通過 Kubernetes 的 Controller（控制器）來管理 Pod，包括 ReplicSet（一般也不直接用，推薦Deployment方式）， Deployment，StatefulSet，DaemonSet 等。

控制器提供如下功能：

1. 水平伸縮，控制運行 Pod 指定個數的副本
2. rollout，即版本更新
3. 故障恢復，當一個節點出現故障，或資源不夠，或進入維護中，控制器會自動在另一個合適的節點調度一個一樣的 Pod，以保障 Pod 以一定的副本數運行

Pod 狀態

Pod狀態並不是容器的狀態，容器的狀態一般包括：

Waiting： 容器的初始狀態，處於 Waiting 狀態的容器，表示仍然有對應的操作在執行，例如：拉取鏡像、應用 Secrets等
Running： 容器處於正常運行的狀態
Terminated： 容器處於結束運行的狀態

而Pod的狀態一般包括：

• Pending： Kubernetes 已經創建並確認該 Pod，可能兩種情況： 1. Pod 還未完成調度（例如沒有合適的節點）；2. 正在從 docker registry 下載鏡像
• Running： 該 Pod 已經被綁定到一個節點，並且該 Pod 所有的容器都已經成功創建，其中至少有一個容器正在運行，或者正在啟動/重啟
• Succeeded：Pod 中的所有容器都已經成功終止，並且不會再被重啟
• Failed：Pod 中的所有容器都已經終止，至少一個容器終止於失敗狀態：容器的進程退出碼不是 0，或者被系統 kill
• Unknown： 因為某些未知原因，不能確定 Pod 的狀態，通常的原因是 master 與 Pod 所在節點之間的通信故障

狀態之間的變遷關系如圖

Pod 剛開始處於 Pending 的狀態，接下來可能會轉換到 Running，也可能轉換到 Unknown，甚至可能轉換到 Failed。然后，當 Running 執行了一段時間之后，它可以轉換到類似像 Successded 或者是 Failed。 當出現 Unknown 這個狀態時，可能由於一些狀態的恢復，它會重新恢復到 Running 或者 Successded 或者是 Failed。

重啟策略

定義 Pod 或工作負載時，可以指定 restartPolicy，可選的值有：

1. Always：默認值，只要退出就重啟
2. OnFailure：失敗退出時（exit code 不為 0）才重啟
3. Never： 永遠不重啟

restartPolicy 作用於 Pod 中的所有容器。kubelete 將在五分鍾內，按照遞延的時間間隔（10s, 20s, 40s ...）嘗試重啟已退出的容器，並在十分鍾后再次啟動這個循環，直到容器成功啟動，或者 Pod 被刪除。在控制器 Deployment/StatefulSet/DaemonSet 中，只支持 Always 這一個選項，不支持 OnFailure 和 Never 選項。

健康檢查

提高應用服務的可用性與穩定性，一般可從兩個方面來進行：

1. 首先是提高應用的可觀測性，如對應用的健康狀態，資源的使用情況，應用日志等可進行實時的觀測
2. 第二是提高應用的可恢復能力，在應用出現故障時，能通過自動重啟等方式進行恢復

Kubernetes 中對 Pod 的健康檢查提供了兩種方式：

1. Readiness probe，就緒探測，用來判斷一個 Pod 是否處於就緒狀態，是否能對外提供相應服務了。當Pod處於就緒狀態時，負載均衡器才會將流量打到這個 Pod，否則將把流量從這個 Pod 上面摘除。
2. Liveness probe，存活探測，用來判斷一個 Pod 是否處於存活狀態，如果一個 Pod 被探測到不處於存活狀態，則由上層判斷機制來處理，如果上層配置重啟策略為 restart always 的話，Pod 就會被重啟。

Liveness probe 適用場景是支持那些可以重新拉起的應用，而 Readiness probe 主要應對的是啟動之后無法立即對外提供服務的應用。

就緒探測、存活探測目前支持三種不同的探測方式：

1. httpGet，通過發送http Get請求來判斷，返回狀態碼在 200-399之間，認為是探測成功
2. Exec，通過執行容器中的一個命令來判斷服務是否正常，如果命令的退出狀態碼為 0，表示成功
3. tcpSocket，通過容器的IP，端口來進行TCP連接檢查，如果TCP連接能被正常建立，則認為成功

以 httpGet 為例，示例配置文件如下，

apiVersion: v1
kind: Pod
metadata:
  name: pod-test
spec:
  containers:
  - # ... 與前同
    - name: workdir
      mountPath: /usr/share/nginx/html
    livenessProbe:
      httpGet:
        path: /
        port: 80
        httpHeaders: # 此處header無意義，僅作示例
        - name: purpose
          value: for-test
      initialDelaySeconds: 2
      periodSeconds: 5
  # ... 與前同

刪除之前的 Pod， 重新創建，使用 kubectl describe 查看，可看到 Events 部分如下圖，

Http 存活探測失敗，狀態碼返回 403， 導致容器重啟。出現這個錯誤的原因是前面做目錄掛載時將 nginx 的 html 目錄掛載到了宿主機的 /tmp 目錄， 而 /tmp 目錄沒有 index.html 文件，導致請求返回403， 在 Pod 調度到的宿主機 /tmp 目錄下創建 index.html 文件即可。

echo '<h1>Hello, K8s!</h1>' > /tmp/index.html

其它 Exec，tcpSocket 探測的配置示例如下（配置在 containers 元素下），

# exec
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

# tcpSocket
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10

支持的參數說明：

• initialDelaySeconds：延遲探測時間，表示 Pod 啟動延遲多久后進行一次檢查，比如某個應用啟動時間如果較長的話，可以設置該值為略大於啟動時間；
• periodSeconds：探測頻率，表示探測的時間間隔，正常默認的這個值是 10 秒；
• timeoutSeconds：超時時間，表示探測的超時時間，當超時時間之內沒有檢測成功，那會認為失敗；
• successThreshold：健康閾值，表示當這個 Pod 從探測失敗到再一次判斷探測成功，所需要的閾值次數，默認情況下是 1 次。如果之前探測失敗，接下來的一次探測成功了，就會認為這個 Pod 是處在一個正常的狀態；
• failureThreshold： 不健康閾值，與 successThreshold 相對，表示認為探測失敗需要重試的次數，默認值是 3。意思是當從一個健康的狀態連續探測到 3 次失敗，就會認為Pod 的狀態處在一個失敗的狀態。

readinessProbe 配置與 livenessProbe 類似。阿里雲上配置就緒檢查如圖所示：

健康檢查的結果分為三種：

1. Success，表示 container 通過了健康檢查，也就是 Liveness probe 或 Readiness probe 是正常的一個狀態；
2. Failure，表示 container 沒有通過健康檢查。針對 Readiness probe，service 層就會將沒有通過 Readiness probe 的 pod 進行摘除，不再分發請求到該 Pod；針對 Liveness probe，就會將這個 pod 進行重新拉起，或者是刪除。
3. Unknown，表示當前的執行機制沒有進行完整的一個執行，可能是因為類似像超時或者像一些腳本沒有及時返回，此時 Readiness probe 或 Liveness probe 不做任何操作，會等待下一次的機制來進行檢查。

健康檢查的一些實踐建議：

1. 如果容器中的進程在碰到問題時可以自己 crash，就不需要執行存活探測，因為 kubelet 可以自動的根據 Pod 的 restartPolicy（重啟策略）來執行對應的動作；
2. 如果希望在容器的進程無響應后，將容器重啟，則指定一個存活探測 livenessProbe，並同時指定 restartPolicy（重啟策略）為 Always 或者 OnFailure；
3. 如果希望在 Pod 確實就緒之后才向其分發服務請求，就指定一個就緒檢查 readinessProbe；
4. 適當調大 exec 探測的超時閾值，因為在容器里面執行一個 shell 腳本，它的執行時長是非常長的，平時在一台虛機上執行可能 3 秒返回的一個腳本在容器里面可能需要 30 秒。可以適當調大超時閾值，來防止由於容器壓力比較大的時候出現偶發的超時；
5. 調整失敗判斷的次數，3 次的默認值有時候可能不一定是最佳實踐，適當調整一下判斷的次數也是一個比較好的方式；
6. 使用 tcpSocket 方式進行判斷的時候，如果遇到了 TLS 的服務，那可能會造成后邊 TLS 里面有很多這種未鑒權的 tcp 連接，這時候需要自己針對業務場景判斷這種連接是否會對業務造成影響。

總結

本文對 Pod 的概念與基本的管理操作，Pod 的狀態變遷機制與重啟策略進行了介紹，對 Pod 的健康檢查進行了詳細的了解。但在 Kubernetes 中，我們一般不直接創建 Pod，而是通過控制器，如Deployment，StatefulSet，DaemonSet， 因為控制器能為我們提供水平伸縮，rollout（版本更新），self-healing（故障恢復）等能力。我們將在接下來的文章了解控制器。

---

[轉載請注明出處]
作者：雨歌
歡迎關注作者公眾號：半路雨歌，查看更多技術干貨文章