提供有关该问题的背景的简要背景。
目前，我和我的团队正在将微服务迁移到 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 https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container）认为一个容器只运行 1 个进程是理想的。还有恢复崩溃进程的情况以及运行supervisord可能会干扰容器执行恢复的方式。但我不太确定它是否适用于我们的用例。
您绝对应该对其进行重组，以便每个容器运行一个进程，每个 Pod 运行一个容器。您通常不需要 init 系统或进程管理器（如supervisord 或 runit）（有一种观点认为有一个专用的 init，如tini https://github.com/krallin/tini可以做特殊的 pid-1 事情）。
您在这里提到了两个问题，重新启动失败的进程和集群中的进程放置。对于这两种情况，Kubernetes 都会自动为您处理。
如果Pod中的主进程失败，Kubernetes将重新启动它。您不需要为此做任何事情。如果重复失败，它将开始延迟重新启动。此功能仅在主进程失败时才起作用 - 如果容器的主进程是主管进程，您将永远不会重新启动 Pod，并且您可能不会直接注意到进程是否根本无法启动。
通常，您将通过具有一定数量的相同副本 Pod 的部署来运行容器。 Kubernetes 本身负责决定哪个节点将运行每个 Pod；您不需要手动指定它。豆荚越小，放置它们就越容易。由于您要控制 Pod 的副本数量，因此您还希望将 Web 服务器与队列工作人员等问题分开，以便可以独立扩展它们。
Kubernetes 具有一定的自动扩展能力，尽管典型的方向是根据工作负载来调整集群的大小：在面向云的设置中，如果您添加一个新的 Pod，该 Pod 请求的 CPU 数量多于集群当前可用的 CPU 数量，它将提供一个新节点。 HorizonalPodAutoscaler 是一种高级设置，但您可以对其进行配置，以使工作线程数量成为队列长度的函数。同样，如果它唯一扩展的是工作容器，而不是打包在一起的不相关事物的集合，那么效果会更好。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
