Pod 是 kubernetes 中的基本單位，容器本身不會直接分配到主機上，而是會封裝到 Pod 對象中。一個 Pod 通常表示單個應用程序，有一個或者多個相關的容器組成，這些容器的生命周期都是相同的，而且會作為一個整體在同一個 node 上調度起來，這些容器共享環(huán)境、存儲卷和 IP 控件。盡管 Pod 中可能存在多個容器，但是在 kubernetes 中是以 Pod 為最小單位進行調度、伸縮并共享資源、管理生命周期。

Pod 的基本操作

我們先來看一下 Pod 的創(chuàng)建、查詢、修改和刪除操作。

創(chuàng)建 Pod

# expod.yml

apiVersion: v1
kind: Pod
metadata:
  name: expod
spec:
  containers:
  - name: expod-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c']
    args: ['echo "Hello Kubernetes!"; sleep 3600']

簡單的模板含義：

• apiVersion 表示 API 版本，v1 表示使用 kubernetes API 的穩(wěn)定版本。
• kind 表示要創(chuàng)建的資源對象。
• metadata 表示該資源對象的元數據。可以擁有多個元數據，name 表示當前資源的名稱。
• spec 表示該資源對象的具體設置。其中 containers 表示容器的集合，我們這里設置了一個簡單的容器。name: 要創(chuàng)建的容器名稱。image: 容器的鏡像地址。imagePullPolicy: 鏡像的下載策略，支持3種策略：Always、Never、IfNotPresent。command: 容器的啟動命令列表，不配置的話就使用鏡像內部的命令。args: 啟動參數列表

運行命令，創(chuàng)建 Pod。

kubectl Apply -f expod.yml

創(chuàng)建成功后，查詢一下當前運行的所有 Pod

kubectl get pod

 

查詢 Pod

Pod 信息查詢的命令有多個，查詢的詳細度也不一樣：

• 查詢默認命名空間 default 的所有 Pod

kubectl get pod

• 查詢指定 Pod 的信息

kubectl get pod expod

• 對 Pod 狀態(tài)進行持續(xù)監(jiān)控

kubectl get pod -w

• 顯示更多概要信息

kubectl get pod -o wide

 

比簡要信息多顯示集群內 IP 地址、所屬 node

• 按照指定格式輸出 Pod 信息

kubectl get pod expod -o yaml

• 最詳細信息顯示，包括 Event

kubectl describe pod expod

這是最常用的資源信息查詢命令，顯示信息比較全面，包括資源的基本信息、容器信息、準備情況、存儲卷信息和相關的事件列表。在資源部署的時候，如果遇到問題，可以用這個命令查詢詳情，分析錯誤原因。

• 查詢Pod的日志信息

kubectl logs Pod名稱

修改 Pod

修改已存在的 Pod 屬性可以使用 replace 命令

kubectl replace -f pod的yaml文件

我們修改一下前面創(chuàng)建 Pod 的 yaml 文件，把輸出 “Hello Kubernetes!" 修改為 "Hello Kubernetes replaced!"。

# expod.yml

apiVersion: v1
kind: Pod
metadata:
  name: expod
spec:
  containers:
  - name: expod-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c']
    args: ['echo "Hello Kubernetes replaced!"; sleep 3600']

Pod 有很多屬性是無法修改的，如果一定要修改，需要加上 --force 參數，相當于重建 Pod。

kubectl replace -f expod.yml --force

可以看一下命令輸出結果

 

先刪除了 expod 這個 Pod，然后創(chuàng)建一個替換的 expod 的 Pod，我們再查看以下 Pod 的日志。

kubectl logs expod

 

可以看到 Pod 信息已經修改了。

刪除 Pod

刪除 Pod 非常簡單，執(zhí)行以下命令即可：

kubectl delete pod expod

如果我們是通過 Pod 模板文件創(chuàng)建的，推薦使用基于模板文件的刪除命令。

kubectl delete -f expod.yml

Pod 與容器

我們可能已經發(fā)現了，Pod 模板和 Docker-Compose 非常相似，但是 Pod 模板可以配置的參數更多、更復雜。

Pod 創(chuàng)建容器的方式

在 Pod 模板的 Containers 部分，指明容器的部署方式，在部署的過程中會轉換成對應的容器運行命令，就以我們最開始的 Pod 模板為例:

apiVersion: v1
kind: Pod
metadata:
  name: expod
spec:
  containers:
  - name: expod-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c']
    args: ['echo "Hello Kubernetes!"; sleep 3600']

