0

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

为此，我相信我可以将一个init 容器添加到我的后端，并让该 init 容器等待（或轮询）直到数据库准备好。这似乎是init 容器的预期用途之一

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

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

4

1 回答 1

-1

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

根据文档：

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

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

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

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

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

希望这有帮助

于 2019-09-20T10:34:47.047 回答