容器的生命周期说明init C+start/stop+探针_readiness就绪性检测是在主容器启动以后检测吗-优快云博客

本文链接：https://blog.youkuaiyun.com/asufeiya/article/details/119429628

在这里插入图片描述

最开始请求指令下达到api接口，被调度到kubelet上，他要进行容器的环境初始化，进入pod的生命周期内部。开始创建，需要init C的过程。也就是初始化容器。比如想要运行一个pod,里面运行两个不同的容器，这两个容器的运行条件就是在本机的xx存储下有一个xx文件存在他才能运行。通过init C生成该文件，初始化完成后进程就死亡。

pod创建后基础容器pause就已经被创建了

readness 就绪检测
liveness 生存检测
在这里插入图片描述

readiness

如下，deploymet管理的pod已经处于running,表示可以通过svc访问了，但其实内部的服务并没有配置好，因此需要readyness探测，通过tcp连接或者http协议获取状态。判断这个服务是否可用了。如果可用再把pod状态更改为running

liveness

pod里面会运行一个主容器叫main C,主容器运行了一个nginx进程，如果nginx出现僵尸进程，比如nginx已经无法使用，但是进程还在运行。pod的状态还是runnig ,表示能继续向外提供服务，因此需要一个机制就是发现nginx不能对外提供服务，应该重启或者重建pod，就是liveness

这些就是pod的生命周期。

过程：

首先，kubectl向API接口发送指令，kube api 会调度到kubelet ，这个调度过程是etcd完成的，通过存储，然后kubelet操作CRI,CRI完成容器的初始化。初始过程会首先启动一个pause的基础容器。负责网络及存储共享。接着进行多个init C初始化。也可以没有。初始化后进入main c运行。在main c之前可以运行执行start开始的一个脚本命令。结束的时候也会运行执行一个stop的命令。也就是退出应该怎么办。过程中探针的参与。readyness不是顶头的，比如可以在容器运行五秒之后再开始探测。这是允许的。同理liveness，只有readiness通过后pod状态才会显示为running或者ready。liveness伴随整个容器的生命周期。当发现主容器损坏或不正常访问就可以重启容器或者删除命令。根据重启策略。

整体访问流程

用户执行kubectl/userClient向apiserver发起一个命令，经过认证授权后，经过scheduler的各种策略，得到一个目标node，然后告诉apiserver，apiserver 会请求相关node的kubelet，通过kubelet把pod运行起来，apiserver还会将pod的信息保存在etcd；pod运行起来后，controllermanager就会负责管理pod的状态，如，若pod挂了，controllermanager就会重新创建一个一样的pod，或者像扩缩容等；pod有一个独立的ip地址，但pod的IP是易变的，如异常重启，或服务升级的时候，IP都会变，这就有了service；完成service工作的具体模块是kube-proxy；在每个node上都会有一个kube-proxy，在任何一个节点上访问一个service的虚拟ip，都可以访问到pod；service的IP可以在集群内部访问到，在集群外呢？service可以把服务端口暴露在当前的node上，外面的请求直接访问到node上的端口就可以访问到service了；

在这里插入图片描述
init C如果没有成功pod就会重启。重新执行。

应用景象分离的意思就是创建的过程可以在init C里面执行，在main C只需要构建即可。

意思就是mc没有访问某文件的权限，但是initc可以访问。initC获取后写入到main C 然后init C写完后退出。但是main C没权限访问。所以安全性提高。
分权限治理

在这里插入图片描述
比如一个pod里面两个容器。一个mysql，一个apache+PHP。所以应该mysql先启动。如果apache先启动连接不上mysql就会报错。以为容器出问题了重启pod,可以在apache加init C去探测mysql是否正常。如果正常就退出容器。apache才开始启动。然后正常连接。
在这里插入图片描述
vim init_pod.yml

command就是启动容器执行的并且替代了cmd的命令。
initcontainers就是为上面的容器赋予一个初始化容器。
nsklookup就是检测后面的域名有没有解析成功,跟下面的svc有关系。until表示如果解析成功正确就退出循环。如果解析失败就输出一句话后休眠两秒继续执行。
第二个就是检测mydb的svc是否能解析成功。

k8s集群内部的dns就会把svc service解析为ip
在这里插入图片描述
因为删除pod之后deployment会重新建立，所以删除所有的deployment

可以发现初始化失败

在这里插入图片描述

ports需要被暴露
端口是80，暴露到svc的端口是9376

init 成功了1个是因为创建了一个svc的，k8s自带的coredns会自动把myservice解析为10.105.103.129

创建玩service会自动写入dns供pod去读取是否已经解析。

然后pod第一个初始化容器退出，退出代码为0。开始执行第二个
在这里插入图片描述

init c 没有执行成功你会发现main c 根本不执行。

就是pause 网络和数据初始化
kubectl edit pod xxx。会发现就是一个yaml文件
只有更改image才会重启pod

init 的容器名字也必须是唯一的。不能和其他的重合。
你会发现两个init容器镜像都一致也不会报错，因为第一个执行完就退出了。所以都使用80端口也可以。

探针

如果就绪探测在init C里面做不太友好，因为他执行完会退出，所以在主容器里面做会比较好。如果主容器探测成功一定能连接上。
在这里插入图片描述

readinessprobe准备好后main C才能对外正常访问，
liveness会跟随容器的整个生命周期。从liveness启动到pod生命结束。持续循环的检测容器的应用程序等资源是否还可用。不可用kubelet会杀死程序。杀死后重启策略为always会重启一个新的pod。
在这里插入图片描述
有的写错了，请看实验截图。

镜像拉去策略是如果有的话就不下载
容器启动1秒之后开始检测
每三秒检测一次
在这里插入图片描述
指的是http请求下的/,不是文件系统的/
因为80端口下的路径下面并没有那个文件，因此虽然running但是并没有准备好

在这里插入图片描述

在这里插入图片描述
404代表页面不存在。
如果想要进入pod的容器exex
进入具体的容器加-c. 但是如果只有一个容器就不用加了

可以看到就绪了

镜像默认下载的是latest
command指的是容器先创建一个文件，休眠60秒后删除，继续休眠
因为探针是启动后1秒开始检测的，六十秒内检测20次，所以大概第二十次就会探测失败。因为那个目录没删除了，存活探针探测不到了。
所以会干掉重启
在这里插入图片描述

-w检测下

重启次数加一了
表示删除了之前的pod，重启了一个新的