Kubernetes 多容器 Pod 概述

随着云原生架构的不断演进，Kubernetes 已成为部署复杂分布式系统的首选平台。在这个生态系统中，Sidecar 模式是最强大但又最微妙的设计模式之一，它允许开发人员在不深入研究源代码的情况下扩展应用程序功能。

Sidecar 模式的起源

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

Kubernetes 实现

在 Kubernetes 中，Sidecar 容器与主应用程序在同一个 Pod 中运行，从而实现通信和资源共享。这听起来是不是就像在 Pod 中将多个容器并排定义一样？确实如此，在 Kubernetes v1.29.0 引入对 Sidecar 的原生支持之前，Sidecar 容器必须这样实现。Sidecar 容器现在可以使用 spec.initContainers 字段在 Pod 清单中定义。使其成为 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. 加载 Secret
3. 验证依赖项的可用性
4. 运行数据库迁移

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

Ambassador 模式

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

在你需要时非常完美

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

配置助手

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

使用场景

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

Adapter 模式

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

优势

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

总结

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

• ←上一篇
• 下一篇→