什么是 Sidecar 模式

将应用程序的功能划分为单独的进程，即 Sidecar 模式。Sidecar 译为摩托车的边车，用到软件架构中，Sidecar 模式指在原来的业务逻辑上再新加一个抽象层。

Sidecar 模式是一种更具动态性的方法，其作为一种模式并不是 Kubernetes 的正式约定。它将应用程序的功能划分为单独的进程，运行在同一个 pod 中，Sidecar 模式允许在应用程序旁边添加功能，而无需修改应用程序代码。

Sidecar 示意图

Sidecar 的优势

在 Sidecar 部署方式中，每个应用的容器旁都会部署一个或者多个伴生容器，多个容器共享存储、网络等资源。具体优势有：

• 将不同的功能抽象到不同的层来降低微服务的代码复杂性。

• 每个 Sidecar 可以独立升级更新。

• 分离业务无关功能（例如：配置文件获取），提升代码重用度。

• 不再需要编写相同的第三方组件配置文件和代码，能够降低代码重复度。

Sidecar 如何工作

本文使用 serivce mesh 做为示例。来自服务的所有传入和传出网络流量均通过 Sidecar 代理，完成服务之间的流量管理、限流、熔断等策略的执行。它将网络依赖抽象成 Sidecar，而服务对于网络是无感知的，只知道所附加的 Sidecar 代理。

Sidecar 如何注入

• 手动注入，通过手工修改工作负载的方式，添加 Sidecar 的配置。

  kind: Deployment  apiVersion: apps/v1  metadata:    name: keeper  spec:    template:      spec:        volumes:          - name: config            emptyDir: {}        initContainers:          - name: install            image: 'dockerhub.qingcloud.com/lowcode/infantry:v20211228edfdfd'            resources: {}            volumeMounts:              - name: config                mountPath: /configs        containers:          - name: container            image: 'dockerhub.qingcloud.com/lowcode/keeper:alpha'            volumeMounts:              - name: config                readOnly: true                mountPath: /configs          - name: watchdog            image: 'dockerhub.qingcloud.com/lowcode/infantry:v202202081416'            command:              - /root/infantry            volumeMounts:              - name: config                mountPath: /configs

• 基于 Kubernetes 的 突变 webhook 入驻控制器mutating webhook addmission controller 的自动 Sidecar 注入。

  kind: Deployment  apiVersion: apps/v1  metadata:    name: keeper    namespace: lowcode    annotations:      servicemesh.kubesphere.io/enabled: 'true'  spec:    template:      metadata:        annotations:          sidecar.istio.io/inject: 'true'      spec:        containers:          - name: container            image: 'dockerhub.qingcloud.com/lowcode/keeper:alpha'        restartPolicy: Always

经典使用案例

• istio：使用领先的服务网格简化可观察性、流量管理、安全性和策略。

• dapr：用于构建可移植且可靠的微服务的 API。

基本术语

容器（Container）

每个运行的容器都是可重复的，包含依赖环境在内的标准，意味着无论你在哪里运行它，都会得到相同的行为。容器将应用程序从底层的主机设施中解耦，这使得更加容易在不同的云或 OS 环境中部署。

Pod

Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）等。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。

工作负载（Workload）

工作负载是在 Kubernetes 上运行的应用程序。无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你可以在一组 Pods 中运行它。 在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器。

引用

Kubernetes：https://kubernetes.io/

突变 webhook 入驻控制器 mutating webhook addmission controller：

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

istio：https://istio.io

dapr：https://dapr.io

公众号：全象云低代码

官网：全象——开源低代码平台，加速企业数智化转型。 (quanxiang.dev)

GitHub：https://github.com/quanxiang-cloud/quanxiang