得益于良好的模块化设计,Istio的各个组件设计清晰,分工明确,几个大的组件之间甚至可以独立工作,所以接下来我们将逐一深入分析Istio的各个组件。本文首先详细分析一下我们最常用的流量管理功能所对应的模块,飞行员和特使。
Istio基本架构
Istio基本架构图如下图所示,网格东西向及南北向的流量控制,核心思路是由飞行员维护管理策略,并通过标准接口下发到特使代理中,由特使最终实现流量的转发。
Istio服务网格逻辑上分为数据平面和控制平面:
-
<李>数据平面:由一组以双轮马车方式部署的智能代理(特使)组成,这些代理可以调节和控制微服务之间所有的网络通信。
<李>控制平面:服务管理和配置代理来路由流量。
其中与流量管理相关的主要包括控制层面的飞行员以及数据层面的特使代理。
控制平面组件——飞行员
飞行员的基本架构如下图所示。
飞行员功能
根据上图,飞行员主要实现下述功能:
<强> 1。统一服务模型
统一服务模型主要功能是从底层平台获取服务相关信息以及通过RuleAPI定义的服务间流量规则,以kubernetes为例,统一服务模型从平台上获取注册在豆荚,服务,节点以及流量规则信息,获取到各种信息后转变成数据平面上可理解的数据格式存储在抽象模型中。
<强> 2。标准数据平面API
获取到各种服务信息以及流量规则之后,会通过该API下发到数据面的双轮马车中。
<强> 3。业务DSL语言(域Speci ?c语言)
SL语言提供了面向业务的高层抽象,可以被运维人员理解和使用。运维人员使用该DSL定义流量规则并下发到飞行员,这些规则被飞行员翻译成数据面的配置,再通过标准API分发到特使实例,可以在运行期对微服务的流量进行控制和调整。
飞行员的规则DSL是采用k8 API服务器中的自定义资源(CRD)实现的,因此和其他资源类型如服务Pod部署的创建和使用方法类似,都可以用Kubectl进行创建。
通过运用不同的流量规则,可以对网格中微服务进行精细化的流量控制,如按版本分流、断路器,故障注入,灰度发布等。
飞行员实现
与飞行员相关的服务主要有两个:
<强>(1)发现服务
对应的码头工人为gcr.io istio-release/飞行员,进程为pilot-discovery,该组件的功能包括:
从服务提供者中获取服务信息,除了这里主要介绍的Kubernetes之外,Istio还支持领事作为服务提供者。
从Kubernetes API服务器中获取流量规则(Kubernetes CRD的资源)。
将服务信息和流量规则转化为数据面可以理解的格式,通过标准的数据面API下发到网格中的各个双轮马车中。
<强> (2)Kubernetes API服务器
提供飞行员相关的CRD资源的增,删,改,查。和飞行员相关的CRD有以下几种:
Virtualservice:用于定义路由规则,如根据来源或头制定规则,或在不同服务版本之间分拆流量。
DestinationRule:定义目的服务的配置策略以及可路由子集。策略包括断路吗?,负载均衡以及TLS等。
ServiceEntry:用ServiceEntry可以向Istio中加入附加的服务条目,以使网格内可以向Istio服务网格之外的服务发出请求。
网关:为网格配置网关,以允许一个服务可以被网格外部访问。
EnvoyFilter:可以为特使配置过滤?。由于特使已经支持Lua过滤吗?,因此可以通过EnvoyFilter启用Lua过滤吗?,动态改变特使的过滤链行为。我之前一直在考虑如何才能动态扩展特使的能力,EnvoyFilter提供了很灵活的扩展性。
数据平面组件,特使
特使实现
Istio通过美丽的入学Webhook机制实现了双轮马车的自动注入,Istio集群中的每个微服务会被加入特使相关的容?。下面是官方示例productpage微服务的豆荚内容,可见除productpage之外,Istio还在该舱中注入了两个容? gcr.io/istio-release proxy_init和gcr.io/istio-release/proxyv2。
<强> 1。初始化容器? proxy_init
Productpage的圆荚体中有一个InitContainer proxy_init, InitContrainer是k8提供的机制,用于在豆荚中执行一些初始化任务,在Initialcontainer执行完毕并退出后,才会启动豆荚中的其它容器。
