一、原理
1. Istio概述
相关概念：
微服务：以一组小型服务来开发单个应用程序的方法，服务间采用轻量级通信机制。
好处：功能内聚、变更独立、便于敏捷升级
问题：网络可靠性、通信安全、网络时延、拓扑变化；需考虑服务发现、负载均衡、链路追踪、熔断容错、动态路由。
服务治理：应用程序中包含治理逻辑、治理逻辑独立的代码（SDK模式）、治理逻辑独立的进程。
Istio与K8S: Istio最大化利用K8S的基础设施，提供服务运行和治理能力，并提供更透明的用户体验。
工作机制：数据面+控制面
自动注入->流量拦截->服务发现->负载均衡->流量治理->访问安全->服务遥测->策略执行->外部访问
服务模型：
Istio服务：主要管理的资源对象，是一个抽象概念，满足名称约束
服务版本：Deployment上的version。 服务实例： Endpoint
主要组件：
Pilot：控制中心，至少包含服务注册中心、配置服务。并提供规则下发。 Envoy订阅Pilot配置资源。
Telemetry： 收集遥收集，采集metric数据然后分发给后端的遥测服务。Mixer服务之一，用于解耦数据面和不同后端对接。
Policy: 另一个Mixer服务，机制流程同Telemetry。数据面访问前先调用它的check，确认是否可访问，配置包括配额、授权、黑白名单。
Citadel：核心安全组件，提供自动生成、分发、轮换与撤销密钥和证书功能。监听Kube-apiserver。
Galley：负责配置管理、验证是否正确，降配置提供给Pilot和Mixer，其它管理面组件解耦。
Sidecar-injector：自动注入组件，Pod创建时向Pod中注入Sidecar容器。
Proxy： Envoy + Agent。Envoy提供了动态服务发现、负载均衡、TLS、HTTP/2及gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等。
Ingressgateway：一个Loadbalancer类型的Service。
其它： Jaeger-agent|collector|query、Kiali、Prometheus、Tracing、Zipkin。
2. 非侵入的流量治理
Istio流量治理原理：
支持功能：路由管理、熔断、负载均衡、故障注入等。
对服务的访问进行管理的工具和策略。以基础设施的方式提供给用户非侵入的流量治理能力，用户只需关注自己的业务逻辑开发，无需关注服务访问管理。
负载均衡：Envoy->Pilot->Envoy。支持轮询、随机和最小连接数。
服务熔断：熔断关闭->熔断开启->熔断半开启。
Hystrix熔断：阻断级联失败，防止雪崩；提供延迟和保护；快速失败并即时恢复；对每个服务调用都进行隔离；对服务维护连接池；配置熔断阈值；恢复探测；提供监控告警。
Istio熔断：提供了连接池和故障实例隔离的能力。
故障注入：设置注入的故障条件、延迟、错误码等。
灰度发布：蓝绿发布/AB测试/金丝雀发布。
基于负载均衡器。
基于K8S, 控制pod版本比例。
基于Istio：Envoy执行分流策略配置。
服务访问入口：
K8S两种：1. Loadbalancer类型的Service。 2. Ingress服务。
Istio：Gateway时一个Envoy。
外部接入服务治理：
ServiceEntry。
相关配置：
Istio都是通过K8S的CRD方式表达
VirtualService路由配置：
概念：是istio流量治理的核心配置。定义了对特定目标的一组流量规则的一个服务。包含流量治理中最重要，最复杂的规则。
配置项：hosts、gateways(可以支持的gateway)、https、tls、tcp、exportTo。
https包含：条件（uri|headers等）、routeDestination(subset用于灰度)、redirect、rewrite、retry、faultinject、corspolicy、mirror（镜像）
典型应用：1. 多个服务的组合 2. 路由规则优先级 3. 复杂条件路由（请求内容和比例并存） 4. 特定版本间的访问规则
DestinationRule目标规则配置：
概念：描述请求到后端后如何处理，描述的是目标的规则。 负载均衡和熔断的定义位置，包含连接池大小、异常实例驱除规则。
配置项：host|trafficPolicy(负载策略、连接池、异常实例检测、端口策略)|subsets|exportTo
典型应用：1. 定义subset作分组。 2. 服务熔断。 3. 负载均衡配置。 4. TLS认证配置。
Gateway网关配置：
概念：在网格边缘接收外部访问，并将流量转发到网格内的服务。常与VirtualService配合使用。Gateway对外、VirtualService对内。
配置项：selector：gateway负载，入口处的envoy运行的pod标签。 servers：开放的服务列表，定义了服务访问入口。
典型应用：1. 将网格内HTTP服务发布为外部访问（可支持HTTPS、双向HTTPS）
ServiceEntry外部服务配置：
概念：将外部服务加入到网格中，以进行流量治理。
配置项：ports、location、resolution、endpoint、port。
典型应用：通常与Egress Gateway合作。mesh/egress。
Sidecar代理规则配置：
概念：Istio1.1版本引入，用于对istio数据面的行为进行更精细的控制。
配置项：workloadSelector、egress、ingress
典型应用：本地端口转发
3. 可扩展的策略和遥测(MIXER)
策略和遥测原理：
要解决的问题：APM的职能：包括采集数据、存储数据和检索数据。
通过一个专门的服务端组件提供一种扩展机制来收集服务运行的遥测数据和对服务间的访问执行一定的策略。
应用场景：1. 传统一对一收集。 2. Sidecar统一上报大盘APM后端。 3. ISTIO方式，sidecar上报到mixer，adapter推送到各apm
实现原理：一个插件就是一个adapter，提供日志、监控、配合、ACL检查等功能。主要通过Handler、Instance、Rule三个资源对象来描述Adapter配置。在Rule中定义满足match条件的请求构造的Instance对象，并将Instance对象发送给配置的Handler处理。
Handler：描述定义的Adapter及其实现。
Instance：定义了Adapter药处理的数据对象，通过模板为Adapter提供对元数据的定义。
Rule：配置了一组规则，告诉Mixer有哪个Instance在什么时候发送给那个Handler来处理。一般包含一个匹配的表达式和执行动作。
Istio遥测适配器配置：
a. Prometheus: 应用广泛的系统监控和报警平台。强大的多为数据模型、高效的数据采集能力、灵活的查询算法、以及可扩展性、方便集成。采用PULL方式采集数据。
Handler配置老化、metric信息。 Instance基于Metric模板。 Rule设置匹配规则，绑定action，设置对应的instance。
b. Fluentd: 开源日志数据收集器、提供了可高度定制化的功能。
Handler配置Fluentd监听地址、间隔、大小。 Instance包含日志变量等。 Rule同上关联action和instances。
c. StatsD： 另一个处理Metric的开源系统。
d. Stdio: 可以将metric作一个标准输入的输出展示组件。
e. Zipkin： 开源实时分布式调用链跟踪系统。提供完整的从调用链埋点、收集、存储、检索到UI的完整方案。对比jaeger、opentracing等。
Handler设置采样率，Instance数据较多。
Istio策略适配器配置：
a. List适配置：用于设置黑白名单
b. Denier适配器: 总是拒绝
c. Memory Quota: 内存配置，一般只能用于单Mixer，不适用生产。
d. Redis Quota: 分布式配额管理
4. 可插拔的服务安全
服务安全原理：istio提供了一个透明的分布式安全层，并提供了底层安全的通信通道，管理服务通信的认证、授权和加密。提供了pod到pod，服务到服务的通信安全。
组件：4个重要组件： Citadel管理密钥和证书。 Envoy代理数据面的安全通信，包括认证和通道加密。Pilot进行配置管理，推送至Envoy。 Mixer通过配置Adapter作授权和访问审计。
认证：方式分为传输认证和来源认证(最终用户认证)mTLS 设置生效流程：kube-apiserver->Pilot->Envoy
授权：RBAC模型。Istio可以为网格中的服务提供命名空间级别、服务级别和方法级别的授权管理。在语法上包括基于角色的语义、服务到服务和最终用户到服务的授权，也可以通过角色方式进行自定义管理。 配置下发流程同上。
密钥证书管理：基于Citadel提供了自动生成、分发、轮换与撤销密钥和证书的功能。(Service Account)
服务认证配置：
配置项：targets、peers(单双向认证)、origins(jwt认证)、principalBinding(关联身份或主体)、tls证书配置
典型应用：
支持多种范围的认证策略[全网格、命名空间、服务级别]。
组合TLS认证和来源认证。
服务授权配置：
可以作集群授权ClusterRbacConfig。
包括ServiceRole和ServiceRoleBinding。
典型应用：
特定命名空间授权
特定服务授权
特定服务接口授权
特定版本的授权
特定源IP的授权
5. 透明的sidecar机制
负责执行配置规则的组件在服务网格中称为服务代理，处理内容包括（流量管理、遥测、治理登功能）。
Sidecar注入：
Sidecar容器与应用容器在同一pod中，共享同一个Network Namespace，共享网络协议栈，所以可以使用iptables。
两种注入方式：通过istioctl命令行工具手动注入。通过Istio Sidecar Injector自动注入。最终都是在应用pod中注入init容器和istio-proxy容器。
注入原理：Sidecar Injector以K8s准入控制器Admission Controller（kube-apiserver请求的拦截器）的形式运行，用于自动注入Sidecar组件。
Sidecar Injector以轻量级HTTPS服务器的形式处理Kube-apiserver的AdmissionRequest请求。
Sidecar流量拦截：
指基于iptables规则(由init容器在Pod启动的时候首先设置的iptables规则)，拦截应用容器Inbound/Outbound的流量，不支持UDP。
iptables(netfilter)是一种内核防火墙框架，可以实现网络安全策略的许多功能：数据包过滤、数据包处理、地址伪装、透明代理、网络地址转换（NAT）。 由表及构成表的链组成。
Raw表：决定数据包是否被状态跟踪机制处理。规则优先于其他表。
Mangle表：修改TOS、TTL及为数据包设置Mark标记，以实现QoS调整及策略路由。
NAT表：用于修改IP地址、端口号
Filter表：默认表，数据包过滤，决定是否放行。
Iptables流量拦截模式：REDIRECT。在initContainer使用istio-iptables.sh为整个Pod的网络命名空间设置所需iptables规则。 inbound->envoy->app->envoy->outbound
6. 多集群服务治理
概念现状：多云管理。
集群：共享API服务器的K8S节点集合。
网络：Istio要求同一网络至少支持四层互通。
网格：属于同一控制面管理的工作负载集合。
模式1：多控制面
每个K8S集群都分别部署自己独立的Istio控制面，并且每个集群的控制面部署形态都相似，各自管理自身的Endpoint。跨集群访问需要创建ServiceEntry规则，对Remote集群服务进行访问（带global后缀的服务域名）。CoreDNS+Gateway。
问题：需要额外配置VirtualService、DestinationRule、Gateway、ServiceEntry等API对象，复杂度高。
模式2：VPN直连单控制面
VirtualService等服务创建在控制面所在的K8S集群中，ISTIO本地集群的配置规则控制服务网格所有集群内容服务间的通信、安全、遥测等。
集群控制面Pilot组件链接访问所有集群的Kube-apiserver获取每个集群的Service、Endpoint、Pod和Node，并负责所有集群Sidecar代理的xDS配置分发。
问题：要求每个集群有相同的Services对象，用作占位和域名解析。不同集群的服务IP和Pod的IP范围不能重叠。
模式3：集群感知服务路由单控制面
配置Istio Gateway转发，来进行单控制面管理。依赖集群感知或者水平分割EDS（Endpoint Discovery Service）特性。
必须打开双向TLS，目标集群网关在转发请求时使用SNI的路由。ClusterID、Network和Gateway三个概念是Split Horizon EDS的基础。
问题：要求一个服务同时存在所有集群中，否则DNS解析会有麻烦。网关在使用SNI路由时，只能提供TCP级别的指标监控，并且在调用链追踪中不会出现。
二、实践
1. 环境安装
2. 流量监控
3. 灰度发布
4. 流量治理
5. 服务保护
6. 多集群管理
三、架构
1. Pilot司令官
2. Mixer守护神
3. Citadel堡垒
4. Envoy高性能代理
5. Pilot-agent代理守护进程
6. Galley配置中心
四、源码
1. Pilot源码
2. Mixer源码
3. Citadel源码
4. Envoy源码
5. Galley源码
935
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
