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容器使用示例，

Kubernetes1.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 容器完成的記錄丟失。

總結

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

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