将 Sidecar 容器带入新的阶段

导读：本文根据徐迪和张晓宇在 KubeCon NA 2019 大会分享整理。分享将会从以下几个方面进行切入：首先会简单介绍一下什么是 Sidecar 容器；其次，会分享几个阿里巴巴经济体的通用场景，以及他们是如何解决这些挑战的。

Sidecar 简介

Sidecar 容器并不是一个新鲜事物。它是一种设计模式，主要用来做一些辅助的工作，比如网络连通性、下载拷贝文件之类的事情；如果大家熟悉 Docker Swarm 的话，就会发现 Docker Ambassador 其实就是 Sidecar。

如上所示，Service Consumer 和 Redis Provider 强耦合，部署在同一个节点上。如果这个时候，Redis Provider 出现问题，需要连接到另外一个 Redis 实例上，需要重新配置，并重启 Service Provider。

那么在引入了 Ambassador 以后，问题变得相对简单些，只需要重启这里的 Redis Ambassador 即可，并不需要 Service Consumer 进行任何变动。

当然这种模式，还可以进行跨节点通信，比如下图。这样 Service Consumer 和 Redis Provider 就可以部署在不同的节点上。在某种程度上，很容易地就将两种服务进行了解耦。

Sidecar 案例分享

1. Sidecar 容器能用来干什么？

一般来讲，Sidecar 容器可以：

• 日志代理/转发，例如 fluentd；
• Service Mesh，比如 Istio，Linkerd；
• 代理，比如 Docker Ambassador；
• 探活：检查某些组件是不是正常工作；
• 其他辅助性的工作，比如拷贝文件，下载文件等；

2. 仅此而已？

事实上，Sidecar 越来越被大家接受，并且使用越来越广泛。Sidecar 容器通常和业务容器（非 Sidecar 容器）部署在同一个 Pod 里，共享相同的生命周期，为业务容器提供辅助功能。这是一个非常好的模式，能够极大程度解耦应用，并且支持异构组件，降低技术壁垒。

但目前 Kubernetes 对 Sidecar 的管理还不完善，越来越不满足我们的使用，尤其是在生产环境中使用 Sidecar。

3. 几个典型案例

顺序依赖

假设我们在一个 Pod 内注入了多个 Sidecar，但是 Sidecar 之间或者 Sidecar 和业务容器之间有相互依赖关系。如下这个例子，我们需要先启动 proxy Sidecar 容器用于建立网络连接，这样 mysql client 才能连接到远端的 mysql 集群，并在本地暴露服务。而后主的业务容器才能正常工作。

当然，有的人会觉得这个地方，可以通过诸如更改镜像启动脚本延迟启动等方法来解决。但是这些方法侵入性太强，不利于扩展，还很难进行准确的配置。

Sidecar 管理

我们来看看另外一个案例。Sidecar 容器和业务容器耦合在同一个 Pod 内，共享相同的生命周期。因此，单独来管控 Sidecar 容器非常不方，比如更新 Sidecar 的镜像。

比如，我们已经给很多 Pod 注入了 Istio Proxy 这样的 Sidecar 容器，目前运行状态良好。但是如果这个时候我们想升级这个 Proxy 镜像的话，该怎么办？

如果按照 Istio 社区官方的文档，我们需要重新注入这些 Sidecar 容器。具体来说，需要删除原有 Pod，重新生成一份新的 Pod（有些 workload 关联的 Pod，会由相应的 workload 控制器自动生成）。

那如果我们有很多个这样的 Pod 需要处理的话，怎么办？通过命令行的话，太不方便，而且容易出错。通过自己单独写的代码的话，可扩展性是个问题，需要频繁更改这些代码。

而且这里还有另外一个问题，我们肯定不会一下子升级所有的 Sidecar，肯定要有个灰度的过程，也就是只升级一部分 Sidecar，这个时候又该怎么办呢？

社区进展

1. 上游社区

这里我们非常感谢 Joseph Irving (@Joseph-Irving) 提出了一个 Sidecar kep，通过定义 LifecycleType 来区分是否是 Sidecar 容器。

未来只需要在 Pod Spec 中，按如下方式标记即可：

