目錄

一 Pod基礎(chǔ)概念

1.1 Pod是什么

1.2 為什么要使用Pod？Pod在K8S集群中的使用方式？

1.3 基礎(chǔ)容器pause

二 Pod的分類

2.1 自主式Pod和控制器管理的Pod

2.2 容器的分類

2.2.1 基礎(chǔ)容器（infrastructure container）

2.2.2?初始化容器（initcontainers）

2.2.3?應(yīng)用容器（Maincontainer）

2.3 Pod容器案例

三 鏡像拉取策略

3.1?IfNotPresent

3.2?Always

3.3?Never

3.4 示例

?四 重啟策略

4.1?Always

4.2?OnFailure

4.3?Never

?4.4 示例

五 Pod如何進(jìn)行資源限制

5.1 最常見的可設(shè)定資源—CPU

5.2 最常見的可設(shè)定資源—內(nèi)存

5.3 示例

六 探針

6.1 探針的三種規(guī)則

6.2 Probe支持的三種檢查方法

6.3 示例

6.3.1?exec方式

6.3.2??httpGet方式

?6.3.3?tcpSocket方式

6.3.4??就緒檢測(cè)

七 Pod的生命周期?

7.1 pod的生命周期

7.2 數(shù)據(jù)流向

---

一 Pod基礎(chǔ)概念

1.1 Pod是什么

Pod是kubernetes中最小的資源管理組件，Pod也是最小化運(yùn)行容器化應(yīng)用的資源對(duì)象。一個(gè)Pod代表著集群中運(yùn)行的一個(gè)進(jìn)程。kubernetes中其他大多數(shù)組件都是圍繞著Pod來進(jìn)行支撐和擴(kuò)展Pod功能的，例如，用于管理Pod運(yùn)行的StatefulSet和Deployment等控制器對(duì)象，用于暴露Pod應(yīng)用的Service和Ingress對(duì)象，為Pod提供存儲(chǔ)的PersistentVolume存儲(chǔ)資源對(duì)象等。

1.2 為什么要使用Pod？Pod在K8S集群中的使用方式？

現(xiàn)代容器技術(shù)建議一個(gè)容器只運(yùn)行一個(gè)進(jìn)程，該進(jìn)程在容器中PID命令空間中的進(jìn)程號(hào)為1，可直接接收并處理信號(hào)，進(jìn)程終止時(shí)容器生命周期也就結(jié)束了。若想在容器內(nèi)運(yùn)行多個(gè)進(jìn)程，需要有一個(gè)類似Linux操作系統(tǒng)init進(jìn)程的管控類進(jìn)程，以樹狀結(jié)構(gòu)完成多進(jìn)程的生命周期管理。運(yùn)行于各自容器內(nèi)的進(jìn)程無法直接完成網(wǎng)絡(luò)通信，這是由于容器間的隔離機(jī)制導(dǎo)致，k8s中的Pod資源抽象正是解決此類問題：

• 多容器協(xié)同：有時(shí)候多個(gè)容器需要共享資源、網(wǎng)絡(luò)空間等，這時(shí)候就可以將它們放在同一個(gè) Pod 中，方便它們之間的協(xié)同工作。

• 生命周期管理：Pod 提供了統(tǒng)一的生命周期，當(dāng) Pod 中的所有容器都終止時(shí)，Pod 進(jìn)程也將終止。這種生命周期的一致性有助于簡(jiǎn)化應(yīng)用程序的管理。

• 共享網(wǎng)絡(luò)：Pod 內(nèi)的容器共享相同的網(wǎng)絡(luò)命名空間，它們可以通過 localhost 直接通信，無需額外的配置。

Pod在K8S集群中有兩種使用方式：

• 一個(gè)Pod中運(yùn)行一個(gè)容器（最常見的用法）：一個(gè)Pod下的容器必須運(yùn)行于同一節(jié)點(diǎn)上。
• 在一個(gè)Pod中同時(shí)運(yùn)行多個(gè)容器：一個(gè)Pod中也可以同時(shí)封裝幾個(gè)需要緊密耦合互相協(xié)作的容器，它們之間共享資源。這些在同一個(gè)Pod中的容器可以互相協(xié)作成為一個(gè)service單位，比如一個(gè)容器共享文件，另一個(gè)“sidecar”容器來更新這些文件，Pod將這些容器的存儲(chǔ)資源作為一個(gè)實(shí)體來管理。

