Istio 简介(2)【二】

（1）服务发现(discovery); 
（2）负载均衡(load balancing); 把前端的请求分发到后台多个服务器
（3）故障恢复(failure recovery); 出现故障具备自恢复的能力
（4）服务度量(metrics); 
（5）服务监控(monitoring); 
（6）A/B 测试(A/B testing); 
（7）灰度发布(canary rollouts); 

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之
前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。 
（8）限流限速(rate limiting); 
（9）访问控制(access control); 
（10）身份认证(end-to-end authentication)

 

【断路器】

断路器也称为服务熔断，在多个服务调用的时候，服务 A 依赖服务 B，服务 B 依赖服务 C，如果服务
C 响应时间过长或者不可用，则会让服务 B 占用太多系统资源，而服务 A 也依赖服 B，同时也在占用大量
的系统资源，造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理，避
免了在代码中侵入控制逻辑，非常方便的就实服务熔断的能力

 

【超时】

在生产环境中经常会碰到由于调用方等待下游的响应过长，堆积大量的请求阻塞了自身服务，造成
雪崩的情况，通过超时处理来避免由于无限期等待造成的故障，进而增强服务的可用性。

【重试】

istio 重试机制就是如果调用服务失败，Envoy 代理尝试连接服务的最大次数。而默认情况下，
Envoy 代理在失败后并不会尝试重新连接服务。

【多路由规则】

1、HTTP 重定向（HTTPRedirect） 
2、HTTP 重写（HTTPRewrite） 
3、HTTP 重试（HTTPRetry） 
4、HTTP 故障注入（HTTPFaultInjection） 
5、HTTP 跨域资源共享（CorsPolicy）

 

Istio构架

1. 自动注入：在创建应用程序时自动注入 Sidecar 代理 Envoy 程序。在 Kubernetes 中创建 Pod 时，
Kube-apiserver 调用控制面组件的 Sidecar-Injector 服务，自动修改应用程序的描述信息并注入
Sidecar。在真正创建 Pod 时，在创建业务容器的 Pod 中同时创建 Sidecar 容器。 
 
2. 流量拦截：在 Pod 初始化时设置 iptables 规则，基于配置的 iptables 规则拦截业务容器的 Inbound
流量和 Outbound 流量到 Sidecar 上。而应用程序感知不到 Sidecar 的存在，还以原本的方式 进行互相
访问。上图中，流出 frontend 服务的流量会被 frontend 服务侧的 Envoy 拦截，而当流量到达 forecast
容器时，Inbound 流量被 forecast 服务侧的 Envoy 拦截。 
 
3. 服务发现：服务发起方的 Envoy 调用控制面组件 Pilot 的服务发现接口获取目标服务的实例列表。
上图中，frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到 forecast 服务各个实例的地址。 
 
 
4. 负载均衡：服务发起方的 Envoy 根据配置的负载均衡策略选择服务实例，并连接对应的实例地址。上
图中，数据面的各个 Envoy 从 Pilot 中获取 forecast 服务的负载均衡配置，并执行负载均衡动作。

5. 流量治理：Envoy 从 Pilot 中获取配置的流量规则，在拦截到 Inbound 流量和 Outbound 流量时执
行治理逻辑。上图中， frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则，并根据该流量治理
规则将不同特征的流量分发到 forecast 服务的 v1 或 v2 版本。 
 
6. 访问安全：在服务间访问时通过双方的 Envoy 进行双向认证和通道加密，并基于服务的身份进行授权
管理。上图中，Pilot 下发安全相关配置，在 frontend 服务和 forecast 服务的 Envoy 上自动加载证书和
密钥来实现双向认证，其中的证书和密钥由另一个管理面组件 Citadel 维护。 
 
7. 服务监测：在服务间通信时，通信双方的 Envoy 都会连接管理面组件 Mixer 上报访问数据，并通过
Mixer 将数据转发给对应的监控后端。上图中，frontend 服务对 forecast 服务的访问监控指标、日志和
调用链都可以通过这种方式收集到对应的监控后端。 
 
 
8. 策略执行：在进行服务访问时，通过 Mixer 连接后端服务来控制服务间的访问，判断对访问是放行还
是拒绝。上图中，Mixer 后端可以对接一个限流服务对从 frontend 服务到 forecast 服务的访问进行速
率控制等操作。 
 
9. 外部访问：在网格的入口处有一个 Envoy 扮演入口网关的角 色。上图中，外部服务通过 Gateway 访
问入口服务 frontend，对 frontend 服务的负载均衡和一些流量治理策略都在这个 Gateway 上执行。

 

【Pilot】

Pilot 是 Istio 的主要控制组件，下发指令控制客户端。在整个系统中，Pilot 完成以下任务： 
1、从 Kubernetes 或者其他平台的注册中心获取服务信息，完成服务发现过程。 
2、读取 Istio 的各项控制配置，在进行转换之后，将其发给数据面进行实施。

 

