16.2 Sidecar、Ambassador、Adapter 与故障实验

辅助容器模式把与主应用生命周期密切相关、但不属于核心业务的能力放进同一个 Pod。它们共享网络和部分存储，也共享扩缩、调度和故障命运。

这种耦合有时正是目的，但不是“把平台功能全部塞进 sidecar”的理由。

Sidecar：伴随主容器的辅助能力

典型 Sidecar 包括日志转发、代理、配置刷新或本地同步器：

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: app
      image: registry.example/scoring@sha256:...
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
    - name: log-forwarder
      image: registry.example/log-forwarder@sha256:...
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
  volumes:
    - name: logs
      emptyDir: {}

评估时要计算每个 Pod 额外的 CPU、内存、启动时间和攻击面。1000 个应用副本意味着 1000 个 Sidecar，不是一个共享代理。

Ambassador：代表应用处理外部通信

Ambassador 是面向外部依赖的本地代理，可负责 TLS、服务发现、连接池和部分重试：

Application → localhost proxy → External Service

应用得到稳定的本地端点，但代理配置必须与业务语义一致。若代理自动重试非幂等写入，主应用甚至可能不知道重复发生。

服务网格数据平面常以 Sidecar 或节点代理实现类似职责，但它不能替代业务级 deadline、幂等键和降级政策。

Adapter：标准化主应用输出

Adapter 容器把应用特有格式转换成平台统一格式，例如把自定义指标转成 Prometheus 暴露格式，或把遗留日志转换成结构化事件。

如果能够直接修改应用使用标准协议，长期通常更简单。Adapter 更适合遗留程序、第三方镜像或迁移阶段。

Init Container 与 Sidecar 不同

一次性的启动前任务，如拉取静态配置、生成证书文件或执行权限准备，适合 Init Container。持续伴随应用运行的能力才适合 Sidecar。

数据库 schema 迁移不宜让每个副本的 Init Container 同时竞争执行。它应是有锁、有审计、可单独观察和回退的发布步骤。

健康和终止要按整体设计

辅助容器引入新的生命周期问题：

• 主应用就绪但代理尚未就绪；
• 主应用退出后，日志转发器尚未排空；
• Sidecar 崩溃但 Pod 仍被视为可服务；
• 网格代理阻止或延迟应用优雅终止。

readiness、启动顺序、终止宽限期和排空协议必须在真实部署环境验证。

混沌工程先从假设开始

混沌工程不是随机“搞坏生产”，而是通过受控实验检验稳态假设：

当单个计分实例被终止时，结算成功率仍高于 99.9%，且 p99 延迟在 2 分钟内恢复到基线。

一个实验包含：

1. 定义可观测稳态；
2. 提出具体故障假设；
3. 选择最小爆炸半径；
4. 设置自动中止条件；
5. 注入实例终止、网络延迟、依赖错误或资源压力；
6. 记录发现并修复，再重复实验。

先在测试环境验证工具和保护，再逐步进入生产的小流量、非关键范围。没有监控、回滚和事件负责人时，不应扩大实验。

应验证的真实问题

• 代理超时是否小于调用方 deadline？
• 重试是否在多个层级叠加？
• Sidecar 资源耗尽会怎样影响主容器？
• 实例终止时在途请求和消息是否安全处理？
• 区域或依赖故障时，系统是快速拒绝还是无界排队？
• 告警是否在用户影响之前或同时触发？

参考资料

• Kubernetes, Pods
• Kubernetes, Sidecar Containers
• Principles of Chaos Engineering, Principles