1.3 基礎(chǔ)容器pause

Pod資源中針對(duì)各容器提供網(wǎng)絡(luò)命令空間等共享機(jī)制的是底層基礎(chǔ)容器pause。

基礎(chǔ)容器（也可稱為父容器）pause為了管理Pod容器間的共享操作，需要能夠準(zhǔn)確地知道如何去創(chuàng)建共享運(yùn)行環(huán)境的容器，還能管理這些容器的生命周期。

pause容器有兩個(gè)核心的功能：

首先，它作為Pod中所有其他容器共享的基礎(chǔ)容器，提供了整個(gè)Pod的Linux命名空間。這意味著所有其他容器將與"pause"容器共享網(wǎng)絡(luò)和存儲(chǔ)等資源。

其次，"pause"容器在每個(gè)Pod中充當(dāng)PID為1的init進(jìn)程，并負(fù)責(zé)管理該P(yáng)od中的所有其他容器的進(jìn)程。它會(huì)啟用PID命名空間，并處理僵尸進(jìn)程的回收。這確保了在Pod中的各個(gè)容器正常啟動(dòng)和停止，并提供了更好的進(jìn)程隔離。

pause容器使得Pod中的所有容器可以共享兩種資源：

• 網(wǎng)絡(luò)：每個(gè)Pod都會(huì)被分配一個(gè)唯一的IP地址。Pod中的所有容器共享網(wǎng)絡(luò)空間，包括IP地址和端口。Pod內(nèi)部的容器可以使用localhost互相通信。Pod中的容器與外界通信時(shí)，必須分配共享網(wǎng)絡(luò)資源（例如使用宿主機(jī)的端口映射）。
• 存儲(chǔ)：Pod可以指定多個(gè)共享的Volume。Pod中的所有容器都可以訪問共享的Volume。Volume也可以用來持久化Pod中的存儲(chǔ)資源，以防容器重啟后文件丟失。

每個(gè)Pod都有一個(gè)特殊的被稱為“基礎(chǔ)容器”的Pause容器。Pause容器對(duì)應(yīng)的鏡像屬于Kubernetes平臺(tái)的一部分，除了Pause容器，每個(gè)Pod還包含一個(gè)或者多個(gè)緊密相關(guān)的用戶應(yīng)用容器。

---

二 Pod的分類

2.1 自主式Pod和控制器管理的Pod

• 自主式Pod ：通過手動(dòng)創(chuàng)建 Pod 資源對(duì)象，將應(yīng)用程序?qū)嵗苯硬渴鸬?Kubernetes 集群中。這種方式不太靈活，因?yàn)?Pod 是直接部署到節(jié)點(diǎn)上的，一旦 Pod 所在的節(jié)點(diǎn)發(fā)生故障或者 Pod 本身出現(xiàn)問題，就需要手動(dòng)介入來修復(fù)問題，這種Pod本身是不能自我修復(fù)的。
• 控制器管理的Pod：通過 Kubernetes 中的 Controller 抽象層來管理的，可以提供副本管理、滾動(dòng)升級(jí)和集群級(jí)別的自愈能力。Controller 能夠自動(dòng)地管理多個(gè) Pod 實(shí)例，對(duì)節(jié)點(diǎn)故障進(jìn)行自動(dòng)調(diào)度，并具有自我修復(fù)的能力。

2.2 容器的分類

2.2.1 基礎(chǔ)容器（infrastructure container）

基礎(chǔ)容器提供了 Kubernetes 集群所需的基礎(chǔ)設(shè)施服務(wù)，比如網(wǎng)絡(luò)、存儲(chǔ)、監(jiān)控等。它們通常不直接參與應(yīng)用程序的運(yùn)行，而是為整個(gè)集群提供支持和服務(wù)。

