isito的相关组件和工作机制概述

àì夳堔傛蜴生んèń 2023-01-15 08:04 125阅读 0赞

2.1 istio的工作机制  
istio架构分为控制面和数据面两部分。  
控制面:包括pilot、mixer、citadel等组件  
数据面:由伴随每个应用程序部署的代理程序envoy组成，执行针对应用程序的治理逻辑

从fronted服务访问forecast服务来看istio内部的组件都做了什么  
如图

：![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70][]  
1）sidecar自动创建与注入：创建应用程序时自动注入sidecar代理。在k8s场景下创建Pod时，在创建业务容器的同时会创建sideCar容器，然后kube-apiserver调用管理面组件的sidecar-injector服务，自动修改应用程序的描述信息并注入sidecar。  
2）流量拦截：pod初始化时设置iptables规则，有流量到来时，基于iptables规则拦截业务容器的Inbound流量和outBound流量到sidecar上，该过程应用程序无感知，应用程序间的访问方式不变。  
上图中：流出fronted服务的流量会被fronted侧的envoy拦截；流量到达froecast容器前，inbound流量会被frecast服务测的envoy拦截。  
3）服务发现：服务发起方的envoy调用管理面组件pilot的服务发现接口获取目标服务的实例列表。  
上图中：fronted侧的envoy调用pilot的服务发现接口得到forecast服务各个实例的地址  
4）负载均衡：服务发起方的envoy根据pilot中配置的负载均衡策略选择服务实例。  
上图中：数据面的各个envoy从pilot中获取forcecast服务的负载均衡配置，并执行负载均衡动作  
5）流量治理：envoy从pilot中获取配置的流量规则，在拦截到inbound和outbound流量时执行治理逻辑。  
上图中：fronted服务侧的envoy从pilot中获取流量治理规则，并根据流量治理规则将不同特征的流量分发到forecats的v1和v2版本。  
6）访问安全：在服务间访问时通过双方的envoy进行双向认证和通道加密，并基于服务的身份进行授权管理  
上图中：pilot下发安全相关配置，在fronted和forecast服务上的envoy上自动加载证书和秘钥来实现双向认证。证书和秘钥由citadel来维护。  
7）服务遥测：服务间通信时，通信双方的envoy都会连接管理面组件mixer上报访问数据，并通过mixer将数据转发给对应的监控后端。  
如上图：fronted服务队forecast服务的访问监控指标、日志和调用链都通过该方式手机到对应的监控后端。  
8）策略执行:进行服务访问时，通过mixer连接后端服务来控制服务间的访问，判断对服务房型还是拒绝。  
上图中：mixer可以对接一个限流服务对fronted服务到forecast服务的访问进行速率控制。  
9）外部访问：网格的入口有一个envoy扮演入口网关的角色。  
上图中:外部服务通过gateway访问入口服务fronted，对fronted服务的负载均衡、治理策略都在该gateway上执行。

每个过程都可以进行如下抽象：服务调用双方的envoy代理拦截流量，并根据管理面的相关配置执行对应的治理动作。

2.2 istio的服务模型  
istio支持将由服务、服务版本和服务实例构造的抽象模型映射到不同的平台上。  
istio的几个约束：  
1）端口命名：istio的服务端口必须命名，名称只能是<protocol>\[-<suffix>\]格式。protocol可以是http、tcp、http2、grps、tls等。  
如： name:http2-forecast或name:http是合法端口名。name:httpsforecast是非法的端口名。  
2）服务关联：Pod需要关联到服务，如果一个pod属于多个k8s服务，则要求服务不能在同一个端口上使用不同的协议  
3）Deployment使用app和version标签。

2.2.1 istio的服务  
逻辑上：istio的资源对象，包括域名和端口列表；每个端口包含端口名称、端口号和端口的协议。不同协议有不同的内容，在istio中也有不同的治理规则。  
物理层面：存在形式就是k8s的service，只要满足了上述约束条件，就可以转换为istio的service并配置规则进行流量治理。

k8s中：service通过虚拟ip和port保证了服务地址是不变的，也无需暴露k8s中pod的端口和地址。

k8s中service的定义  
apiVersion: v1  
kind: Service  
metadata:  
 name: forecast  
spec:  
 ports:  
 - port: 8081 \#指定service的虚拟端口号  
  targetPort: 8080 \#对应到Pod容器的8080端口  
 selector:   
  app: forecast \#对应到拥有label（app=webapp）的Pod

istio的service与k8s的区别在于：要满足istio的服务约束，如在端口名称上指定协议。如下(唯一区别是指定了协议为http)：  
apiVersion: v1  
kind: Service  
metadata:  
 name: forecast  
spec:  
 ports:  
 - port: 8081 \#指定service的虚拟端口号  
  targetPort: 8080 \#对应到Pod容器的8080端口  
  name: http  
 selector:   
  app: forecast \#对应到拥有label（app=webapp）的Pod

