istio基础概念
lstio
envoy的控制平面实现之一，开源的服务网格
版本演进：
istio 1.0
单体，性能损耗大
架构
控制平面：
- pilot：控制平面核心组件
- citadel：认证相关
- mixer：遥测和策略
数据平面：
- sidecar envoy
istio 1.1
分布式，性能损耗更大
架构
- mixer：将插件模型改为进程外的adapter进行扩展，完成mixer与扩展间解耦，但性能更差
- galley：从pilot中拆分出来，将适配底层平台相关功能独立，用于配置验证、处理、分发等
istio 1.5
单体，性能损耗小
架构
- istiod：整合pilot、citadel、galley、sidecar injector为一个整体，抛弃mixer。智能化负载均衡机制，流量绕过kube-proxy
istio架构
控制平面
istiod，将配置分发到所有sidecar代理和网关，istiod内部又由4个组件构成
仅实现了envoy的部分功能
pilot
控制平面核心组件。管理和配置部署在istio服务网格中的所有envoy代理实例
为envoy sidecar提供服务发现、智能路由的流量管理功能（A/B测试、金丝雀）、弹性（超时、重试、断路器等）
由4个组件构成：
- platform adapter：适配底层平台，完成从平台特有的服务模型到istio服务模型的转换
- abstract model：聚合底层平台的服务和配置规则并对上层提供统一接口，解耦envoy api和底层平台
- envoy xds api：通过xds服务器提供服务发现接口，基于envoy定于的资源名进行配置分发
- rules api：高级流量管理规则的api接口，通过api将规则转为低级配置，在分发到envoy
配置分发机制
负责将网格中数据平面相关的配置信息获取、生成、分发，通过用户配置及服务注册表获取网格配置，并转为xds接口的标准数据格式，再经过grpc分发到envoy
- service registry：服务注册表中存储相关平台上注册的各服务信息，k8s中就是svc
- config storage：配置存储，如k8s的api-server，配置信息通常是由用户提供，对于k8s来说，以k8s crd格式提供并存储在api-server中
注：基于适配器机制，pilot还可以冲mesos、cloud foundry、consul等平台中获取服务信息，用户可开发适配器将其他服务发现的组件集成到pilot
citadel
身份和凭据管理等安全相关的功能，实现强大的服务到服务的最终用户身份验证
在k8s中，使用sds api，基于secret资源动态将证书注入到sidecar容器，非容器环境中，使用系统上运行的节点agent生产csr请求，再向citadel发起签发请求后，存在磁盘中
注：除istio的citadel外，还有vaule等证书管理系统可用
galley
pilot中适配底层平台的功能独立完成的组件
istio中配置验证、摄取、处理、分发组件，负责将其余的istio组件从底层平台（k8s）获取用户配置的细节隔离开，从而将pilot与底层平台进行解耦
sidecar injector
基于k8s的admission controller webhook（准入控制器）注入istio兼容的sidecar到pod中
注入的容器：
- istio-init：初始化容器，在微服务相关的pod中生成iptables规则，进行流量拦截，并转发给envoy
- istio-proxy：正常容器，与pod中业务程序一起运行
注入方法：
- 手动注入：用istioctl工具注入
- 自动注入：用istio sidecar injector自动注入（k8s中使用webhook实现diecar自动注入，注入发生在admission控制器的mutarion阶段，根据自动注入配置，kube-apiserver拦截pod创建请求时调用自动注入服务istio-sidecar-injector生成sidecar容器的配置清单插入到pod清单中）
注：自动注入只在有开启自动注入标签的ns中生效
数据平面
工作负载实例：注入sidecar envoy
网关：
- istio-ingressgateway
- istio-egressgateway
结合k8s应用
使用istio后，流量不会经过svc，svc只是用来帮助集群端点发现（使用svc做eds发现时，destation rules为空），所有流量都被sidecar envoy拦截（基于ipstbales规则）后做重定向处理
istio为网格中每个service端口创建位侦听器，匹配的endpoint组合为集群，这些侦听器和集群会配置给每个sidecar envoy。
1个sidecar envoy中，属于自己的service会定义为Inbound listener（ingress），集群中其他所有service生成为Outbount listener（egress）。这部分后面单独讲
crd资源
istio的所有路由规则和控制策略都基于k8s的CRD（Custom Resource Definition）实现，也就是说kube-apiserver是istio的api-server，galley从kube-apiserver加载配置进行分发
自定义VS、DR是对pilot所发现的路由和集群配置做增强
crd分类组：
- 网络：networking.istio.io，提供vs、dr、gw、se、we、wg等资源
- 安全：security.istio.io
- 遥测：telemetry.istio.io
- 扩展：extensions.istio.io
- operator：install.istio.io
envoy、istio与k8s资源对应关系：
istio自动将k8s中svc自动配置为每个sidecar envoy中，其中：
- Listener：由svc端口指定，80自动处理为8080，并生成虚拟主机，对应svc名称
- Route：自动为匹配所有svc对应的pod。对应istio中的vs资源
- Cluster：由svc名称生成，通过eds下发给所有sidecar，所有集群名称都是对应k8s中svc名称。对应istio中dr资源
- Endpoint：由svc基于标签选择器，发现各pod的ip生成