①負(fù)責(zé)維護(hù)整個(gè) Pod 網(wǎng)絡(luò)和存儲(chǔ)空間；

②node 節(jié)點(diǎn)中操作；

③啟動(dòng)一個(gè)Pod時(shí)，k8s會(huì)自動(dòng)啟動(dòng)一個(gè)基礎(chǔ)容器。

2.2.2?初始化容器（initcontainers）

初始化容器用于在主應(yīng)用容器啟動(dòng)之前執(zhí)行特定的初始化任務(wù)，例如加載配置、初始化數(shù)據(jù)庫(kù)等。它們可以確保在主應(yīng)用容器啟動(dòng)之前完成必要的準(zhǔn)備工作，使得應(yīng)用容器能夠順利啟動(dòng)和運(yùn)行。

Init 容器與普通的容器非常像，除了以下兩點(diǎn)：
●Init 容器總是運(yùn)行到成功完成為止。

●每個(gè) Init 容器都必須在下一個(gè) Init 容器啟動(dòng)之前成功完成啟動(dòng)和退出。如果 Pod 的 Init 容器失敗，K8S不斷地重啟該 Pod，直到 Init 容器成功為止。然而，如果 Pod 對(duì)應(yīng)的重啟策略（restartPolicy）為 Never，它不會(huì)重新啟動(dòng)。

Init 的容器作用：
因?yàn)閕nit容器具有與應(yīng)用容器分離的單獨(dú)鏡像，其啟動(dòng)相關(guān)代碼具有如下優(yōu)勢(shì)：
●Init 容器可以包含一些安裝過程中應(yīng)用容器中不存在的實(shí)用工具或個(gè)性化代碼。例如，沒有必要僅為了在安裝過程中使用類似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個(gè)鏡像來生成一個(gè)新的鏡像。

●Init 容器可以安全地運(yùn)行這些工具，避免這些工具導(dǎo)致應(yīng)用鏡像的安全性降低。

●應(yīng)用鏡像的創(chuàng)建者和部署者可以各自獨(dú)立工作，而沒有必要聯(lián)合構(gòu)建一個(gè)單獨(dú)的應(yīng)用鏡像。

●Init 容器能以不同于Pod內(nèi)應(yīng)用容器的文件系統(tǒng)視圖運(yùn)行。因此，Init容器可具有訪問 Secrets 的權(quán)限，而應(yīng)用容器不能夠訪問。

●由于 Init 容器必須在應(yīng)用容器啟動(dòng)之前運(yùn)行完成，因此 Init 容器提供了一種機(jī)制來阻塞或延遲應(yīng)用容器的啟動(dòng)，
直到滿足了一組先決條件。一旦前置條件滿足，Pod內(nèi)的所有的應(yīng)用容器會(huì)并行啟動(dòng)。

2.2.3?應(yīng)用容器（Maincontainer）

應(yīng)用容器是 Kubernetes Pod 中運(yùn)行實(shí)際應(yīng)用程序的容器，如 Web 服務(wù)器、后端服務(wù)、數(shù)據(jù)庫(kù)等。它們是構(gòu)成應(yīng)用程序的核心組件，負(fù)責(zé)提供實(shí)際的業(yè)務(wù)功能。

2.3 Pod容器案例

kubectl describe pod myapp-pod

#查看容器日志內(nèi)容

#創(chuàng)建一個(gè)名為myservice的 Service 并查看 K8S集群中的 Pod 和 Service 的狀態(tài)。

vim myservice.yamlapiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 9376kubectl create -f myservice.yaml

#獲取當(dāng)前 K8S 集群中所有 Service 的狀態(tài)和信息。

?#獲取 K8S 集群中所有運(yùn)行在kube-system命名空間下的 Pod 的狀態(tài)和信息和獲取集群中所有 Pod 的狀態(tài)和信息

vim mydb.yamlapiVersion: v1
kind: Service
metadata:name: mydb
spec:ports:- protocol: TCPport: 80targetPort: 9377kubectl create -f mydb.yamlkubectl get pods

注意：?

