健康检查与进程回收
一个什么都不做的健康声明比没有声明更糟，因为另外两个机制会读取并信任它。
滚动更新需要在将流量从旧容器转移到新容器之前，知道新容器是否已就绪；没有探针，就绪状态就无从知晓。启动顺序也存在同样的依赖：等待某个组件变得健康，只有在健康状态被观察到时才有意义。过去，这两个检查仅凭存在健康块就能被满足——而一个不产生探针的健康块，其效果与一个正常工作的健康块完全一样。结果就是一个通过了所有关卡却从未被实际检查过的部署。
平台如何解决此问题
Section titled “平台如何解决此问题”只有平台能够实际运行的探针才会被接受。 一个声明了 URL 或端口，并要求平台自行构建命令来测试它的探针，会在应用时被拒绝，而不是被存储并静默忽略。接受的格式详见 部署参考，而拒绝信息会指出具体字段和替代方案。
该拒绝是一个经过权衡的决策，而非偏好。当平台确实合成探针时，它会用镜像无法运行的命令来覆盖镜像自身携带的健康检查——因为合成探针调用的工具并不存在于镜像中，导致一个健康的容器报告了失败。
有一条规则会重写你存储的内容，并且会说明。 低于平台下限的探针超时值会被提升到下限，而不是保留原样，因为超时的探针会被终止，而正是这条终止路径会导致下文描述的泄漏。此变更会在响应和日志中以其专属代码公布，因此你未发送的值永远不会被静默更改。每条此类公布都列在 拒绝与修改中。
另外两个值遵循平台默认值，而不是被固定到你的描述中：它们在容器创建时应用，而你存储的文档仍保持为空。区别很重要——一个写入你记录的默认值，会将你固定在你上次操作时平台的默认值上，而没有人做过这个决定。
超时的探测会被终止，其启动的任何进程都会成为孤儿进程。孤儿进程会被容器中作为第一个进程运行的程序收养，而大多数镜像在那里运行应用程序——一个永远不会回收它刚继承的已死子进程的应用程序。这些进程会在容器的生命周期内累积。
补救措施是一个小型的第一进程，其唯一工作就是回收这些进程。它并非专用于声明探测的容器：镜像可以携带自己的健康检查，而一个启动子进程的应用程序即使没有任何探测也会泄漏。
Not this
这不是负载均衡器的探测。路由边缘有自己的健康检查，具有自己的路径和间隔，它决定是否发送流量，两者永远无法从对方推断得出。
此页也不包含最小值、默认值或接受的命令。它们是生成参考中的列，散文中重复的数字可能与平台强制执行的数字不一致。
