Kubernetes 多容器 Pod：概述

作者 Agata Skorupka (The Scale Factory) | 译者 Xin Li (Daocloud) |

随着云原生架构的不断演进，Kubernetes 已成为部署复杂分布式系统的首选平台。 在这个生态系统中，最强大却又微妙的设计模式之一是边车（Sidecar） 模式 —— 一种允许开发者扩展应用程序功能而不深入源代码的技术。

边车模式的起源

想象一下边车就像一个可靠的伴侣摩托车附件。历史上，IT 基础设施总是使用辅助服务来处理关键任务。 在容器出现之前，我们依赖后台进程和辅助守护程序来管理日志记录、监控和网络。 微服务革命改变了这种方法，使边车成为一种结构化且有意图的架构选择。 随着微服务的兴起，边车模式变得更加明确，允许开发者从主服务中卸载特定职责而不改变其代码。 诸如 Istio 和 Linkerd 之类的服务网格普及了边车代理， 展示了这些伴侣容器如何优雅地处理分布式系统中的可观察性、安全性和流量管理。

Kubernetes 实现

在 Kubernetes 中，边车容器 与主应用程序位于同一个 Pod 内，实现通信和资源共享。 这听起来就像是在 Pod 内一起定义多个容器一样？实际上确实如此， 这也是在 Kubernetes v1.29.0 引入对边车的本地支持之前实现边车容器的唯一方式。 现在，边车容器可以使用 spec.initContainers 字段在 Pod 清单中定义。 所指定容器之所以变成了边车容器，是因为你在规约中设置了 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 可能听起来令人困惑。为何在定义 边车容器时，必须在 spec.initContainers 数组中添加条目？ spec.initContainers 在主应用程序启动前运行至完成，因此它们是一次性的，而 边车容器通常与主应用容器并行运行。正是通过带有 restartPolicy:Always 的 spec.initContainers 区分了经典的 Init 容器和 Kubernetes 原生的边车容器，并确保它们始终保持运行。

何时采用（或避免使用）边车

虽然边车模式在许多情况下非常有用，但除非使用场景证明其合理性， 否则通常不推荐优先采用这种方法。添加边车会增加复杂性、 资源消耗以及可能的网络延迟。因此，应首先考虑更简单的替代方案， 例如内置库或共享基础设施。

在以下情况部署边车：

  1. 你需要扩展应用程序功能，而无需修改原始代码
  2. 实现日志记录、监控或安全等跨领域关注点
  3. 处理需要现代网络功能的遗留应用
  4. 设计需要独立扩展和更新的微服务

谨慎行事，如果：

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

四个基本的多容器模式

Init 容器模式

Init 容器模式用于在主应用程序容器启动之前执行（通常是关键的）设置任务。 与常规容器不同，初始化容器会运行至完成然后终止，确保满足主应用程序的前提条件。

适合于：

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

初始化容器确保你的应用程序在一个可预测、受控的环境中启动，而无需修改代码。

Ambassador 模式

一个大使（Ambassador）容器提供了 Pod 本地的辅助服务，这些服务暴露了一种访问网络服务的简单方式。 通常，Ambassador 容器代表应用容器发送网络请求，并处理诸如服务发现、对等身份验证或传输中加密等挑战。

能够完美地处理以下需求：

  1. 卸载客户端连接问题
  2. 实现语言无关的网络功能
  3. 添加如 TLS 的安全层
  4. 创建强大的断路器和重试机制

配置助手

一个配置助手边车容器动态地向应用程序提供配置更新， 确保它始终可以访问最新的设置而不会中断服务。 通常，助手需要在应用程序能够成功启动之前提供初始配置。

使用场景：

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

适配器模式

一个适配器（adapter）（有时也称为切面（façade））容器使主应用程序容器与外部服务之间能够互操作。 它通过转换数据格式、协议或 API 来实现这一点。

优点：

  1. 转换遗留数据格式
  2. 搭建通信协议桥梁
  3. 帮助不匹配服务之间的集成

总结

尽管边车模式提供了巨大的灵活性，但它不是万能的。所添加的每个边车容器都会引入复杂性、 消耗资源，并可能增加操作负担。始终首先评估更简单的替代方案。 关键在于战略性实施：将边车用作解决特定架构挑战的精准工具，而不是默认选择。 正确使用时，它们可以提升容器化环境中的安全性、网络和配置管理。 明智地选择，谨慎地实施，让你的边车提升你的容器生态系统。