●在Pod啟動(dòng)過程中，Init容器會(huì)按順序在網(wǎng)絡(luò)和數(shù)據(jù)卷初始化之后啟動(dòng)。每個(gè)容器必須在下一個(gè)容器啟動(dòng)之前成功退出。
●如果由于運(yùn)行時(shí)或失敗退出，將導(dǎo)致容器啟動(dòng)失敗，它會(huì)根據(jù)Pod的restartPolicy指定的策略進(jìn)行重試。然而，如果Pod的restartPolicy設(shè)置為Always，Init容器失敗時(shí)會(huì)使用RestartPolicy策略。
●在所有的Init容器沒有成功之前，Pod將不會(huì)變成Ready狀態(tài)。Init容器的端口將不會(huì)在Service中進(jìn)行聚集。正在初始化中的Pod處于Pending狀態(tài)，但應(yīng)該會(huì)將Initializing狀態(tài)設(shè)置為true。
●如果Pod重啟，所有Init容器必須重新執(zhí)行。
●對(duì)Init容器spec的修改被限制在容器image字段，修改其他字段都不會(huì)生效。更改Init容器的image字段，等價(jià)于重啟該P(yáng)od。
●Init容器具有應(yīng)用容器的所有字段。除了readinessProbe，因?yàn)镮nit容器無法定義不同于完成（completion）的就緒（readiness）之外的其他狀態(tài)。這會(huì)在驗(yàn)證過程中強(qiáng)制執(zhí)行。
●在Pod中的每個(gè)app和Init容器的名稱必須唯一；與任何其它容器共享同一個(gè)名稱，會(huì)在驗(yàn)證時(shí)拋出錯(cuò)誤。

---

三 鏡像拉取策略

鏡像拉取策略是指在創(chuàng)建或更新容器時(shí)，決定是否從鏡像倉(cāng)庫(kù)中拉取新的鏡像。在 K8S 中，有三種常見的鏡像拉取策略可以選擇。

3.1?IfNotPresent

如果本地沒有該鏡像，則從鏡像倉(cāng)庫(kù)中拉取鏡像。如果本地已經(jīng)存在該鏡像，則直接使用本地鏡像，不再拉取新的鏡像。默認(rèn)的鏡像拉取策略。

3.2?Always

每次都從鏡像倉(cāng)庫(kù)中拉取最新的鏡像。無論本地是否已經(jīng)存在該鏡像，都會(huì)強(qiáng)制拉取最新的鏡像。

3.3?Never

從不拉取鏡像。只使用本地存在的鏡像。如果本地不存在該鏡像，則容器將無法啟動(dòng)。

注意：對(duì)于標(biāo)簽為“:latest”的鏡像文件，其默認(rèn)的鏡像獲取策略即為“Always”；而對(duì)于其他標(biāo)簽的鏡像，其默認(rèn)策略則為“IfNotPresent”。

nginx:latest

3.4 示例

#master01 上操作

kubectl edit deployment/nginx-deployment

#?創(chuàng)建測(cè)試案例

mkdir /opt/demo
cd /opt/demovim pod1.yamlapiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginximagePullPolicy: Alwayscommand: [ "echo", "SUCCESS" ]kubectl create -f pod1.yaml

#此時(shí) Pod 的狀態(tài)異常，原因是 echo 執(zhí)行完進(jìn)程終止，容器生命周期也就結(jié)束了??

?#可以發(fā)現(xiàn) Pod 中的容器在生命周期結(jié)束后，由于 Pod 的重啟策略為 Always，容器再次重啟了，并且又重新開始拉取鏡像。?

#修改 pod1.yaml 文件

cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: pod-test1
spec:containers:- name: nginximage: nginx:1.14							#修改 nginx 鏡像版本imagePullPolicy: Always#command: [ "echo", "SUCCESS" ]			#刪除

?#刪除原有的資源

kubectl delete -f pod1.yaml 

#更新資源

kubectl apply -f pod1.yaml 

#?查看 Pod 狀態(tài)

#在任意 node 節(jié)點(diǎn)上使用 curl 查看頭部信息

---

?四 重啟策略

重啟策略是指在容器發(fā)生故障或終止時(shí)，Kubernetes 控制器將采取的措施。以下是三種常見的重啟策略。