Pod 内容器的启动顺序按照：初始化容器->Sidecar 容器->业务容器 的顺序依次启动。

其中上述 kep 的 kubelet 端实现 正在进行中。

为了支持 Sidecar 更多的使用场景，我们以此为基础提出了 PreSidecar 和 PostSidecar，分别用于在业务容器之前和之后启动。

具体的使用场景见 我们的 PR。

为什么我们觉得 Sidecar 应该区分前置和后置呢？

这是因为在一些场景下，我们需要 Sidecar 容器优先于应用容器启动，帮助做一些准备工作。例如分发证书，创建共享卷，或者拷贝下载一些其他文件等。

而在另外一些场景下，我们需要一些 Sidecar 容器在应用容器之后启动。考虑到解耦和版本管理的因素，我们将应用分为两部分，应用容器专注于业务本身，而一些数据和个性化的配置放在 Sidecar 容器中。通常情况下，这两个容器将会共享一个存储卷，后置的 Sidecar 容器会更新替换掉一些默认和过时数据。

当然考虑到未来更复杂的场景，我们可能还会对容器的启动顺序做 DAG 编排，当然这个需要视生产实际需要而定。

2. 蚂蚁金服及阿里巴巴如何应对

为了解决 Sidecar 的管理工作，我们需要一个更细粒度的 workload 方便我们进行管理。这个 workload 我们命名为 SidecarSet，目前已经开源，生产可用。大家可以访问 OpenKruise 这个项目，可以在项目的 roadmap 里了解我们目前的一些新进展。OpenKruise 这个项目目前有三个生产可用的 workload，分别是 Advanced StatefulSet、BroadcastJob、SidecarSet。另外2个 workload（AdvancedHPA 和 PodHealer）正在加紧开发中， 很快会开源出来，敬请期待。相关使用 Demo，大家可以观看 Lachlan Evenson 的尝鲜视频。

spec 中的 SidecarContainer 的定义就是 Kubernetes 代码库中的 corev1.Container 定义。通过额外的一个 labelSelector，可以很方便地对指定的容器组进行操作。我们支持滚动升级（RollingUpdate）的方式，让用户可以分批的升级 Sidecar，同时也提供了 pause 功能，可以在紧急情况下暂停 Sidecar 的升级。

如果只是简单升级 Sidecar 的镜像， SidecarSet 控制器仅仅会 patch 原有 pod 的，非常方便的就可以一键升级镜像。

其他的挑战

我们在生产实践过程中，还发现了一些其他的挑战，目前还在寻找比较好的解法。

1. Sidecar 容器的资源管理

一般来讲 Sidecar 容器占用的资源都比较小，那么这个资源要不要计算到整个 pod 当中？还是可以直接共享业务容器的资源即可？相同的 Sidecar 在和不同的应用容器搭配使用，如何准确给 Sidecar 容器分配资源这些都需要进行考虑。

2. Sidecar 容器的容错性

一般来讲，Sidecar 容器都是非主要容器，那么这类容器出现问题时，比如 liveness 探活，要不要对主容器的状态或者整个 pod 的状态也产生影响。再或者，Sidecar 镜像更新出现问题时，要不要直接标记整个 pod 出现问题。当然，还有一些其他的挑战，我们只是列举了几个通用的。对于这些挑战，我们需要大家一起集思广益，找到比较合理的解法。

小结

随着 Sidecar 在生产环境使用越来越广泛，对其的管理愈发需要重视。Sidecar 虽然和业务容器部署在同一个 Pod 内，但是其本质上只是辅助性的容器。本文介绍了目前 Sidecar 的典型使用案例，以及面临的挑战，同时跟上游社区一起合作，将阿里经济体的技术解决方案在社区落地，帮助更多的用户.

作者简介：

蚂蚁金服技术专家：负责蚂蚁金融云 PaaS 平台建设，Kubernetes 社区老兵，核心代码库贡献量社区前50；
张晓宇 阿里云技术专家：负责阿里巴巴云原生应用容器平台的生态建设，主要设计和研发节点稳定性和资源利用率相关解决方案，同时也是 Kubernetes 社区热心的成员和贡献者。

 

本文作者：徐迪、张晓宇

原文链接

本文为阿里云内容，未经允许不得转载。