Kubernetes 多容器 Pod：概述

随着云原生架构的不断发展，Kubernetes 已成为部署复杂分布式系统的首选平台。在该生态系统中最强大却又微妙的设计模式之一是 Sidecar 模式——一种允许开发者在不深入源代码的情况下扩展应用功能的技法。

Sidecar 模式的起源

将 Sidecar 想象成一个可靠的摩托车伴侣挂斗。历史上，IT 基础设施一直使用辅助服务来处理关键任务。在容器出现之前，我们依赖后台进程和守护进程来管理日志、监控和网络。微服务革命改变了这种方法，使 Sidecar 成为一种结构化且有意的架构选择。随着微服务的兴起，Sidecar 模式变得更加清晰，允许开发者在不修改主服务代码的情况下，将特定职责卸载给伴随容器。Istio 和 Linkerd 等服务网格推广了 Sidecar 代理，展示了这些伴随容器如何在分布式系统中优雅地处理可观测性、安全和流量管理。

Kubernetes 实现

在 Kubernetes 中，Sidecar 容器与主应用容器在同一个 Pod 内运行，从而实现通信和资源共享。这听起来是不是就像在 Pod 内部一起定义多个容器？实际上确实如此，在 Kubernetes v1.29.0 引入原生 Sidecar 支持之前， Sidecar 容器就必须这样实现。现在，可以使用 Pod 清单中的 spec.initContainers 字段定义 Sidecar 容器。使之成为 Sidecar 容器的关键在于，你需要将其 restartPolicy 指定为 Always。你可以在下面的示例中看到这一点，这是一个完整的 Kubernetes 清单的部分片段

initContainers:
  - name: logshipper
    image: alpine:latest
    restartPolicy: Always
  command: ['sh', '-c', 'tail -F /opt/logs.txt']
    volumeMounts:
    - name: data
        mountPath: /opt

字段名 spec.initContainers 听起来可能令人困惑。为什么当你想要定义 Sidecar 容器时，必须在 spec.initContainers 数组中添加一个条目呢？ spec.initContainers 在主应用容器启动之前运行直到完成，因此它们是一次性的，而 Sidecar 通常与主应用容器并行运行。正是带有 restartPolicy:Always 的 spec.initContainers 将经典的Init 容器与 Kubernetes 原生 Sidecar 容器区分开来，并确保它们始终运行。

何时采用（或避免）Sidecar

虽然 Sidecar 模式在许多情况下都很有用，但通常除非用例证明其合理性，否则它并不是首选方法。添加 Sidecar 会增加复杂性、资源消耗和潜在的网络延迟。因此，应首先考虑内置库或共享基础设施等更简单的替代方案。

以下情况应部署 Sidecar：

1. 你需要在不接触原始代码的情况下扩展应用功能
2. 实现横切关注点，如日志、监控或安全
3. 处理需要现代网络功能的遗留应用
4. 设计需要独立扩缩和更新的微服务

以下情况请谨慎使用：

1. 资源效率是你的首要考量
2. 最小化网络延迟至关重要
3. 存在更简单的替代方案
4. 你希望最小化故障排除的复杂性

四种基本的多容器模式

Init 容器模式

Init 容器模式用于在主应用容器启动之前执行（通常是关键的）设置任务。与常规容器不同，Init 容器运行直到完成然后终止，确保满足主应用的先决条件。

适用于：

1. 准备配置
2. 加载密钥
3. 验证依赖可用性
4. 运行数据库迁移

Init 容器确保你的应用在无需修改代码的情况下，在可预测、受控的环境中启动。

Ambassador 模式

Ambassador 容器提供 Pod 本地的辅助服务，以简单的方式访问网络服务。通常，Ambassador 容器代表应用容器发送网络请求，并负责处理服务发现、对等身份验证或传输中加密等挑战。

在你需要以下情况时非常有用：

1. 卸载客户端连接方面的顾虑
2. 实现语言无关的网络功能
3. 添加 TLS 等安全层
4. 创建健壮的断路器和重试机制

配置助手

配置助手 Sidecar 动态地为应用提供配置更新，确保应用在不中断服务的情况下始终能访问最新的设置。通常，助手需要在应用能够成功启动之前提供初始配置。

用例：

1. 获取环境变量和密钥
2. 轮询配置更改
3. 将配置管理与应用逻辑解耦

Adapter 模式

Adapter（有时也称为Façade）容器通过转换数据格式、协议或 API，实现主应用容器与外部服务之间的互操作性。

优势：

1. 转换遗留数据格式
2. 桥接通信协议
3. 促进不匹配服务之间的集成

总结

虽然 Sidecar 模式提供了巨大的灵活性，但它并非灵丹妙药。每一个新增的 Sidecar 都会增加复杂性、消耗资源并可能增加运维开销。务必首先评估更简单的替代方案。关键在于战略性实施：将 Sidecar 作为解决特定架构挑战的精确工具，而不是作为默认方法。正确使用时，它们可以提高容器化环境中的安全性、网络和配置管理。明智选择，谨慎实施，让你的 Sidecar 提升你的容器生态系统。

• ←上一篇
• 下一篇→