4.1?Always

默認(rèn)策略，無論何時(shí)容器終止，Kubernetes 都會(huì)自動(dòng)重啟該容器。

確保容器始終處于運(yùn)行狀態(tài)，即使容器終止也會(huì)自動(dòng)重啟，適用于需要保持長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序。

4.2?OnFailure

當(dāng)容器異常退出（退出狀態(tài)碼非0）時(shí)，重啟容器；正常退出則不重啟容器。

4.3?Never

Kubernetes 不會(huì)自動(dòng)重啟容器，即使容器終止。

適用于一次性任務(wù)或者不希望容器終止后自動(dòng)重啟的場(chǎng)景，確保容器終止后不會(huì)重新啟動(dòng)。

這些重啟策略可以在 Pod 的配置文件中通過spec.restartPolicy字段來指定。例如，你可以在 Pod 的配置中添加如下字段來設(shè)置重啟策略：

spec:restartPolicy: Always

?4.4 示例

vim pod3.yamlapiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3kubectl apply -f pod3.yaml

#查看Pod狀態(tài)，等容器啟動(dòng)后30秒后執(zhí)行exit退出進(jìn)程進(jìn)入error狀態(tài)，就會(huì)重啟次數(shù)加1

kubectl delete -f pod3.yamlvim pod3.yamlapiVersion: v1
kind: Pod
metadata:name: foo
spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Neverkubectl apply -f pod3.yaml

?#容器進(jìn)入error狀態(tài)不會(huì)進(jìn)行重啟

---

五 Pod如何進(jìn)行資源限制

當(dāng)定義 Pod 時(shí)可以選擇性地為每個(gè)容器設(shè)定所需要的資源數(shù)量。 最常見的可設(shè)定資源是 CPU 和內(nèi)存大小，以及其他類型的資源。

當(dāng)為 Pod 中的容器指定了 request 資源時(shí)，調(diào)度器就使用該信息來決定將 Pod 調(diào)度到哪個(gè)節(jié)點(diǎn)上。當(dāng)還為容器指定了 limit 資源時(shí)，kubelet 就會(huì)確保運(yùn)行的容器不會(huì)使用超出所設(shè)的 limit 資源量。kubelet 還會(huì)為容器預(yù)留所設(shè)的 request 資源量， 供該容器使用。

如果 Pod 運(yùn)行所在的節(jié)點(diǎn)具有足夠的可用資源，容器可以使用超出所設(shè)置的 request 資源量。不過，容器不可以使用超出所設(shè)置的 limit 資源量。

如果給容器設(shè)置了內(nèi)存的 limit 值，但未設(shè)置內(nèi)存的 request 值，Kubernetes 會(huì)自動(dòng)為其設(shè)置與內(nèi)存 limit 相匹配的 request 值。 類似的，如果給容器設(shè)置了 CPU 的 limit 值但未設(shè)置 CPU 的 request 值，則 Kubernetes 自動(dòng)為其設(shè)置 CPU 的 request 值 并使之與 CPU 的 limit 值匹配。

Pod 和 容器 的資源請(qǐng)求和限制：
spec.containers[].resources.requests.cpu?? ??? ?#定義創(chuàng)建容器時(shí)預(yù)分配的CPU資源
spec.containers[].resources.requests.memory?? ??? ?#定義創(chuàng)建容器時(shí)預(yù)分配的內(nèi)存資源
spec.containers[].resources.limits.cpu? ? ? ? ? ? #定義 cpu 的資源上限?
spec.containers[].resources.limits.memory? ? ? ? #定義內(nèi)存的資源上限

5.1 最常見的可設(shè)定資源—CPU

在 Kubernetes 中，CPU 資源的 request 和 limit 都以 CPU 核心（Core）或者毫核（MilliCore）為單位。一個(gè) CPU 核心或者毫核在 Kubernetes 中通常被定義為等同于一個(gè)虛擬 CPU（vCPU），也可以理解為一個(gè)超線程。

