重用依赖服务的就绪探测来控制服务的启动答案

【问题标题】：Reusing readiness probe of a dependent service to control start up of a service重用依赖服务的就绪探测来控制服务的启动
【发布时间】：2023-03-29 08:25:02
【问题描述】：

我有一个后端服务，我将使用 Kubernetes（使用 Helm 图表）来控制它。这个后端服务连接到一个数据库（MonogoDB，它就是这样）。在数据库准备好接收连接之前启动后端服务是没有意义的（后端将通过重试来处理丢失的数据库，但它会浪费资源并用分散注意力的方式填充日志文件错误消息）。

为此，我相信我可以将add an init container 发送到我的后端，并让该初始化容器等待（或轮询）直到数据库准备好。看来这是init containers的预期用途之一

由于 init 容器在任何应用容器启动之前运行完成，因此 init 容器提供了一种机制来阻止或延迟应用容器启动，直到满足一组先决条件。

也就是说，让my 服务的init 容器与数据库的readiness probe 进行相同操作。这反过来意味着将代码从数据库的配置（Helm 图表）复制并粘贴到我的后端的配置（或 Helm 图表）。不理想。有没有更简单的方法？有没有一种方法可以向 Kubernetes 声明，在知道数据库准备好之前我的服务不应该启动？

【问题讨论】：

就绪探针的实现是容器实现的一部分，因此没有简单的方法将其复制到另一个容器。如何从 Helm 图表中复制就绪探测的实现？
@weibeld 文本编辑器中的复制粘贴。我不是指一些巧妙的模板操作。
我的意思是在 Helm 图表中如何实现就绪探测？您想复制粘贴readinessProbe.httpGet 字段吗？
@Raedwald 您尝试过这个解决方案还是其他解决方案？

标签： kubernetes dependencies initialization kubernetes-helm readinessprobe

【解决方案1】：

如果我理解正确的话。从 Mongo DB 的角度来看，使用 readinessprobe 一切都按预期工作：

根据documentation：

kubelet 使用就绪探测来了解容器何时准备好开始接受流量。当一个 Pod 的所有容器都准备好时，它就被认为准备好了。此信号的一种用途是控制哪些 Pod 用作服务的后端。 当 Pod 未准备好时，它会从服务负载均衡器中移除。

从后端的角度来看，您可以使用 initcontainer - 一个缺点是，当您的后端服务启动一次时（在成功初始化 initcontainer 之后），DB pod 将准备好为流量提供服务，但是当它将失败后端服务将填充您的错误消息 - 和以前一样。

所以我可以建议使用here 描述的解决方案。

在您的后端部署中，您可以结合额外的 readinessprobes 来验证您的主要部署是否已准备好为流量提供服务，您可以使用 sidecar 容器来处理此过程（验证与主要数据库服务的连接并将 f.e. 信息写入静态文件每个特定时间段）。作为示例，请查看带有 mongoDBCheck 边车的 EKG library。或者只是简单地执行命令作为脚本在 Sidecar 容器中运行的结果：

readinessProbe:
  exec:
    command:
      - find
      - alive.txt
      - -mmin
      - '-1'
  initialDelaySeconds: 5
  periodSeconds: 15

希望有帮助

【讨论】：