Pod 的生命周期及探针
目錄
?
?
Pod 的生命周期
Pod 生命期
Pod 階段
容器狀態(tài)
Waiting?（等待）
Running（運(yùn)行中）
Terminated（已終止）
容器重啟策略
Pod 狀況
Pod 就緒態(tài)
Pod 就緒態(tài)的狀態(tài)
容器探針
何時(shí)該使用存活態(tài)探針?
何時(shí)該使用就緒態(tài)探針?
何時(shí)該使用啟動(dòng)探針？
Pod 的終止
強(qiáng)制終止 Pod
失效 Pod 的垃圾收集
配置存活、就緒和啟動(dòng)探測(cè)器
準(zhǔn)備開始
定義存活命令
定義一個(gè)存活態(tài) HTTP 請(qǐng)求接口
定義 TCP 的存活探測(cè)
使用命名端口
使用啟動(dòng)探測(cè)器保護(hù)慢啟動(dòng)容器
定義就緒探測(cè)器
配置探測(cè)器
HTTP 探測(cè)
TCP 探測(cè)
探測(cè)器級(jí)別?terminationGracePeriodSeconds
總結(jié)
?
Pod 的生命周期
?Pod 遵循一個(gè)預(yù)定義的生命周期，起始于?Pending?階段，如果至少 其中有一個(gè)主要容器正常啟動(dòng)，則進(jìn)入?Running，之后取決于 Pod 中是否有容器以 失敗狀態(tài)結(jié)束而進(jìn)入?Succeeded?或者?Failed?階段。
在 Pod 運(yùn)行期間，kubelet?能夠重啟容器以處理一些失效場(chǎng)景。 在 Pod 內(nèi)部，Kubernetes 跟蹤不同容器的狀態(tài)?并確定使 Pod 重新變得健康所需要采取的動(dòng)作。
在 Kubernetes API 中，Pod 包含規(guī)約部分和實(shí)際狀態(tài)部分。 Pod 對(duì)象的狀態(tài)包含了一組?Pod 狀況（Conditions）。 如果應(yīng)用需要的話，你也可以向其中注入自定義的就緒性信息。
Pod 在其生命周期中只會(huì)被調(diào)度一次。 一旦 Pod 被調(diào)度（分派）到某個(gè)節(jié)點(diǎn)，Pod 會(huì)一直在該節(jié)點(diǎn)運(yùn)行，直到 Pod 停止或者 被終止。
Pod 生命期
和一個(gè)個(gè)獨(dú)立的應(yīng)用容器一樣，Pod 也被認(rèn)為是相對(duì)臨時(shí)性（而不是長(zhǎng)期存在）的實(shí)體。 Pod 會(huì)被創(chuàng)建、賦予一個(gè)唯一的 ID（UID）， 并被調(diào)度到節(jié)點(diǎn)，并在終止（根據(jù)重啟策略）或刪除之前一直運(yùn)行在該節(jié)點(diǎn)。
如果一個(gè)節(jié)點(diǎn)死掉了，調(diào)度到該節(jié)點(diǎn) 的 Pod 也被計(jì)劃在給定超時(shí)期限結(jié)束后刪除。
Pod 自身不具有自愈能力。如果 Pod 被調(diào)度到某節(jié)點(diǎn)?而該節(jié)點(diǎn)之后失效，Pod 會(huì)被刪除；類似地，Pod 無法在因節(jié)點(diǎn)資源 耗盡或者節(jié)點(diǎn)維護(hù)而被驅(qū)逐期間繼續(xù)存活。Kubernetes 使用一種高級(jí)抽象 來管理這些相對(duì)而言可隨時(shí)丟棄的 Pod 實(shí)例，稱作?控制器。
任何給定的 Pod （由 UID 定義）從不會(huì)被“重新調(diào)度（rescheduled）”到不同的節(jié)點(diǎn)； 相反，這一 Pod 可以被一個(gè)新的、幾乎完全相同的 Pod 替換掉。 如果需要，新 Pod 的名字可以不變，但是其 UID 會(huì)不同。
如果某物聲稱其生命期與某 Pod 相同，例如存儲(chǔ)卷， 這就意味著該對(duì)象在此 Pod （UID 亦相同）存在期間也一直存在。 如果 Pod 因?yàn)槿魏卧虮粍h除，甚至某完全相同的替代 Pod 被創(chuàng)建時(shí)， 這個(gè)相關(guān)的對(duì)象（例如這里的卷）也會(huì)被刪除并重建。
Pod 階段
Pod 的?status?字段是一個(gè)?PodStatus?對(duì)象，其中包含一個(gè)?phase?字段。
下面是?phase?可能的值：
| Pending（懸決） | Pod 已被 Kubernetes 系統(tǒng)接受，但有一個(gè)或者多個(gè)容器尚未創(chuàng)建亦未運(yùn)行。此階段包括等待 Pod 被調(diào)度的時(shí)間和通過網(wǎng)絡(luò)下載鏡像的時(shí)間， |
| Running（運(yùn)行中） | Pod 已經(jīng)綁定到了某個(gè)節(jié)點(diǎn)，Pod 中所有的容器都已被創(chuàng)建。至少有一個(gè)容器仍在運(yùn)行，或者正處于啟動(dòng)或重啟狀態(tài)。 |
| Succeeded（成功） | Pod 中的所有容器都已成功終止，并且不會(huì)再重啟。 |
| Failed（失敗） | Pod 中的所有容器都已終止，并且至少有一個(gè)容器是因?yàn)槭〗K止。也就是說，容器以非 0 狀態(tài)退出或者被系統(tǒng)終止。 |
| Unknown（未知） | 因?yàn)槟承┰驘o法取得 Pod 的狀態(tài)。這種情況通常是因?yàn)榕c Pod 所在主機(jī)通信失敗。 |
如果某節(jié)點(diǎn)死掉或者與集群中其他節(jié)點(diǎn)失聯(lián)，Kubernetes 會(huì)實(shí)施一種策略，將失去的節(jié)點(diǎn)上運(yùn)行的所有 Pod 的?phase?設(shè)置為?Failed。
容器狀態(tài)
Kubernetes 會(huì)跟蹤 Pod 中每個(gè)容器的狀態(tài)，就像它跟蹤 Pod 總體上的階段一樣。 你可以使用容器生命周期回調(diào)?來在容器生命周期中的特定時(shí)間點(diǎn)觸發(fā)事件。
一旦調(diào)度器將 Pod 分派給某個(gè)節(jié)點(diǎn)，kubelet?就通過?容器運(yùn)行時(shí)?開始為 Pod 創(chuàng)建容器。 容器的狀態(tài)有三種：Waiting（等待）、Running（運(yùn)行中）和?Terminated（已終止）。
要檢查 Pod 中容器的狀態(tài)，你可以使用?kubectl describe pod <pod 名稱>。 其輸出中包含 Pod 中每個(gè)容器的狀態(tài)。
每種狀態(tài)都有特定的含義：
Waiting?（等待）
如果容器并不處在?Running?或?Terminated?狀態(tài)之一，它就處在?Waiting?狀態(tài)。 處于?Waiting?狀態(tài)的容器仍在運(yùn)行它完成啟動(dòng)所需要的操作：例如，從某個(gè)容器鏡像 倉庫拉取容器鏡像，或者向容器應(yīng)用?Secret?數(shù)據(jù)等等。 當(dāng)你使用?kubectl?來查詢包含?Waiting?狀態(tài)的容器的 Pod 時(shí)，你也會(huì)看到一個(gè) Reason 字段，其中給出了容器處于等待狀態(tài)的原因。
Running（運(yùn)行中）
Running?狀態(tài)表明容器正在執(zhí)行狀態(tài)并且沒有問題發(fā)生。 如果配置了?postStart?回調(diào)，那么該回調(diào)已經(jīng)執(zhí)行且已完成。 如果你使用?kubectl?來查詢包含?Running?狀態(tài)的容器的 Pod 時(shí)，你也會(huì)看到 關(guān)于容器進(jìn)入?Running?狀態(tài)的信息。
Terminated（已終止）
處于?Terminated?狀態(tài)的容器已經(jīng)開始執(zhí)行并且或者正常結(jié)束或者因?yàn)槟承┰蚴 ?如果你使用?kubectl?來查詢包含?Terminated?狀態(tài)的容器的 Pod 時(shí)，你會(huì)看到 容器進(jìn)入此狀態(tài)的原因、退出代碼以及容器執(zhí)行期間的起止時(shí)間。
如果容器配置了?preStop?回調(diào)，則該回調(diào)會(huì)在容器進(jìn)入?Terminated?狀態(tài)之前執(zhí)行。
容器重啟策略
Pod 的?spec?中包含一個(gè)?restartPolicy?字段，其可能取值包括 Always、OnFailure 和 Never。默認(rèn)值是 Always。
restartPolicy?適用于 Pod 中的所有容器。restartPolicy?僅針對(duì)同一節(jié)點(diǎn)上?kubelet?的容器重啟動(dòng)作。當(dāng) Pod 中的容器退出時(shí)，kubelet?會(huì)按指數(shù)回退 方式計(jì)算重啟的延遲（10s、20s、40s、...），其最長(zhǎng)延遲為 5 分鐘。 一旦某容器執(zhí)行了 10 分鐘并且沒有出現(xiàn)問題，kubelet?對(duì)該容器的重啟回退計(jì)時(shí)器執(zhí)行 重置操作。
Pod 狀況
Pod 有一個(gè) PodStatus 對(duì)象，其中包含一個(gè)?PodConditions?數(shù)組。Pod 可能通過也可能未通過其中的一些狀況測(cè)試。
- PodScheduled：Pod 已經(jīng)被調(diào)度到某節(jié)點(diǎn)；
- ContainersReady：Pod 中所有容器都已就緒；
- Initialized：所有的?Init 容器?都已成功啟動(dòng)；
- Ready：Pod 可以為請(qǐng)求提供服務(wù)，并且應(yīng)該被添加到對(duì)應(yīng)服務(wù)的負(fù)載均衡池中。
| type | Pod 狀況的名稱 |
| status | 表明該狀況是否適用，可能的取值有 "True", "False" 或 "Unknown" |
| lastProbeTime | 上次探測(cè) Pod 狀況時(shí)的時(shí)間戳 |
| lastTransitionTime | Pod 上次從一種狀態(tài)轉(zhuǎn)換到另一種狀態(tài)時(shí)的時(shí)間戳 |
| reason | 機(jī)器可讀的、駝峰編碼（UpperCamelCase）的文字，表述上次狀況變化的原因 |
| message | 人類可讀的消息，給出上次狀態(tài)轉(zhuǎn)換的詳細(xì)信息 |
Pod 就緒態(tài)
FEATURE STATE:?Kubernetes v1.14 [stable]
你的應(yīng)用可以向 PodStatus 中注入額外的反饋或者信號(hào)：Pod Readiness（Pod 就緒態(tài)）。 要使用這一特性，可以設(shè)置 Pod 規(guī)約中的?readinessGates?列表，為 kubelet 提供一組額外的狀況供其評(píng)估 Pod 就緒態(tài)時(shí)使用。
就緒態(tài)門控基于 Pod 的?status.conditions?字段的當(dāng)前值來做決定。 如果 Kubernetes 無法在?status.conditions?字段中找到某狀況，則該狀況的 狀態(tài)值默認(rèn)為 "False"。
這里是一個(gè)例子：
kind: Pod ... spec:readinessGates:- conditionType: "www.example.com/feature-1" status:conditions:- type: Ready # 內(nèi)置的 Pod 狀況status: "False"lastProbeTime: nulllastTransitionTime: 2018-01-01T00:00:00Z- type: "www.example.com/feature-1" # 額外的 Pod 狀況status: "False"lastProbeTime: nulllastTransitionTime: 2018-01-01T00:00:00ZcontainerStatuses:- containerID: docker://abcd...ready: true ...你所添加的 Pod 狀況名稱必須滿足 Kubernetes?標(biāo)簽鍵名格式。
Pod 就緒態(tài)的狀態(tài)
命令?kubectl patch?不支持修改對(duì)象的狀態(tài)。 如果需要設(shè)置 Pod 的?status.conditions，應(yīng)用或者?Operators?需要使用?PATCH?操作。 你可以使用?Kubernetes 客戶端庫?之一來編寫代碼，針對(duì) Pod 就緒態(tài)設(shè)置定制的 Pod 狀況。
對(duì)于使用定制狀況的 Pod 而言，只有當(dāng)下面的陳述都適用時(shí)，該 Pod 才會(huì)被評(píng)估為就緒：
- Pod 中所有容器都已就緒；
- readinessGates?中的所有狀況都為?True?值。
當(dāng) Pod 的容器都已就緒，但至少一個(gè)定制狀況沒有取值或者取值為?False，?kubelet?將 Pod 的狀況設(shè)置為?ContainersReady。
容器探針
Probe?是由?kubelet?對(duì)容器執(zhí)行的定期診斷。 要執(zhí)行診斷，kubelet 調(diào)用由容器實(shí)現(xiàn)的?Handler?（處理程序）。有三種類型的處理程序：
-
ExecAction： 在容器內(nèi)執(zhí)行指定命令。如果命令退出時(shí)返回碼為 0 則認(rèn)為診斷成功。
-
TCPSocketAction： 對(duì)容器的 IP 地址上的指定端口執(zhí)行 TCP 檢查。如果端口打開，則診斷被認(rèn)為是成功的。
-
HTTPGetAction： 對(duì)容器的 IP 地址上指定端口和路徑執(zhí)行 HTTP Get 請(qǐng)求。如果響應(yīng)的狀態(tài)碼大于等于 200 且小于 400，則診斷被認(rèn)為是成功的。
每次探測(cè)都將獲得以下三種結(jié)果之一：
- Success（成功）：容器通過了診斷。
- Failure（失敗）：容器未通過診斷。
- Unknown（未知）：診斷失敗，因此不會(huì)采取任何行動(dòng)。
針對(duì)運(yùn)行中的容器，kubelet?可以選擇是否執(zhí)行以下三種探針，以及如何針對(duì)探測(cè)結(jié)果作出反應(yīng)：
-
livenessProbe：指示容器是否正在運(yùn)行。如果存活態(tài)探測(cè)失敗，則 kubelet 會(huì)殺死容器， 并且容器將根據(jù)其重啟策略決定未來。如果容器不提供存活探針， 則默認(rèn)狀態(tài)為?Success。
-
readinessProbe：指示容器是否準(zhǔn)備好為請(qǐng)求提供服務(wù)。如果就緒態(tài)探測(cè)失敗， 端點(diǎn)控制器將從與 Pod 匹配的所有服務(wù)的端點(diǎn)列表中刪除該 Pod 的 IP 地址。 初始延遲之前的就緒態(tài)的狀態(tài)值默認(rèn)為?Failure。 如果容器不提供就緒態(tài)探針，則默認(rèn)狀態(tài)為?Success。
-
startupProbe: 指示容器中的應(yīng)用是否已經(jīng)啟動(dòng)。如果提供了啟動(dòng)探針，則所有其他探針都會(huì)被 禁用，直到此探針成功為止。如果啟動(dòng)探測(cè)失敗，kubelet?將殺死容器，而容器依其?重啟策略進(jìn)行重啟。 如果容器沒有提供啟動(dòng)探測(cè)，則默認(rèn)狀態(tài)為?Success。
如欲了解如何設(shè)置存活態(tài)、就緒態(tài)和啟動(dòng)探針的進(jìn)一步細(xì)節(jié)，可以參閱?配置存活態(tài)、就緒態(tài)和啟動(dòng)探針。
何時(shí)該使用存活態(tài)探針?
FEATURE STATE:?Kubernetes v1.0 [stable]
如果容器中的進(jìn)程能夠在遇到問題或不健康的情況下自行崩潰，則不一定需要存活態(tài)探針;?kubelet?將根據(jù) Pod 的restartPolicy?自動(dòng)執(zhí)行修復(fù)操作。
如果你希望容器在探測(cè)失敗時(shí)被殺死并重新啟動(dòng)，那么請(qǐng)指定一個(gè)存活態(tài)探針， 并指定restartPolicy?為 "Always" 或 "OnFailure"。
何時(shí)該使用就緒態(tài)探針?
FEATURE STATE:?Kubernetes v1.0 [stable]
如果要僅在探測(cè)成功時(shí)才開始向 Pod 發(fā)送請(qǐng)求流量，請(qǐng)指定就緒態(tài)探針。 在這種情況下，就緒態(tài)探針可能與存活態(tài)探針相同，但是規(guī)約中的就緒態(tài)探針的存在意味著 Pod 將在啟動(dòng)階段不接收任何數(shù)據(jù)，并且只有在探針探測(cè)成功后才開始接收數(shù)據(jù)。
如果你的容器需要加載大規(guī)模的數(shù)據(jù)、配置文件或者在啟動(dòng)期間執(zhí)行遷移操作，可以添加一個(gè) 就緒態(tài)探針。
如果你希望容器能夠自行進(jìn)入維護(hù)狀態(tài)，也可以指定一個(gè)就緒態(tài)探針，檢查某個(gè)特定于 就緒態(tài)的因此不同于存活態(tài)探測(cè)的端點(diǎn)。
說明：請(qǐng)注意，如果你只是想在 Pod 被刪除時(shí)能夠排空請(qǐng)求，則不一定需要使用就緒態(tài)探針； 在刪除 Pod 時(shí)，Pod 會(huì)自動(dòng)將自身置于未就緒狀態(tài)，無論就緒態(tài)探針是否存在。 等待 Pod 中的容器停止期間，Pod 會(huì)一直處于未就緒狀態(tài)。
何時(shí)該使用啟動(dòng)探針？
FEATURE STATE:?Kubernetes v1.18 [beta]
對(duì)于所包含的容器需要較長(zhǎng)時(shí)間才能啟動(dòng)就緒的 Pod 而言，啟動(dòng)探針是有用的。 你不再需要配置一個(gè)較長(zhǎng)的存活態(tài)探測(cè)時(shí)間間隔，只需要設(shè)置另一個(gè)獨(dú)立的配置選定， 對(duì)啟動(dòng)期間的容器執(zhí)行探測(cè)，從而允許使用遠(yuǎn)遠(yuǎn)超出存活態(tài)時(shí)間間隔所允許的時(shí)長(zhǎng)。
如果你的容器啟動(dòng)時(shí)間通常超出?initialDelaySeconds + failureThreshold × periodSeconds?總值，你應(yīng)該設(shè)置一個(gè)啟動(dòng)探測(cè)，對(duì)存活態(tài)探針?biāo)褂玫耐欢它c(diǎn)執(zhí)行檢查。?periodSeconds?的默認(rèn)值是 10 秒。你應(yīng)該將其?failureThreshold?設(shè)置得足夠高， 以便容器有充足的時(shí)間完成啟動(dòng)，并且避免更改存活態(tài)探針?biāo)褂玫哪J(rèn)值。 這一設(shè)置有助于減少死鎖狀況的發(fā)生。
Pod 的終止
由于 Pod 所代表的是在集群中節(jié)點(diǎn)上運(yùn)行的進(jìn)程，當(dāng)不再需要這些進(jìn)程時(shí)允許其體面地 終止是很重要的。一般不應(yīng)武斷地使用?KILL?信號(hào)終止它們，導(dǎo)致這些進(jìn)程沒有機(jī)會(huì) 完成清理操作。
設(shè)計(jì)的目標(biāo)是令你能夠請(qǐng)求刪除進(jìn)程，并且知道進(jìn)程何時(shí)被終止，同時(shí)也能夠確保刪除 操作終將完成。當(dāng)你請(qǐng)求刪除某個(gè) Pod 時(shí)，集群會(huì)記錄并跟蹤 Pod 的體面終止周期， 而不是直接強(qiáng)制地殺死 Pod。在存在強(qiáng)制關(guān)閉設(shè)施的前提下，?kubelet?會(huì)嘗試體面地終止 Pod。
通常情況下，容器運(yùn)行時(shí)會(huì)發(fā)送一個(gè) TERM 信號(hào)到每個(gè)容器中的主進(jìn)程。 很多容器運(yùn)行時(shí)都能夠注意到容器鏡像中?STOPSIGNAL?的值，并發(fā)送該信號(hào)而不是 TERM。 一旦超出了體面終止限期，容器運(yùn)行時(shí)會(huì)向所有剩余進(jìn)程發(fā)送 KILL 信號(hào)，之后 Pod 就會(huì)被從?API 服務(wù)器?上移除。如果?kubelet?或者容器運(yùn)行時(shí)的管理服務(wù)在等待進(jìn)程終止期間被重啟， 集群會(huì)從頭開始重試，賦予 Pod 完整的體面終止限期。
下面是一個(gè)例子：
你使用?kubectl?工具手動(dòng)刪除某個(gè)特定的 Pod，而該 Pod 的體面終止限期是默認(rèn)值（30 秒）。
API 服務(wù)器中的 Pod 對(duì)象被更新，記錄涵蓋體面終止限期在內(nèi) Pod 的最終死期，超出所計(jì)算時(shí)間點(diǎn)則認(rèn)為 Pod 已死（dead）。 如果你使用?kubectl describe?來查驗(yàn)?zāi)阏趧h除的 Pod，該 Pod 會(huì)顯示為 "Terminating" （正在終止）。 在 Pod 運(yùn)行所在的節(jié)點(diǎn)上：kubelet?一旦看到 Pod 被標(biāo)記為正在終止（已經(jīng)設(shè)置了體面終止限期），kubelet?即開始本地的 Pod 關(guān)閉過程。
如果 Pod 中的容器之一定義了?preStop?回調(diào)，?kubelet?開始在容器內(nèi)運(yùn)行該回調(diào)邏輯。如果超出體面終止限期時(shí)，preStop?回調(diào)邏輯 仍在運(yùn)行，kubelet?會(huì)請(qǐng)求給予該 Pod 的寬限期一次性增加 2 秒鐘。
說明：?如果?preStop?回調(diào)所需要的時(shí)間長(zhǎng)于默認(rèn)的體面終止限期，你必須修改?terminationGracePeriodSeconds?屬性值來使其正常工作。
kubelet?接下來觸發(fā)容器運(yùn)行時(shí)發(fā)送 TERM 信號(hào)給每個(gè)容器中的進(jìn)程 1。
說明：?Pod 中的容器會(huì)在不同時(shí)刻收到 TERM 信號(hào)，接收順序也是不確定的。 如果關(guān)閉的順序很重要，可以考慮使用?preStop?回調(diào)邏輯來協(xié)調(diào)。
超出終止寬限期限時(shí)，kubelet?會(huì)觸發(fā)強(qiáng)制關(guān)閉過程。容器運(yùn)行時(shí)會(huì)向 Pod 中所有容器內(nèi) 仍在運(yùn)行的進(jìn)程發(fā)送?SIGKILL?信號(hào)。?kubelet?也會(huì)清理隱藏的?pause?容器，如果容器運(yùn)行時(shí)使用了這種容器的話。
kubelet?觸發(fā)強(qiáng)制從 API 服務(wù)器上刪除 Pod 對(duì)象的邏輯，并將體面終止限期設(shè)置為 0 （這意味著馬上刪除）。
API 服務(wù)器刪除 Pod 的 API 對(duì)象，從任何客戶端都無法再看到該對(duì)象。
強(qiáng)制終止 Pod
注意：?對(duì)于某些工作負(fù)載及其 Pod 而言，強(qiáng)制刪除很可能會(huì)帶來某種破壞。
默認(rèn)情況下，所有的刪除操作都會(huì)附有 30 秒鐘的寬限期限。?kubectl delete?命令支持?--grace-period=<seconds>?選項(xiàng)，允許你重載默認(rèn)值， 設(shè)定自己希望的期限值。
將寬限期限強(qiáng)制設(shè)置為?0?意味著立即從 API 服務(wù)器刪除 Pod。 如果 Pod 仍然運(yùn)行于某節(jié)點(diǎn)上，強(qiáng)制刪除操作會(huì)觸發(fā)?kubelet?立即執(zhí)行清理操作。
說明：?你必須在設(shè)置?--grace-period=0?的同時(shí)額外設(shè)置?--force?參數(shù)才能發(fā)起強(qiáng)制刪除請(qǐng)求。
執(zhí)行強(qiáng)制刪除操作時(shí)，API 服務(wù)器不再等待來自?kubelet?的、關(guān)于 Pod 已經(jīng)在原來運(yùn)行的節(jié)點(diǎn)上終止執(zhí)行的確認(rèn)消息。 API 服務(wù)器直接刪除 Pod 對(duì)象，這樣新的與之同名的 Pod 即可以被創(chuàng)建。 在節(jié)點(diǎn)側(cè)，被設(shè)置為立即終止的 Pod 仍然會(huì)在被強(qiáng)行殺死之前獲得一點(diǎn)點(diǎn)的寬限時(shí)間。
如果你需要強(qiáng)制刪除 StatefulSet 的 Pod，請(qǐng)參閱?從 StatefulSet 中刪除 Pod?的任務(wù)文檔。
失效 Pod 的垃圾收集
對(duì)于已失敗的 Pod 而言，對(duì)應(yīng)的 API 對(duì)象仍然會(huì)保留在集群的 API 服務(wù)器上，直到 用戶或者控制器進(jìn)程顯式地 將其刪除。
控制面組件會(huì)在 Pod 個(gè)數(shù)超出所配置的閾值 （根據(jù)?kube-controller-manager?的?terminated-pod-gc-threshold?設(shè)置）時(shí) 刪除已終止的 Pod（階段值為?Succeeded?或?Failed）。 這一行為會(huì)避免隨著時(shí)間演進(jìn)不斷創(chuàng)建和終止 Pod 而引起的資源泄露問題
?
?
?
?
?
?
?
配置存活、就緒和啟動(dòng)探測(cè)器
kubelet?使用存活探測(cè)器來知道什么時(shí)候要重啟容器。 例如，存活探測(cè)器可以捕捉到死鎖（應(yīng)用程序在運(yùn)行，但是無法繼續(xù)執(zhí)行后面的步驟）。 這樣的情況下重啟容器有助于讓應(yīng)用程序在有問題的情況下更可用。
kubelet 使用就緒探測(cè)器可以知道容器什么時(shí)候準(zhǔn)備好了并可以開始接受請(qǐng)求流量， 當(dāng)一個(gè) Pod 內(nèi)的所有容器都準(zhǔn)備好了，才能把這個(gè) Pod 看作就緒了。 這種信號(hào)的一個(gè)用途就是控制哪個(gè) Pod 作為 Service 的后端。 在 Pod 還沒有準(zhǔn)備好的時(shí)候，會(huì)從 Service 的負(fù)載均衡器中被剔除的。
kubelet 使用啟動(dòng)探測(cè)器可以知道應(yīng)用程序容器什么時(shí)候啟動(dòng)了。 如果配置了這類探測(cè)器，就可以控制容器在啟動(dòng)成功后再進(jìn)行存活性和就緒檢查， 確保這些存活、就緒探測(cè)器不會(huì)影響應(yīng)用程序的啟動(dòng)。 這可以用于對(duì)慢啟動(dòng)容器進(jìn)行存活性檢測(cè)，避免它們?cè)趩?dòng)運(yùn)行之前就被殺掉。
準(zhǔn)備開始
你必須擁有一個(gè) Kubernetes 的集群，同時(shí)你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 如果你還沒有集群，你可以通過?Minikube?構(gòu)建一 個(gè)你自己的集群，或者你可以使用下面任意一個(gè) Kubernetes 工具構(gòu)建：
- Katacoda
- 玩轉(zhuǎn) Kubernetes
定義存活命令
許多長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序最終會(huì)過渡到斷開的狀態(tài)，除非重新啟動(dòng)，否則無法恢復(fù)。 Kubernetes 提供了存活探測(cè)器來發(fā)現(xiàn)并補(bǔ)救這種情況。
?
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 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5在這個(gè)配置文件中，可以看到 Pod 中只有一個(gè)容器。?periodSeconds?字段指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測(cè)。?initialDelaySeconds?字段告訴 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待 5 秒。 kubelet 在容器內(nèi)執(zhí)行命令?cat /tmp/healthy?來進(jìn)行探測(cè)。 如果命令執(zhí)行成功并且返回值為 0，kubelet 就會(huì)認(rèn)為這個(gè)容器是健康存活的。 如果這個(gè)命令返回非 0 值，kubelet 會(huì)殺死這個(gè)容器并重新啟動(dòng)它。
當(dāng)容器啟動(dòng)時(shí)，執(zhí)行如下的命令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"這個(gè)容器生命的前 30 秒，?/tmp/healthy?文件是存在的。 所以在這最開始的 30 秒內(nèi)，執(zhí)行命令?cat /tmp/healthy?會(huì)返回成功代碼。 30 秒之后，執(zhí)行命令?cat /tmp/healthy?就會(huì)返回失敗代碼。
創(chuàng)建 Pod：
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml在 30 秒內(nèi)，查看 Pod 的事件：
kubectl describe pod liveness-exec輸出結(jié)果表明還沒有存活探測(cè)器失敗：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e35 秒之后，再來看 Pod 的事件：
kubectl describe pod liveness-exec在輸出結(jié)果的最下面，有信息顯示存活探測(cè)器失敗了，這個(gè)容器被殺死并且被重建了。
FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox" 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox" 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e 2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory再等另外 30 秒，檢查看這個(gè)容器被重啟了：
kubectl get pod liveness-exec輸出結(jié)果顯示?RESTARTS?的值增加了 1。
NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 1 1m定義一個(gè)存活態(tài) HTTP 請(qǐng)求接口
另外一種類型的存活探測(cè)方式是使用 HTTP GET 請(qǐng)求。 下面是一個(gè) Pod 的配置文件，其中運(yùn)行一個(gè)基于?k8s.gcr.io/liveness?鏡像的容器。
pods/probe/http-liveness.yaml?
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è)容器。?periodSeconds?字段指定了 kubelet 每隔 3 秒執(zhí)行一次存活探測(cè)。?initialDelaySeconds?字段告訴 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待 3 秒。 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)示失敗。
可以在這里看服務(wù)的源碼?server.go。
容器存活的最開始 10 秒中，/healthz?處理程序返回一個(gè) 200 的狀態(tài)碼。之后處理程序返回 500 的狀態(tài)碼。
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {duration := time.Now().Sub(started)if duration.Seconds() > 10 {w.WriteHeader(500)w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))} else {w.WriteHeader(200)w.Write([]byte("ok"))} })kubelet 在容器啟動(dòng)之后 3 秒開始執(zhí)行健康檢測(cè)。所以前幾次健康檢查都是成功的。 但是 10 秒之后，健康檢查會(huì)失敗，并且 kubelet 會(huì)殺死容器再重新啟動(dòng)容器。
創(chuàng)建一個(gè) Pod 來測(cè)試 HTTP 的存活檢測(cè)：
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml10 秒之后，通過看 Pod 事件來檢測(cè)存活探測(cè)器已經(jīng)失敗了并且容器被重新啟動(dòng)了。
kubectl describe pod liveness-http在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 運(yùn)行的節(jié)點(diǎn)上設(shè)置了環(huán)境變量?http_proxy（或者?HTTP_PROXY），HTTP 的存活探測(cè)會(huì)使用這個(gè)代理。 在 1.13 之后的版本中，設(shè)置本地的 HTTP 代理環(huán)境變量不會(huì)影響 HTTP 的存活探測(cè)。
定義 TCP 的存活探測(cè)
第三種類型的存活探測(cè)是使用 TCP 套接字。 通過配置，kubelet 會(huì)嘗試在指定端口和容器建立套接字鏈接。 如果能建立連接，這個(gè)容器就被看作是健康的，如果不能則這個(gè)容器就被看作是有問題的。
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如你所見，TCP 檢測(cè)的配置和 HTTP 檢測(cè)非常相似。 下面這個(gè)例子同時(shí)使用就緒和存活探測(cè)器。kubelet 會(huì)在容器啟動(dòng) 5 秒后發(fā)送第一個(gè)就緒探測(cè)。 這會(huì)嘗試連接?goproxy?容器的 8080 端口。 如果探測(cè)成功，這個(gè) Pod 會(huì)被標(biāo)記為就緒狀態(tài)，kubelet 將繼續(xù)每隔 10 秒運(yùn)行一次檢測(cè)。
除了就緒探測(cè)，這個(gè)配置包括了一個(gè)存活探測(cè)。 kubelet 會(huì)在容器啟動(dòng) 15 秒后進(jìn)行第一次存活探測(cè)。 與就緒探測(cè)類似，會(huì)嘗試連接?goproxy?容器的 8080 端口。 如果存活探測(cè)失敗，這個(gè)容器會(huì)被重新啟動(dòng)。
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml15 秒之后，通過看 Pod 事件來檢測(cè)存活探測(cè)器：
kubectl describe pod goproxy使用命名端口
對(duì)于 HTTP 或者 TCP 存活檢測(cè)可以使用命名的?ContainerPort。
ports: - name: liveness-portcontainerPort: 8080hostPort: 8080livenessProbe:httpGet:path: /healthzport: liveness-port使用啟動(dòng)探測(cè)器保護(hù)慢啟動(dòng)容器
有時(shí)候，會(huì)有一些現(xiàn)有的應(yīng)用程序在啟動(dòng)時(shí)需要較多的初始化時(shí)間。 要不影響對(duì)引起探測(cè)死鎖的快速響應(yīng)，這種情況下，設(shè)置存活探測(cè)參數(shù)是要技巧的。 技巧就是使用一個(gè)命令來設(shè)置啟動(dòng)探測(cè)，針對(duì)HTTP 或者 TCP 檢測(cè)，可以通過設(shè)置?failureThreshold * periodSeconds?參數(shù)來保證有足夠長(zhǎng)的時(shí)間應(yīng)對(duì)糟糕情況下的啟動(dòng)時(shí)間。
所以，前面的例子就變成了：
ports: - name: liveness-portcontainerPort: 8080hostPort: 8080livenessProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 1periodSeconds: 10startupProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 30periodSeconds: 10幸虧有啟動(dòng)探測(cè)，應(yīng)用程序?qū)?huì)有最多 5 分鐘(30 * 10 = 300s) 的時(shí)間來完成它的啟動(dòng)。 一旦啟動(dòng)探測(cè)成功一次，存活探測(cè)任務(wù)就會(huì)接管對(duì)容器的探測(cè)，對(duì)容器死鎖可以快速響應(yīng)。 如果啟動(dòng)探測(cè)一直沒有成功，容器會(huì)在 300 秒后被殺死，并且根據(jù)?restartPolicy?來設(shè)置 Pod 狀態(tài)。
定義就緒探測(cè)器
有時(shí)候，應(yīng)用程序會(huì)暫時(shí)性的不能提供通信服務(wù)。 例如，應(yīng)用程序在啟動(dòng)時(shí)可能需要加載很大的數(shù)據(jù)或配置文件，或是啟動(dòng)后要依賴等待外部服務(wù)。 在這種情況下，既不想殺死應(yīng)用程序，也不想給它發(fā)送請(qǐng)求。 Kubernetes 提供了就緒探測(cè)器來發(fā)現(xiàn)并緩解這些情況。 容器所在 Pod 上報(bào)還未就緒的信息，并且不接受通過 Kubernetes Service 的流量。
說明：?就緒探測(cè)器在容器的整個(gè)生命周期中保持運(yùn)行狀態(tài)。
注意：?活躍性探測(cè)器?不等待?就緒性探測(cè)器成功。 如果要在執(zhí)行活躍性探測(cè)器之前等待，應(yīng)該使用 initialDelaySeconds 或 startupProbe。
就緒探測(cè)器的配置和存活探測(cè)器的配置相似。 唯一區(qū)別就是要使用?readinessProbe?字段，而不是?livenessProbe?字段。
readinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5HTTP 和 TCP 的就緒探測(cè)器配置也和存活探測(cè)器的配置一樣的。
就緒和存活探測(cè)可以在同一個(gè)容器上并行使用。 兩者都用可以確保流量不會(huì)發(fā)給還沒有準(zhǔn)備好的容器，并且容器會(huì)在它們失敗的時(shí)候被重新啟動(dòng)。
配置探測(cè)器
Probe?有很多配置字段，可以使用這些字段精確的控制存活和就緒檢測(cè)的行為：
- initialDelaySeconds：容器啟動(dòng)后要等待多少秒后存活和就緒探測(cè)器才被初始化，默認(rèn)是 0 秒，最小值是 0。
- periodSeconds：執(zhí)行探測(cè)的時(shí)間間隔（單位是秒）。默認(rèn)是 10 秒。最小值是 1。
- timeoutSeconds：探測(cè)的超時(shí)后等待多少秒。默認(rèn)值是 1 秒。最小值是 1。
- successThreshold：探測(cè)器在失敗后，被視為成功的最小連續(xù)成功數(shù)。默認(rèn)值是 1。 存活和啟動(dòng)探測(cè)的這個(gè)值必須是 1。最小值是 1。
- failureThreshold：當(dāng)探測(cè)失敗時(shí)，Kubernetes 的重試次數(shù)。 存活探測(cè)情況下的放棄就意味著重新啟動(dòng)容器。 就緒探測(cè)情況下的放棄 Pod 會(huì)被打上未就緒的標(biāo)簽。默認(rèn)值是 3。最小值是 1。
?
說明：在 Kubernetes 1.20 版本之前，exec 探針會(huì)忽略?timeoutSeconds：探針會(huì)無限期地 持續(xù)運(yùn)行，甚至可能超過所配置的限期，直到返回結(jié)果為止。
這一缺陷在 Kubernetes v1.20 版本中得到修復(fù)。你可能一直依賴于之前錯(cuò)誤的探測(cè)行為， 甚至你都沒有覺察到這一問題的存在，因?yàn)槟J(rèn)的超時(shí)值是 1 秒鐘。 作為集群管理員，你可以在所有的 kubelet 上禁用?ExecProbeTimeout?特性門控?（將其設(shè)置為?false），從而恢復(fù)之前版本中的運(yùn)行行為，之后當(dāng)集群中所有的 exec 探針都設(shè)置了?timeoutSeconds?參數(shù)后，移除此標(biāo)志重載。 如果你有 Pods 受到此默認(rèn) 1 秒鐘超時(shí)值的影響，你應(yīng)該更新 Pod 對(duì)應(yīng)的探針的 超時(shí)值，這樣才能為最終去除該特性門控做好準(zhǔn)備。
當(dāng)此缺陷被修復(fù)之后，在使用?dockershim?容器運(yùn)行時(shí)的 Kubernetes?1.20+?版本中，對(duì)于 exec 探針而言，容器中的進(jìn)程可能會(huì)因?yàn)槌瑫r(shí)值的設(shè)置保持持續(xù)運(yùn)行， 即使探針返回了失敗狀態(tài)。
注意：如果就緒態(tài)探針的實(shí)現(xiàn)不正確，可能會(huì)導(dǎo)致容器中進(jìn)程的數(shù)量不斷上升。 如果不對(duì)其采取措施，很可能導(dǎo)致資源枯竭的狀況。
HTTP 探測(cè)
HTTP Probes?可以在?httpGet?上配置額外的字段：
- host：連接使用的主機(jī)名，默認(rèn)是 Pod 的 IP。也可以在 HTTP 頭中設(shè)置 “Host” 來代替。
- scheme?：用于設(shè)置連接主機(jī)的方式（HTTP 還是 HTTPS）。默認(rèn)是 HTTP。
- path：訪問 HTTP 服務(wù)的路徑。默認(rèn)值為 "/"。
- httpHeaders：請(qǐng)求中自定義的 HTTP 頭。HTTP 頭字段允許重復(fù)。
- port：訪問容器的端口號(hào)或者端口名。如果數(shù)字必須在 1 ～ 65535 之間。
對(duì)于 HTTP 探測(cè)，kubelet 發(fā)送一個(gè) HTTP 請(qǐng)求到指定的路徑和端口來執(zhí)行檢測(cè)。 除非?httpGet?中的?host?字段設(shè)置了，否則 kubelet 默認(rèn)是給 Pod 的 IP 地址發(fā)送探測(cè)。 如果?scheme?字段設(shè)置為了?HTTPS，kubelet 會(huì)跳過證書驗(yàn)證發(fā)送 HTTPS 請(qǐng)求。 大多數(shù)情況下，不需要設(shè)置host?字段。 這里有個(gè)需要設(shè)置?host?字段的場(chǎng)景，假設(shè)容器監(jiān)聽 127.0.0.1，并且 Pod 的?hostNetwork?字段設(shè)置為了?true。那么?httpGet?中的?host?字段應(yīng)該設(shè)置為 127.0.0.1。 可能更常見的情況是如果 Pod 依賴虛擬主機(jī)，你不應(yīng)該設(shè)置?host?字段，而是應(yīng)該在?httpHeaders?中設(shè)置?Host。
針對(duì) HTTP 探針，kubelet 除了必需的?Host?頭部之外還發(fā)送兩個(gè)請(qǐng)求頭部字段：?User-Agent?和?Accept。這些頭部的默認(rèn)值分別是?kube-probe/{{ skew latestVersion >}}?（其中?1.21?是 kubelet 的版本號(hào)）和?*/*。
你可以通過為探測(cè)設(shè)置?.httpHeaders?來重載默認(rèn)的頭部字段值；例如：
livenessProbe:httpGet:httpHeaders:- name: Acceptvalue: application/jsonstartupProbe:httpGet:httpHeaders:- name: User-Agentvalue: MyUserAgent你也可以通過將這些頭部字段定義為空值，從請(qǐng)求中去掉這些頭部字段。
livenessProbe:httpGet:httpHeaders:- name: Acceptvalue: ""startupProbe:httpGet:httpHeaders:- name: User-Agentvalue: ""TCP 探測(cè)
對(duì)于一次 TCP 探測(cè)，kubelet 在節(jié)點(diǎn)上（不是在 Pod 里面）建立探測(cè)連接， 這意味著你不能在?host?參數(shù)上配置服務(wù)名稱，因?yàn)?kubelet 不能解析服務(wù)名稱。
探測(cè)器級(jí)別?terminationGracePeriodSeconds
FEATURE STATE:?Kubernetes v1.21 [alpha]
在 1.21 版之前，pod 級(jí)別的?terminationGracePeriodSeconds?被用來終止 未能成功處理活躍性探測(cè)或啟動(dòng)探測(cè)的容器。 這種耦合是意料之外的，可能會(huì)導(dǎo)致在設(shè)置了 pod 級(jí)別的?terminationGracePeriodSeconds?后， 需要很長(zhǎng)的時(shí)間來重新啟動(dòng)失敗的容器。
在1.21中，啟用特性標(biāo)志?ProbeTerminationGracePeriod?后， 用戶可以指定一個(gè)探測(cè)器級(jí)別的?terminationGracePeriodSeconds?作為探測(cè)器規(guī)格的一部分。 當(dāng)該特性標(biāo)志被啟用時(shí)，若同時(shí)設(shè)置了 Pod 級(jí)別和探測(cè)器級(jí)別的?terminationGracePeriodSeconds， kubelet 將使用探測(cè)器級(jí)的值。
例如，
spec:terminationGracePeriodSeconds: 3600 # pod-levelcontainers:- name: testimage: ...ports:- name: liveness-portcontainerPort: 8080hostPort: 8080livenessProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 1periodSeconds: 60# Override pod-level terminationGracePeriodSeconds #terminationGracePeriodSeconds: 60探測(cè)器級(jí)別的?terminationGracePeriodSeconds?不能用于設(shè)置就緒態(tài)探針。 它將被 API 服務(wù)器拒絕。
?
?
?
?
?
總結(jié)
StartupProbe：k8s 1.16版本后新加的探測(cè)方式，用于判斷容器內(nèi)應(yīng)用程序是否已經(jīng)啟動(dòng)。如果配置了startupProbe，就會(huì)先禁止其他的探測(cè)，直到它成功為止，成功后將不再進(jìn)行探測(cè)。比較適用于容器啟動(dòng)時(shí)間長(zhǎng)的場(chǎng)景。
LivenessProbe：用于探測(cè)容器是否運(yùn)行，如果探測(cè)失敗，kubelet會(huì)根據(jù)配置的重啟策略進(jìn)行相應(yīng)的處理。若沒有配置該探針，默認(rèn)就是success。
ReadinessProbe：一般用于探測(cè)容器內(nèi)的程序是否健康，它的返回值如果為success，那么久代表這個(gè)容器已經(jīng)完成啟動(dòng)，并且程序已經(jīng)是可以接受流量的狀態(tài)。
?
#???startupProbe: # 可選，檢測(cè)容器內(nèi)進(jìn)程是否完成啟動(dòng) #??????httpGet:??????# httpGet檢測(cè)方式，生產(chǎn)環(huán)境建議使用httpGet實(shí)現(xiàn)接口級(jí)健康檢查，健康檢查由應(yīng)用程序提供。 #????????????path: /api/successStart # 檢查路徑 #????????????port: 80readinessProbe: # 可選，健康檢查httpGet:??????# httpGet檢測(cè)方式，生產(chǎn)環(huán)境建議使用httpGet實(shí)現(xiàn)接口級(jí)健康檢查，健康檢查由應(yīng)用程序提供。path: / # 檢查路徑port: 80????????# 監(jiān)控端口livenessProbe:??# 可選，健康檢查#exec:????????# 執(zhí)行容器命令檢測(cè)方式#command:?#- cat#- /health#httpGet:???????# httpGet檢測(cè)方式#???path: /_health # 檢查路徑#???port: 8080#???httpHeaders: # 檢查的請(qǐng)求頭#???- name: end-user#?????value: Jason?
二、Pod探針的檢測(cè)方式
注意：三種檢查方式同時(shí)只能使用一種。
ExecAction：在容器內(nèi)執(zhí)行一個(gè)命令，如果返回值為0，則認(rèn)為容器健康。
TCPSocketAction：通過TCP連接檢查容器內(nèi)的端口是否通的，如果是通的就認(rèn)為容器健康。
HTTPGetAction：通過應(yīng)用程序暴露的API地址檢查程序是否正常，如果狀態(tài)碼為200~400之間，則認(rèn)為容器健康。（常用）
三、探針檢查參數(shù)配置
# ?????initialDelaySeconds: 60 ??????# 初始化時(shí)間 # ?????timeoutSeconds: 2 ????# 超時(shí)時(shí)間 # ?????periodSeconds: 5 ?????# 檢測(cè)間隔 # ?????successThreshold: 1 # 檢查成功為1次表示就緒 # ?????failureThreshold: 2 # 檢測(cè)失敗2次表示未就緒?
?
?
?
?
?
總結(jié)
以上是生活随笔為你收集整理的Pod 的生命周期及探针的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SYSU每周一赛（13.03.16)10
- 下一篇： Clover Configurator