Istio—组件及其架构

文章是作者根据《云原生服务网格Istio》书 读后摘抄+自己的一些理解

1.工作机制

（1）自动注入
创建应用程序的时候自动注入Sidecar代理。在K8S场景下创建Pod的时候，Kube-apiserver调用管理面组件的Sidecar-Injector服务，自动修改应用程序的描述信息并注入Sidecar。在真正创建Pod时，在创建业务容器的同时在Pod中创建Sidecar。在真正创建Pod时，在创建业务容器的同时在Pod中创建Sidecar容器。
（2）流量拦截
在Pod初始化设置iptables规则，当有流量到来时基于配置的iptables规则拦截业务容器的Inbound流量和Outbound流量到Sidecar上，应用容器感知不到Sidecar的存在还在用原先的方式进行访问。
（3）服务发现
服务发起方的Envoy调用管理面组件Pilot的服务发现接口获取目标的服务实例列表。
（4）负载均衡
服务发起方的Envoy根据配置的负载均衡策略选择服务实例，并连接对应的实例地址
（5）流量治理
Envoy从Pilot中获取配置得流量规则，在拦截到Inbound流量和Outbound流量时执行的治理逻辑
（6）访问安全
在服务间访问时通过双方的Envoy进行双向的认证和通道加密，并基于服务的身份进行授权管理
（7）服务遥测
在服务间通信时，通信双方的Envoy都会连接管理面组件Mixer上报访问数据，并通过Mier将数据转发给对应的监控后端
（8）策略执行
在进行服务访问时，通过Mixer连接后端服务来控制服务间的访问，判断对访问是放行还是拒绝，
（9）外部访问
在网格入口处有一个Envoy扮演入口网关的角色
这里总结在一行的工程中涉及的动作和动作主题，可以将其中的每个过程都抽象成一句话：服务调用双方的Envoy代理拦截流量，并根据管理面的相关配置执行相应的治理动作，这也是istio的数据面和控制面的配合方式

2.组件介绍

（1）istio-pilot
服务列表中的istio-pilot是istio的控制中枢Pilot服务。如果把数据面的Envoy也看作一种Agent，则Pilot类似于传统C/S架构的服务端Master，下发指令控制客户端完成业务功能。和传统的微服务架构相比，Pilot至少涵盖服务注册中心和Config Sever等管理组件功能。
（2）Istio-telemetry
Istio-telemetry是专门用于收集遥测数据的Mixer服务组件。在部署上istio控制面部署了良哥Mixer组件istio-tekenetry和istio-policy，分别处理遥测数据的收集和策略的执行，查看两个容器会发现镜像是相同的，都是/istio/mixer
（3）Istio-policy
Istio-policy是另外一个Mixer服务，和istio-telemetry基本上是完全相同的机制和流程。数据面在转发服务的请求前调用istio-policy的Check接口检查是允许访问，Mixer根据配置将请求转发给对应的Adapter做对应检查，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的控制后端，对付物件的访问进行可扩展的控制。
（4）Istio-citadel
服务列表中的Istio-citadel是istio的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel一直监听Kube-apiserver，以Secret的行是为每个服务都生成证书密钥，并在Pod创建时挂载在Pod上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能，这样用户就不用在代码中维护证书密钥了。
（5）Istio-galley
Istio-galley并不直接香数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的Pilot和Mixer服务使用，这样其他管理面组件只用和Galley打交道，从而与底层平台解耦。
（6）Istio-sidecar-injector
Istio-sidecar-injector是负责自动注入的组件，只要开了自动注入，在Pod创建时就会自动调用Istio-sidecar-injector向Pod中注入Sidecar容器
在K8S环境下，根据自动注入配置，Kube-api-server在拦截到Pod创建的请求时会调用自动注入服务Istio-sidecar-injector生成Sidecar的描述并将其插入原Pod的定义中，这样，在创建的Pod内除了包括业务容器，还包括Sidecar容器，这个诸如过程对用户透明，用户使用远方是创建工作复杂
（7）Istio-proxy
Envoy、Sidecar、Proxy等术语有时混着用，都表示Istio数据面的轻量代理。但关注Pod的详细信息会发现这个容器的正是名字是istio-proxy，不是通用的Envoy镜像而是跌价了istio的proxy功能的一个扩展版本。另外在istio-proxy容器中除了有Envoy，还有一个pilot-agent的守护进程
（8）Istio-ingressgateway
Istio-ingressgateway就是入口处的Gateway，从网格外访问网格内的服务就是通过这个Gateway进行的。Istio-ingressgateway比较特别，是一个Loadbalancer类型的Service，不同于其他服务组件只有以两个端口，Istio-ingressgateway开放了一组端口，这些就是网格内服务的外部访问端口。网格入口网官Istio-ingressgateway的负载和网格内的Sidecar是同样的知兴替，也和网格内的其他Sidecar一样从Pilot处接收流量规则并执行。因为入口初的流量都走这个服务，会有较大的并发并可能出现流量峰值，所以需要评估流量来规划规格和实例数。Istio通过一个特有的资源对象Gateway来配置对外的协议、端口等
（9）其他组件
除了以istio为前缀的几个istio自有的组件，在集群中一般还会安装Jaeger-agent、Jaeger-collector、Jaeger-query、Kiali、Prometheus、Grafana、Tracing、Zipkin等组件，这些组件提供了istio的调用链、监控等功能。可以选择安装来完成完整的服务监控和管理功能