在 kubernetes 進行調度的時候，會執(zhí)行如下命令：

docker run --name expod-container busybox sh -c 'echo "Hello Kubernetes!"; sleep 3600'

command 和 args 的設置會分別覆蓋 Docker 鏡像中定義的 EntryPoint 與 CMD。

Pod 組織容器的方式

Pod 是由各個容器組成的一個整體，同時調度到某臺 Node 上，容器之間可以共享資源、網絡環(huán)境和依賴，并擁有相同的生命周期。

容器如何組成一個 Pod

每個 Pod 都包含一個或一組密切相關的業(yè)務容器，但是還有一個成為”根容器“的特殊 Pause 容器。Pause 容器是屬于 Kubernetes 的一部分，如果一組業(yè)務容器作為一個整體，我們很難對整個容器進行判斷，假如一個業(yè)務組容器當中的某個容器掛載了能代表整個 Pod 都掛載了嗎？如果引入一個和業(yè)務無關的 Pause 容器，用它作為 Pod 的根容器，用它的狀態(tài)代表整組容器的狀態(tài)，就能解決這個問題。而且一個 Pod 中的所有容器都共享 Pause 容器的 IP 地址及其掛載的存儲卷，這樣也簡化了容器之間的通信和數據共享問題，類似于 Docker 容器網絡的 Container 模式。

我們在開始創(chuàng)建的 Pod，可以登錄上對應的 Node 機器，查看容器信息。

kubectl get pod -o wide

 

登錄 k8s-node2 以后，執(zhí)行 docker ps 命令查看詳細信息：

 

可以看到有三個 pause 容器，其中兩個是 flannel 和 proxy 容器，還有一個是我們的 expod 的容器，它與另一個 expod 容器共同組成了一個 Pod。

Pod 中的容器共享兩種資源-存儲和網絡。

• 存儲

在 Pod 里面，我們可以指定一個或者多個存儲卷，Pod 中的所有容器都可以訪問這些存儲卷，存儲卷可以分為臨時和持久化兩種。

 

• 網絡

在 kubernetes 集群中，每個 Pod 都分配了唯一的 IP 地址，Pod 中的容器都共享網絡命名空間，包括 IP 地址和網絡端口。在 Pod 內部各容器之間可以通過 localhost 互相通信。我們可以對比一下 Docker 和 kubernetes 在網絡空間上的差異。

Docker的網絡空間

從圖中可以看出，容器之間通過docker0網卡連接，每個容器擁有獨立的內部網絡地址

kubernetes 的網絡空間

從圖中可以看出，Pod 中的所有容器共享一個網絡地址

Pod 之間如何通信

Pod 之間的通信主要分為兩種情況：

• 同一個 Node 上 Pod 之間的通信

同一個 Node 上的 Pod 使用的都是相同的網橋( docker0 )進行連接，相當于 Docker 的網絡空間，只不過是以 Pod 為基礎。每個 Pod 都有一個全局 IP 地址，同一個 Node 內不同 Pod 之間通過 veth 連接在同一個 docker0 網橋上，其 IP 地址都是從 docker0 網橋上動態(tài)獲取的，并且關聯(lián)在同一個 docker0 網橋上，地址段也相同，所以它們之間能直接通信。

• 不同 Node 之間的 Pod 通信

要實現不同 Node 的 Pod 之間通信，首先要保證 Pod 在一個 kubernetes 集群中擁有全局唯一的 IP 地址。又因為一個 Node 上的 Pod 是通過 Docker 網橋與外部進行通信的，所以只要將不同 Node 上的 Docker 網橋配置成不同的 IP 地址段就可以實現這個功能。 Flannel 會配置 Docker 網橋，通過修改 Docker 的啟動參數 bip 來實現這一點，這樣就使得集群中機器的 Docker 網橋就得到了全局唯一的 IP 地址段，機器上所創(chuàng)建的容器也就擁有了全局唯一的 IP 地址。

跨 Node 的 Pod 之間的通信

我們在搭建 kubernetes 集群的時候，在每個 Node 機器上都創(chuàng)建了一個 kube-flannel 容器，這是在每個 Node 機器上使用 Flannel 虛擬網卡接管容器并跨主機通信，當一個節(jié)點的容器訪問另一個節(jié)點的容器時，源節(jié)點上的數據會從 docker0 網橋路由到 flannel0 網卡，在目的節(jié)點處會從 flannel0 網卡路由到 docker0 網橋，然后再轉發(fā)給目標容器。Flannel 重新規(guī)劃了容器集群的網絡，這樣既保證了容器 IP 的全局唯一性，又讓不同機器上的容器能通過內網 IP 地址互相通信。但是，容器的 IP 地址并不是固定的，Flannel 只分配子網段，所以容器的 IP 地址是在此網段的范圍內進行動態(tài)分配的。

