云原生核心技术之Istio服务网格核心理论概念

Istio服务网格核心理论概念

1.Service Mesh基本概念

1.1.什么是Service Mesh服务网格

在熟悉和使用Istio之前首先要了解什么是Service Mesh。

Service Mesh即为 “服务网格” ，是用于处理服务与服务之间通信的基础设施层，主要负责为复杂构建的云原生应用提供一个可靠网络传递请求，并为微服务通信实现了基本的功能，例如服务发现、负载均衡、监控、流量管理、访问控制等等。

服务网格通常是将一个应用程序与一个代理程序部署在一起，并进行关联，对于应用程序来说是透明的，所有的请求都是由代理程序进行处理。

如下图所示：整张图好比是微服务应用，每一个方框都可以看作是一个微服务程序，其中绿框表示具体的应用，蓝框表示代理程序（Sidecar Proxy），各个微服务之间的通信都是通过代理程序完成的，图中的蓝线就表示各个微服务程序之间的通信路线，整张图看起来就像是错综复杂的网格，这也就是服务网格名称的由来。

1.2.服务网格的特点

• 微服务治理能力
• 应用程序无感知
• 服务通信的基础设置层
• 解耦应用程序的重试/超市、监控、追踪和服务发现

Service Mesh服务网格主要是方便管理微服务而诞生的，在微服务环境中，少到几个微服务程序多到上百个微服务应用程序，使用传统模式时，需要为不同的微服务程序分别配置代理，当微服务数量庞大时运维的成本会大大提高，并且不易管理，当使用服务网格后，每一个微服务程序都会关联一个代理程序，所有的流量请求都有代理程序处理，并且服务网格具备控制中心概念，所有的代理程序均通过控制中心进行统一管理，减少人工维护的成本。

以Sidecar代理程序为例，既然所有的流量请求都是有服务网格中的代理程序处理，那么可以做到的事情就非常之多了。

• 微服务的的治理能力：每一个微服务程序都会关联一个Sidecar代理程序，所有的进出流量都有Sidecar处理。
• 应用程序无感知：每个应用程序虽然都需要关联一个代理程序，但是无需修改程序代码，程序与代理是通过标签进行关联绑定的。
• 服务通信的基础设施层：使用网格后，应用程序不会直接进行通信，所有通信由代理程序处理，避免超时导致无法通信，保障了基础的通信设施
• 解耦应用程序：使用网格后，所有的请求、流量控制都有代理程序处理，从一定角度上实现了应用程序的解耦，既然所有的请求都由代理程序来出来，从运维成本上难度也大大降低，我们可以直接从代理程序中获取流量监控、各链路之间的追踪以及监控。

服务网格中的代理相较于传统代理，底层实现都是相同的，不过服务网格中有控制中心，可以统一的管理各个应用的代理程序。

1.3.服务网格与传统代理的不同

Service Mesh服务网格的代理与传统的代理程序并不相同，服务网格是基于传统代理程序之上的一个更加高级的概念，另外传统代理是面向单一应用的，服务网格是面向分布式的代理环境并且具备统一管理的能力。

• 服务网格
  • 分布式代理场景，每个应用程序都会关联一个代理程序，各应用之间都通过代理程序进行通信，所有的流量都会被代理程序处理，服务网格中有控制中心，由控制中心统一管理服务网格中所有的代理程序。
• 传统代理程序
  • 单体服务，所有的请求先通过代理在转发到实际的后端程序，即一个应用程序一个代理程序，各代理程序需要手动配置，手动管理。

2.Istio基本理论概念

2.1.Istio服务网格介绍

ServiceMesh服务网格的产品有很多，世界上第一个服务网格产品是Linkerd。

Istio是目前非常主流的服务网格产品，功能丰富，成熟度高，Istio 解决了开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战。

目前应用程序都是部署在K8S集群进行管理，而微服务程序也使用Pod控制器去部署，部署使用是没有问题的，但是想更加细腻的管理微服务程序，比如流量的控制、链路状态跟踪、速率限制等等这些功能，K8S是无法满足的，因此就需要使用服务网格去管理微服务程序，在企业中最常用的方案就是将Istio与K8S结合起来使用，K8S主要负责应用的部署、弹性伸缩、资源隔离，Istio主要负责微服务治理、流量监控、熔断限流、动态路由、链路追踪等功能，两者可以完美的取长补短。

