在 Kubernetes 中运行对数据库进行维护的 pod/容器

Question

我发现有几个人询问如何启动一个运行数据库的容器，然后运行另一个容器，该容器在数据库上运行维护/迁移，然后退出。以下是我研究过的所有解决方案以及我认为每个解决方案存在的问题：

1. Init Containers - 这不起作用，因为它们在主容器启动之前运行，并且它们会阻止主容器的启动，直到它们成功完成。
2. Post Start Hook - 如果 postStart 钩子可以启动容器而不是简单地在容器内执行命令，那么这将起作用。不幸的是，带有数据库的容器不（也不应该）包含以这种方式运行它所需的相当大的维护应用程序。这将违反每个组件应该做一件事并做好的原则。
3. Sidecar Pattern - 如果 restartPolicy 在容器级别而不是 pod 级别是可分配或可覆盖的，这将起作用。在我的情况下，维护容器应该在 pod 被视为 Running 之前成功终止（就像 postStart 挂钩可以运行容器的情况一样），而 DB 容器应该总是重启。
4. 单独的 Pod - 作为单独的 Pod 运行维护可以工作，但在维护运行之前不应考虑 DB。这意味着管理 Running 状态必须完全独立于 Kubernetes 来完成。系统中的每个其他容器/pod 都必须进行自定义检查以确保维护已运行，而不是简单地检查数据库是否已启动。
5. 使用 Job - 除非我误解了它们的工作原理，否则这将等同于上述（“单独的 Pod”）。
6. OnFailure 带有 Sidecar 的重启策略 - 这意味着对 POD 使用 OnFailure 的 restartPolicy，然后破解数据库容器，使其始终退出一个错误。这是可行的，但显然只是一个被黑的解决方法。编辑：这也会导致 POD 状态出现问题。当维护运行并保持启动并且两个容器都在运行时，POD 的状态是Ready，但是一旦维护容器退出，即使使用 SUCCESS（0 退出代码），POD 的状态也是转到NotReady 1/2。

上述解决方案是否存在我忽略的选项或遗漏的内容？谢谢。

Answer 1

一种选择是使用Sidecar pattern，对您描述的方法稍作改动：

1. 执行维护命令后，您可以使用while : ; do sleep 86400; done 命令或类似命令保持容器运行。
2. 您设置了适当的startupProbe，仅当您的维护命令成功执行时才能成功解析。例如，您可以创建一个文件 /maintenance-done 并像这样使用 startupProbe：

startupProbe:
  exec:
    command:
    - cat
    - /maintenance-done
  initialDelaySeconds: 5
  periodSeconds: 5

使用这种方法，您会得到以下结果：

1. 感谢sleep hack，为您的数据库和边车容器使用相同的restartPolicy 可以正常工作。
2. 只有当两个容器都准备好时，Pod 才会准备好。在 sidecar 容器的情况下，这会在 startupProbe 成功时发生。

此外，您的 pod 中不会有明显的开销：即使 sidecar 容器继续运行，它也会消耗接近于零的资源，因为它只运行 sleep 命令。