我从第二个问题开始回答。第二个问题是：

活性探头是在吊舱准备好后才开始工作吗？换句话说，我认为一旦POD准备好了，就已经完成了就绪探测作业。在那之后，LivenessProbe负责健康检查。

我们初步的理解是，活性探测将在就绪探测成功后开始检查，但事实并非如此。它为这次挑战打开了一个问题。你可以仰望here。然后通过添加startup probes.解决了这个问题

总而言之：

• livenessProbe**

**livenessProbe：**容器是否正在运行。如果活性探测失败，kubelet将杀死Container，并且Container将受到其重启策略的约束。如果容器不提供活性探测，则the default state is Success.

• ReadinessProbe**

**ReadinessProbe：**容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有服务的端点中删除Pod的IP地址。初始延迟之前的默认就绪状态是故障。如果容器不提供就绪探测，则the default state is Success.

• 创业机会**

StartupProbe：容器内的应用程序是否启动。**如果提供启动探测，则禁用所有其他探测，直到成功。**如果启动探测失败，kubelet将杀死Container，并且Container受其重启策略的约束。如果容器不提供启动探测器，则the default state is Success

查找here。

活性探头用于检查容器是否已启动且处于活动状态。如果不是这样，Kubernetes最终会重启容器。

准备情况探测器还检查依赖项，如数据库连接或容器完成其工作所依赖的其他服务。作为一名开发人员，您必须在这里投入更多的时间来实现，而不仅仅是为了活跃度探测。您必须公开一个端点，该端点在被查询时也会检查提到的依赖关系。

您当前的配置使用活动探测通常使用的健康终结点。它可能不会检查您的服务是否真的准备好处理流量。

库伯内斯依赖于准备情况调查。在滚动更新期间，它将使旧容器保持正常运行，直到新服务声明它已准备好接受流量。因此，必须正确实施准备情况探测。

就绪探测和活跃度探测似乎具有相同的行为。他们做同样类型的检查。但他们在失败的情况下采取的行动是不同的。

就绪探测会关闭流量的服务。因此服务始终可以将请求发送到健康Pod，而活跃性探测器在故障情况下重新启动Pod。它不会为服务做任何事情。当Pod处于可用状态时，服务会照常向Pod发送请求。

建议同时使用两种探头！！

有关代码示例的详细说明，请查看here。

我将通过几个简单的要点来说明它们之间的区别：

livenessProbe

livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 它用来表明集装箱是否已经启动和是否活着，即证明是可用的。
• 在该示例中，如果请求失败，则会重启容器。
• 如果未提供，则默认状态为成功。

ReadinessProbe

readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

• 它用来表明集装箱是否已准备好服务于交通运输，即证明已准备好使用。
• 它检查依赖项，如数据库连接或容器完成其工作所依赖的其他服务。
• 在给定的示例中，在请求返回成功之前，它不会为任何流量提供服务(通过从与Pod匹配的所有服务的端点中删除Pod的IP地址)。
• Kubernetes在滚动更新期间依赖就绪探测，它保持旧容器的启动和运行，直到新服务声明它已经准备好接受流量。
• 如果未提供，则默认状态为成功。

摘要

活体探测：用于检查容器是否可用且活着。

就绪探测：用于检查应用程序是否已准备就绪，并服务于流量。

Kubernetes平台具有验证容器应用程序的功能，称为运行状况检查。活跃度是可用性的证明，而就绪是示例准备就绪的证明。这些功能旨在通过在需要时启用重启来防止服务停机和映像不一致。Kubernetes使用活跃度来知道何时重启容器，因此可以解决大部分问题。Kubernetes使用就绪来了解容器何时可以接受请求。当所有容器都准备好时，吊舱就被认为是准备好的。因此，当Pod初始化时间太长时(通过缓存挂载、数据库模式等)建议增加InitialDelaySecond。

我想把它作为评论发布，但它太长了，所以让我们把它作为一个完整的答案。
我的上述配置是否符合给定要求？

IMHO否，对于两个探测器，您都缺少initialDelaySeconds，而活动和红色可能不应该调用相同的终结点。我会用建议的形式@fgul

活体探头只有在吊舱准备好后才开始工作吗？换句话说，我认为一旦POD准备好了，就已经完成了就绪探测作业。在那之后，LivenessProbe负责健康检查。在本例中，我可以忽略livenessProbe的InitialDelaySecond。如果它们是独立的，当吊舱本身还没有准备好时，做livenessProbe检查有什么意义？

我认为你在想startupProbe，@fgul再次描述了什么是做什么的，所以我重复没有意义。

我在想，只有在livenessProbe失败的情况下，运行的吊舱才会自动关闭。不是ReadinessProbe。医生说是另一种方式。

Pod只能基于livenessProbe重新启动，而不能基于redinessProbe重新启动。

在将红色探测器与外部服务绑定之前，我会三思而后行(正如@Randy建议的那样处于活动状态)，特别是在高负载服务中：

让我们假设您已经定义了一个具有大量Pod的部署，这些Pod连接到一个数据库并正在处理大量请求。现在，数据库出现故障。红色探头也在检查数据库连接，并将所有吊舱标记为“停止服务”。现在，db上升了。豆荚红色探测器将开始通过，但不是立即和所有豆荚立即-豆荚将被标记为“准备好”一个接一个。但它可能太慢-第二个Pod将第一个Pod标记为就绪，所有流量将单独发送到这个Pod。它可能会以一种情况结束，那就是那些被叫醒的豆荚将会陆续被车流扼杀。

对于这种情况，我会说红舱应该只检查舱内部的东西，而不关心外部的服务。Kubernetes端点将返回一个错误，客户端可能支持失败的服务(称为“为失败而设计”)，或者负载均衡器/入口可以覆盖它。

活性探测器是一种相对专门的工具，您可能根本不需要它。然而，他们完全独立地运行AFAIK。

我认为下图描述了每种方法的用例。