这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
随着云原生架构的不断演进，Kubernetes 已成为部署复杂分布式系统的首选平台。 在这个生态系统中，最强大却又微妙的设计模式之一是边车（Sidecar） 模式 —— 一种允许开发者扩展应用功能而不深入源代码的技术。
想象一下边车就像一个可靠的伴侣摩托车附件。历史上，IT 基础设施总是使用辅助服务来处理关键任务。 在容器出现之前，我们依赖后台进程和辅助守护程序来管理日志记录、监控和网络。 微服务革命改变了这种方法，使边车成为一种结构化且有意图的架构选择。 随着微服务的兴起，边车模式变得更加明确，允许开发者从主服务中卸载特定职责而不改变其代码。 诸如 Istio 和 Linkerd 之类的服务网格普及了边车代理， 展示了这些伴侣容器如何优雅地处理分布式系统中的可观察性、安全性和流量管理。
在 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 原生的边车容器，并确保它们始终保持运行。
虽然边车模式在许多情况下非常有用，但除非使用场景证明其合理性， 否则通常不推荐优先采用这种方法。添加边车会增加复杂性、 资源消耗以及可能的网络延迟。因此，应首先考虑更简单的替代方案， 例如内置库或共享基础设施。
在以下情况部署边车：
谨慎行事，如果：
Init 容器模式用于在主应用容器启动之前执行（通常是关键的）设置任务。 与常规容器不同，Init 容器会运行至完成然后终止，确保满足主应用的前提条件。
适合于：
Init 容器确保你的应用在一个可预测、受控的环境中启动，而无需修改代码。
一个大使（Ambassador）容器提供了 Pod 本地的辅助服务，这些服务暴露了一种访问网络服务的简单方式。 通常，Ambassador 容器代表应用容器发送网络请求，并处理诸如服务发现、对等身份验证或传输中加密等挑战。
能够完美地处理以下需求：
一个配置助手边车容器动态地向应用提供配置更新， 确保它始终可以访问最新的设置而不会中断服务。 通常，助手需要在应用能够成功启动之前提供初始配置。
使用场景：
一个适配器（adapter）（有时也称为切面（façade））容器使主应用容器与外部服务之间能够互操作。 它通过转换数据格式、协议或 API 来实现这一点。
优点：
尽管边车模式提供了巨大的灵活性，但它不是万能的。所添加的每个边车容器都会引入复杂性、 消耗资源，并可能增加操作负担。始终首先评估更简单的替代方案。 关键在于战略性实施：将边车用作解决特定架构挑战的精准工具，而不是默认选择。 正确使用时，它们可以提升容器化环境中的安全性、网络和配置管理。 明智地选择，谨慎地实施，让你的边车提升你的容器生态系统。