在 Kubernetes 中使用（或不使用）Sidecar 的原因
Sidecar 容器为需要在大规模容器应用集群中进行管理的开发人员提供了极大的便利。但这是否总是正确的方法呢？
Kubernetes 引入 Sidecar 容器来解决一个根本性的挑战：当您通过 Kubernetes 部署应用程序时，往往很难直接将应用程序与各种外部监控工具、日志系统和其他组件集成在一起，这些工具通常对于使用传统服务器的开发人员来说是随时可用的。
Sidecar 容器方法通过在自己的 Kubernetes Pod 实例中运行应用程序的核心进程，同时运行在其旁边的伴随 Pod，来解决这个问题，从而方便访问外部资源和与外部系统通信。换句话说，在 Kubernetes 中使用 Sidecar 可以让您同时实现两个目标。
然而，使这种方法行之有效的关键在于理解何时以及如何使用 Sidecar 容器。让我们检查一些 Sidecar 容器方法的主要优点和缺点，并回顾一些指南，以帮助您决定是否应采用这种方法。
Sidecar 容器的优点
在 Kubernetes 中，Sidecar 容器方法主要是一种用于突破干扰抽象的方法。在这种情况下，它们提供了几个重要优点：
- 隔离。主要应用程序可以在一个容器中独立运行，而 Sidecar 则可以运行补充进程和工具。这也使得应用程序的主代码库对与之连接的外部服务隐藏起来，可以帮助隔离故障。
- 快速部署。部署 Sidecar 容器相对较容易，比尝试添加额外层次到主应用程序容器中来集成 Sidecar 中托管的任何功能要容易得多。
- 可扩展性。一旦您将 Sidecar 容器放置在适当的位置，就可以轻松扩展以支持所需的 Pod 数量。如果您想要，您可以部署一百个 Sidecar 容器，就像部署一个容器一样容易。
Sidecar 容器的缺点
当然，使用 Kubernetes 中的 Sidecar 并非免费的。以下是一些与 Sidecar 容器相关的明显缺点：
- 资源消耗。更多的容器意味着更多的内存消耗和 CPU 利用率。从资源的角度来看，有时在单个容器中托管所有进程或在节点级别运行补充任务更有效。
- 管理复杂性。Sidecar 增加了您需要监视和管理的容器总数，更不用说它们之间的关系。您需要一个全面的监控系统，能够跟踪例如 Sidecar 容器故障如何影响您的主应用程序。
- 更新兼容性。确保更新主应用程序容器与支持它的 Sidecar 兼容可能需要更多的工作，以及这些更新是否可以跨所有相关组件无问题传递。
Sidecar 容器方法的替代方案
Sidecar 容器不是在 Kubernetes 抽象层中建立通道的唯一方法。当然，最明显的选择是直接将您需要的任何额外功能添加到应用程序容器本身中，前提是这不会损害性能。类似地，您可以配置您的全局软件网络，使应用程序可以通过网络本身与外部软件和工具交互。
在许多情况下，还可以向每个 Kubernetes 节点添加类似 DaemonSets 的管理组件，以执行无法在单个容器内部处理的任务。
决定是否值得使用 Sidecar
一般来说，管理 Kubernetes 集群的大型和复杂的团队最终会依赖于 Sidecar 容器。因此，在 Kubernetes Pod 与世界其他部分之间形成的抽象中，Sidecar 已成为一个应对方案。然而，他们并非没有缺点，因此开发团队在随意部署 Sidecar 之前需要仔细考虑。
为了确定 Sidecar 是否是正确的方法，问自己以下几个问题：
- 您的性能需求是什么？ Sidecar 不是运行补充工具的最有效方法，并且如果您只需要为相对简单的任务优化性能，则可能会成为问题。
- 您的规模是多少？ 由于它们易于大规模部署，因此 Sidecar 容器在大型集群中提供最大的利益。在较小的集群中，您可能可以不使用 Sidecar。
- 功能修改有多困难？ 如果您能够轻松将所需的功能添加到应用程序的主代码库或容器中，而不会引起太多问题，则 Sidecar 容器可能是一种过度方法。
- 您能够管理多少集群复杂性？ 尽管它可能简化主应用程序容器，但 Sidecar 通过增加您需要部署和监视的容器数量来增加您的 Pod 集群的复杂性。考虑将复杂性添加到单个实例而不是整个集群的权衡。