标签：readiness probe 容器 liveness 探针 deployment pod 就绪
1.概要
我遇到的问题主要是，在部署的时候老的pod都是正常的，但是新部署的pod由于参数等配置错了，其实启动是有问题的。但是新的pod在启动3秒以后就把老的pod给干掉了，错误判断属于正常启动，然后几秒以后新的pod又挂了，导致运维的时候出现服务无法访问的情况。
同时当你使用 Kubernetes 的时候，有没有遇到过 Pod 在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过 Kubernetes 是如何检测 pod 是否还存活？虽然容器已经启动，但是 Kubernetes 如何知道容器的进程是否准备好对外提供服务了呢？让我们通过 Kubernetes 官网的这篇文章 Configure Liveness and Readiness Probes，来一探究竟。
本文将展示如何配置容器的存活和可读性探针。
2.探针类型
2.1. liveness probe（存活探针）
Kubelet 使用 liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness 探针将捕获到 deadlock，重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去（谁的程序还没几个 bug 呢）。
2.2. readiness probe（就绪探针）
Kubelet 使用 readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当 Pod 中的容器都处于就绪状态时 kubelet 才会认定该 Pod 处于就绪状态。该信号的作用是控制哪些 Pod 应该作为 service 的后端。如果 Pod 处于非就绪状态，那么它们将会被从 service 的 load balancer 中移除。
最关键的是，一个新的pod处于就绪状态以后，老的pod就会被杀掉，所以就绪状态前需要确保真的就绪
3.探针配置参数
Probe 中有很多精确和详细的配置，通过它们你能准确的控制 liveness 和 readiness 检查：
initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。periodSeconds：执行探测的频率。默认是 10 秒，最小 1 秒。timeoutSeconds：探测超时时间。默认 1 秒，最小 1 秒。successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness 必须是 1。最小值是 1。failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3。最小值是 1。
4.配置实例
4.1. liveness probe（存活探针）
- deployment配置
等待30s再开始检测是否重启
- restart以后情况
可以看到新启动的pod在3秒内就已经running并且就绪状态(1/1)；这样的话老的pod就被关闭了；但是实际上，新的pod是有问题的，连接不上consul
4.2. readiness probe（就绪探针）
- deployment配置
等待30s再开始检测就绪
- restart以后情况
由于新的pod是有问题的，连接不上consul，所以当然是不希望能取代已经正常的老的pod；可以看到就绪探针起到效果了，37s的时候还没有就绪，因为内部已经报错了，连接consul异常；这样就导致了一直重启。
这也是我要的状态：新的pod留够缓冲时间来判断是否正常，如果30s还没有正常启动，那么就有问题了
标签：readiness,probe,容器,liveness,探针,deployment,pod,就绪 来源： https://www.cnblogs.com/zhanchenjin/p/16649277.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。