initContainers是一種專用的容器，在應用程序容器啟動之前運行，可以包括一些應用程序鏡像中不存在的實用工具和安裝腳本，可以完成應用的必要數據初始化等工作。總的來說就是在正式的容器啟動之前做一些准備工作的。
例如一個應用容器掛載的volume目錄需要一些必不可少的初始化文件，不加init容器的時候直接掛載volume應用容器的那個目錄是空的（因為docker掛載一個volume時，會用volume的內容覆蓋容器內掛載目錄的內容），這就需要讓init容器也跟應用容器掛載同一個volume目錄，將初始化文件放進去，然后在啟動應用容器就能正常看到那些初始化文件了，我也正是遇到了這樣的問題，才來研究和學習init容器的。
1、一個pod可以運行多個容器，同樣的一個pod也可能有一個或多個先於應用容器啟動的 Init 容器，每個容器啟動失敗后都會根據你配置的重啟策略進行重啟，直到運行成功。Init 容器與普通的基本一樣，主要區別如下
- Init 容器總是運行到成功運行完為止。
- 前面的 Init 容器必須已經運行完成，才會開始運行下一個init容器，而應用程序容器時並行運行的。
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-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: - name: init-myservice image: busybox command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] - name: init-mydb image: busybox command: ['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: TCP port: 80 targetPort: 9376 --- kind: Service apiVersion: v1 metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 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: Waiting Reason: PodInitializing Ready: False [...] Containers: myapp-container: [...] State: Waiting Reason: PodInitializing Ready: 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.201 16s 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 容器完成的記錄丟失。