今天继续给大家介绍Linux运维相关知识，本文主要内容是Pod容器探测。
一、Pod生命周期重要行为
在Pod的生命周期中，有如下几个重要行为：
1、初始化容器
初始化容器即在应用程序的主容器在启动前要运行的容器，该容器的任务通常是为主容器的启动进行一些预置操作。初始化容器具有以下两点特征：
（1）初始化容器必须运行完成直至结束，如果初始化容器阶段运行失败，那么Kubernetes需要重启并等待初始化完成，除非在Pod的spec.restartPolicy中设置为Never对该项进行限制。
（2）每个初始化容器必须按照定义的顺序串行运行。
2、容器探测
容器探测是Pod在运行时，由Kubelet对容器进行周期性的健康诊断，诊断的具体操作由容器的处理器进行定义。尽管Kubernetes使用Controller来管理Pod，当Pod启动发生错误时会重新启动，但是Pod中容器的部分非错误性故障却无法使得Controller识别。例如，Pod中的容器虽然工作正常，但是80端口无法提供Web服务等。在这种情况下，就需要我们通过容器探测，进一步探测容器所处的状态，并根据容器的健康情况决定对容器的重启等操作。
二、容器探测分类
按照容器探测的方法进行分类，容器探测可以分为以下三种：
1、ExecAction
在容器内执行指定命令，如果该命令返回为0表示健康，否则即为不健康状态，这种检测方式为Exec探测。
2、HTTPGetAction
通过向容器的指定路径发起HTTP Get的请求，如果返回2xx或者3xx的状态码则表示健康，否则即为不健康，这种检测方式为HTTP的探测。
3、TCPSocketAction
通过与容器的某端口尝试建立TCP链接，如果能够成功建立链接，则处于健康状态，如果不能则视为不健康，这种检测方式为TCP的探测。
按照容器探测的类型进行分类，容器探测可以分为以下两种：
1、存活性探测
存活性探测用于判定Pod是否处于“健康”状态，如果判定Pod中的容器处于不健康状态，kubectl将会杀死容器并根据重启策略来决定是否对该容器进行重启。未定义存活性检测的容器的默认状态为Success。
2、就绪性探测
就绪性探测用于判断容器是否准备就绪，是否可以为外部提供服务。如果就绪性探测失败，Pod的端点控制器（如Service）就会将该Pod的IP移除，从而使得外部流量避免访问该未就绪的容器，当就绪性检测成功后，其IP会被添加回来。
一般而言，灵活性探测和就绪性探测的选择要基于以下原则：
1、如果容器能够在遇到问题或者不能提供服务的情况下自行崩溃，则不需要使用存活探针，Kubernetes集群本身即可完成这样的操作。
2、如果希望容器在探测处于不健康状态时能够被杀死并重新启动，那么可以指定一个存活性探针，并且指定restartPolicy为Always或者是OnFailure。
3、如果要仅在探测成功后才向Pod发送数据流量，则应该使用就绪性探测。就绪性探测会使得Pod启动，并继续完成其初始化过程，直至Pod初始化完成后，才开始向Pod内引导数据流量。
4、如果希望容器能够自行维护，则可以合理的指定就绪探测和存活探测，并分别探测不同的端点。
5、如果想在Pod容器被删除后终止请求，则无需使用任何探针，因为Kubernetes集群会自动帮助我们做到这一点。
三、容器的重启策略
在Pod.spec中，有一个resatartPolicy字段，该字段适用于所有Pod中容器，其值可以设置为Always、OnFailure和Never。Always是默认设置，表示一旦Pod对象终止，就立即重启；OnFailure表示仅在Pod对象出现错误时才进行重启；而Never则表示从不重启。
如果Pod中的容器需要重启，那么其第一次重启时会根据需要，立即重启，之后的重启操作由kubelet延迟一段时间后进行。之后的重启操作时长依次为10秒、20秒、40秒……并依次倍增，直至达到300秒的最大延迟时间。
原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/weixin_40228200/article/details/124286708
