各类服务网格的实现在特性上重叠性颇高，他们几乎都具有下列功能
流量治理
对哪些流量进行治理
动态路由：条件式路由，基于权重的流量分发，流量镜像
韧性：超时 重试 断路器
策略：访问控制
测试：故障注入
安全
加密：mTLS，证书管理，CA
严格的身份标识机制
认证和授权
可观测性
指标监控
分布式链路跟踪
流量监控
网格
运行在kubernetes上
多集群
Istio是什么
Istio是Envoy Data Plance的控制平面实现之一
Istio是一个开源的独立服务网格，可以用户成功运行分布式微服务架构提供所需的基础设施
控制平面主要有三个组件
Pilot：控制平台核心组件
管理和配置部署在Istio服务网格中所有的Envoy代理实例
为Envoy Sidecar提供服务发现、只能撸友的流量管理功能(例如，A/B测试、金丝雀推出等)和弹性(超时、重试、断路器等)
Citadel
身份和凭据管理等安全相关的功能，实现强大的服务到服务和最终用户身份验证
Mixer：遥测和策略
通过内部插件借口扩展支持第三方组件
插件的修改或更新，需要重新部署Mixer
Galley
Pilot中适配底层平台的功能独立成的组件
是Istio的配置验证、摄取、处理和分发组件
负责将其余的Istio组件与从底层平台(例如kubernetes)获取用户配置的细节隔离开来，从而将Pilot与底层平台进行解耦
Istiod：1.5新增，将Polot、Gitadel、Galley和Sidecar Injector整合为一个单体应用istiod
Istiod充当控制平面，将配置分发到所有Sidecar代理和网管
他能够为支持网格的应用实现智能化的负载均衡机制，且相关流量绕过了kube-proxy
数据平面Envoy
基于sidecar模式同网格中的每个服务实例一同部署
拦截服务流量，强制执行控制平面中定义的策略，并收集要测数据。
Pilot功能简介
Pilot管理和配置部署在Istio服务网格中的所有Envoy代理实例，是Istio控制平面的核心组件
他主要由Platform Adapter、Abstract Model、Envoy API(xDS)和Rules API四个组件构成；
平台适配器：负责适配底层平台，并完成从平台特有的服务模型到Istio服务模型的转换；
抽象聚合层：聚合底层不同平台的服务和配置规则并对上提供统一的接口，从而解耦Envoy API和底层平台；
Envoy API：Pilot通过xDS服务器提供服务发现接口xDS API，而xDS服务器接口并维护Envoy代理的链接，并给予Envoy订阅的资源名称进行配置分发；
Rules API：高级流量管理规则的API接口，用户通过该API配置流量管理规则并由其转换为低级配置，而后通过discovery API分发到Envoy实例；
Pilot功能：
服务发现
配置Sidecar
流量治理
A/B testing：Ab测试
failover：故障转移
Fault Injection：故障注入
Canary rollout：金丝雀发布
Circuit Breaker：断路器
Retries：重试
Timeouts：超时
Citadel功能简介
Citadel是Istio控制平面的核心安全组件，负责服务的私钥和梳子证书管理，用于提供自动生成、分发、轮换及撤销私钥和数据证书的功能；
kubernetes平台上，Citadel的传统工作方式是基于Secret资源将证书私钥注入到Sidecar容器中；
非容器环境中，首先通过系统上运行的Node Agent生成CSR，而后向Citadel发起证书签署请求，并将接收到的证书和私钥存储于本地文件系统提供给Envoy使用；
Istio1.1版本起支持基于SDS API动态配置Secret给Envoy；
另外出了Istio的Citadel之外，还有Vault等其他证书和私钥管理系统可用；
Istio的安全模型需要多个组件协同工作
Citadel管理私钥和数字证书
Sidecar和perimeter proxies执行服务间的安全通信
Pilot向代理分发认证策略和名称信息
Galley功能简介
Galley负责向Istio控制平面的其它组件提供支撑功能，它核验进入网格的配置信息的格式和内 容的正确性，并将这些配置信息提供给Pilot和Mixer;
Galley从底层平台接收配置信息并完成分发，从而将其它组件同底层平台解耦
MCP(Mesh Configuration Protocol)是Istio网格中用于分发配置的传输协议
基于gRPC
与xDS协议类似，一次完整的MCP请求/响应流程包括请求、响应和ACK/NACK;
MeshConfigRequest
MeshConfigResponse
以MeshConfigRequest形式发送的ACK或NACK
目前尚不支持增量配置分发机制;
从实现上来说，Galley通过Kubernetes的动态Admission Controller(Admission Hook)完成组件 配置的校验;
在Mutation阶段，实现对请求内容的修改，利用为服务注入Sidecar;
在Validation阶段实现对请求内容进行校验，Galley对配置的校验即发生在此阶段;
Istio Gateway用于将Istio功能(例如，监控和路由规则)应用于进入服务网格的流量
通过将Envoy代理部署在服务之前，运维人员可以针对面向用户的服务进行A/B测试、金丝雀部署等
Istio Gateway不同于Kubernetes Ingress
类似地，有必要时，也可以部署专用的Egress Gateway，运维人员可以为这些服务添加超时控制、重 试、断路器等功能，同时还能从服务连接中获取各种细节指标
程序文件istio-ingressgateway和istio-egressgateway
Istio Sidecar Injector
Istio服务网格中的每个Pod都必须伴随一个Istio兼容的Sidecar一同运行，常用的将Sidecar注入 Pod中的方法有两种
手工注入:使用istioctl客户端工具进行注入
自动注入:使用Istio sidecar injector自动完成注入过程
利用Kubernets webhook实现sidecar的自动注入
创建Pod时自动注入过程发生在Admission Controller的Mutation阶段，根据自动注入配置，kube-apiserver拦截到Pod创建请 求时调用自动注入服务istio-sidecar-injector生 成Sidecar容器的描述并将其插入到Pod的配置清单中
总结
Istio服务网格：
控制平面：
istiod：Pilot，galley，citedal，istio sidecar injector
Control Plane API
数据平面：
工作负载实例：注入Sidecar Envoy
网关：Istio-IngressGateway，Istio-EngressGateway
Data Plane API
附件：
可观测性：
Grafana，prometheus
Jaeger/Zipkin
WebUI：Kiali
Istio相对于kubernetes是什么？
特点：
声明式API，各种资源类型
控制器，Controller Manager
就是Kubernetes的系统扩展：增强了Kubernetes平台的功能
CRD：扩充了Kubernetes的资源类型，这些资源类型用于承载Istio的目标功能
Operator：Istiod，其实就是CRD定义资源类型的控制器
生效边界：仅是那些具有数据平面Sidecar的服务
Sidecar的自动注入功能：以namespace为边界
在namespace上添加特定的label
注意：
Istio目标并非用于管理任何可运行于Kubernetes的应用
核心功能：治理微服务
基于Kubernetes CRD描述规则
Istio的所有路由规则和控制策略都基于Kubernetes CRD实现，于是，其各种配置策略的定义也 都保存于kube-apiserver后端的存储etcd中;
这意味着kube-apiserver也就是Istio的APIServer
Galley负责从kube-apiserver加载配置并进行分发
Istio提供了许多的CRD，它们隶属于以下几个功能群组
Network(networking.istio.io):流量治理，主要包括VirtualService、DestinationRule、Gateway、ServiceEntry、Sidecar、EnvoyFilter、WorkloadEntry 和WorkloadGroup等8个CR;
Security(security.istio.io):网格安全，主要包括AuthorizationPolicy、 PeerAuthentication和 RequestAuthentication等3个CR;
Telemetry(telemetry.istio.io):网格遥测，目前仅包括Telemetry这一个CR;
Extensions(extensions.istio.io):扩展机制，目前仅包括WasmPlugin这一个CR;
IstioOperator(install.istio.io):IstioOperator，目前包括的一个CR也是IstioOperator;
Istio的功能及其相关实现组件
Istio提供了如下开箱即用(Out Of The Box)的功能
Service Discovery / Load Balancing（服务发现、负载均衡） →ServicEntry + DestinationRule
Secure service-to-service communication (mTLS) （通信加密） →DestinationRule
Traffic control / shaping / shifting （流量控制、流量整形、流量迁移） →VirtualService
Policy / Intention based access control （策略、内部访问控制） →AuthorizationPolicy
Traffic metric collection （指标收集） →(built in)
以下功能不能做到OOTB（开箱即用），在一定程度上，依赖用户自行定义
Cross-cluster Networking → EnvoyFilter + ServiceEntry + Gateway
External Auth / Rate Limiting →EnvoyFilter
Traffic Failover →EnvoyFilter
WAMS Filters →EnvoyFilter
Access Logging / many unexposed Envoy features →EnvoyFilter + ?
Istio流量治理的关键配置
Virtual Services和Destination Rules是Istio流量路由功能的核心组件
Virtual Services用于将分类流量并将其路由到指定的目的地(Destination)，而Destination Rules则用于配置那个指定Destination如何处理流量
Virtual Services
用于在Istio及其底层平台(例如Kubernetes)的基础上配置如何将请求路由到网格中的各Service之上
通常由一组路由规则(routing rules )组成，这些路由规则按顺序进行评估，从而使Istio能够将那些对Virtual Service的 每个给定请求匹配到网格内特定的目标之上
事实上，其定义的是分发给网格内各Envoy的VirtualHost和Route的相关配置
Destination Rules
定义流量在“目标”内部的各端点之间的分发机制，例如将各端点进行分组，分组内端点间的流量均衡机制，异常 探测等
事实上，其定义的是分发给网格内各Envoy的Cluster的相关配置
VirtualService定义虚拟机及相关的路由规则，包括路由至哪个目标(集群或子集)
DestinationRule定义集群或子集内部的流量分发机制
流量治理的相关资源：
Gateway：生效在istio-ingressgateway上，用于配制接入哪一类型的外部流量，生成一个Listener，若Listener已经存在，则在该Listener之上生成一个VirtualHost，但该VirtualHost接收到的流量，发往何处(流量目标)并不会自动生成；
VirtualService：配置流量的具体路由路径
存在两种生效逻辑：
生效在istio-ingressgateway上：作为Ingress Listener存在
生效在mesh上(配置在网格内的所有Sidecar Envoy上)：作为Egress Listener存在
DestinationRule：配置集群内部的流量分发逻辑
负载均衡算法
连接池
网格内部通信：
将任何一个Service自动配置为每个Sidecar Envoy上的：
Listener：由Service Port指定；80会被自动处理为8080
额外生成一个VirtualHost的定义，主机头的名称为该Service的名称；
Route：由一个Service的Listener进入的所有流量（match /*）全部路由给该Service的各Pod生成的Cluster
Cluster：由Service基于各名称生成，并通过EDS下发给每个Sidecar，所有集群名称同Service的名称；
Endpoint：由Service基于Label Selector发现的各Pod的IP生成
流程：
Client --> Envoy Sidecar 自己的 （outbound：egress listener --> route --> cluster（目标集群） --> endpoint（目标端点））--> Server Pod Envoy Sidecar （inbound：ingress listener --> route --> local cluster --> localhost(业务容器)（由所属的服务生成））
网格外部的流量：
流量必须经由某个IngressGateway进入
因而，接入流量的前提是在某个IngressGateway上自行开启一个Listener，开启Listener的方法，就是该IngressGateway定义一个Gateway CRD资源；
在该Listener基于目标Host匹配流量
匹配到的流量，需要经由VirtualService定义其路由目标(网格内的某个服务)
流程：
External Client --> IngressGateway Service --> Ingress Gateway Pod(Listener（由Gateway定义） --> Route（由VirtualService定义）--> Cluster（可由控制平面通过发现的Service自动配置）--> endpoint)
小结：
gateway：若Listener已经存在，于IngressGateway上基于指定的端口启用一个Listener，并在该Listener上配置一个Virtual Host；
VirtualService：在Listener上，为某Host（通常会由VirtualHost的定义所匹配）定制高级路由
如何匹配Listener？
由关联的Gateway CRD资源所定义
由关联的Service (通过hosts指定)的端口生成的Listener
默认的路由配置：/* --> 由同一Service生成的Cluster
DestinationRule：在Cluster上，为Cluster定义高级配置
默认的配置：把Service Name定义成集群，该Service匹配到的Pod，定义为集群端点
高级配置：lbPolicy，Connection Pool
Istio：
基于某个Service Registry(API Server)发现Service
所有Service都会被纳入网格治理体系：配置在Sidecar和Gateway
非网格治理下的Service，只要能够被Istio发现，而且只要客户端在网格内部，就同样支持经VS和DR定义高级配置；原因在于：客户端自身的Sidecar上listener发挥了作用；但是，网格外部的服务没有Sidecar，某些功能就无法支持，例如双向tls
支持经由Gateway，将特定的Service暴露至网格外部；
Sidecar Envoy使用的端口
Port | Protocol | Description | Pod-internal only |
15000 | TCP | Envoy admin port | YES |
15001 | TCP | 出向流量端口 | NO |
15004 | HTTP | Debug port | YES |
15006 | TCP | 入向流量端口 | NO |
15008 | H2 | mTLS 隧道端口 被放行的端口 | NO |
15009 | H2C | HBONE port for secure networks | NO |
15020 | HTTP | Prometheus采集聚合指标 | NO |
15021 | HTTP | 健康状态检测的端口，检测sidecar是否健康 | NO |
15053 | DNS | DNS端口 | YES |
15090 | HTTP | 暴露Prometheus指标的端口，采集Envoy指标 | NO |
控制平面使用的端口
Port | Protocol | Description | Local host only |
443 | HTTPS | Webhook service | NO |
8080 | HTTP | Debug interface | NO |
15010 | GPRC | 下发配置和CA的 明文的 | NO |
15012 | GPRC | 下发配置和CA的 加密的 | NO |
15014 | HTTP | 指标监控 | NO |
15017 | HTTPS | 接收从443转发进来的与webhook功能相关的接口 | NO |
