Kubernetes Init Container 在很多場景中秒梳，應(yīng)用在啟動之前都需要進行如下初始化操作星澳。 等待其他關(guān)聯(lián)組件正確運行（例如數(shù)據(jù)庫或某個后臺服務(wù)）抄沮。 基于環(huán)境變量或配置模板生成配置文件串稀。 從遠程數(shù)據(jù)庫獲取本地所需配置，或者自身注冊到某個中央數(shù)據(jù)中薯酝。 下載某個依賴包半沽，或者對系統(tǒng)進行一些預配置操作。 Kubernetes v1.3 引入了一個 Alpha 版本的新特新 init container（在 Kubernetes v1.5 時被更新為 Beta 版本）吴菠，用于在啟動應(yīng)用容器（app container）之前啟動一個或多個 “初始化” 容器者填，完成應(yīng)用容器所需的預置條件。Init container 與應(yīng)用容器本質(zhì)上一樣的做葵，但它們是僅運行一次就結(jié)束的任務(wù)占哟，而且必須在成功執(zhí)行完成之后，系統(tǒng)才會繼續(xù)執(zhí)行下一個容器酿矢。根據(jù) Pod 的重啟策略（RestartPolicy）榨乎，當 init container 執(zhí)行失敗，在設(shè)置了 RestartPolicy=Never 時瘫筐，Pod 將會啟動失斆凼睢；而設(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í)行過程 展開源碼 啟動完成之后，進入 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í)行完成，當設(shè)置了多個 init container 時棺牧，將按順序逐個運行巫糙，并且只有前一個 init container 運行成功之后才能運行后一個 init container。當所有 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 的有效資源請求值/資源限制值進行計算颓哮，也就是說 init container 可以為初始化操作預留系統(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 將會重新運行，導致 Pod 重啟徒溪。僅更新應(yīng)用容器的進行只會應(yīng)用容器被重啟忿偷。 Pod 的 infrastructure 容器（pause）更新時，Pod 將會重啟臊泌。 若 Pod 中的所有應(yīng)用容器都停止了鲤桥，并且 RestartPolicy=Always，則 Pod 將會重啟渠概。