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