因為 Pod 的 IP 地址本身是虛擬 IP，所以只有 kubernetes 集群內部的機器( Master 和 Node )和其他 Pod 可以直接訪問這個 IP 地址，集群之外的機器無法直接訪問 Pod 的 IP 地址。我們創(chuàng)建了一個 Nginx Pod：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: exnginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: nginxport
      containerPort: 80

通過命令創(chuàng)建后查詢以下 IP 地址：

[root@k8s-master]# kubectl apply -f exnginx.yml
[root@k8s-master]# kubectl get pod -o wide

 

集群中的所有機器和 Pod 都可以訪問這個虛擬地址和 containerPort 暴露的端口

[root@k8s-master]# curl http://10.244.1.6

 

同時我們看到我們有兩個 Pod，一個在 Node1 上，一個在 Node2 上，而 Node2 上的 Pod IP 地址是10.244.2.6，Node1 上的 Pod IP 地址是10.244.1.6，登錄到兩臺機器上，使用 ifconfig flannel.1 命令查看集群子網段。

k8s-node1

K8s-node2

要使集群外的機器訪問 Pod 提供的服務，后面我們會介紹 Service 和 Ingress 來發(fā)布服務。

Pod 的生命周期

Pod 的狀態(tài)

 

一旦開始在集群節(jié)點中創(chuàng)建 Pod，首先就會進入 Pending 狀態(tài)，只要 Pod 中的所有容器都已啟動并正常運行，則 Pod 接下來會進入 Running 狀態(tài)，如果 Pod 被要求終止，且所有容器終止退出時的狀態(tài)碼都為0，Pod 就會進入 Succeeded 狀態(tài)。

如果進入 Failed 狀態(tài)，通常有以下3種原因。

• Pod 啟動時，只要有一個容器運行失敗，Pod 將會從 Pending 狀態(tài)進入 Failed 狀態(tài)。
• Pod 正處于 Running 狀態(tài)，若 Pod 中的一個容器突然損壞或者在退出時狀態(tài)碼不為0，Pod 將會從 Running 進入 Failed 狀態(tài)。
• 在要求 Pod 正常關閉的時候，只要有一個容器退出的狀態(tài)碼不為0，Pod 就會進入 Failed 狀態(tài)。

Pod 的重啟策略

在配置 Pod 的模板文件中有個 spec 模塊，其中有一個名為 restartPolicy 的字段，字段的值為 Always、OnFailure、Never。Node 上的 kubelet 通過 restartPolicy 執(zhí)行重啟操作，由 kubelet 重新啟動的已退出容器將會以遞增延遲的方式（10s，20s，40s，...）嘗試重新啟動，上限時間為 5min，延時的累加值會在成功運行 10min 后重置，一旦 Pod 綁定到某個節(jié)點上，就絕對不會重新綁定到另一個節(jié)點上。

重啟策略對 Pod 狀態(tài)的影響如下：

• 假設有1個運行中的 Pod，包含1個容器，容器退出成功后。

Always：重啟容器，Pod 狀態(tài)仍為 Running。

OnFailure：Pod 狀態(tài)變?yōu)?Completed。

Never：Pod 狀態(tài)變?yōu)?Completed。

• 假設有1個運行中的 Pod，包含1個容器，容器退出失敗后。

Always：重啟容器，Pod 狀態(tài)仍為 Running。

OnFailure：重啟容器，Pod 狀態(tài)仍為 Running。

Never：Pod 狀態(tài)變?yōu)?Failed。

• 假設有1個運行中的 Pod，包含2個容器，第1個容器退出失敗后。

Always：重啟容器，Pod 狀態(tài)仍為 Running。

OnFailure：重啟容器，Pod 狀態(tài)仍為 Running。

Never：不會重啟容器，Pod 狀態(tài)仍為 Completed。

• 假設第1個容器沒有運行起來，而第2個容器也退出了。

Always：重啟容器，Pod 狀態(tài)仍為 Running。

OnFailure：重啟容器，Pod 狀態(tài)仍為 Running。

Never：Pod 狀態(tài)變?yōu)?Failed。

• 假設有1個運行中的 Pod，包含1個容器，容器發(fā)生內存溢出后。

