The Introduction of Istio
介绍
Istio是一个与Kubernetes紧密结合的适用于云原生场景的Service Mesh形态的用于服务治理的开放平台。根据官方介绍，Istio的服务治理涉及连接（Connect）、安全（Secure）、策略执行（Control）和可观察性（Observe），如图所示。
- 连接：Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能
- 安全：Istio 提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性
- 策略执行：Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力
- 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状况，发现并解决问题
架构
Istio服务网格的架构，从逻辑上分为数据平面和控制平面。
- 数据平面：由一组智能代理（Envoy）组成。这些代理负责协调和控制微服务之间的所有网络通信。它们还收集和报告所有网络流量的遥测数据
- 控制平面：包括Pilot、Galley、Citadel等服务组件，用于管理并配置代理来精细化的流量控制
具体而言，Istio中每个核心组件如下：
- Envoy是唯一与数据平面流量交互的Istio组件，用于协调服务网格中所有服务的入站和出站流量
- Pilot将流量控制行为的高级路由规则转换为特定的环境配置，并在运行时将它们传播到Sidercar。并且，Pilot将特定于平台的服务发现机制抽象出来，并将它们合成为任何符合Envoy API的Sidercar都可以使用的标准格式
- Citadel通过内置的身份和证书管理，可以支持强大的服务到服务以及最终用户的身份验证
- Galley是Istio的配置验证、提取、处理和分发组件。它负责将其余的Istio组件与从底层平台（例如Kubernetes）获取用户配置的细节隔离开来
Istio的架构决定其部署形态：
Istio的流量管理、遥测、治理等功能，均需要通过下发配置规则到应用所在的运行环境并执行才能生效。而负责执行这些配置规则的组件在服务网格中被称为服务代理，这些承载这些服务代理的实体称为Sidercar。应用程序发送或接收的流量都被sidecar拦截，并由sidecar进行认证、授权、策略执行及遥测数据上报等众多治理功能。
从单个应用来看，sidecar与应用程序的解耦带来的应用完全无侵入、开发语言无关等特点解除了开发语言的约束，从而极大降低了应用开发者的开发成本。
Istio提供更细粒度的控制：
Istio的服务发现先从Kube-apiserver中获取Service和Endpoint，在将其转换成Istio服务模型的Service和ServiceInstance，但其数据面组件不再是Kube-proxy，而是部署在每个Pod里的Sidercar，即每个服务实例的Proxy。通过这种方式，Proxy和服务实例的关系更加紧密，从而提供更精细化的流量控制。
功能
| 功能 | 子功能 | Istio 1.9 |
|---|---|---|
| Sidercar自动注入 | ✓ |
|
| 服务发现 | ✓ |
|
| 流量拦截 | HTTP流量 | ✓ |
| TLS流量 | ✓ |
|
| TCP流量 | ✓ |
|
| UDP流量 | ✓ |
|
| SCTP流量 | - |
|
| gRPC流量 | ✓ |
|
| Websocket | ✓ |
|
| Websocket Secure | - |
|
| 流量治理 | 负载均衡 | ✓ |
| 会话保持 | ✓ |
|
| 动态路由规则 | ✓ |
|
| 熔断限流 | ✓ |
|
| 故障注入 | ✓ |
|
| 灰度发布 | ✓ |
|
| 访问安全 | 双向认证 | ✓ |
| 通道加密 | ✓ |
|
| 授权管理 | ✓ |
|
| 可观测性 | 监控指标 | ✓ |
| 调用链追踪 | ✓ |
|
| 访问日志 | ✓ |
|
| 外部访问 | ✓ |
注：
✓Istio版本所支持的功能+Istio版本不具备的功能，但在后续版本中会支持-Istio版本不具备的功能，或已弃用的功能
参考
《云原生服务网格Istio：原理、实践、架构与源码解析》