Istio有四个代名词：

• 连接（Connect）
  • 智能的实现流量的管理、负载均衡，以及程序的灰度发布。
• 安全加固（Secure）
  • 所有的流量都是由代理程序管理，因此可以对接收的流量自动做一些认证和鉴权方面的处理。
• 控制（Control）
  • 可以根据流量做一些访问控制的操作。
• 观察（Observe）
  • 可以监控服务器运行期间的各种数据，比如日志、链路监控、流量监控。

2.2.Istio版本架构方面的变化

Istio在1.5版本时架构发生了重大变化，主要是针对控制平面架构的变化，1.5版本之前部署Istio需要安装很多组件，并且在使用环境中个别组件也很容易出现故障，复杂性极高，在1.5及以后的版本中，Istio将原有的很多个组件整合成了单体结构也就是Istiod服务，同事将1.5版本之前的mixer组件废弃，将mixer部分功能集成到了Istiod中。

Istiod服务中也包含了pliot、citadel、Galley等主要组件的功能，架构变成单体结构后复杂性大大降低。

2.3.Istio服务网格组件介绍

控制平台组件

• Pilot
  • 流量管理组件，是Istio中最主要的控制组件，Pilot组件为Envoy Sidecar提供服务发现的功能，为智能路由（金丝雀部署、A/B测试）和流量处理（超时、重试、熔断限流）等提供流量管理能力。
  • Pilot组件还可以向数据层面下发治理规则，代理程序的配置等等。
• Citadel
  • 安全组件，提供证书生成以及下发、加密通信和访问控制。
• Galley
  • 配置管理组件，验证配置信息的格式和内容的正确性，将配置信息分发到其他的组件。
• Ingressgateway
  • Istio服务网格的网关组件，从网格外部访问网格内的服务都是通过Gateway实现的，Istio的Gateway程序是一个LoadBlancer类型的service资源，该service资源开放了一组端口，这些端口就是网格服务的外部访问端口。

数据平台组件

• Proxy
  • 负责微服务网络通信，每一个应用程序都会关联一个Sidecar Proxy，在Istio中称为envoy，由代理程序进行流量转发。
  • Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，Envoy提供了动态服务发现、负载均 衡、TLS、HTTP/2 及 gRPC代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能，大部分治理能力最终都落实到 Envoy的实现上。

2.4.Istio服务网格功能特性

• 自动注入
  • 创建应用程序时会自动注入Sidecar代理envoy程序，在K8S集群中创建Pod时，kube-apiserver组件会调用Istio控制平面的sidecar-injecor服务服务，自动修改应用程序的描述信息并注入Sidecar代理程序，即在创建业务容器的同时也创建Sidecar容器。
• 流量拦截
  • 对于应用程序是无感知的，Istio会在pod初始化时修改iptables规则，基于配置的iptables规则拦截Inbound和Outbound流量到Sidecar代理程序中，从而实现流量的拦截。
• 服务发现
  • 服务发起方的Sidecar代理程序会调用Istio控制平面的pilot组件的服务发现接口从而获取目标服务的实例列表。
• 负载均衡
  • 服务发起方的Sidecar代理程序会根据配置的负载均衡策略将同一应用程序的其他实例连接形成负载均衡。
• 流量治理
  • 代理程序会从pilot组件中获取配置的流量规则，在进行流量处理时执行治理逻辑。
• 访问安全
  • 各个微服务之间的访问都会通过代理程序进行通信，双方的代理程序都会进行双向认证和通道加密，也可以基于服务的身份进行授权管理。
• 服务监测
  • 所有的流量请求都由Sidecar代理程序处理，可以很好的做到服务监测。

2.5.Istio配置资源

Istio有4个配置资源，也就是控制器类型。

• VirtualService：虚拟服务，实现服务请求的路由规则功能，主要是将gateway的请求转发到对应的后端service中。
• DestinationRule：目标规则，实现目标服务的负载均衡、服务发现、故障处理和故障注入的功能。
• Gateway：让服务网格中的应用程序对外发布。
• ServiceEntry：服务入口，允许管理网格外的服务流量。