摘要：pause容器创建完成之后，会创建初始化容器initC。初始化容器initC并不是伴随着整个容器的生命周期存在而存在，它只是出现在容器生命周期的前一部分，initC容器只是完成一些初始化的操作，可以在资源清单中定义几个初始化容器initC。初始化容器就是下载容
kubernetes中同一个Pod的不同容器之间是共享网络、IPC和PID的。
pod的生命周期：pod从创建到死亡的过程。
Pod是kubernetes集群中部署的最小单元。
pause容器的作用：①：初始化网络栈
②：挂载存储卷
③：和其他容器共享网络、共享IPC、共享PID
④：回收后续进程的僵尸进程或者称为孤儿进程。
pause容器创建完成之后，会创建初始化容器initC。初始化容器initC并不是伴随着整个容器的生命周期存在而存在，它只是出现在容器生命周期的前一部分，initC容器只是完成一些初始化的操作，可以在资源清单中定义几个初始化容器initC。初始化容器就是下载容器镜像、配置容器和pause容器之间网络的过程。InitC初始化容器是线性的， initC初始化容器返回码或者退出码必须是0，每一个initC初始化容器必须工作到完全退出为止。initC初始化容器是线性的，容器不能并行出现。只有第一个成功退出，第二个才能被创建。每一个都通过返回码为0，初始化容器initC才算结束。只要有一个initC初始化容器返回码不是0，都要重新开始创建、重新运行，直到返回码为0为止。
危险性的操作可以放到初始化容器initC中运行，这样可以保证安全性，也可以具有相应的功能。初始化容器initC具有阻塞的特性，initC如果不能成功的话，那么后面的容器不能被创建出来。只有每一个初始化容器initC都成功了，每一个初始化容器initC返回码是0，才能进行后续的容器才能允许被创建。
主容器，也就是应用容器是MainC，主容器不间断地持续运行。主容器类似一种守护进程的类型。初始化容器initC类似脚本类型，它有退出条件和退出时机。
主容器mainc是没有个数限制的，它们是可以共同存在的。它们可以同时存在，并发地运行。如果一个pod有多个mainc主容器，设计上是允许并发执行的。新版本kubernetes中下载镜像是并发执行的，老版本kubernetes中下载镜像是线性进行的。
钩子有两种：启动后post start和关闭前。
关闭前钩子执行完成之后，才执行再执行关闭信号，释放容器。
Pod所在节点的kubelet执行启动后和关闭前钩子，每一个kubelet管理的钩子数量是有限的。
探针分成：就绪探针、启动探针和存活探针。
就绪探针readiness probe成功了，容器就会被标记成可访问状态。当所有的nainc主容器都被标记为就绪了，pod才允许通过负载均衡提供给客户去访问。
当前任何一个pod没有被标记成就绪状态，这样的pod都不被允许通过负载均衡提供给客户访问。
存活探针：liveness probe， 提供给客户稳定可靠的访问。如果存活探针失败，会通过杀掉容器重新创建的方式去恢复。 存活探针保证正在运行的容器都是可以提供给用户访问的。
启动探针startup probe是kubernetes v1.16新增加的内容。就绪探针和存活探针都是在启动探针startup probe之后才执行的。
这些启动探针、就绪探针、存活探针保证了pod里面的mainc主容器能够正常稳定地运行并且就绪。
启动探测、就绪探测、存活探测可以不设置，默认就是空。就绪探测，如果不定义，那么它默认就绪存活。如果启动探测不定义，那么它默认就是启动。所有的探测机制或者叫探针，包括启动探针、就绪探针和存活探针通过所在节点的kubelet去完成执行。
这就是pod容器的一个生命周期。
InitC初始化容器与普通容器非常像，除了以下两点：
①：initC初始化容器总是运行到成功完成为止。也就是如果返回码为非0的话，我们就会重建第一个initC初始化容器，以此保证每个initC初始化容器都必须是连贯的，并且以0的返回码成功退出。
②：每个initC初始化容器都必须在下一个initC初始化容器启动之前成功完成。也就是如果前一个initC初始化容器是启动失败的，那么后一个initC初始化容器根本轮不到去运行。
如果pod的initC初始化容器启动失败,kubernetes会不断地重启这个pod，直到所有的initC初始化容器成功完成为止。然而，如果pod对应的restartPolicy为Never永不，它不会重新启动。如果pod的重启策略设置为Never永不，那么initC初始化容器只要错一次，这个pod就会被标记为失败。
pod容器的生命周期分成initc初始化容器和mainc主容器的部分。主容器的探测机制又包括:启动探针、就绪探针和存活探针。
initC初始化容器与应用容器MainC具备不同的镜像，可以把一些危险的工具放在initC初始化容器中进行使用。
initC初始化容器多个之间是线性启动的，所以可以做一些延迟性的操作。
initC无法定义readinessProbe就绪探针，除此之外和应用容器MainC没有差别。
initC初始化容器具有阻塞性。
CoreDNS组件给kubernetes集群提供私有域名解析服务。
使用yaml格式的文件创建pod：
kubectl create -f xxx.pod.yaml
查看pod事件：
kubectl describe pod $pod_name
initC初始化容器，只有前一个以0的返回码退出之后，后一个initC初始化容器才会被创建，这就是initC初始化容器具有阻塞性。
查看容器的创建日志：
kubectl logs $pod_name -c $container_name
kubernetes创建clusterip类型的服务：
kubectl create svc clusterip $svc_name --tcp=
:
举例：
kubectl create svc clusterip myservice --tcp=5678:8080
这里的5678是service的本地端口，8080就是远程的端口，相当于是pod的端口。
前一个是负载均衡集群的端口，后面那个端口是访问后端服务器的端口。
也就是对外暴露一个端口，能访问到集群内部的服务。
service可以简写成svc，deployment可以简写成deploy，pod可以简写成po。
查看服务service信息：
kubectl get svc -n $namespace_name
所有的pod如果要访问api-server，都需要去访问kubernetes 这个service服务。
集群内部的服务通过简单的服务名称去访问，而无需知道具体的IP地址。名为myservice的服务，可以通过myservice.default.svc.cluster.local，假设服务部署在default命名空间内。
初始化容器initC每个容器要结束，并且要以0的返回码结束。返回码为0才能创建成功；返回码为1就要去重建pod。
查看容器的创建日志：
kubectl describe $pod_name -c
查看其中的Event对应的事件。
创建initc初始化容器的返回码是0，才能进入创建mainc主容器的进程。
如果容器被创建在kubernetes集群中的不同worker node节点，那么需要重新下载镜像。
查看pod创建在哪个worker node节点：
kubectl get pod -n $namespace -o wide | grep $pod_name
只有initC初始化容器的返回码是0，才可以进入到mainC主容器的创建流程。
初始化容器initC必须是线性的，并且返回码必须是0，才可以创建主容器mainC。
白莲花
鼓励的话语：当结局是差强人意的时候，那一定是上帝另有安排。人生的光荣，不在永不失败，而在于能够屡败屡战！
来源：老吴的科学大讲堂
