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

---

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