标签：jin 基本 linu with span 思路 创建 node comm
initContainers是一种专用的容器，在应用程序容器启动之前运行，可以包括一些应用程序镜像中不存在的实用工具和安装脚本，可以完成应用的必要数据初始化等工作。总的来说就是在正式的容器启动之前做一些准备工作的。
例如一个应用容器挂载的volume目录需要一些必不可少的初始化文件，不加init容器的时候直接挂载volume应用容器的那个目录是空的（因为docker挂载一个volume时，会用volume的内容覆盖容器内挂载目录的内容），这就需要让init容器也跟应用容器挂载同一个volume目录，将初始化文件放进去，然后在启动应用容器就能正常看到那些初始化文件了，我也正是遇到了这样的问题，才来研究和学习init容器的。
1、一个pod可以运行多个容器，同样的一个pod也可能有一个或多个先于应用容器启动的 Init 容器，每个容器启动失败后都会根据你配置的重启策略进行重启，直到运行成功。Init 容器与普通的基本一样，主要区别如下
2、因为 Init 容器具有与应用程序容器分离的单独镜像，所以使用他们可以具有如下优势：
3、下面是一些如何使用 Init 容器的思路：
for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d ‘instance=$(<POD_NAME>)&ip=$(<POD_IP>)‘
4、 init容器使用示例，
Kubernetes 1.6 版本后使用新语法，把 Init 容器的声明移到 spec 中，只需要添加 initContainers 即可，下面列一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动，第二个等待 mydb 启动。 一旦这两个 Service 都启动完成，Pod 将开始启动。
apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: [‘sh‘, ‘-c‘, ‘echo The app is running! && sleep 3600‘] initContainers: - name: init-myservice image: busybox command: [‘sh‘, ‘-c‘, ‘until nslookup myservice; do echo waiting for myservice; sleep 2; done;‘] - name: init-mydb image: busybox command: [‘sh‘, ‘-c‘, ‘until nslookup mydb; do echo waiting for mydb; sleep 2; done;‘]
下面的 yaml 文件展示了 mydb 和 myservice 两个 Service：
kind: Service apiVersion: v1 metadata: name: myservice spec: ports: - protocol: TCP port: 80 targetPort: 9376 --- kind: Service apiVersion: v1 metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377
这个 Pod 可以使用下面的命令进行启动和调试
$ kubectl create -f myapp.yaml pod "myapp-pod" created $ 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 $ kubectl logs myapp-pod -c init-myservice # Inspect the first init container $ kubectl logs myapp-pod -c init-mydb # Inspect the second init container
一旦我们启动了 mydb 和 myservice 这两个 Service，我们能够看到 Init 容器完成，并且 myapp-pod 被创建：
$ kubectl create -f services.yaml service "myservice" created service "mydb" created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m
在 Pod 上使用 activeDeadlineSeconds，在容器上使用 livenessProbe，这样能够避免 Init 容器一直失败， 这就为 Init 容器活跃设置了一个期限。在 Pod 中的每个 app 和 Init 容器的名称必须唯一，与任何其它容器共享同一个名称，会在验证时抛出错误。
在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动。 每个容器必须在下一个容器启动之前成功退出。 如果由于运行时或失败退出，导致容器启动失败，它会根据 Pod 的 restartPolicy 指定的策略进行重试，在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态，如果 Pod 重启，所有 Init 容器必须重新执行。
因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的（即任意多次执行所产生的影响与一次执行的影响相同）。 特别地，被写到 EmptyDirs 中文件的代码，应该对输出文件可能已经存在做好准备。
5、Pod 能够重启，会导致 Init 容器重新执行，重启主要有如下几个原因：
标签：jin 基本 linu with span 思路 创建 node comm
原文地址：https://www.cnblogs.com/yanh0606/p/11395920.html
