一、initContainer工作原理

初始化容器是在pod的主容器啟動之前要運行的容器，主要是做一些 主容器的前置工作，它具有兩大特征：

1、初始化容器必須運行完成直至結束，若某初始化容器運行失敗，那么kubernetes需要重啟它直到成功完成；

2、初始化容器必須按照定義的順序執行，當且僅當前一個成功之后，后面的一個才能運行，一旦失敗，如果 Pod 對應的 restartPolicy 值為 Never，它不會重新啟動；

初始化容器有很多的應用場景，下面列出的是最常見的幾個：

提供主容器鏡像中不具備的工具程序或自定義代碼；

初始化容器要先于應用容器串行啟動并運行完成，因此可用于延后應用容器的啟動直至其依賴的條件得到滿足；

二、initConatiner數據共享

需求：假設要以主容器來運行nginx，但是要求在運行nginx之前需要拿到最新的index主頁；

創建pod-initcontainer.yaml，內容如下：

apiVersion:v1
kind:Pod
metadata:
name:php-updated
spec:
containers:
-name:php
 image:php:7-fpm
 volumeMounts:
 -name:dir
  mountPath:/var/www/html/
initContainers:
-name:install
 image:busybox
 volumeMounts:
 -name:dir
  mountPath:/var/www/html/
 command:
 -wget
 -"-O"
 -"/var/www/html/index.php"
 -https://gitee.com
volumes:
-name:dir
 emptyDir: {}

啟動成功后，登陸進PHP容器，可以查看到/var/www/html/目錄下的index.html文件為init container所生成。

三、initConatiner前置數據操作

初始化容器和PortStart的區別：

PostStart：依賴主應用的環境，而且并不一定先于Command運行

InitContainer：不依賴主應用的環境，可以有更高的權限和更多的工具，一定會在主應用啟動之前完成。

Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe。

需求：

假設 主容器在運行前，需要依賴一個B應用，只有B應用成功啟動后此容器才可以正常運行；

創建pod-initcontainer22.yaml，內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
 run: my-app
name: my-app
spec:
replicas: 2
selector:
 matchLabels:
  run: my-app
template:
 metadata:
  labels:
   run: my-app
 spec:
  restartPolicy: Always
  containers:
  - name: myapp-container
   image: busybox:1.28
   command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myappb
   image: busybox:1.28
   command: ['sh', '-c', "until nslookup myappb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myappb; sleep 2; done"]

創建測試所用的svc：

apiVersion: v1
kind: Service
metadata:
name: myappb
spec:
ports:
- protocol: TCP
 port: 80
 targetPort: 9377

為創建svc前，initcontainer一直處于等待，可以從console端輸出日志看到其狀態，一旦創建svc，initcontainer探測到svc正常后，即啟動后續的mainContainer。