Always：重啟容器，Pod 狀態(tài)仍為 Running。

OnFailure：重啟容器，Pod 狀態(tài)仍為 Running。

Never：記錄失敗事件，Pod 狀態(tài)變?yōu)?Failed。

Pod 的創(chuàng)建于銷毀過程

Pod 的創(chuàng)建過程：

• kubectl 命令將轉換為對 API Server 的調用。
• API Server 驗證請求并將其保存到 etcd 中。
• etcd 通知 API Server。
• API Server 調用調度器。
• 調度器決定在哪個節(jié)點上運行 Pod，并將其返回給 API Server。
• API Server 將其對應節(jié)點保存到 etcd 中。
• etcd 通知 API Server。
• API Server 在相應的節(jié)點中調用 kubelet。
• kubelet 與容器運行時 API 發(fā)生交互，與容器守護進程通信以創(chuàng)建容器。
• kubelet 將 Pod 狀態(tài)更新到 API Server 中。
• API Server 把最新的狀態(tài)保存到 etcd 中。

Pod 的銷毀過程：

• 用戶發(fā)送刪除 Pod 的命令。
• 將會更新 API Server 中的 Pod 對象，設定 Pod 被”銷毀“完成的大致時間（默認 30s），超出這個寬限時間 Pod 將被強制終止。
• 同時觸發(fā)以下操作：Pod 被標記為 Terminating。kubelet 發(fā)現 Pod 已標記為 Terminating 后，將會執(zhí)行 Pod 關閉過程。Endpoint 控制器監(jiān)控到 Pod 即將刪除，將溢出所有 Service 對象中與該 Pod 相關的 Endpoint。
• 如果 Pod 定義了 preStop 回調，則這會在 Pod 中執(zhí)行，如果寬限時間到了 preStop 還在運行，則會通知 API Server增加少量寬限時間（2s）。
• Pod 中的進程接收到 TERM 信號。
• 如果寬限時間過期，Pod 中的進行仍在運行，則會被 SIGKILL 信號終止。
• kubelet 通過 API Server 設置寬限時間為 0（立即刪除），完成 Pod 的刪除操作，Pod 從 API 中移除。

刪除操作的延遲時間默認為 30s。kubectl delete 命令支持--grace-period=秒，用戶可以自定義延遲時間。如果這個值設置為0，則表示強制刪除 Pod，但是在使用--grace-period=0 時需要增加選項 --force 才能執(zhí)行強制刪除。

Pod 的生命周期時間

Pod 在整個運行過程中，會有兩個大的階段，第一階段是初始化容器運行階段，第二階段是正式容器運行階段，每個階段都會有不同的事件

初始化容器運行階段

Pod 中可以包含一個或者多個初始化容器，這些容器是在應用程序容器正式運行之前運行的，主要負責一些初始化工作，所有初始化容器執(zhí)行完后才能執(zhí)行應用程序容器，因此初始化容器不能是長期運行的容器，而是執(zhí)行完一定操作后就必須結束的。如果是多個初始化容器，只能順序執(zhí)行，不能同時運行。在應用程序容器開始前，所有初始化容器都必須正常結束。

初始化容器執(zhí)行失敗時，如果 restartPolicy 是 OnFailure 或者 Always，那么會重復執(zhí)行失敗的初始化容器，直到成功；如果 restartPolicy 是 Never，則不會重啟失敗的初始化容器。

下面我們舉一個例子，在部署應用程序前，檢測 db 是否就緒，并執(zhí)行以下初始化腳本。

apiVersion: v1
kind: Pod
metadata:
  name: expodinitcontainer
spec:
  containers:
  - name: maincontainer
    image: busybox
    command: ['sh', '-c']
    args: ['echo "maincontainer is running!"; sleep 3600']
  initContainers:
  - name: initdbcheck
    image: busybox
    command: ['sh', '-c']
    args: ['echo "checking db!"; sleep 30; echo "checking done!"']
  - name: initscript
    image: busybox
    command: ['sh', '-c']
    args: ['echo "init script exec!"; sleep 30; echo "init script exec done!"']

這里包含一個主容器，兩個初始化容器，每個初始化容器執(zhí)行 30s，接下來我們創(chuàng)建一下 Pod，再查看他們的狀態(tài)：

kubectl apply -f expodinitcontainers.yml

