Istio基础概念
各类服务网格的实现在特性上重叠性颇高，他们几乎都具有下列功能
流量治理
对哪些流量进行治理
动态路由：条件式路由，基于权重的流量分发，流量镜像
韧性：超时 重试 断路器
策略：访问控制
测试：故障注入
安全
加密：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 |
