Istio的架构概述

Istio的架构概述

Istio的工作机制

首先整个Istio的工作机制和架构主要分为控制面和数据面两个部分，控制面包括Pilot、Mixer、Citadel等服务组件，数据面则是由应用程序部署的代理程序Envoy组成。
大概表述一下全体流程：

• 自动注入：当创建应用程序时，自动注入Sidecar代理。再Kubernetes创建Pod时，Kube-apiserver调用管理面组件Sidecar-Injector服务，自动修改应用程序的描述信息，并注入Sidecar，也就是说在创建业务容器的时候不仅仅创建了单个容器，还创建了一个附属容器Sidecar。
• 流量拦截：在创建Pod后，初始化iptables规则时，基于配置的iptables规则将拦截业务容器的Inbound和Outbound到附属的Sidecar上。在Pod与Pod之间的访问都会通过各自的Sidecar进行通信。
• 服务发现：服务发起方的Envoy调用管理面组件Pilot的服务发现接口获取目标服务的实例列表。
• 负载均衡：当新建的业务容器发起服务请求的时候，其搭载的Envoy会根据配置的负载均衡策略选择服务实例，并且连接对应的实例地址。
• 流量治理：当Envoy从Pilot中获取到配置的流量规则，在连接到的Inbound流量和Outbound流量是执行治理逻辑。根据流量治理规则，将不同特征的流量分发到不同的容器上。
• 访问安全：在服务间访问时通过双方的Envoy进行双向认证合同到加密，并给予服务的身份进行授权管理，其中的证书和密钥由管理面中的组件Citadel维护。
• 服务遥测：在服务之间通信的时候，双方的Envoy都会连接到管理面组件Mixer上报访问数据，并通过Mixer将数据转发给对应的监控后端。
• 策略执行：在进行服务访问的时候，通过Mixer连接后端服务来控制服务间的访问，判断对该访问方形还是拒绝。
• 外部访问：在网格的入口处有一个Envoy扮演的入口网关的角色，外部服务只能通过这个Gateway访问网格内的服务，并且执行负载均衡和流量治理的策略。
  总结：服务调用双方的Envoy代理拦截流量，并根据管理面的相关配置执行相应的治理动作。

Istio的主要组件

Istio-pilot

Istio-pilot是Istio的控制中枢Pilot，Pilot直接从运行平台提取数据并将其构造和转换成Istio的服务发现模型，因此Pilot只有服务发现功能，无需进行服务注册。除了服务发现，其更加重要的的功能是向数据面下发规则，例如VirtualService、DestinationRule、Gateway、ServiceEntry等流量治理规则，也包含认证授权等安全规则。
Pilot负责将各种规则转换成Envoy可识别的格式，通过标准的xDS协议发送给Envoy，指导Envoy完成动作。在通信上，Envoy通过gRPC流式订阅Pilot的配置资源。

Istio-telemetry

Istio-telemetry是专门用于收集遥测数据的Mixer服务组件。当网格中的两个服务间有调用发生时，服务的代理Envoy就会上报遥测数据给Istio-telemetry服务组件，Istio-telemetry服务组件则根据配置将生成访问Metric等数据分发给后端的遥测服务。数据面代理通过Report接口上报数据时访问数据会被批量上报。

Istio-policy

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

Istio-citadel

Istio-citadel是Istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel一直监听Kube-apiserver，以Secret的形式为每个服务都生成证书密钥，并在Pod创建时挂载到Pod上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证，通道加密、访问授权等安全功能，这样用户就不用再代码中维护证书密钥。

Istio-galley

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

Istio-sidecat-injector

Istio-sidecat-injector负责自动注入的组件，只要开启了自动注入，再Pod创建时就会自动调用Istio-sidecat-injector向Pod中注入sidecar容器。
再Kubernetes环境中，根据自动注入配置，Kube-apiserver拦截到创建Pod的请求时，会调用自动注入
服务Istio-sidecat-injector生成的Sidecar容器的描述并将其插入原Pod的定义中，这样在创建Pod时不仅仅包含了业务容器，还包括了Sider容器。

Istio-ingressgateway

Istio-ingressgateway是一个Gateway，从网格外访问网格内的服务就是通过Gateway进行的。是一个Loadbalancer类型的Service，并且开放了一组端口，这些就是网格内服务的外部访问端口。