k8s 就绪探针

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

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

今天我们就单独来分享一下就绪探针

就绪探针

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

• Exec 探针

在执行进程的地方，容器的状态是由进程的退出状态码决定的

• HTTP GET 探针

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

• TCP soket 探针

打开一个 TCP 连接到容器的指定端口，如果可以建立连接，那么就认为容器是已经准备好了

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

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

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

• 存活探针是通过杀死异常的容器，使用新的正常的容器来替代他们，最终保证 pod 能够正常工作
• 就绪探针是确认只有那些准备好处理请求的 pod 才会被加入到服务中来

画一个图来说明一下效果：

对于未就绪的 pod ，就绪探针仍然是周期性的探测，若 pod 未就绪，也不会杀掉或者重启 pod，当 pod 被检测到就绪后，该 pod 仍然是可以被加入到服务中的

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

如何在 pod 中加入就绪探针

还记得之前我们我们演示存活探针的例子是在什么资源里面演示的吗？我们是在 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 中，但是对于何时才算就绪，应用程序达到了什么状态才算是就绪，才算是能够正常处理外部客户端打过来的请求，这个就需要业务实现者根据自身的需求来定义了

以上就是今天分享到的 就绪探针，顺带回顾了一下存活探针的，希望对你有帮助