关于后端:k8s-就绪探针

提起探针，不知兄 dei 们是否有印象，之前咱们分享过存活探针，分享 存活探针是如何确保异样容器主动重启来放弃应用程序的失常运行，感兴趣的能够查看文章 k8s 系列 k8s 学习十七，存活探针正本机制 2

明天咱们就独自来分享一下 就绪探针

就绪探针也是分为 3 种类型

在执行过程的中央，容器的状态是由过程的退出状态码决定的

向容器中发送 GET 申请，通过响应的 HTTP 状态码判断容器是否筹备好了

关上一个 TCP 连贯到容器的指定端口，如果能够建设连贯，那么就认为容器是曾经筹备好了

看了上述 3 种类型，是不是感觉和存活探针如同也差不多

那么咱们持续看看就绪探针的细节，存活探针和就绪探针的区别

启动容器的时候，存活探针和就绪探针，都能够给 k8s 配置一个等待时间，当等待时间到了之后，才能够执行查看的操作

存活探针	就绪探针
存活探针查看容器的时候，如果查看未通过，会立马重启 pod	周期性的查看容器，若查看不通过，证实 pod 没有筹备好，那么该 pod 就会从服务中删除掉当查看 pod 再次准备就绪了，那么该 pod 又会从新增加到服务中

画一个图来阐明一下成果：

对于未就绪的 pod，就绪探针依然是周期性的探测，若 pod 未就绪，也不会杀掉或者重启 pod，当 pod 被检测到就绪后，该 pod 依然是能够被退出到服务中的

此处的从服务中删除和退出到服务中，具体体现是在 service 的 endpoints 列表中的 IP 和 PORT 信息

还记得之前咱们咱们演示存活探针的例子是在什么资源外面演示的吗？咱们是在 RC 和 RS 外面演示，因为 RC / RS 能够动静的扩缩 pod 的数量，演示起来不便

查看咱们试验环境的 rs 资源信息

编辑 rs 资源清单，计入就绪探针

readinessProbe:
  exec:
    command:
    - ls
    - /var/xmtready

删除以后的 pod

学了 RS 和 RC 后咱们晓得，当批改了 RS 或者 RC 资源后，对于现有的 pod 并不会影响，只有新生成一个 pod 的时候才会用咱们最新的容器模板来创立 pod

因而，咱们能够先删除掉 pod

kubectl delete po --all

查看到成果，生成的每一个 pod 都是未就绪的，咱们能够查看任意 pod，describe 查看一下详情

对于 Readiness: exec [ls /var/xmtready] delay=0s timeout=1s period=10s #success=1 #failure=3 一栏，参数和之前的存活探针含意统一，此处就不在赘述了

来关注一下报错信息：

kubelet, minikube  Readiness probe failed: ls: cannot access /var/xmtready: No such file or directory

能够看到失败的起因是就绪探针，探测失败了，没有方法正确拜访到 pod 外面的 /var/xmtready 文件或者目录

此处也就是模仿 pod 须要失常解决申请的前置条件，必须要前置条件筹备好之后，pod 才是就绪的

人为筹备好就绪条件

那么对于当初试验的这个状况，咱们能够认为的在 pod 外面退出就绪的前置条件，那就是在 pod 中创立一个 /var/xmtready 文件或者目录即可

kubectl exec kubia-rs-4kvg2 -- touch /var/xmtready

此时对于 pod kubia-rs-4kvg2，曾经有了就绪的前置条件，那么该 pod 就会被认为是就绪了，就能够失常解决内部的申请了，因为咱们在 kubectl get po 的时候就 能够看到 READY 是 1/1

此处要阐明一下，上述形式是为了演示不便，才应用间接去人为增加探针的前置条件来增加或者删除 pod 到服务中来

后面的文章也分享到，咱们应该通过应用标签的形式来从服务中增加 pod 或者删除 pod

在工作中，咱们都能够将就绪探针退出到 pod 中，然而对于何时才算就绪，应用程序达到了什么状态才算是就绪，才算是可能失常解决内部客户端打过去的申请，这个就须要业务实现者依据本身的需要来定义了

以上就是明天分享到的 就绪探针，顺带回顾了一下存活探针的，心愿对你有帮忙

明天就到这里，学习所得，若有偏差，还请斧正

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是 阿兵云原生，欢送点赞关注珍藏，下次见~

【k8s 系列】k8s 学习二十，就绪探针