云原生服务网格istio 第二章

　　　　　　　　　　　　　　　　　　Istio架构概述

Istio的工作机制
　　1.1版本

 1.5版本

（1）自动注入：指在创建应用程序时自动注入 Sidecar代理。在 Kubernetes场景下创建 Pod时，Kube- apiserver调用管理面组件的 Sidecar-Injector服务，自动修改应用程序的描述信息并注入Sidecar。在真正创 建Pod时，在创建业务容器的同时在Pod中创建Sidecar容器
（2）流量拦截：在 Pod 初始化时设置 iptables 规则，当有流量到来时，基于配置的iptables规则拦截 业务容器的Inbound流量和Outbound流量到Sidecar上。应用程序感知不到Sidecar的存在，还以原本的方式 进行互相访问。在图2-1中，流出frontend服务的流量会被 frontend服务侧的 Envoy拦截，而当流量到达 forecast容器时，Inbound流量被forecast服务侧的Envoy拦截
（3）服务发现：服务发起方的 Envoy 调用管理面组件 Pilot 的服务发现接口获取目标服务的实例列 表。在图 2-1 中，frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到forecast服务各个实例的地址， 为访问做准
（4）负载均衡：服务发起方的Envoy根据配置的负载均衡策略选择服务实例，并连接对应的实例地 址。在图2-1中，数据面的各个Envoy从Pilot中获取forecast服务的负载均衡配置，并执行负载均衡动作
（5）流量治理：Envoy 从 Pilot 中获取配置的流量规则，在拦截到 Inbound 流量和Outbound 流量时执 行治理逻辑。在图 2-1 中，frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则，并根据该流量治理规 则将不同特征的流量分发到forecast服务的v1或v2版本
（6）访问安全：在服务间访问时通过双方的Envoy进行双向认证和通道加密，并基于服务的身份进 行授权管理。在图2-1中，Pilot下发安全相关配置，在frontend服务和forecast服务的Envoy上自动加载证书 和密钥来实现双向认证，其中的证书和密钥由另一个管理面组件Citadel维护
（7）服务遥测：在服务间通信时，通信双方的Envoy都会连接管理面组件Mixer上报访问数据，并通 过Mixer将数据转发给对应的监控后端
（8）策略执行：在进行服务访问时，通过Mixer连接后端服务来控制服务间的访问，判断对访问是 放行还是拒绝。在图2-1中，Mixer后端可以对接一个限流服务对从frontend服务到forecast服务的访问进行 速率控制
（9）外部访问：在网格的入口处有一个Envoy扮演入口网关的角色。在图2-1中，外部服务通过 Gateway访问入口服务 frontend，对 frontend服务的负载均衡和一些流量治理策略都在这个Gateway上执 行。

2.2.3 Istio的服务实例

服务实例是真正处理服务请求的后端，就是监听在相同端口上的具有同样行为的对等后端。服务访 问时由代理根据负载均衡策略将流量转发到其中一个后端处理。Istio 的ServiceInstance 主要包括 Endpoint、Service、Labels、AvailabilityZone 和 ServiceAccount等属性，Endpoint 是其中最主要的属性， 表示这个实例对应的网络后端（ip：port），Service表示这个服务实例归属的服务

Istio的服务发现基于Kubernetes构建，本章讲到的Istio的Service对应Kubernetes的Service，Istio的服务 实例对应Kubernetes的Endpoint，如图2-4所示

2.3 Istio的主要组件

2.3.1 istio-pilot