因此，在 Kubernetes 中，一個(gè) CPU 的定義相當(dāng)于一個(gè) vCPU 或一個(gè)超線程的計(jì)算能力。當(dāng)你在 Pod 的配置中設(shè)置 CPU 資源時(shí)，可以使用整數(shù)值表示整個(gè) CPU 核心，也可以使用小數(shù)或者毫核值來表示部分 CPU 核心的計(jì)算能力。

如果你在 Pod 的配置中設(shè)置了如下 CPU 請(qǐng)求和限制：

resources:requests:cpu: 0.5limits:cpu: 1

這個(gè)配置表示該容器請(qǐng)求了半個(gè) CPU 核心的計(jì)算資源，并且限制了最大使用量為一個(gè) CPU 核心。

?注意：Kubernetes 不允許設(shè)置精度小于 1m 的 CPU 資源。?

5.2 最常見的可設(shè)定資源—內(nèi)存

內(nèi)存的 request 和 limit 以字節(jié)為單位?？梢砸哉麛?shù)表示，或者以10為底數(shù)的指數(shù)的單位（E、P、T、G、M、K）來表示， 或者以2為底數(shù)的指數(shù)的單位（Ei、Pi、Ti、Gi、Mi、Ki）來表示。

如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

5.3 示例

vim pod2.yamlapiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: webimage: nginxenv:- name: WEB_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: "abc123"resources:requests:memory: "512Mi"cpu: "500m"limits:memory: "1Gi"cpu: "1"kubectl apply -f pod2.yaml
kubectl describe pod frontend

?kubectl get pods -o wide

?kubectl describe nodes node01

---

六 探針

探針是由kubelet對(duì)容器執(zhí)行的定期診斷。

6.1 探針的三種規(guī)則

●livenessProbe ：判斷容器是否正在運(yùn)行。如果探測(cè)失敗，則kubelet會(huì)殺死容器，并且容器將根據(jù) restartPolicy 來設(shè)置 Pod 狀態(tài)。 如果容器不提供存活探針，則默認(rèn)狀態(tài)為Success。

●readinessProbe ：判斷容器是否準(zhǔn)備好接受請(qǐng)求。如果探測(cè)失敗，端點(diǎn)控制器將從與 Pod 匹配的所有 service 址endpoints 中剔除刪除該P(yáng)od的IP地。 初始延遲之前的就緒狀態(tài)默認(rèn)為Failure。如果容器不提供就緒探針，則默認(rèn)狀態(tài)為Success。

●startupProbe（這個(gè)1.17版本增加的）：判斷容器內(nèi)的應(yīng)用程序是否已啟動(dòng)，主要針對(duì)于不能確定具體啟動(dòng)時(shí)間的應(yīng)用。如果配置了 startupProbe 探測(cè)，在則在 startupProbe 狀態(tài)為 Success 之前，其他所有探針都處于無效狀態(tài)，直到它成功后其他探針才起作用。 如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據(jù) restartPolicy 來重啟。如果容器沒有配置 startupProbe， 則默認(rèn)狀態(tài)為 Success。
注意：以上規(guī)則可以同時(shí)定義。在readinessProbe檢測(cè)成功之前，Pod的running狀態(tài)是不會(huì)變成ready狀態(tài)的。

6.2 Probe支持的三種檢查方法

●exec ：在容器內(nèi)執(zhí)行指定命令。如果命令退出時(shí)返回碼為0則認(rèn)為診斷成功。

●tcpSocket ：對(duì)指定端口上的容器的IP地址進(jìn)行TCP檢查（三次握手）。如果端口打開，則診斷被認(rèn)為是成功的。

●httpGet ：對(duì)指定的端口和路徑上的容器的IP地址執(zhí)行HTTPGet請(qǐng)求。如果響應(yīng)的狀態(tài)碼大于等于200且小于400，則診斷被認(rèn)為是成功的。

每次探測(cè)都將獲得以下三種結(jié)果之一：
●成功：容器通過了診斷。
●失敗：容器未通過診斷。
●未知：診斷失敗，因此不會(huì)采取任何行動(dòng)。

6.3 示例

6.3.1?exec方式

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs:  - /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60livenessProbe:exec:command:- cat- /tmp/healthyfailureThreshold: 1 initialDelaySeconds: 5periodSeconds: 5