在 30s 內執(zhí)行第一個初始化容器，所以 Pod 狀態(tài)是 Init:0/2，在 30s-60s 之間執(zhí)行第二個初始化容器，所以 Pod 狀態(tài)是 Init:1/2，當所有初始化容器執(zhí)行完畢后，狀態(tài)會先變?yōu)?PodInitializing，然后變?yōu)?Running 狀態(tài)。通過 kubectl describe 命令查看 Pod 詳細信息，可以看到先執(zhí)行 initdbcheck，然后執(zhí)行 initscript，最后才運行 maincontainer。

 

正式容器運行階段

正式容器創(chuàng)建成功后，就會觸發(fā) PostStart 事件，在容器運行的過程中，可以設置存活探針和就緒探針來持續(xù)監(jiān)測容器的健康狀況，在容器結束前，會觸發(fā) PreStop 事件。

• PostStart：容器剛創(chuàng)建成功后，觸發(fā)此事件，如果回調執(zhí)行失敗，則容器會被終止，然后根據重啟策略決定是否要重啟該容器。
• PreStop：容器開始和結束前，觸發(fā)此事件，無論執(zhí)行結果如何，都會結束容器。

回調的方式有兩種：Exec 執(zhí)行一段腳本和 HttpGet 執(zhí)行特定的請求。

• Exec 回調會執(zhí)行特定的命令，如果 Exec 執(zhí)行的命令最后正常退出，則代表執(zhí)行成功；否則就認為執(zhí)行異常，配置方式如下：

postStart/preStop:
  exec:
    command: xxxxx  # 命令列表

• HttpGet 回調會執(zhí)行特定的 Http 請求，通過返回的狀態(tài)碼來判斷該請求執(zhí)行是否成功，配置方式如下：

postStart/preStop:
  httpGet:
    host: xxxx # 請求的 IP 地址或域名
    port: xx # 請求的端口號
    path: xxxxxx # 請求的路徑，比如github.com/xingxingzaixian，"/xingxingzaixian"就是路徑
    scheme: http/https # 請求的協(xié)議，默認為 HTTP

我們來舉例使用一下 PostStart 和 PreStop 事件

apiVersion: v1
kind: Pod
metadata:
  name: expodpostpre
spec:
  containers:
  - name: postprecontainer
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c']
    args: ['echo "Hello Kubernetes!"; sleep 3600']
    lifecycle:
      postStart:
        httpGet:
          host: www.baidu.com
          path: /
          port: 80
          scheme: HTTP
      preStop:
        exec:
          command: ['sh', '-c', 'echo "preStop callback done!"; sleep 60']

postStart 中我們執(zhí)行 HttpGet 回調，訪問了百度首頁，preStop 則執(zhí)行命令輸出一段文本，然后停留 60s。我們執(zhí)行創(chuàng)建命令，觀察一下 Pod 的狀態(tài)。

kubectl apply -f expodpostpre.yml

正常情況下是和之前的是一樣的，我們做一些測試操作，例如把 postStart 的網址寫一個不可訪問的網址，比如：

host: www.fackbook.com

創(chuàng)建后，查看日志信息

kubectl logs expodpostpre

 

還可以通過 kubectl describe 來查看詳細情況

 

Pod 的健康檢查

在容器運行的過程中，我們可以通過探針來持續(xù)檢查容器的狀況，kubernetes 為我們提供了兩種探針：存活探針、就緒探針。

• 存活探針livenessProbe：檢測容器是否正在運行，如果返回 Failure，kubelet 會終止容器，然后容器會按照重啟策略執(zhí)行。如果沒有提供存活探針，默認狀態(tài)就是 Success。
• 就緒探針readlinessProbe：檢測容器是否已經可以啟動了應用服務，如果返回 Failure，Endpoint 控制器就會從所有 Service 的 Endpoint 中移除此 Pod 的 IP 地址。從容器啟動到第一次探測之前，默認的就緒狀態(tài)是 Failure。如果沒有提供就緒探針，默認狀態(tài)就是 Success。

容器配置當中有 3 種方法來執(zhí)行探針檢測：exec、tcpSocket、httpGet。

• exec：在容器內部執(zhí)行指定的命令，如果命令以狀態(tài)碼“0”退出，則表示診斷成功。配置如下：

livenessProbe/readlinessProbe:
  exec:
    command: [xxxx] # 命令列表

• tcpSocket：對容器的指定端口執(zhí)行 TCP 檢測。如果端口是打開的，則診斷成功。配置如下：

livenessProbe/readlinessProbe:
  tcpSocket:
    port: Number # 指定端口號

• httpGet：對容器內的 HTTP 服務進行檢測，如果響應的狀態(tài)碼范圍為 200~400，則診斷成功。配置如下：

