-de8bd8f33c3e44a59907dafe1884f228.png)
Istio 总体来说分为两部分：控制面和数据面，如下所述。
- 数据面被称为”Sidecar”，可将其理解为旧式三轮摩托车的挂斗。Sidecar 通过注入的方式和业务容器共存于一个Pod中，会劫持业务应用容器的流量，并接受控制面组件的控制，同时会向控制面输出日志、跟踪及监控数据。
- 控制面是 lstio 的核心，管理 Istio 的所有功能。lstio 的主要组件及其相互关系大致如下图所示。
Pilot
Pilot 是 lstio 的主要控制点，Istio 的流量就是由 Pilot 管理的，具体执行是由 Sidecar 完成的。
在整个系统中，Pilot 完成以下任务：
- 从 Kubernetes 或者其他平台的注册中心获取服务信息，完成服务发现过程；
- 读取 Istio 的各项控制配置，在进行转换之后，将其发给数据面进行实施。
Pilot 的配置内容会被转换为数据面能够理解的格式，下发给数据面的 Sidecar，Sidecar 根据 Pilot 指令，将路由、服务、监听、集群等定义信息转换为本地配置，完成控制行为的落地。如下图所示为 Pilot 的工作示意图。
上图简要说明了 Pilot 的工作流程：
- 用户通过
kubectl或istioctl（当然也可以通过 API）在 Kubernetes 上创建 CRD 资源，对 Istio 控制平面发出指令； - Pilot 监昕 CRD 中的
config、rbac、networking及authentication资源，在检测到资源对象的变更之后，针对其中涉及的服务，发出指令给对应服务的 Sidecar； - Sidecar 根据这些指令更新自身配置，根据配置修正通信行为；
Mixer
Mixer 的职责主要有两个：预检和汇报。如下图所示是 Mixer 的一个简单工作示意图：
如图所示，Mixer 的简单工作流程如下。
- 用户将 Mixer 配置发送到 Kubernetes 中。
- Mixer 通过对 Kubernetes 资源的监听，获知配置的变化。
- 网格中的服务在每次调用之前，都向 Mixer 发出预检请求，查看调用是否允许执行。在每次调用之后，都发出报告信息，向 Mixer 汇报在调用过程中产生的监控跟踪数据。
如图所示，在 Mixer 中包含多个被称为 Adapter 的组件，这些组件用来处理在 Mixer 中接收的预检和报告数据，从而完成 Mixer 的各种功能。
Citadel
Citadel 在 Istio 的早期版本中被称为 lstio-CA，不难看出，它是用于证书管理的。在集群中启用了服务之间的加密之后，Citadel 负责为集群中的各个服务在统一 CA 的条件下生成证书，井下发给各个服务中的 Sidecar，服务之间的 TLS 就依赖这些证书完成校验过程。
Sidecar（Envoy）
Sidecar 就是 lstio 中的数据面，负责控制面对网格控制的实际执行。
lstio 中的默认 Sidecar 是由 Envoy 派生出来的，在理论上，只要支持 Envoy 的 xDS 协议，其他类似的反向代理软件就都可以代替 Envoy 来担当这一角色。在 Istio 的默认实现中，lstio 利用 istio-init 初始化容器中的 iptables 指令，对所在 Pod 的流量进行劫持，从而接管 Pod 中应用的通信过程，如此一来，就获得了通信的控制权，控制面的控制目的最终得以实现。
注入 Sidecar 前后的通信模式变化如下图所示。
熟悉 Kubernetes 的朋友应该都知道，在同一个 Pod 内的多个容器之间，网络栈是共享的，这正是 Sidecar 模式的实现基础。从上图中可以看到，Sidecar 在加入之后，原有的源容器→目的容器的直接通信方式，变成了源容器→Sidecar→Sidecar→目的容器的模式。而 Sidecar 是用来接受控制面组件的操作的，这样一来，就让通信过程中的控制和观察成为可能。
评论区