在istio中：service是治理的对象，是提供了对外访问能力的执行体，是istio服务的元数据。

2.2.2 istio的服务版本  
istio应用场景中，灰度发布是一个重要的场景，即要求一个service有多个不同版本的实现。k8s语法上并不支持一个deployment中定义多个版本，在istio中多个版本的定义是将一个service关联到多个deployment。  
如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1][]

说明：  
1）两个deployment都有相同的app:forecast标签，该标签和service的标签选择器一致，所以service能关联到这两个deployment对应的Pod。  
2）两个deployment有不同的镜像版本，各自创建的Pod也不相同。version标签不同，分别是v1和v2

假设两个deployment分别创建3个和2个Pod，5个Pod都运行在不同的Node上，对service访问，根据配置的流量规则，可以将不同的流量转发到不同版本的Pod上，如下图:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2][]

2.2.3 istio的服务实例  
服务实例：真正处理服务请求的后端，由代理根据负载均衡策略将流量转发发到其中一个后端处理。  
属性：endpoints service labels avalibilityZone serviceAccount

istio的service对应k8s的service；  
istio的服务实例对应k8s的endpoints  
k8s的endpoints对象名称和service对应名称相同，是<pod ip>:<targetPort>列表。

2.3 Istio的组件功能和机制  
2.3.1 istio-pilot  
和传统的微服务架构对比，pilot至少涵盖服务注册中心和configServer的功能。  
1）服务发现：pilot直接从运行平台提取数据，并将其构造成istio的服务发现模型。

如下图：![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 3][]

2）规则转化与下发：负责将各种规则转换成envoy可识别的格式，通过xDs协议发送给envoy。  
规则包括：virtualService、destinationRule、Gateway、ServiceEntry等流量治理规则，也包括认证授权等安全规则。  
pilot将virtualService表达的路由规则分发到envoy如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 4][]

2.3.2 istio-telemetry  
收集遥测数据的mixer服务组件。  
调用时机：  
与pilot不同，因为pilot管理的是配置数据，在配置改变时和数据面交互即可。  
服务间每次交互，envoy都会对mixer进行一次调用，因此是一种实时管理。但是通过缓存机制，也可以不用每次都访问mixer。

如图：当网格中的两个服务发生了调用，服务的代理envoy就会上报遥测数据给istio-telemetry，istio-telemetry组件则根据配置将数据分发给后端的遥测服务。  
图图

2.3.3 istio-policy  
另一个mixer服务，和istio相同的机制。数据面在转发服务的请求前调用istio-policy的check接口检查是否允许访问，mixer根据配置将请求转发到对应的adapter做对应检查，返回允许或拒绝。如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 5][]

2.3.4 istio-citadel  
istio的核心安全组件，提供了自动生成、分发、转化与车市秘钥和证书的功能。  
实现：一直监听kube-apiserver,为每个服务生成证书和秘钥，并在pod创建时挂载到Pod上，代理容器使用这些文件做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密等安全功能。

2.3.5 istio-galley  
负责配置的管理组件，如验证配置纤细格式和内容的正确性，并将这些配置信息提供给pilot和mixer。

2.3.6 istio-sidecar-injector  
负责自动注入，只要开启了自动注入，就会在pod创建时自动调用istio-sidecar-injector向pod中注入sidecar容器。  
实现：kube-apiserver在拦截到Pod的创建请求时，会调用自动注入服务istio-sidecar-injector生成sidcar容器的描述并插入原pod的定义中。所以最终创建的容器包括业务和sidecar容器。且注入过程对用户透明。

2.3.7 isito-proxy  
istio-proxy中除了有envoy，还有一个pilot-agent。 有时envoy、proxy、sidecar会混用。  
envoy是c++开发的非常有影响力的服务代理，提供了动态服务发现、负载均衡、TLS、熔断、健康检查、流量拆分、灰度等功能。

2.3.8 istio-ingressgateway  
入口处的gateway，即网格外访问网格内的服务就是通过这个gateway进行的。  
ingressgateway的复杂和网格内的死的car是同样的执行体，都是从pilot处接收流量并执行。  
如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 6][]  
特点：  
1）开放了一组端口，是网格内服务的外部访问接口。  
2）入口处的流量都走该服务，会有并发和流量峰值，所以需要评估流量来规划规格和实例数。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70]: /images/20221022/437b1a57318c4ff7b5cb5bed3d419b33.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 1]: /images/20221022/2db7c9f5fdbc45dba1ac3725acbd7a11.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 2]: /images/20221022/dcba922d0bed4c178d30c247ae6de655.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 3]: /images/20221022/02222cd08f344229a2f815f30103f265.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 4]: /images/20221022/a52531e68d1042f3867408f03e9a908e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 5]: /images/20221022/730a58fd2116453087be03b1bed73270.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2gyNjA0Mzk2NzM5_size_16_color_FFFFFF_t_70 6]: /images/20221022/7818f2f38f3141ddb2850156f4ea5bc8.png