livenessProbe/readlinessProbe:
  httpGet:
    port: Number # 指定的端口號
    path: String # 指定路徑

下面舉幾個例子來展示一下探針的使用。

存活探針的使用

apiVersion: v1
kind: Pod
metadata:
  name: expodlive
spec:
  containers:
  - name: livecontainer
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c']
    args: ['mkdir /files_dir; echo "Hello Kubernetes!" > /files_dir/newfile; sleep 3600']
    livenessProbe:
      exec:
        command: ['cat', '/files_dir/newfile']

先創(chuàng)建一個文件夾 files_dir，再新建一個文件 newfile，寫入 Hello Kubernetes! 內容，然后在存活探針中使用 cat 查看文件內容。執(zhí)行創(chuàng)建 Pod 命令：

kubectl apply -f expodlive.yml

 

目前 Pod 運行一切正常，現在我們可以做一些破壞性的操作，進入 Pod 內部，刪除 newfile 文件。

[root@k8s-master]# kubectl exec -it expodlive -- /bin/sh
/# rm -f /files_dir/newfile
/# exit

由于探針定期檢查 /files_dir/newfile 文件是否存在，而我們的 Pod 默認是異常后重啟，因此可以通過以下命令查看 Pod 詳細信息：

kubectl describe pods expodlive

 

可以看到 Event 中打印了存活探針的運行情況：存活探針失敗，并且準備重啟。

就緒探針的使用

apiVersion: v1
kind: Pod
metadata:
  name: expodread
spec:
  containers:
  - name: readcontainer
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: portnginx
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /

我們創(chuàng)建了一個 Nginx 容器，通過 containerPort 屬性，將 80 端口暴露出來，然后設置一個就緒探針定期向 80 端口發(fā)送 HttpGet 請求，檢測響應范圍是否為 200~400。使用 apply 命令創(chuàng)建成功后，我們同樣要進行一些測試性的操作。

[root@k8s-master]# kubectl apply -f expodread.yml
[root@k8s-master]# kubectl exec -it expodread -- /bin/sh
/# nginx -s stop

 

執(zhí)行 nginx -s stop 命令后，容器就會退出，因為 Nginx 容器是持續(xù)提供服務的，服務停止后，容器就異常了，然后 kubernetes 又會重新拉起一個容器，在這個過程當中，我們使用 kubectl get pod 命令就會發(fā)現，容器的狀態(tài)先變?yōu)?Completed，然后變?yōu)?CrashLoopBackOff，最后變?yōu)?Running。

 

對于初學者來講，總是分不清存活探針和就緒探針的區(qū)別，什么情況下該使用存活探針？什么情況下應該使用就緒探針？我給的建議如下：

• 如果容器中的進程能夠在遇到問題或異常的情況下自行崩潰，就像剛才的 Nginx 容器，那么不一定需要存活探針，kubelet 會根據 Pod 的重啟策略自動執(zhí)行正確的操作。
• 如果想在探測失敗時終止并重啟容器，則可以指定存活探針，并將重啟策略設置為 Always 或 OnFailure。
• 如果只想在探針成功時才對 Pod 發(fā)送網絡請求，則可以指定就緒探針，例如 HttpGet。
• 如果容器需要在啟動期間處理大型數據、配置文件或遷移，就使用就緒探針。

對于每種探針，還可以設置 5 個參數：

• initialDelaySeconds：啟動容器后首次監(jiān)控檢測的等待時間，單位為秒。
• timeoutSeconds：發(fā)送監(jiān)控檢測請求后等待響應的超時時間，單位為秒，如果超時就認為探測失敗，默認值為 10s。
• periodSeconds：探針的執(zhí)行周期，默認 10s 執(zhí)行一次。
• successThreshold：如果出現失敗，則需要連續(xù)探測成功多次才能確認診斷成功。默認值為1.
• failureThreshold：如果出現失敗，則要連續(xù)失敗多次才重啟 Pod（對于存活探針）或標記為 Unready（對于就緒探針）。默認值為3。

具體設置方法如下：

livenessProbe/readinessProbe:
  exec/tcpSocket/httpGet:
    initialDelaySeconds: Number
    timeoutSeconds: Number
    periodSeconds: Number
    successThreshold: Number
    failureThreshold: Number

總結

這篇文章我們主要講了 Pod 的增刪改查，Pod 與容器的關系，如何組織容器，Pod 的生命周期及對應事件，以及 Pod 的健康檢查機制。