在一个容器中运行多个类似的进程有意义吗？

Question

简要背景以提供有关该问题的上下文。

目前，我和我的团队正在将我们的微服务迁移到 k8s，以减少必须维护多个部署工具和管道的工作。

我们计划迁移的微服务之一是 ETL worker，它监听 SQS 上的消息并执行多阶段处理。

它是使用 PHP Laravel 构建的，我们使用 supervisord 来控制在 aws ec2 上的每个工作实例上运行多少进程。每个进程基本上都会执行一个 laravel 命令来轮询不同的队列以获取新消息。我们还定期调整进程数量，以最大限度地利用每个实例的计算能力。

所以问题是：

迁移到 k8s 时，这种部署方法是否仍然可行？是否仍然需要“最大化”计算使用率？我们是否最好使用“容器方式”在每个容器中运行 1 个进程（不确定这个工具叫什么。runit？）

我从多个来源（例如https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container）读到，理想的是一个容器只运行 1 个进程。还有恢复崩溃进程的情况，以及运行 supervisord 可能会如何干扰容器执行恢复的方式。但我不太确定它是否适用于我们的用例。

Answer 1

你绝对应该重构它，让每个容器运行一个进程，每个 Pod 运行一个容器。您通常不需要 init 系统或像 supervisord 或 runit 这样的进程管理器（有一个论点，即拥有像tini这样的专用 init可以执行特殊的 pid-1 事情）。

您在这里提到了两个问题，重新启动失败的进程和集群中的进程放置。对于这两种情况，Kubernetes 会自动为您处理。

如果 Pod 中的主进程失败，Kubernetes 将重新启动它。您无需为此做任何事情。如果它反复失败，它将开始延迟重启。这个功能只有在主进程失败时才有效——如果你容器的主进程是一个主管进程，你永远不会重启 pod，如果一个进程根本无法启动，你可能不会直接注意到。

通常，您将通过具有一定数量的相同副本 Pod 的部署来运行容器。Kubernetes 本身负责决定哪个节点将运行每个 pod；您无需手动指定此项。豆荚越小，放置它们就越容易。由于您要控制 Pod 的副本数量，因此您还希望将 Web 服务器与队列工作器等关注点分开，以便您可以独立扩展它们。

Kubernetes 有一些自动扩展的能力，尽管典型的方向是根据工作负载调整集群的大小：在面向云的设置中，如果您添加一个新的 pod，它请求的 CPU 比集群当前可用的 CPU 多，它将提供一个新节点。Horizo​​nalPodAutoscaler 是一种高级设置，但您可以对其进行配置，以便工作程序的数量是您的队列长度的函数。同样，如果它扩展的唯一内容是工作程序 Pod，而不是打包在一起的不相关内容的集合，则效果会更好。