多容器 Pod 与 Init 容器

一个 Pod 一个容器最省心，但 Kubernetes 也允许把多个容器捆在一个 Pod 里。这不是为了炫技，是因为有些活必须”哥俩好”才能干。

13-1 为什么要塞多个容器

回忆第 11 章：同一个 Pod 里的容器共享网络和存储卷，还被调度到同一台机器。这意味着它们能用 localhost 互相通信，能读写同一块盘。

如果有两个程序必须贴得这么近，那把它们放一个 Pod 就比放两个 Pod 简单得多。反之，如果只是”都要扩容”，请拆开用多个 Pod 加副本，别硬塞。

13-2 三种常见协作模式

社区总结了三套经典搭配，记住名字，以后看架构图不懵。

sidecar（边车）：主容器干正事，边车在旁边打辅助。好比摩托车旁边挂的挎斗。典型用例是日志收集，主程序往本地文件写日志，边车容器把日志转发出去。

adapter（适配器）：把主容器的输出统一成标准格式。比如主程序吐私有格式的监控数据，adapter 把它转成 Prometheus 能认的格式，对外暴露。

ambassador（大使）：替主容器处理对外通信。比如主程序连本地代理，由 ambassador 容器负责接后端的数据库或消息队列，主程序完全不用关心地址在哪。

这三种本质都是”主容器 + 辅助容器”。辅助容器生命周期跟着主容器走。

13-3 Init 容器：开工前的准备工作

Init 容器（初始化容器）是在应用容器启动之前跑的容器。它有几个硬性特点。

一是按顺序跑。如果有多个 Init 容器，它们一个接一个，前一个成功退出，后一个才开跑。

二是必须全部成功。只要有一个 Init 容器失败，Pod 就会不断重启它，直到跑通。这就给了你一个”启动关卡”：关卡没过，主程序别想起来。

三是跑完就退。Init 容器跑完就结束，不常驻。它用的镜像可以和主容器完全不同，比如用 busybox 去下载配置文件，再交给主容器用。

常见用途：等依赖服务就绪、下载初始化数据、生成配置文件、做权限检查。

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
  - name: wait-for-svc
    image: busybox:1.36
    command: ['sh', '-c', 'until nslookup order-svc; do echo waiting; sleep 2; done']
  containers:
  - name: app
    image: myapp:1.0

这个例子里，Init 容器不停地用 nslookup 等 order-svc 这个服务出现，出现了才让主容器 app 启动。

13-4 sidecar 容器与重启策略

从 v1.29 起，Kubernetes 默认支持”sidecar 容器”（Beta），v1.33 起正式 GA。做法是把一个 Init 容器设 restartPolicy: Always。

设了 Always，这个 Init 容器就不”跑完即退”了，而是被当成 sidecar，在 Pod 整个生命周期常驻，并且比主容器先启动、后关闭。

spec:
  initContainers:
  - name: log-shipper
    image: fluentbit:3.0
    restartPolicy: Always
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  containers:
  - name: app
    image: myapp:1.0
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  volumes:
  - name: logs
    emptyDir: {}

这里 log-shipper 是 sidecar，app 是主容器。它们共享 logs 这个 emptyDir 卷。主程序写日志，sidecar 读日志转发出去。

13-5 共享存储怎么配

多容器 Pod 的核心就是”共享”。存储共享靠卷（Volume），网络共享靠 Pod 网络命名空间。

上面例子里的 emptyDir 是种临时卷：Pod 在就存在，Pod 删了数据也没。两个容器把同一个 emptyDir 挂到各自路径，就能互相传文件。

通信就更简单：同一个 Pod 内，容器直接用 localhost:端口 对话，不需要 Service。

13-6 常见坑

多容器 Pod 虽好，坑也不少。

一是资源争夺。多个容器共用一个 Pod 的 CPU/内存配额，得给每个容器都设 requests/limits（第 15 章），不然一个吃满，其它饿死。

二是启动顺序。普通应用容器之间没有固定启动顺序，别假设谁先起。需要顺序请用 Init 容器。

三是别滥用。我见过有人把八九个容器塞一个 Pod，结果一个崩全得重启，排查地狱。紧耦合才放一起，其它交给多个 Pod。

下一章讲健康检查。多容器 Pod 里尤其该给主容器配探针，不然节点都不知道它到底活没活。