• initialDelaySeconds：指定 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待5秒，即第一次探測(cè)是在容器啟動(dòng)后的第6秒才開始執(zhí)行。默認(rèn)是 0 秒，最小值是 0。
• periodSeconds：指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測(cè)。默認(rèn)是 10 秒。最小值是 1。
• failureThreshold: 當(dāng)探測(cè)失敗時(shí)，Kubernetes 將在放棄之前重試的次數(shù)。 存活探測(cè)情況下的放棄就意味著重新啟動(dòng)容器。就緒探測(cè)情況下的放棄 Pod 會(huì)被打上未就緒的標(biāo)簽。默認(rèn)值是 3。最小值是 1。
• timeoutSeconds：探測(cè)的超時(shí)后等待多少秒。默認(rèn)值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探針會(huì)忽略 timeoutSeconds 探針會(huì)無限期地 持續(xù)運(yùn)行，甚至可能超過所配置的限期，直到返回結(jié)果為止。）

可以看到 Pod 中只有一個(gè)容器。kubelet 在執(zhí)行第一次探測(cè)前需要等待 5 秒，kubelet 會(huì)每 5 秒執(zhí)行一次存活探測(cè)。kubelet 在容器內(nèi)執(zhí)行命令 cat /tmp/healthy 來進(jìn)行探測(cè)。如果命令執(zhí)行成功并且返回值為 0，kubelet 就會(huì)認(rèn)為這個(gè)容器是健康存活的。 當(dāng)?shù)竭_(dá)第 31 秒時(shí)，這個(gè)命令返回非 0 值，kubelet 會(huì)殺死這個(gè)容器并重新啟動(dòng)它。

vim exec.yamlapiVersion: v1
kind: Pod
metadata:name: liveness-execnamespace: default
spec:containers:- name: liveness-exec-containerimage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]livenessProbe:exec:command: ["test","-e","/tmp/live"]initialDelaySeconds: 1periodSeconds: 3kubectl create -f exec.yaml

?kubectl get pods -w

6.3.2??httpGet方式

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: k8s.gcr.io/livenessargs:- /serverlivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3

在這個(gè)配置文件中，可以看到 Pod 也只有一個(gè)容器。initialDelaySeconds 字段告訴 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒執(zhí)行一次存活探測(cè)。kubelet 會(huì)向容器內(nèi)運(yùn)行的服務(wù)（服務(wù)會(huì)監(jiān)聽 8080 端口）發(fā)送一個(gè) HTTP GET 請(qǐng)求來執(zhí)行探測(cè)。如果服務(wù)器上 /healthz 路徑下的處理程序返回成功代碼，則 kubelet 認(rèn)為容器是健康存活的。如果處理程序返回失敗代碼，則 kubelet 會(huì)殺死這個(gè)容器并且重新啟動(dòng)它。

任何大于或等于 200 并且小于 400 的返回代碼標(biāo)示成功，其它返回代碼都標(biāo)示失敗。

vim httpget.yamlapiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl create -f httpget.yaml

kubectl create -f httpget.yamlkubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

?6.3.3?tcpSocket方式

apiVersion: v1
kind: Pod
metadata:name: goproxylabels:app: goproxy
spec:containers:- name: goproxyimage: k8s.gcr.io/goproxy:0.1ports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20

?這個(gè)例子同時(shí)使用 readinessProbe 和 livenessProbe 探測(cè)。kubelet 會(huì)在容器啟動(dòng) 5 秒后發(fā)送第一個(gè) readinessProbe 探測(cè)。這會(huì)嘗試連接 goproxy 容器的 8080 端口。如果探測(cè)成功，kubelet 將繼續(xù)每隔 10 秒運(yùn)行一次檢測(cè)。除了 readinessProbe 探測(cè)，這個(gè)配置包括了一個(gè) livenessProbe 探測(cè)。kubelet 會(huì)在容器啟動(dòng) 15 秒后進(jìn)行第一次 livenessProbe 探測(cè)。就像 readinessProbe 探測(cè)一樣，會(huì)嘗試連接 goproxy 容器的 8080 端口。如果 livenessProbe 探測(cè)失敗，這個(gè)容器會(huì)被重新啟動(dòng)。

