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