我正在执行此任务Configure Liveness, Readiness and Startup Probes 而且我不清楚进行检查的容器是否仅用于检查容器的可用性的容器？因为如果Pod Check容器失败是有道理的，那么api不会让任何流量进入Pod。
因此，运行状况检查信号必须来自运行某些图像或应用程序的容器吗？ （抱歉，另一个问题）
答案 0 :(得分：1)
从您提供的链接看来，他们似乎是在谈论容器，而不是豆荚，因此这些探针是针对每个容器的。当所有容器都准备好时，按照您提供的文档中的说明，豆荚也被描述为准备就绪：
kubelet使用就绪探针来了解何时容器准备就绪 开始接受流量。当所有Pod已准备就绪时， 容器已准备就绪。此信号的一种用途是控制哪个Pod 用作服务的后端。当Pod尚未准备就绪时， 已从服务负载平衡器中删除。
是的，每个运行某些图像或应用程序的容器都应该公开这些指标。
答案 1 :(得分：1)
Livenes和就绪探针是容器内的附加检查，并根据特定探针的设置由 kubelet 进行了验证：
如果命令（由health-check定义）成功，则返回0，并且kubelet认为Container仍然健康。如果该命令返回非零值，则kubelet将杀死Container并重新启动它。
此外：
kubelet使用活动探针来了解何时重新启动Container。例如，活动性探针可能会陷入僵局，而应用程序正在运行，但无法取得进展。在这种状态下重新启动容器可以帮助使应用程序在存在错误的情况下更加可用。
从另一个角度来看：
Pod是Kubernetes REST API中的顶级资源。
根据文档： 豆荚是短暂的。它们的设计目的不是永远运行，当Pod终止时，无法将其恢复。通常，只有在用户或控制器将其删除后，它们才能消失。 有关控制器的信息可以找到Ko2r：
因此，最佳实践是使用上述控制器。您很少会直接在Kubernetes中创建单个Pod，甚至是单身Pod。这是因为Pod被设计为相对短暂的一次性实体。当Pod被创建时（直接由您或由Controller间接创建），它被安排在集群中的Node上运行。 Pod会保留在该节点上，直到进程终止，pod对象被删除，由于缺少资源而将Pod逐出或该节点发生故障为止。
注意：
重新启动Pod中的容器不应与重新启动Pod混淆。 Pod本身不会运行，而是容器在其中运行并一直存在直到被删除的环境
因为Pod表示集群中节点上正在运行的进程，所以当不再需要它们时（使它们被KILL信号强行杀死并且没有机会清理），让这些进程正常终止很重要。用户应该能够请求删除并知道进程何时终止，而且还能够确保删除最终完成。当用户请求删除Pod时，系统会在允许强制杀死Pod之前记录预期的宽限期，并将TERM信号发送到每个容器中的主进程。一旦宽限期到期，就会将KILL信号发送到那些进程，然后从API服务器中删除Pod。如果在等待进程终止时重新启动Kubelet或容器管理器，则会在整个宽限期内重试终止。
Kubernetes API服务器验证和配置api对象的数据，这些对象包括容器，服务，复制控制器等。 API Server为REST操作提供服务，并为群集的共享状态提供前端，所有其他组件都通过该前端进行交互。
例如，当您使用Kubernetes API创建部署时，将为系统提供新的所需状态。 Kubernetes控制平面记录了对象的创建，并通过启动所需的应用程序并将它们调度到群集节点来执行您的指令，从而使群集的实际状态与所需状态相匹配。
在这里您可以找到有关here的信息。
有不同的探针： 例如HTTP探针：
有关processing pod termination的更多信息。
希望获得帮助。