考虑一个通过 http 端点进行健康检查设置的 pod/health在端口 80 上，需要近 60 秒才能真正准备好并为流量提供服务。
readinessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 60
livenessProbe:
httpGet:
path: /health
port: 80
问题：
- 我的上述配置对于给定的要求是否正确？
- Liveness Probe 是否只有在 Pod 准备就绪后才开始工作？换句话说，我假设一旦 POD 准备就绪，就绪探测作业就完成了。之后 livenessProbe 负责健康检查。在这种情况下，我可以忽略
initialDelaySeconds用于 livenessProbe。如果它们是独立的，当 pod 本身还没有准备好时，进行 livenessProbe 检查有什么意义！ ？
- 检查这个文档 https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/。他们的意思是什么
如果您希望您的容器能够自行关闭
维护，您可以指定检查端点的就绪探针
特定于与活性探针不同的就绪性。
我假设，只有当 livenessProbe 失败时，正在运行的 Pod 才会自行关闭。不是 readinessProbe。医生说的是另一种方式。
Clarify!
我从第二个问题回答。第二个问题是：
Does 活性探针仅在 Pod 准备就绪后才开始工作？
换句话说，我假设一旦 POD 就绪探测作业就完成了
准备好了。之后 livenessProbe 负责健康检查。
我们最初的理解是，活性探针将在就绪探针成功后开始检查，但是事实并非如此。它为此挑战提出了一个问题。您可以查看here https://github.com/kubernetes/kubernetes/issues/27114。然后通过添加解决了这个问题启动探针。 https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190221-livenessprobe-holdoff.md
总结：
活性探针：指示容器是否正在运行。如果
活性探测失败，kubelet 杀死 Container，并且
容器受其重启策略的约束。如果容器没有
提供活性探针，the default state is Success.
准备情况探针：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态是“失败”。如果容器不提供就绪探针，the default state is Success.
启动探针：表示Container内的应用程序是否启动。如果提供了启动探针，则所有其他探针都将被禁用，直到成功为止。如果启动探测失败，kubelet 会杀死 Container，并且 Container 会遵循其重启策略。如果容器不提供启动探针，the default state is Success
look up here https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
