建站
咨詢
售后
建站咨詢
新聞中心
Init 容器
本頁提供了 Init 容器的概覽。Init 容器是一種特殊容器，在 Pod 內(nèi)的應(yīng)用容器啟動之前運行。Init 容器可以包括一些應(yīng)用鏡像中不存在的實用工具和安裝腳本。
你可以在 Pod 的規(guī)約中與用來描述應(yīng)用容器的 ?containers ?數(shù)組平行的位置指定 Init 容器。
理解 Init 容器
每個 Pod 中可以包含多個容器， 應(yīng)用運行在這些容器里面，同時 Pod 也可以有一個或多個先于應(yīng)用容器啟動的 Init 容器。
Init 容器與普通的容器非常像，除了如下兩點：
- 它們總是運行到完成。
- 每個都必須在下一個啟動之前成功完成。
如果 Pod 的 Init 容器失敗，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止。 然而，如果 Pod 對應(yīng)的 ?restartPolicy ?值為 "Never"，并且 Pod 的 Init 容器失敗， 則 Kubernetes 會將整個 Pod 狀態(tài)設(shè)置為失敗。
為 Pod 設(shè)置 Init 容器需要在 Pod 規(guī)約 中添加 ?initContainers ?字段， 該字段以 Container 類型對象數(shù)組的形式組織，和應(yīng)用的 ?containers ?數(shù)組同級相鄰。 參閱 API 參考的容器章節(jié)了解詳情。
Init 容器的狀態(tài)在 ?status.initContainerStatuses? 字段中以容器狀態(tài)數(shù)組的格式返回 （類似 ?status.containerStatuses? 字段）。
與普通容器的不同之處
Init 容器支持應(yīng)用容器的全部字段和特性，包括資源限制、數(shù)據(jù)卷和安全設(shè)置。 然而，Init 容器對資源請求和限制的處理稍有不同，在下面資源節(jié)有說明。
同時 Init 容器不支持 ?lifecycle?、?livenessProbe?、?readinessProbe ?和 ?startupProbe?， 因為它們必須在 Pod 就緒之前運行完成。
如果為一個 Pod 指定了多個 Init 容器，這些容器會按順序逐個運行。 每個 Init 容器必須運行成功，下一個才能夠運行。當所有的 Init 容器運行完成時， Kubernetes 才會為 Pod 初始化應(yīng)用容器并像平常一樣運行。
使用 Init 容器
因為 Init 容器具有與應(yīng)用容器分離的單獨鏡像，其啟動相關(guān)代碼具有如下優(yōu)勢：
- Init 容器可以包含一些安裝過程中應(yīng)用容器中不存在的實用工具或個性化代碼。 例如，沒有必要僅為了在安裝過程中使用類似 ?
sed?、?awk?、?python?或 ?dig?這樣的工具而去 ?FROM?一個鏡像來生成一個新的鏡像。 - Init 容器可以安全地運行這些工具，避免這些工具導(dǎo)致應(yīng)用鏡像的安全性降低。
- 應(yīng)用鏡像的創(chuàng)建者和部署者可以各自獨立工作，而沒有必要聯(lián)合構(gòu)建一個單獨的應(yīng)用鏡像。
- Init 容器能以不同于 Pod 內(nèi)應(yīng)用容器的文件系統(tǒng)視圖運行。因此，Init 容器可以訪問 應(yīng)用容器不能訪問的 Secret 的權(quán)限。
- 由于 Init 容器必須在應(yīng)用容器啟動之前運行完成，因此 Init 容器 提供了一種機制來阻塞或延遲應(yīng)用容器的啟動，直到滿足了一組先決條件。 一旦前置條件滿足，Pod 內(nèi)的所有的應(yīng)用容器會并行啟動。
示例
下面是一些如何使用 Init 容器的想法：
- 等待一個 Service 完成創(chuàng)建，通過類似如下 shell 命令：
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register \
-d 'instance=$()&ip=$()' sleep 60
使用 Init 容器的情況
下面的例子定義了一個具有 2 個 Init 容器的簡單 Pod。 第一個等待 ?myservice ?啟動， 第二個等待 ?mydb ?啟動。 一旦這兩個 Init容器 都啟動完成，Pod 將啟動 ?spec ?節(jié)中的應(yīng)用容器。
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]你通過運行下面的命令啟動 Pod：
kubectl apply -f myapp.yaml
輸出類似于：
pod/myapp-pod created
使用下面的命令檢查其狀態(tài)：
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如需查看 Pod 內(nèi) Init 容器的日志，請執(zhí)行：
kubectl logs myapp-pod -c init-myservice # 查看第一個 Init 容器
kubectl logs myapp-pod -c init-mydb # 查看第二個 Init 容器在這一刻，Init 容器將會等待至發(fā)現(xiàn)名稱為 ?mydb ?和 ?myservice ?的 Service。
如下為創(chuàng)建這些 Service 的配置文件：
---
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377創(chuàng)建 ?mydb ?和 ?myservice ?服務(wù)的命令：
kubectl create -f services.yaml
輸出類似于：
service "myservice" created
service "mydb" created這樣你將能看到這些 Init 容器執(zhí)行完畢，隨后 ?my-app? 的 Pod 進入 ?Running ?狀態(tài)：
kubectl get -f myapp.yaml
輸出類似于：
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m具體行為
在 Pod 啟動過程中，每個 Init 容器會在網(wǎng)絡(luò)和數(shù)據(jù)卷初始化之后按順序啟動。 kubelet 運行依據(jù) Init 容器在 Pod 規(guī)約中的出現(xiàn)順序依次運行之。
每個 Init 容器成功退出后才會啟動下一個 Init 容器。 如果某容器因為容器運行時的原因無法啟動，或以錯誤狀態(tài)退出，kubelet 會根據(jù) Pod 的 ?restartPolicy ?策略進行重試。 然而，如果 Pod 的 ?restartPolicy ?設(shè)置為 "Always"，Init 容器失敗時會使用 ?restartPolicy ?的 "OnFailure" 策略。
在所有的 Init 容器沒有成功之前，Pod 將不會變成 ?Ready ?狀態(tài)。 Init 容器的端口將不會在 Service 中進行聚集。正在初始化中的 Pod 處于 ?Pending ?狀態(tài)， 但會將狀況 ?Initializing ?設(shè)置為 false。
如果 Pod 重啟，所有 Init 容器必須重新執(zhí)行。
對 Init 容器規(guī)約的修改僅限于容器的 ?image ?字段。 更改 Init 容器的 ?image ?字段，等同于重啟該 Pod。
因為 Init 容器可能會被重啟、重試或者重新執(zhí)行，所以 Init 容器的代碼應(yīng)該是冪等的。 特別地，基于 ?emptyDirs ?寫文件的代碼，應(yīng)該對輸出文件可能已經(jīng)存在做好準備。
Init 容器具有應(yīng)用容器的所有字段。然而 Kubernetes 禁止使用 ?readinessProbe?， 因為 Init 容器不能定義不同于完成態(tài)（Completion）的就緒態(tài)（Readiness）。 Kubernetes 會在校驗時強制執(zhí)行此檢查。
在 Pod 上使用 ?activeDeadlineSeconds ?和在容器上使用 ?livenessProbe ?可以避免 Init 容器一直重復(fù)失敗。 ?activeDeadlineSeconds ?時間包含了 Init 容器啟動的時間。 但建議僅在團隊將其應(yīng)用程序部署為 Job 時才使用 ?activeDeadlineSeconds?， 因為 ?activeDeadlineSeconds ?在 Init 容器結(jié)束后仍有效果。 如果你設(shè)置了 ?activeDeadlineSeconds?，已經(jīng)在正常運行的 Pod 會被殺死。
在 Pod 中的每個應(yīng)用容器和 Init 容器的名稱必須唯一； 與任何其它容器共享同一個名稱，會在校驗時拋出錯誤。
資源
在給定的 Init 容器執(zhí)行順序下，資源使用適用于如下規(guī)則：
- 所有 Init 容器上定義的任何特定資源的 limit 或 request 的最大值，作為 Pod 有效初始 request/limit。 如果任何資源沒有指定資源限制，這被視為最高限制。
- Pod 對資源的 有效 limit/request 是如下兩者的較大者：
- 所有應(yīng)用容器對某個資源的 limit/request 之和
- 對某個資源的有效初始 limit/request
- 基于有效 limit/request 完成調(diào)度，這意味著 Init 容器能夠為初始化過程預(yù)留資源， 這些資源在 Pod 生命周期過程中并沒有被使用。
- Pod 的 有效 QoS 層 ，與 Init 容器和應(yīng)用容器的一樣。
配額和限制適用于有效 Pod 的請求和限制值。 Pod 級別的 cgroups 是基于有效 Pod 的請求和限制值，和調(diào)度器相同。
Pod 重啟的原因
Pod 重啟會導(dǎo)致 Init 容器重新執(zhí)行，主要有如下幾個原因：
- Pod 的基礎(chǔ)設(shè)施容器 (譯者注：如 ?
pause?容器) 被重啟。這種情況不多見， 必須由具備 root 權(quán)限訪問節(jié)點的人員來完成。 - 當 ?
restartPolicy?設(shè)置為 "?Always?"，Pod 中所有容器會終止而強制重啟。 由于垃圾收集機制的原因，Init 容器的完成記錄將會丟失。
當 Init 容器的鏡像發(fā)生改變或者 Init 容器的完成記錄因為垃圾收集等原因被丟失時， Pod 不會被重啟。這一行為適用于 Kubernetes v1.20 及更新版本。如果你在使用較早 版本的 Kubernetes，可查閱你所使用的版本對應(yīng)的文檔。
本文題目：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes Init容器
網(wǎng)站URL：http://www.dlmjj.cn/article/cdehhsp.html