Pilot 将配置内容下发给数据面的 Envoy，Envoy 根据 Pilot 指令，将路由、服务、监听、集群等
定义信息转换为本地配置，完成控制行为的落地。 
 
1）Pilot 为 Envoy 提供服务发现 
2）提供流量管理功能（例如，A/B 测试、金丝雀发布等）以及弹性功能（超时、重试、熔断器等）； 
3）生成 envoy 配置 
4）启动 envoy 
5）监控并管理 envoy 的运行状况，比如 envoy 出错时 pilot-agent 负责重启 envoy，或者 envoy 配置变更后 reload envoy

 

【Envoy】

Envoy 是用 C++ 开发的高性能代理，用于协调服务网格中所有服务的入站和出站流量。 
Envoy 有许多强大的功能，例如: 
动态服务发现 
负载均衡 
TLS 终端 
HTTP/2 与 gRPC 代理 
断路器

健康检查 
流量拆分 
灰度发布 
故障注入

Istio 中 Envoy 与服务什么关系？ 
为了便于理解 Istio 中 Envoy 与服务的关系，下图为 Envoy 的拓扑图，如图所示：

Envoy 和 Service A 同属于一个 Pod，共享网络和命名空间，Envoy 代理进出 Pod A 的流量，并将流量按照外部请求的规则作用于 Service A 中。 
 
Pilot-agent 是什么？ 
Envoy 不直接跟 k8s 交互，通过 pilot-agent 管理的 
Pilot-agent 进程根据 K8S APIserver 中的配置信息生成 Envoy 的配置文件，并负责启动 Envoy 进程。 
Envoy 由 Pilot-agent 进程启动，启动后，Envoy 读取 Pilot-agent 为它生成的配置文件，然后根据
该文件的配置获取到 Pilot 的地址，通过数据面从 pilot 拉取动态配置信息，包括路由（route），监听器（listener），服务集群（cluster）和服务端点（endpoint）。

 

【 Citadel】

负责处理系统上不同服务之间的 TLS 通信。 Citadel 充当证书颁发机构(CA)，并生成证书以允许在
数据平面中进行安全的 mTLS 通信。 
 
Citadel 是 Istio 的核心安全组件，提供了自动生 成、分发、轮换与撤销密钥和证书功能。
Citadel 一直监听 Kube- apiserver，以 Secret 的形式为每个服务都生成证书密钥，并在 Pod 创建
时挂载到 Pod 上，代理容器使用这些文件来做服务身份认证，进而代 理两端服务实现双向 TLS 认
证、通道加密、访问授权等安全功能。如图 所示，frontend 服 务对 forecast 服务的访问用到了
HTTP 方式，通过配置即可对服务增加认证功能，双方的 Envoy 会建立双向认证的 TLS 通道，从而在
服务间启用双向认证的 HTTPS。

 

【Galley】

Galley 是 istio 的配置验证、提取、处理和分发的组件。Galley 是提供配置管理的服务。实现原理
是通过 k8s 提供的 ValidatingWebhook 对配置进行验证。 
 
Galley 使 Istio 可以与 Kubernetes 之外的其他环境一起工作，因为它可以将不同的配置数据转换为
Istio 可以理解的通用格式。

【Ingressgateway】

Ingressgateway 就是入口处的 Gateway，从网格外访问网格内的服务就是通过这个 Gateway 进行
的。istio-ingressgateway 是一个 Loadbalancer 类型的 Service，不同于其他服务组件只有一两个
端 口，istio-ingressgateway 开放了一组端口，这些就是网格内服务的外部访问端口。如下图所
示，网格入口网关 istio-ingressgateway 的负载和网格内的 Sidecar 是同样的执行流程，也和网格
内的其他 Sidecar 一样从 Pilot 处接收流量规则并执行。

【Sidecar-injector】

Sidecar-injector 是负责自动注入的组件，只要开启了自动注 入，在 Pod 创建时就会自动调用
istio-sidecar-injector 向 Pod 中注入 Sidecar 容器。 
在 Kubernetes 环境下，根据自动注入配置，Kube-apiserver 在拦截到 Pod 创建的请求时，会调用
自动注入服务 istio-sidecar-injector 生成 Sidecar 容器的描述并将其插入原 Pod 的定义中，这
样，在创建的 Pod 内除了包括业务容器，还包括 Sidecar 容器，这个注入过程对用户透明。 
 
【其他组件】 
除了以“istio”为前缀的 Istio 自有组件，在集群中一般还安装 Jaeger-agent、Jaeger-collector、Jaeger-query、Kiali、Prometheus、Grafana、 Tracing、Zipkin 等组件，这些组件提
供了 Istio 的调用链、监控等功能，可以选择安装来完成完整的服务监控管理功能。