如何为Kubernetes构建最优的容器镜像（三）：使用容器实现进程管理

接前文：
如何为Kubernetes构建最优的容器镜像（一）：高效容器镜像的特征、基础镜像层的重用与镜像层的管理

如何为Kubernetes构建最优的容器镜像（二）：容器和Pod级别功能范围的界定、运行时配置的设计

使用容器实现进程的管理

在向容器过渡时，我们通常会从将现有工作负载几乎不做或仅做少量更改地转移到新环境中。通过将已有的实现封装在新的抽象中，将应用程序打包成容器，虽然这种迁移方式能让让应用程序顺利跑起来，但有时却可能导致设计无效。

将容器视为应用程序，而非服务

当开发者在容器内实现大量服务管理功能时，可能经常碰到问题。例如，在容器内运行systemd服务或将Web服务器设置为守护进程，在传统环境中可能是最佳实践，但它们却与容器模型固有的假设相冲突。

主机通过向容器内PID为1的进程发送信号来管理容器的生命周期。PID 1 是第一个启动的进程，在传统计算环境中通常是init系统（如systemd或SysVinit）。然而，由于主机只能管理容器内PID为1的进程，因此使用传统的init系统来管理容器内的进程有时意味着无法控制主体应用程序。主机可以启动、停止或杀死内部的init系统，但无法直接管理应用程序。虽然这些信号有时能够将预期的行为传播到正在运行的应用程序上，但这仍然增加了复杂性。

大多数情况下，最好简化容器内的运行环境，以便PID 1 是在前台运行的主要应用程序。如果必须运行多个进程，则PID 1 应负责管理后续进程的生命周期。某些应用程序如Apache，通过生成和管理处理连接的工作进程原生地具备这种能力。而对于其他应用程序，则可以使用封装好的脚本或非常轻量级的init系统（如dumb-init或tini i