initContainers是一種專用的容器，在應用程序容器啟動之前運行，可以包括一些應用程序鏡像中不存在的實用工具和安裝腳本，可以完成應用的必要數據初始化等工作。總的來說就是在正式的容器啟動之前做一些準備工作的。

? ? ? ? 例如一個應用容器掛載的volume目錄需要一些必不可少的初始化文件，不加init容器的時候直接掛載volume應用容器的那個目錄是空的（因為docker掛載一個volume時，會用volume的內容覆蓋容器內掛載目錄的內容），這就需要讓init容器也跟應用容器掛載同一個volume目錄，將初始化文件放進去，然后在啟動應用容器就能正常看到那些初始化文件了，我也正是遇到了這樣的問題，才來研究和學習init容器的。

?

1、一個pod可以運行多個容器，同樣的一個pod也可能有一個或多個先于應用容器啟動的 Init 容器，每個容器啟動失敗后都會根據你配置的重啟策略進行重啟，直到運行成功。Init 容器與普通的基本一樣，主要區別如下

• Init 容器總是運行到成功運行完為止。
• 前面的?Init 容器必須已經運行完成，才會開始運行下一個init容器，而應用程序容器時并行運行的。2、

2、因為 Init 容器具有與應用程序容器分離的單獨鏡像，所以使用他們可以具有如下優勢：

• 它們可以包含并運行實用工具，但是出于安全考慮，是不建議在應用程序容器鏡像中包含這些實用工具的。
• 它們可以包含使用工具和定制化代碼來安裝，但是不能出現在應用程序鏡像中。例如，創建鏡像沒必要?FROM?另一個鏡像，只需要在安裝過程中使用類似?sed、?awk、?python?或?dig?這樣的工具。
• 應用程序鏡像可以分離出創建和部署的角色，而沒有必要聯合它們構建一個單獨的鏡像。
• Init 容器使用 Linux Namespace，所以相對應用程序容器來說具有不同的文件系統視圖。因此，它們能夠具有訪問 Secret 的權限，而應用程序容器則不能。
• 它們必須在應用程序容器啟動之前運行完成，而應用程序容器是并行運行的，所以 Init 容器能夠提供了一種簡單的阻塞或延遲應用容器的啟動的方法，直到滿足了一組先決條件。

3、下面是一些如何使用 Init 容器的思路：

• 等待一個 Service 創建完成，通過類似如下 shell 命令： for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1
• 將 Pod 注冊到遠程服務器，通過在命令中調用 API，類似如下： curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
• 在啟動應用容器之前等一段時間，使用類似?sleep 60?的命令。
• 克隆 Git 倉庫到數據卷。
• 將配置值放到配置文件中，運行模板工具為主應用容器動態地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主應用配置文件。

4、 init容器使用示例，

? ? ? ?Kubernetes?1.6 版本后使用新語法，把 Init 容器的聲明移到?spec?中，只需要添加?initContainers 即可，下面列一個具有 2 個 Init 容器的簡單 Pod。 第一個等待?myservice?啟動，第二個等待?mydb?啟動。 一旦這兩個 Service 都啟動完成，Pod 將開始啟動。

apiVersion: v1 kind: Pod metadata:name: myapp-podlabels:app: myapp spec:containers:- name: myapp-containerimage: busyboxcommand: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: busyboxcommand: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']- name: init-mydbimage: busyboxcommand: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

下面的 yaml 文件展示了?mydb?和?myservice?兩個 Service：

kind: Service apiVersion: v1 metadata:name: myservice spec:ports:- protocol: TCPport: 80targetPort: 9376 --- kind: Service apiVersion: v1 metadata:name: mydb spec:ports:- protocol: TCPport: 80targetPort: 9377

這個 Pod 可以使用下面的命令進行啟動和調試

$ kubectl create -f myapp.yaml pod "myapp-pod" created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m $ kubectl describe -f myapp.yaml Name: myapp-pod Namespace: default [...] Labels: app=myapp Status: Pending [...] Init Containers:init-myservice: [...]State: Running [...]init-mydb: [...]State: WaitingReason: PodInitializingReady: False [...] Containers:myapp-container: [...]State: WaitingReason: PodInitializingReady: False [...] Events:FirstSeen LastSeen Count From SubObjectPath Type Reason Message--------- -------- ----- ---- ------------- -------- ------ -------16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.20116s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox"13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox"13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 $ kubectl logs myapp-pod -c init-myservice # Inspect the first init container $ kubectl logs myapp-pod -c init-mydb # Inspect the second init container

一旦我們啟動了?mydb?和?myservice?這兩個 Service，我們能夠看到 Init 容器完成，并且?myapp-pod?被創建：

$ kubectl create -f services.yaml service "myservice" created service "mydb" created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m

? ? ? ??在 Pod 上使用?activeDeadlineSeconds，在容器上使用?livenessProbe，這樣能夠避免 Init 容器一直失敗， 這就為 Init 容器活躍設置了一個期限。在 Pod 中的每個 app 和 Init 容器的名稱必須唯一，與任何其它容器共享同一個名稱，會在驗證時拋出錯誤。

? ? ? ? 在 Pod 啟動過程中，Init 容器會按順序在網絡和數據卷初始化之后啟動。 每個容器必須在下一個容器啟動之前成功退出。 如果由于運行時或失敗退出，導致容器啟動失敗，它會根據 Pod 的?restartPolicy?指定的策略進行重試，在所有的 Init 容器沒有成功之前，Pod 將不會變成?Ready?狀態，如果 Pod?重啟，所有 Init 容器必須重新執行。

? ? ? ??因為 Init 容器可能會被重啟、重試或者重新執行，所以 Init 容器的代碼應該是冪等的（即任意多次執行所產生的影響與一次執行的影響相同）。 特別地，被寫到?EmptyDirs?中文件的代碼，應該對輸出文件可能已經存在做好準備。

5、Pod 能夠重啟，會導致 Init 容器重新執行，重啟主要有如下幾個原因：

• 用戶更新 PodSpec 導致 Init 容器鏡像發生改變。更改 Init 容器的 image 字段，等價于重啟該 Pod，應用容器鏡像的變更只會重啟應用容器。
• Pod 基礎設施容器被重啟。這不多見，但某些具有 root 權限可訪問 Node 的人可能會這樣做。
• 當?restartPolicy?設置為 Always，Pod 中所有容器會終止，強制重啟，由于垃圾收集導致 Init 容器完成的記錄丟失。

?

因為 Init 容器具有與應用程序容器分離的單獨鏡像，所以使用他們可以具有如下優勢：

轉載于:https://www.cnblogs.com/yanh0606/p/11395920.html

總結

以上是生活随笔為你收集整理的Kubernetes的初始化容器initContainers的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。