vim tcpsocket.yamlapiVersion: v1
kind: Pod
metadata:name: probe-tcp
spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10failureThreshold: 2kubectl create -f tcpsocket.yaml

kubectl get pods -w
NAME        READY   STATUS    RESTARTS   AGE
probe-tcp   1/1     Running             0          1s
probe-tcp   1/1     Running             1          25s       #第一次是 init(5秒) + period(10秒) * 2
probe-tcp   1/1     Running             2          45s       #第二次是 period(10秒) + period(10秒)  重試了兩次
probe-tcp   1/1     Running             3          65s

6.3.4??就緒檢測(cè)

vim readiness-httpget.yamlapiVersion: v1
kind: Pod
metadata:name: readiness-httpgetnamespace: default
spec:containers:- name: readiness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl create -f readiness-httpget.yaml

#readiness探測(cè)失敗，無法進(jìn)入READY狀態(tài)

kubectl get pods 
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   0/1     Running   0          20s

?kubectl get pods?

kubectl get pods -w
NAME                READY   STATUS    RESTARTS   AGE
readiness-httpget   1/1     Running   0          4m10s
readiness-httpget   0/1     Running   1          4m15s

---

七 Pod的生命周期?

7.1 pod的生命周期

?

• Pause（父容器）：主要作用是為了管理所有組件的生命周期。它負(fù)責(zé)啟動(dòng)和終止整個(gè)容器組。

• Init（初始化容器）：Init 容器用于提供應(yīng)用容器所需的依賴環(huán)境。它會(huì)在應(yīng)用容器啟動(dòng)之前運(yùn)行，并且應(yīng)用容器需要等待所有的初始化容器啟動(dòng)完成且退出后才會(huì)啟動(dòng)。

• Main（應(yīng)用容器）：Main 容器是應(yīng)用程序的主要運(yùn)行容器。它在初始化容器運(yùn)行完成后才開始運(yùn)行，負(fù)責(zé)整個(gè)應(yīng)用程序的啟動(dòng)。

• Startup（啟動(dòng)探針）：啟動(dòng)探針用于檢測(cè)應(yīng)用容器是否已經(jīng)啟動(dòng)完成。它會(huì)判斷應(yīng)用容器是否已經(jīng)準(zhǔn)備好接收外部請(qǐng)求。

• Readiness（就緒探針）：用于判斷應(yīng)用容器是否已經(jīng)準(zhǔn)備好接收對(duì)外的分發(fā)請(qǐng)求。如果就緒探針檢測(cè)失敗，通常會(huì)導(dǎo)致容器被標(biāo)記為不可用，并觸發(fā)重啟策略，但不會(huì)直接殺死應(yīng)用容器。此外，若應(yīng)用容器持續(xù)無法通過就緒探針檢測(cè)，則系統(tǒng)可能會(huì)將該容器從服務(wù)端點(diǎn)中移除，以確保不會(huì)向其發(fā)送流量。

• Liveness（存活探針）：存活探針用于檢測(cè)應(yīng)用容器是否仍然在正常運(yùn)行。如果存活探針失敗，則會(huì)認(rèn)為應(yīng)用容器不可用，并觸發(fā)重啟策略。

7.2 數(shù)據(jù)流向

• 發(fā)送指令進(jìn)行容器初始化。
• 初始化容器（Init）逐個(gè)啟動(dòng)，直到所有初始化容器成功啟動(dòng)。
• 啟動(dòng)探針（Startup）檢測(cè)應(yīng)用容器是否已經(jīng)啟動(dòng)完成。
• 應(yīng)用容器（Main）并行啟動(dòng)。
• 就緒探針（Readiness）檢測(cè)應(yīng)用容器是否準(zhǔn)備好接收請(qǐng)求。
• 存活探針（Liveness）檢測(cè)應(yīng)用容器是否正常運(yùn)行。
• 如果需要關(guān)閉容器，則啟動(dòng)停止指令（Stop）。