3.Istio的服务模型

Istio 官方对这几个约束的描述如下。如果从较早版本就开始关注 Istio 的话，会注意到这些约束其实已经慢慢减少了，即功能增强则约束减少，但保留了某些原理上的约束。
◎ 端口命名：对 Istio 的服务端口必须进行命名，而且名称只允许是＜protocol＞[-＜suffix＞]这种格式，其中＜protocol＞可以是tcp、http、http2、https、grpc、tls、mongo、mysql、redis等，Istio根据在端口上定义的协议来提供对应的路由能力。例如“name：http2-forecast”和“name：http”是合法的端口名，但是“name：http2forecast”是非法的端口名。如果端口未命名或者没有基于这种格式进行命名，则端口的流量会被当作TCP流量来处理。
◎ 服务关联：Pod 需要关联到服务，如果一个 Pod 属于多个 Kubernetes 服务，则要求服务不能在同
一个端口上使用不同的协议。在 Istio 0.8 之前的版本中要求一个Pod 只能属于一个 Kubernetes 服务，这种
约束更简单，也更能满足绝大多数使用要求。
◎ Deployment使用app和version标签：建议Kubernetes Deployment显式地包含app和 version 标签。每个 Deployment 都需要有一个有业务意义的 app 标签和一个表示版本的version标签。在分布式追踪时可以 通过app标签来补齐上下文信息，还可以通过app和version标签为遥测数据补齐上下文信息。

4.Istio的服务

从逻辑上看，服务是Istio主要管理的资源对象，是一个抽象概念，主要包含HostName和Ports等属性，并指定了Service的域名和端口列表。每个端口都包含端口名称、端口号和端口的协议。
从物理层面看，Istio服务的存在形式就是Kubernetes的Service，在启用了Istio的集群中创建Kubernetes的 Service时只要满足以上约束，就可以转换为 Istio的 Service并配置规则进行流量治理。
Service是Kubernetes的一个核心资源，用户通过一个域名或者虚拟的IP就能访问到后端Pod，避免向用户暴露Pod地址的问题，特别是在Kubernetes中，Pod作为一个资源创建、调度和管理的最小部署单元的封装，本来就是动态变化的，在节点删除、资源变化等多种情况下都可能被重新调度，Pod的后端地址也会随之变化。
Istio虽然依赖于了Kubernetes的Service定义，但是除了一些约束，在定位上还有些差别。在Kubernetes中，一般先通过 Deploymnent创建工作负载，再通过创建 Service关联这些工作负载，从而暴露工作负载的接口。因而看上去主体是工作负载，Service只是一种访问方式，某些后台执行的负载若不需要被访问，就不用定义Service。在Istio中，Service是治理的对象，是Istio中的核心管理实体，所以在Istio中，Service是一个提供了对外访问能力的执行体，可以将其理解为一个定义了服务的工作负载，没有访问方式的工作负载不是Istio的管理对象，Kubernetes的Service定义就是Istio服务的元数据。

5.Istio的服务版本

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

6.Istio的服务实例

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

Kubernetes提供了一个 Endpoints对象，这个 Endpoints对象的名称和 Service的名称相同，它是一个＜ Pod IP＞：＜targetPort＞列表，负责维护Service后端Pod的变化。如前面例子中介绍的，forecast服务对应如下Endpoints对象，包含两个后端Pod，后端地址分别是172.16.0.16和 172.16.0.19，当实例数量发生变化时，对应的Subsets列表中的后端数量会动态更新；同样，当某个Pod迁移时，Endpoints对象中的后端IP地址也会更新