哪些场景可在同container部署多应用、同k8s Pod部署多container？

这两种部署方式都不是什么“错误实践”，各自有非常明确的适用边界，别乱套就行，分开说：

首先先敲个警钟：90%以上的生产场景都不推荐这么做，本身容器的设计初衷就是单进程、单一职责，多个进程塞一个容器里会遇到信号转发不及时产生僵尸进程、日志收集混乱、资源配额无法精准隔离、故障定位困难一堆问题，只有下面几种场景是真的划算：

• 完全拆不开的遗留系统改造：比如有些跑了多年的Java单体老系统，硬编码依赖本地部署的加密狗代理、或者老旧的本地中间件客户端，俩进程必须走127.0.0.1的Unix域套接字通信，改代码解耦的成本高到业务根本不批预算，这种时候直接把俩进程打包到同一个镜像，用tini或者supervisord当1号进程托管所有子进程就行，比硬拆靠谱得多。
• 极轻量的辅助逻辑不值得单独拆容器：比如你就需要一个几百KB的小进程做日志轮转、或者本地流量的简单拦截，单独做个镜像、配成sidecar反而增加调度和维护成本，直接塞到业务容器里性价比更高。
• 本地开发环境的快速联调：开发环境不用讲那么多规范，你要是嫌单独起MySQL、Redis、Mock服务太麻烦，完全可以把这些轻量依赖和你的Java应用打包成一个开发专用镜像，起一个容器就能跑完整联调环境，省很多折腾的时间，记住仅限开发环境用，生产绝对别这么搞。

这个是k8s原生就支持的标准能力，Pod本身的设计就是让多个容器共享网络、存储命名空间，同生命周期调度，生产用的场景非常多，核心判断标准就是：这些容器必须和业务应用强绑定、同生共死、必须调度到同一个节点、需要依赖本地环回通信/共享本地存储，符合这个标准的都可以塞一个Pod里，常见场景：

• Sidecar模式的通用能力注入，这个是最普及的用法：
  • 服务网格代理：比如Istio的Envoy、Linkerd的代理，都是自动注入到业务Pod里的sidecar容器，拦截所有进出流量做灰度、限流、熔断，业务代码完全不用改。
  • 日志/监控采集：比如在Java应用Pod里加个Filebeat/Promtail容器，和业务容器共享日志存储卷，专门采集业务日志上报，不用把采集客户端打包到每个业务镜像里。
  • 配置/证书热更新：跑一个轻量sidecar定时拉取最新的配置、SSL证书，写到共享卷给业务容器用，业务不用自己实现配置监听、证书热加载的逻辑。
• 排障/运维辅助场景：
  • 线上问题排查的时候，用kubectl debug把带Arthas、JDK诊断工具的临时容器注入到业务Pod里，共享进程命名空间直接诊断Java进程，不用重启业务、也不用提前把诊断工具打包到业务镜像里，对业务零影响。
  • 前置初始化操作：Init容器作为Pod生命周期的一部分，会在业务容器启动前执行，比如Java应用启动前需要从对象存储拉取依赖的安装包、初始化目录权限，用Init容器跑这些逻辑，不用把这些初始化脚本写到业务镜像的启动脚本里。
• 强耦合的本地辅助进程：比如你需要一个本地的缓存代理、或者数据库代理，业务走127.0.0.1访问代理，延迟几乎为0，代理和业务同生命周期，业务扩缩容的时候代理跟着一起调度，不用单独维护代理集群的连接关系。
• 离线任务场景的逻辑拆分：比如跑Java写的CronJob数据同步任务，主容器跑同步逻辑，再加一个小容器专门负责同步结果的告警、上报，俩容器共享工作目录，主容器写完结果文件，通知容器直接读取发送，逻辑拆得干净，不用把告警逻辑耦合到业务镜像里。

别为了“省事”把能独立运行、需要单独扩缩容的应用塞到同一个容器或者同一个Pod里，比如你把Java应用和Redis塞一个Pod，那Java应用扩容的时候Redis也跟着多起一堆实例，纯纯浪费资源。

内容的提问来源于stack exchange，提问作者gstackoverflow