k8s-livenessProbe与ReadinessProbe

Question

考虑一个通过http端点/health在端口80上进行运行状况检查的吊舱，实际上准备就绪并为流量提供服务大约需要60秒。

readinessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 60
livenessProbe:
  httpGet:
    path: /health
    port: 80

问题：

• 以上配置是否符合给定要求？
• 活动探针是否仅在准备就绪后才能开始工作？换句话说，我认为一旦POD准备就绪，就绪探测工作就完成了。之后，liveprobe会进行健康检查。在这种情况下，我可以忽略livenessProbe的initialDelaySeconds。如果它们是独立的，那么在吊舱本身未准备就绪时检查livenessProbe的意义何在！ ？
• 选中此documentation。
是什么意思

  

如果您希望自己的集装箱能够自行拆除   维护，您可以指定一个用于检查端点的就绪探针   专门针对准备情况，与活力调查不同。

我以为，仅当livenessProbe失败时，运行中的吊舱才会自行倒下。不是readinessProbe。医生说另一种方式。

澄清！

Answer 1

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

活力探测器仅在吊舱准备就绪后才能开始工作吗？ 换句话说，我假设一旦POD完成了准备工作， 准备好了。之后，liveProbe会进行健康检查。

我们最初的理解是，对活动性的调查将在成功进行准备性调查后开始进行检查，但事实并非如此。这项挑战为此带来了一个问题。Yon可以查询here。然后通过添加startup probes.

解决了这个问题

总结：

• livenessProbe

livenessProbe ：指示容器是否正在运行。如果 活度探测失败，kubelet杀死了Container，并且 容器受其重新启动策略约束。如果容器没有 提供生动的探针the default state is Success.

• readinessProbe

readinessProbe ：指示容器是否准备好处理请求。如果就绪探针失败，则端点控制器将从与Pod匹配的所有服务的端点中删除Pod的IP地址。初始延迟之前的默认就绪状态为“失败”。如果容器未提供准备情况调查，请the default state is Success.

• startupProbe

startupProbe ：指示是否启动容器中的应用程序。 如果提供了启动探针，则将禁用所有其他探针，直到成功为止。。如果启动探针失败，则kubelet将杀死Container，并且Container将接受其重启策略。如果容器未提供启动探针，则the default state is Success

查找here。

Answer 2

活动性探针将检查容器是否已启动且仍处于活动状态。如果不是这种情况，kubernetes最终将重新启动容器。

准备情况探测还会依次检查依赖关系，例如数据库连接或您的容器要完成其工作所依赖的其他服务。作为开发人员，您需要在这里花更多的时间在实施上，而不仅仅是活动性探针。您必须公开一个端点，该端点在查询时还要检查提到的依赖项。

您当前的配置使用运行状况探针，通常由活动性探针使用。它可能不会检查您的服务是否真的准备好吸引流量。

Kubernetes依赖于准备情况探针。在滚动更新期间，它将使旧容器保持运行状态，直到新服务声明已准备好接受流量为止。因此，准备情况探针必须正确实施。

Answer 3

Kubernetes平台具有验证容器应用程序的功能，称为运行状况检查。 活跃度是可用性的证明，就绪度是可以使用的吊舱就绪性的证明。 这些功能旨在通过在需要时启用重新启动功能来防止服务停机和映像不一致。 Kubernetes使用 liveness 来知道何时重新启动容器，因此它可以解决大多数问题。 Kubernetes使用 readness 来了解何时该容器可用于接受请求。当所有容器都准备好时，该吊舱被视为准备就绪。因此，当pod花费太长时间来初始化（通过高速缓存安装，数据库架构等）时，建议增加initialDelaySeconds。

Answer 4

活动探针是一种相对专用的工具，您可能根本不需要。但是它们完全独立地运行于AFAIK。

Answer 5

准备就绪探针和活力探针似乎具有相同的行为。他们执行相同类型的检查。但是，如果发生故障，他们采取的措施是不同的。

就绪探针会关闭服务中的流量。这样服务就可以始终将请求发送到正常运行的Pod，而活动性探针会在失败时重新启动Pod。它对服务没有任何作用。如果请求处于“ 可用”状态，服务将继续照常将请求发送到Pod。

建议同时使用两个探针！

检查here以获得代码示例的详细说明。

Answer 6

我会将其发布为评论，但是它太长了，所以让我们作一个完整的答案。

我的上述配置是否符合给定的要求？

恕我直言，不，您缺少initialDelaySeconds来进行探测，活跃度和重现性可能不应调用相同的端点。我会使用建议表@fgul

活动探针是否仅在准备就绪后才能开始工作？ 换句话说，我假设一旦POD完成了准备工作， 准备好了。之后，livenessProbe会进行健康检查。在这个 情况下，我可以忽略livenessProbe的initialDelaySeconds。如果他们 是独立的，做活度检查的重点是什么时候 吊舱本身尚未准备好！ ？

我认为您在考虑startupProbe，@ fgul再次描述了做什么，所以我没有必要重复。

我当时假设，只有在 livenessProbe失败。不是readinessProbe。医生说另一种方式。

只能根据livenessProbe而不是redinessProbe重新启动广告连播。

在将rediness探针与外部服务（如@randy建议仍然存在）绑定之前，我会三思而后行，尤其是在高负载服务中：

让我们假设您定义了一个部署，该部署包含许多Pod，这些Pod连接到数据库并正在处理大量请求。 现在数据库关闭了。 Rediness探针还在检查数据库连接，并将所有Pod标记为“服务中断”。 现在数据库上升了。 Pods Rediness探针将开始通过，但不会立即通过，并且会立即在所有Pod上传递-Pod将一个接一个地标记为“ Ready”。 但这可能太慢-第一个Pod将被标记为就绪的第二秒，所有流量都将单独发送到该Pod。最终可能会遇到这样一种情况，即“醒来的”豆荚会被交通一个接一个地杀死。

对于这种情况，我想说Rediness Pod应该只检查Pod内部的东西，而不关心外部服务。 kubernetes端点将返回错误，并且客户端可能支持失败的服务（称为“为失败而设计”），或者负载平衡器/入口可以覆盖它。