服务列表中的 istio-pilot是 Istio 的控制中枢 Pilot服务。如果把数据面的 Envoy 也看作一种Agent，则 Pilot类似传统C/S架构中的服务端Master，下发指令控制客户端完成业务功能。和传统的微服务架构对 比，Pilot 至少涵盖服务注册中心和 Config Server 等管理组件的功能
Pilot 直接从运行平台提取数据并将其构造和转换成 Istio 的服务发现模型，因此Pilot 只有服务发现功能，无须进行服务注册。这种抽象模型解耦了Pilot和底层平台的不同实现，可支持 Kubernetes、Consul等平台。Istio 0.8还支持Eureka，但随着Eureka停止维护，Istio在1.0之后的版本中也删 除了对Eureka的支持

 除了服务发现，Pilot 更重要的一个功能是向数据面下发规则，包括 VirtualService、DestinationRule、 Gateway、ServiceEntry 等流量治理规则，也包括认证授权等安全规则。Pilot 负责将各种规则转换成 Envoy 可识别的格式，通过标准的 xDS 协议发送给 Envoy，指导Envoy完成动作。在通信上，Envoy通过 gRPC流式订阅Pilot的配置资源。如图2-6所示，Pilot将 VirtualService表达的路由规则分发到 Evnoy上， Envoy根据该路由规则进行流量转发

2.3.2 istio-telemetry(1.5版本之前) 

　　istio-telemetry是专门用于收集遥测数据的Mixer服务组件。如服务列表所示，在部署上，Istio控制面 部署了两个Mixer组件：istio-telemetry和istio-policy，分别处理遥测数据的收集和策略的执行。查看两个组 件的 Pod 镜像会发现，容器的镜像是相同的，都是“/istio/mixer”。

　　Mixer是Istio独有的一种设计，不同于Pilot，在其他平台上总能找到类似功能的服务组件。从调用时 机上来说，Pilot管理的是配置数据，在配置改变时和数据面交互即可；然而，对于Mixer来说，在服务间 交互时Envoy都会对Mixer进行一次调用，因此这是一种实时管理。当然，在实现上通过在Mixer和Proxy 上使用缓存机制，可保证不用每次进行数据面请求时都和Mixer交互（已废弃）

2.3.3 istio-policy 

　　istio-policy是另外一个Mixer服务，和istio-telemetry基本上是完全相同的机制和流程。如图2-8所示， 数据面在转发服务的请求前调用istio-policy的Check接口检查是否允许访问，Mixer 根据配置将请求转发到对应的 Adapter 做对应检查，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的 控制后端，对服务间的访问进行可扩展的控制

2.3.4 istio-citadel 

　　服务列表中的 istio-citadel是 Istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书 功能。Citadel一直监听 Kube-apiserver，以 Secret的形式为每个服务都生成证书密钥，并在Pod创建时挂载 到Pod上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、 访问授权等安全功能，这样用户就不用在代码里面维护证书密钥了。如图 2-9 所示，frontend 服务对 forecast 服务的访问用到了HTTP方式，通过配置即可对服务增加认证功能，双方的Envoy会建立双向认证 的TLS通道，从而在服务间启用双向认证的HTTPS

2.3.5 istio-galley 

　　istio-galley并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley作为负责 配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的 Pilot和 Mixer 服务使用，这样其他管理面组件只用和 Galley打交道，从而与底层平台解耦

2.3.6 istio-sidecar-injector 

　　istio-sidecar-injector是负责自动注入的组件，只要开启了自动注入，在Pod创建时就会自动调用istio-idecar-injector向Pod中注入Sidecar容器

2.3.7 istio-proxy 

　　Envoy、Sidecar、Proxy等术语有时混着用，都表示Istio数据面的轻量代理

　　　　　　常用的服务访问治理规则和其执行位置

2.3.8 istio-ingressgateway

　　istio-ingressgateway 就是入口处的 Gateway，从网格外访问网格内的服务就是通过这个Gateway进行 的

2.3.9 其他组件 

　　除了以“istio”为前缀的以上几个Istio自有的组件，在集群中一般还安装Jaeger-agent、Jaeger-collector、 Jaeger-query、Kiali、Prometheus、Tracing、Zipkin组件，这些组件提供了Istio的调用链、监控等功能，可 以选择安装来完成完整的服务监控管理功能