k8s-探针(四)
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了k8s-探针(四)相关的知识，希望对你有一定的参考价值。
参考技术A k8s 可以通过存活探针 (liveness probe) 检查容器是否还在运行。 可以为 pod 中的每个容器单独指定存活探针。如果探测失败， k8s 将定期执行探针并重新启动容器。使用这个app.js构建出对应的镜像.
探针是针对Pod的，所以只需要在Pod上, template.pec处配置，这里测试使用ReplicaSet来测试，用下面的yaml.
演示
查看rs的状态
除了明确指定的存活探针选项，还可以看到其他属性，例如delay(延迟）、 timeout(超时）、period(周期）等。delay=15s显示在容器启动15s后开始探测。timeout仅设置为1秒，因此容器必须在1秒内进行响应， 不然这次 探测记作失败。每10秒探测一次容器(period=10s), 并在探测连续三次失败 (#failure= 3)后重启容器。
过段时间后再去查看pod
Last State 这一栏及后面信息，可以看到，上次终止， Reason=Error , Exit Code=137 .这个退出码128+x, 137=128+9(SIGKILL).9的原因是因为我们容器是好的，但是探针探测到之后，需要重启容器，所以直接杀死进程(kill -9)
Pod可能需要时间来加载配置或数据，或者可能需要执行预热过程以防止第一个用户请求时间太长影响了用户体验。在这种情况下，不希望该Pod立即开始接收请求，尤其是在运行的示例可以正确快速的处理请求的情况下。不要讲请求转发到正在启动的Pod中，直到完全准备就绪。
这个准备就绪的概念显然是每个容器特有的东西。k8s只能检查咋容器中运行的应用程序是否响应一个简单的GET请求，或者他可以响应特定的URL路径(该URL导致应用程序执行一系列检查已确定它是否准备就绪)。
像存活探针一样，就绪探针也有三种类型
启动容器时，可以为k8s配置一个等待时间，经过等待时间后才可以执行第一次准备就绪检查。之后，它会周期性的调用探针，并根据就绪探针的结果采取行动。如果某个Pod报告它尚未准备就绪，则会从该服务中删除该Pod。如果Pod再次准备就绪，则重新添加Pod。
与存活探针不同，如果容器未通过准备检查，则不会 被终止或重新启动。这是存活探针与就绪探针之间的重要区别。存活探针通过杀死异常的容器，并用新的正常容器替代他们来保持Pod正常工作，而就绪探针确保只有准备好处理请求的Pod才可以接收请求。
就绪探针将定期在容器内执行 ls /var/ready 命令。如果文件存在， 则 ls 命令返回退出码 0, 否则返回非0的退出码。如果文件存在，则就绪探针将成功，否则，它会失败。
查看Pod,因为还没有 /var/ready 文件，所以探针失败，所有pod处于NotReady状态(0/1).
查看endpoints
可以看到，因为Pod全都是未就绪，所以endpoints一个ip都没有。
可以看到第一个容器已经ready了，并且endpoints中也已经加入了对应的Pod的IP，访问也正常，且只有这一个Pod响应请求。
其实Pod是已经启动了的，只是因为就绪探针探测失败，所以是NotReady状态(0/1).我们可以尝试访问一下另外的未就绪的容器。
可以看到，容器其实是在运行的，只是探针一直未就绪而已，就绪探针不会杀死容器(和存活探针的区别)， curl 直接访问Pod的IP也是可以正常接收请求的。
可以看到 未就绪状态 部分描述。
Unity接入北斗探针SDK（基于UnityPlayerActivity）丨四编写Java代码，导出AAR
