Kubernetes Init Container 在很多場景中，應(yīng)用在啟動之前都需要進(jìn)行如下初始化操作。 等待其他關(guān)聯(lián)組件正確運行（例如數(shù)據(jù)庫或某個后臺服務(wù)）。 基于環(huán)境變量或配置模板生成配置文件。 從遠(yuǎn)程數(shù)據(jù)庫獲取本地所需配置，或者自身注冊到某個中央數(shù)據(jù)中。 下載某個依賴包，或者對系統(tǒng)進(jìn)行一些預(yù)配置操作。 Kubernetes v1.3 引入了一個 Alpha 版本的新特新 init container（在 Kubernetes v1.5 時被更新為 Beta 版本），用于在啟動應(yīng)用容器（app container）之前啟動一個或多個 “初始化” 容器，完成應(yīng)用容器所需的預(yù)置條件。Init container 與應(yīng)用容器本質(zhì)上一樣的，但它們是僅運行一次就結(jié)束的任務(wù)，而且必須在成功執(zhí)行完成之后，系統(tǒng)才會繼續(xù)執(zhí)行下一個容器。根據(jù) Pod 的重啟策略（RestartPolicy），當(dāng) init container 執(zhí)行失敗，在設(shè)置了 RestartPolicy=Never 時，Pod 將會啟動失?。欢O(shè)置 RestartPolicy=Always 時，Pod 將會被啟動自動重啟。 v1.8 版本之后，Init Container 特性完全成熟，其定義被放入了 Pod 的 spec.initContainers。 下面以 Nginx 應(yīng)用為例，在啟動 Nginx 之前，通過初始化容器 busybox 為 Nginx 創(chuàng)建一個 index.html 主頁文件。這里為 init container 和 Nginx 設(shè)置了一個共享的 volume，以提供 Nginx 訪問 init container 設(shè)置的 index.html。 nginx-init-containers.yaml apiVersion: v1 kind: Pod metadata: name: nginx annotations: spec: initContainers: - name: install image: busybox command: - wget - "-O" - "/work-dir/index.html" - http://kubernetes.io volumeMounts: - name: workdir mountPath: "/work-dir" containers: - name: nginx image: nginx ports: - containerPort: 80 volumeMounts: - name: workdir mountPath: "/usr/share/nginx/html" dnsPolicy: Default volumes: - name: workdir emptyDir: {} 創(chuàng)建這個 Pod： $ kubectl apply -f nginx-init-containers.yaml 在運行 init container 的過程中，查看 Pod 的狀態(tài)，可見 init 過程還未完成： $ kubectl get po nginx NAME READY STATUS RESTARTS AGE nginx 0/1 Init:0/1 0 23s # or $ kubectl get po NAME READY STATUS RESTARTS AGE nginx 0/1 PodInitializing 0 1m 在 init container 成功執(zhí)行完成之后，系統(tǒng)繼續(xù)期待 Nginx 容器，再次查看 Pod 的狀態(tài)： $ kubectl get po nginx NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 1m 查看 Pod 的時間，可以看到系統(tǒng)首先創(chuàng)建并運行 init container 容器（名為 install），成功之后繼續(xù)創(chuàng)建運行 Nginx 容器： $ kubectl describe po nginx 執(zhí)行過程 展開源碼 啟動完成之后，進(jìn)入 Nginx 容器，可以看到掛載的目錄下已經(jīng)有了 index.html 文件為 init container 所生產(chǎn)，其內(nèi)容為： $ kubectl exec -it nginx cat /usr/share/nginx/html/index.html 執(zhí)行結(jié)果 展開源碼 init container 與應(yīng)用容器的區(qū)別如下： （1）init container 的運行方式與應(yīng)用容器不同，它們必須先于應(yīng)用容器執(zhí)行完成，當(dāng)設(shè)置了多個 init container 時，將按順序逐個運行，并且只有前一個 init container 運行成功之后才能運行后一個 init container。當(dāng)所有 init container 都成功運行后，Kubernetes 才會初始化 Pod 的各種信息，并開始創(chuàng)建和運行應(yīng)用容器。 （2）在 init container 的定義中也可以設(shè)置資源限制、volume 的使用和安全策略，等等。但資源限制的設(shè)置與應(yīng)用容器略有不同。 如果多個 init container 都定義了資源請求/資源限制，則取最大的值作為所有 init container 的資源請求值/資源限制值。 Pod 的有效 (efective) 資源請求值/資源限制值取以下二者中的較大值。 a）所有應(yīng)用容器的資源請求值/資源限制值之和。 b）init container 的有效資源請求值/資源限制值。 調(diào)度算法將基于 Pod 的有效資源請求值/資源限制值進(jìn)行計算，也就是說 init container 可以為初始化操作預(yù)留系統(tǒng)資源，及時后續(xù)應(yīng)用容器無須使用這些資源。 Pod 的有效 QoS 等級適用于 init container 和應(yīng)用容器。 資源配額和限制將根據(jù) Pod 的有效資源請求/限制，與調(diào)度機制一致。 init container 不能設(shè)置 readinessProbe 探針，因為必須在它們成功運行后才能繼續(xù)運行 Pod 中定義的普通容器。 在 Pod 重新啟動（Restart）時，init container 將會重新運行，場景的 Pod 重啟場景如下： init container 的鏡像被更新時，init container 將會重新運行，導(dǎo)致 Pod 重啟。僅更新應(yīng)用容器的進(jìn)行只會應(yīng)用容器被重啟。 Pod 的 infrastructure 容器（pause）更新時，Pod 將會重啟。 若 Pod 中的所有應(yīng)用容器都停止了，并且 RestartPolicy=Always，則 Pod 將會重啟。