k8s家族Pod輔助小能手Init容器認(rèn)知答疑？
k8s集群Init 容器是一種特殊容器票腰，職責(zé)是在Pod的生命周期中作為應(yīng)用容器的前置啟動容器城看。
在很多應(yīng)用場景中，在 Pod 內(nèi)的應(yīng)用容器正式啟動之前之前需要進(jìn)行預(yù)熱操作杏慰，為正式啟動應(yīng)用容器鋪墊先決條件测柠，如預(yù)加載一些基本配置、資源限制配額缘滥、還可以包括一些應(yīng)用鏡像中不存在的實(shí)用工具和安裝腳本
囧么肥事-胡說八道
Init容器有什么特殊嗎轰胁？與普通容器有何不同？
k8s集群Init 容器是一種特殊容器朝扼，職責(zé)是在Pod的生命周期中作為應(yīng)用容器的前置啟動容器赃阀。
在很多應(yīng)用場景中，在 Pod 內(nèi)的應(yīng)用容器正式啟動之前之前需要進(jìn)行預(yù)熱操作吟税，為正式啟動應(yīng)用容器鋪墊先決條件凹耙，如預(yù)加載一些基本配置姿现、資源限制配額、還可以包括一些應(yīng)用鏡像中不存在的實(shí)用工具和安裝腳本肖抱。例如
1备典、基于環(huán)境變量或配置模板生成配置文件
2、等待其他關(guān)聯(lián)組件加載完成（如MySQL數(shù)據(jù)庫服務(wù)意述，Nginx服務(wù)等）
3提佣、下載相關(guān)依賴包，對系統(tǒng)預(yù)配置等
4荤崇、從遠(yuǎn)程數(shù)據(jù)庫獲取本地應(yīng)用所需配置拌屏，或?qū)⒆约簲?shù)據(jù)庫注冊到某個(gè)中央數(shù)據(jù)庫等
Init 容器與普通的容器非常像，Init 容器支持應(yīng)用容器的全部字段和特性术荤，包括資源限制倚喂、數(shù)據(jù)卷和安全設(shè)置磷蛹。
但是也有自己獨(dú)特的”性格“袄膏。
第一點(diǎn)Init容器必須保證成功啟動后才會啟動下個(gè)容器
如果 Pod 的 Init 容器失敗二汛，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止极谊，然后才會考慮去啟動其他容器罕拂。對自己的要求比較嚴(yán)格团甲，只許成功挎春，不許失斊煅洹仑嗅！
第二點(diǎn) Kubernetes 其實(shí)禁止Init容器使用 readinessProbe
因?yàn)?Init 容器不能定義不同于完成態(tài)（Completion）的就緒態(tài)（Readiness）
第二點(diǎn)Init 容器對資源請求和限制的處理稍有不同
在給定的 Init 容器執(zhí)行順序下宴倍，資源使用適用于如下規(guī)則：
- 所有 Init 容器上定義的任何特定資源的
limit或request的最大值，作為 Pod 有效初始request/limit仓技。 如果任何資源沒有指定資源限制鸵贬，這被視為最高限制。 - Pod 對資源的有效
limit/request浑彰，取決于兩種判斷標(biāo)準(zhǔn)中的較大者- 所有應(yīng)用容器對某個(gè)資源的
limit/request之和 - 對某個(gè)資源的有效初始
limit/request
- 所有應(yīng)用容器對某個(gè)資源的
- 基于有效 limit/request 完成調(diào)度恭理，這意味著 Init 容器能夠?yàn)?strong>初始化過程預(yù)留資源， 這些資源在 Pod 生命周期過程中并沒有被使用郭变。
- Pod 的 有效
QoS層 颜价，與 Init 容器和應(yīng)用容器的一樣。
配額和限制適用于有效 Pod 的請求和限制值诉濒。 Pod 級別的 cgroups 是基于有效 Pod 的請求和限制值周伦，和調(diào)度器相同。
同時(shí) Init 容器不支持 lifecycle未荒、livenessProbe专挪、readinessProbe 和 startupProbe， 因?yàn)樗鼈儽仨氃?Pod 就緒之前運(yùn)行完成。
如果為一個(gè) Pod 指定了多個(gè) Init 容器寨腔，這些容器會按順序逐個(gè)運(yùn)行速侈。 每個(gè) Init 容器必須運(yùn)行成功，下一個(gè)才能夠運(yùn)行迫卢。當(dāng)所有的 Init 容器運(yùn)行完成時(shí)倚搬， Kubernetes 才會為 Pod 初始化應(yīng)用容器并像平常一樣運(yùn)行。
它的啟動有什么不同乾蛤，如果多個(gè)Init容器啟動呢每界？失敗呢？
在 Pod 啟動過程中家卖，每個(gè) Init 容器會在網(wǎng)絡(luò)和數(shù)據(jù)卷初始化之后按順序啟動眨层。 kubelet 運(yùn)行依據(jù) Init 容器在 Pod 規(guī)約中的出現(xiàn)順序依次運(yùn)行之。
如果 Pod 的 Init 容器失敗上荡，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止趴樱。 然而，如果 Pod 對應(yīng)的 restartPolicy 值為 "Never"榛臼，并且 Pod 的 Init 容器失敗伊佃， 則 Kubernetes 會將整個(gè) Pod 狀態(tài)設(shè)置為失敗。
如果為一個(gè) Pod 指定了多個(gè) Init 容器沛善，這些容器會按順序逐個(gè)運(yùn)行。 每個(gè) Init 容器必須運(yùn)行成功塞祈，下一個(gè)才能夠運(yùn)行金刁。當(dāng)所有的 Init 容器運(yùn)行完成時(shí)， Kubernetes 才會為 Pod 初始化應(yīng)用容器并像平常一樣運(yùn)行议薪。
使用 Init 容器有什么優(yōu)勢尤蛮？
因?yàn)?Init 容器具有與應(yīng)用容器分離的單獨(dú)鏡像，其啟動相關(guān)代碼具有如下優(yōu)勢：
-
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容器可以訪問 應(yīng)用容器不能訪問的Secret的權(quán)限。由于 Init 容器必須在應(yīng)用容器啟動之前運(yùn)行完成，因此 Init 容器 提供了一種機(jī)制來阻塞或延遲應(yīng)用容器的啟動谤祖，直到滿足了一組先決條件婿滓。 一旦前置條件滿足，Pod 內(nèi)的所有的應(yīng)用容器會并行啟動粥喜。
《Kubernetes-企業(yè)級容器應(yīng)用托管》-持續(xù)胡說八道
第一段：推薦閱讀：【云原生新時(shí)代弄潮兒k8s憑什么在容器化方面獨(dú)樹一幟空幻？】
第二段：推薦閱讀：【趁著同事玩游戲偷偷認(rèn)識k8s一家子補(bǔ)補(bǔ)課】
第三段：推薦閱讀：【Kubernetes家族容器小管家Pod在線答疑?】
第四段：推薦閱讀：【同事提出個(gè)我從未想過的問題，為什么Kubernetes要"多此一舉"推出靜態(tài)Pod概念容客？】
第五段：推薦閱讀：【探針配置失誤秕铛，線上容器應(yīng)用異常死鎖后，kubernetes集群未及時(shí)響應(yīng)自愈重啟容器缩挑？】
第六段：推薦閱讀：【kubernetes集群之Pod說能不能讓我體面的消亡呀但两？】
第七段：推薦閱讀：【k8s家族Pod輔助小能手Init容器認(rèn)知答疑？】
第八段：待更新供置？推薦休閑閱讀：【囧么肥事】
