docker - k8s中如何等待其他容器完成执行？

Question

假设我有一个应用程序 A 容器和另一个名为 resources-preparation 的容器，它将尝试创建数据库表等以引导应用程序 A。

App A 容器和 resources-preparation 容器位于不同的 pod 中。 resources-preparation 容器完成后，如何启动 App A 容器。

PS: resources-preparation 容器根本不是一个服务。所以我可能无法使用 waitfor 图像来检测 resources-preparation 容器完成。

Answer 1

似乎存在一种架构不一致:现有的应用程序架构与 Kubernetes 范式不太吻合:

• pod A 绑定(bind)到 pod resources-preparation，因此必须等待其成功完成，而 k8s 假定独立或松散耦合的微服务。
• 由于紧密依赖，容器 A 和 resources-preparation 被放入不同的 pod 中，而辅助应用程序应放入与主容器相同的容器中。参见讨论 Communicate Between Containers in the Same Pod .
• pod A 依赖于外部数据库，而在 k8s 中，微服务应该使用自己的数据库或副本以保持独立性。
• pod A 和 resources-preparation 应该通过 k8s API 进行通信。这意味着 pod A 应该从 kube-apiserver 获取有关 resources-preparation 完成的信息。

列出的原则会导致额外的开销，但这是您为 Kubernetes 所依赖的冗余所付出的代价。

解决问题的可能方法:

1. 根据k8s原则重新设计或修改应用程序和后端数据库，将它们分解成一组松散耦合的微服务。作为假设:

   • a) 让应用 A 独立地从它的数据库副本开始；
   • b) 并行地让resources-preparation 开始并在它自己的副本中创建表；
   • c) 然后将新表添加到现有复制或创建新复制。在这种方法中，pod A 不必等待 pod resources-preparation。数据库复制将改为等待。这样，依赖关系就会从 k8s 级别移到上层。

   不幸的是，将现有应用程序适配到 k8s 可能具有挑战性，并且通常需要从头开始重新开发应用程序。这是一项耗费时间和资源的任务。

   这里有一份很好的白皮书:Principles of container-based application design .

2. 因为 resources-preparation 是 A 的辅助容器，所以将两个容器放在同一个 pod 中。这样来自 Init Containers 的示例代码concept 将完全满足容器 A 的需求。对于等待 resources-preparation 完成的容器 A 来说重要的是:

   • Init 容器总是运行完成。
   • 每个初始化容器必须成功完成才能启动下一个容器。

3. 如果您出于某种原因无法将两个容器加入到同一个 pod 中，作为一种变通方法，可以将应用程序组件放入一个“包装器”中，以帮助它们假装表现为松散耦合的微服务。这个包装器应该在 pod 级别以下实现，以便对 Kubernetes 透明:围绕容器或应用程序。在一个简单的例子中，您可以使用 until 循环从 shell 脚本中启动应用程序 A。该脚本应获取在 StatefulSet 中运行的 resources-preparation pod 的状态通过 kube-apiserver 决定应用程序 A 是否可以启动。

   可以为此使用 REST API 请求(参见答案 Kubernetes API server, serving pod logs)。

   应该为 API 请求提供一种在 kube-apiserver 上进行身份验证的方法。理论和实际例子在这里:

   Access Clusters Using the Kubernetes API

   cURLing the Kubernetes API server