《云原生服务网格Istio》第2章 Istio架构概述

第2章 Istio架构概述

2.1 Istio的工作机制

• 分为控制面和数据面两部分。可以看到，控制面主要包括Pilot、Mixer、Citadel等服务组件；数据面由伴随每个应用程序部署的代理程序Envoy组成，执行针对应用程序的治理逻辑
• 即观察frontend服务对 forecast 服务进行一次访问时，在 Istio 内部都发生了什么，以及 Istio 的各个组件是怎样参与其中的，分别做了哪些事情
• 虽然从时序上来讲，控制面的配置在前，数据面执行在后，但为了便于理解，在下面介绍这些动作时以数据面上的数据流为入口

• 服务调用双方的Envoy代理拦截流量，并根据管理面的相关配置执行相应的治理动作，这也是Istio的数据面和控制面的配合方式

2.2 Istio的服务模型

• 刚才介绍服务发现、负载均衡、流量治理等过程时提到了 Istio 的服务、服务版本和服务实例等几个对象。这几个对象构成了 Istio 的服务模型
• Istio几个约束描述
  • 端口命名：对 Istio 的服务端口必须进行命名，而且名称只允许是＜protocol＞[-＜suffix＞]这种格式，其中＜protocol＞可以是tcp、http、http2、https、grpc、tls、mongo、mysql、redis等，Istio根据在端口上定义的协议来提供对应的路由能力。如果端口未命名或者没有基于这种格式进行命名，则端口的流量会被当作TCP流量来处理
  • 服务关联：Pod 需要关联到服务，如果一个 Pod 属于多个 Kubernetes 服务，则要求服务不能在同一个端口上使用不同的协议
  • Deployment使用app和version标签：建议Kubernetes Deployment显式地包含app和 version 标签

2.2.1 Istio的服务

• 从逻辑上看，服务是Istio主要管理的资源对象，是一个抽象概念，主要包含HostName和Ports等属性，并指定了Service的域名和端口列表
• 从物理层面看，Istio服务的存在形式就是Kubernetes的Service
• Istio的Service比较简单，可以看到差别就是要满足Istio服务的约束，并在端口名称上指定协议

• 在 Kubernetes中，一般先通过 Deploymnent创建工作负载，再通过创建 Service关联这些工作负载，从而暴露工作负载的接口。因而看上去主体是工作负载，Service只是一种访问方式，某些后台执行的负载若不需要被访问，就不用定义Service。在Istio中，Service是治理的对象，是Istio中的核心管理实体，所以在Istio中，Service是一个提供了对外访问能力的执行体，可以将其理解为一个定义了服务的工作负载，没有访问方式的工作负载不是Istio的管理对象

2.2.2 Istio的服务版本

• 在Istio的应用场景中，灰度发布是一个重要的场景，即要求一个Service有多个不同版本的实现。而 Kubernetes在语法上不支持在一个 Deployment上定义多个版本，在 Istio中多个版本的定义是将一个Service关联到多个Deployment

• 观察和比较这两个Deployment描述文件的不同

• 多版本的Service

2.2.3 Istio的服务实例

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

• Kubernetes提供了一个 Endpoints对象，这个 Endpoints对象的名称和 Service的名称相同，它是一个＜Pod IP＞：＜targetPort＞列表，负责维护Service后端Pod的变化
• 当实例数量发生变化时对应的Subsets列表后端数量会更新；某个Pod迁移时，Endpoints对象的后端IP地址也会更新

2.3 Istio的主要组件

2.3.1 istio-pilot

• 服务列表中的 istio-pilot是 Istio的控制中枢 Pilot服务。如果把数据面的 Envoy也看作一种 Agent，则 Pilot类似传统 C/ S架构中的服务端 Master，下发指令控制客户端完成业务功能。和传统的微服务架构对比， Pilot至少涵盖服务注册中心和 Config Server等管理组件的功能

• 除了服务发现，Pilot 更重要的一个功能是向数据面下发规则，包括 VirtualService、DestinationRule、Gateway、ServiceEntry 等流量治理规则，也包括认证授权等安全规则

2.3.2 istio-telemetry

• istio-telemetry是专门用于收集遥测数据的Mixer服务组件。Istio控制面部署了两个Mixer组件：istio-telemetry和istio-policy，分别处理遥测数据的收集和策略的执行
• 当网格中的两个服务间有调用发生时，服务的代理Envoy就会上报遥测数据给 istio-telemetry 服务组件，

2.3.3 istio-policy

• 数据面在转发服务的请求前调用istio-policy的Check接口检查是否允许访问，可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制

2.3.4 istio-citadel

2.3.5 istio-galley

• Galley作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的 Pilot和 Mixer服务使用，这样其他管理面组件只用和 Galley打交道，从而与底层平台解耦。在新的版本中Galley的作用越来越核心

2.3.6 istio-sidecar-injector

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

2.3.7 istio-proxy

• 在本书和Istio的其他文档中，Envoy、Sidecar、Proxy等术语有时混着用，都表示Istio数据面的轻量代理。但关注Pod的详细信息，会发现这个容器的正式名字是istio-proxy，不是通用的Envoy镜像，而是叠加了Istio的Proxy功能的一个扩展版本。在istio-proxy容器中除了有Envoy，还有一个pilot-agent的守护进程
• Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，Envoy提供了动态服务发现、负载均衡、TLS、HTTP/2 及 gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能，
• 常用的服务访问治理规则和其执行位置

2.3.8 istio-ingressgateway

• istio-ingressgateway比较特别，是一个Loadbalancer类型的Service，不同于其他服务组件只有一两个端口，istio-ingressgateway 开放了一组端口

2.3.9 其他组件

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

2.4 本章总结

• 本章介绍了 Istio 的工作机制、服务模型和主要组件。会对Istio总体的工作机制有全局、概要的理解