k8s家族Pod輔助小能手Init容器認知答疑？

• 2022 年 2 月 25 日
• 筆記
• k8s, Kubernetes, 雲原生, 囧么肥事, 容器, 胡說八道-k8s, 集群

k8s家族Pod輔助小能手Init容器認知答疑？

k8s集群Init 容器是一種特殊容器，職責是在Pod的生命周期中作為應用容器的前置啟動容器。

在很多應用場景中，在 Pod 內的應用容器正式啟動之前之前需要進行預熱操作，為正式啟動應用容器鋪墊先決條件，如預載入一些基本配置、資源限制配額、還可以包括一些應用鏡像中不存在的實用工具和安裝腳本

囧么肥事-胡說八道

Init容器有什麼特殊嗎？與普通容器有何不同？

k8s集群Init 容器是一種特殊容器，職責是在Pod的生命周期中作為應用容器的前置啟動容器。

在很多應用場景中，在 Pod 內的應用容器正式啟動之前之前需要進行預熱操作，為正式啟動應用容器鋪墊先決條件，如預載入一些基本配置、資源限制配額、還可以包括一些應用鏡像中不存在的實用工具和安裝腳本。例如

• 1、基於環境變數或配置模板生成配置文件

• 2、等待其他關聯組件載入完成（如MySQL資料庫服務，Nginx服務等）

• 3、下載相關依賴包，對系統預配置等

• 4、從遠程資料庫獲取本地應用所需配置，或將自己資料庫註冊到某個中央資料庫等

Init 容器與普通的容器非常像，Init 容器支援應用容器的全部欄位和特性，包括資源限制、數據卷和安全設置。

但是也有自己獨特的」性格「。

第一點Init容器必須保證成功啟動後才會啟動下個容器

如果 Pod 的 Init 容器失敗，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止，然後才會考慮去啟動其他容器。對自己的要求比較嚴格，只許成功，不許失敗！

第二點 Kubernetes 其實禁止Init容器使用 readinessProbe

因為 Init 容器不能定義不同於完成態（Completion）的就緒態（Readiness）

第二點Init 容器對資源請求和限制的處理稍有不同

在給定的 Init 容器執行順序下，資源使用適用於如下規則：

• 所有 Init 容器上定義的任何特定資源的 limit 或 request 的最大值，作為 Pod 有效初始 request/limit。 如果任何資源沒有指定資源限制，這被視為最高限制。
• Pod 對資源的有效 limit/request，取決於兩種判斷標準中的較大者
  • 所有應用容器對某個資源的 limit/request 之和
  • 對某個資源的有效初始 limit/request
• 基於有效 limit/request 完成調度，這意味著 Init 容器能夠為初始化過程預留資源， 這些資源在 Pod 生命周期過程中並沒有被使用。
• Pod 的 有效 QoS 層 ，與 Init 容器和應用容器的一樣。

配額和限制適用於有效 Pod 的請求和限制值。 Pod 級別的 cgroups 是基於有效 Pod 的請求和限制值，和調度器相同。

同時 Init 容器不支援 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因為它們必須在 Pod 就緒之前運行完成。

如果為一個 Pod 指定了多個 Init 容器，這些容器會按順序逐個運行。 每個 Init 容器必須運行成功，下一個才能夠運行。當所有的 Init 容器運行完成時， Kubernetes 才會為 Pod 初始化應用容器並像平常一樣運行。

它的啟動有什麼不同，如果多個Init容器啟動呢？失敗呢？

在 Pod 啟動過程中，每個 Init 容器會在網路和數據卷初始化之後按順序啟動。 kubelet 運行依據 Init 容器在 Pod 規約中的出現順序依次運行之。

如果 Pod 的 Init 容器失敗，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止。 然而，如果 Pod 對應的 restartPolicy 值為 “Never“，並且 Pod 的 Init 容器失敗， 則 Kubernetes 會將整個 Pod 狀態設置為失敗。

如果為一個 Pod 指定了多個 Init 容器，這些容器會按順序逐個運行。 每個 Init 容器必須運行成功，下一個才能夠運行。當所有的 Init 容器運行完成時， Kubernetes 才會為 Pod 初始化應用容器並像平常一樣運行。

使用 Init 容器有什麼優勢？

因為 Init 容器具有與應用容器分離的單獨鏡像，其啟動相關程式碼具有如下優勢：

• Init 容器可以包含一些安裝過程中應用容器中不存在的實用工具或個性化程式碼。

  例如，沒有必要僅為了在安裝過程中使用類似 sed、awk、python 或 dig 這樣的工具而去 FROM 一個鏡像來生成一個新的鏡像。

• Init 容器可以安全地運行這些工具，避免這些工具導致應用鏡像的安全性降低。

• 應用鏡像的創建者和部署者可以各自獨立工作，而沒有必要聯合構建一個單獨的應用鏡像。

• Init 容器能以不同於 Pod 內應用容器的文件系統視圖運行。因此，Init 容器可以訪問 應用容器不能訪問的Secret 的許可權。

• 由於 Init 容器必須在應用容器啟動之前運行完成，因此 Init 容器 提供了一種機制來阻塞或延遲應用容器的啟動，直到滿足了一組先決條件。 一旦前置條件滿足，Pod 內的所有的應用容器會並行啟動。

《Kubernetes-企業級容器應用託管》-持續胡說八道

第一段：推薦閱讀：【雲原生新時代弄潮兒k8s憑什麼在容器化方面獨樹一幟？】

第二段：推薦閱讀：【趁著同事玩遊戲偷偷認識k8s一家子補補課】

第三段：推薦閱讀：【Kubernetes家族容器小管家Pod在線答疑❓】

第四段：推薦閱讀：【同事提出個我從未想過的問題，為什麼Kubernetes要”多此一舉”推出靜態Pod概念？】

第五段：推薦閱讀：【探針配置失誤，線上容器應用異常死鎖後，kubernetes集群未及時響應自愈重啟容器？】

第六段：推薦閱讀：【kubernetes集群之Pod說能不能讓我體面的消亡呀？】

第七段：推薦閱讀：【k8s家族Pod輔助小能手Init容器認知答疑？】

第八段：待更新？推薦休閑閱讀：【囧么肥事】