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

【雨歌】發表於2020-09-11
筆記

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

該命令輸出內容如下圖，

describe-pod

各部分說明：

  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-status-trans

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 部分如下圖，

liveness-probe

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 類似。阿里雲上配置就緒檢查如圖所示：

aliyun-readiness-probe

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

  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（故障恢復）等能力。我們將在接下來的文章瞭解控制器。

[轉載請註明出處]
作者：雨歌
歡迎關注作者公眾號：半路雨歌，檢視更多技術乾貨文章
qrcode

相關文章