文章目录

• 一、什么是服务网格 Service Mesh
• • 1.1 主要概念
  • • 1.1.1、容器组织框架(Container orchestratiob framework )
    • 1.1.2、Service 与 Service 实例(Service Instance )
    • 1.1.3、Sidecar 代理(Sidecar Proxy)
    • 1.1.4、服务发现(Service discovery)
    • 1.1.5、负载均衡(Load balancing)
    • 1.1.6、加密(Encryption)
    • 1.1.7、认证与权限(Authentication and Authorization)
    • 1.1.8、支持熔断器模式(Support for the circuit breaker pattern)
• 二、什么是 Istio
• 三、Istio 的核心组件
• • 3.1、Pilot
  • 3.2、Mixer
  • 3.3、Citadel
  • 3.4、Sidecar (Envoy)

一、什么是服务网格 Service Mesh

服务网格(Service Mesh)，最早使用由开发 Linkerd 的 Buoyant 公司提出，并在内部使用。

2016 年 9 月 29 日第一次公开使用这个术语。

2017 年的时候随着 Linkerd 的传入，Service Mesh 进入国内技术社区的视野。

服务网格( Service Mesh )是指用于微服务应用的可配置基础架构层，功能在于处理服务间通信，职责是负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。

服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式等一系列功能。

1.1 主要概念

1.1.1、容器组织框架(Container orchestratiob framework )

容器组织框架用于监控和管理一系列容器的独立工具。

1.1.2、Service 与 Service 实例(Service Instance )

确切来讲，开发者创建的并非是一个 Service，而是一个由 Service 定义的或者框架定义的实例。

1.1.3、Sidecar 代理(Sidecar Proxy)

Sidecar Proxy 指专注于每个具体的 Service 实例的一个代理实例。它与其他的 Sidecar Proxy 通讯并由容器组织框架( 比如 Kubernetes )进行统一管理。

1.1.4、服务发现(Service discovery)

当一个实例需要与其他 Service 进行通讯时，它需要寻找并发现( find & discovery )另一个健康、可用的 Service 实例。容器管理框架( container managment framework ) 维护着一个时刻准备接收请求的实例列表。

1.1.5、负载均衡(Load balancing)

在一个服务网格中，负载均衡自底向上工作。由服务网格维护的可用实例列表可以进行打分、评级、并选出“最闲”的 Service，这就是在高层次上的负载均衡。

1.1.6、加密(Encryption)

服务网格可以加密和解密服务间的请求与响应，并从 Service 中将这些步骤分离，从而减轻每个 Service 内的负担。服务网格可以通过优先再利用已经存在的、持续的连接(connection) 来提高性能，以便减少重新建立连接时的计算开销。

1.1.7、认证与权限(Authentication and Authorization)

服务网格可以授权并认证从外来的或是 app 内服的各种请求，并且只发送那些有效的请求给 Service。

1.1.8、支持熔断器模式(Support for the circuit breaker pattern)

服务网格能够支持熔断器模式，它能隔离那些不健康的实例，并逐渐将那些有保证的实例再次添加进健康实例池( healthy instance pool )。

二、什么是 Istio

Istio 2017 年由 Google，IBM 和 Lyft 联合推出，初始的设计目标是在 Kubernetes 基础之上，以非侵入式的方式为运行在集群中的微服务提供流量管理、安全加固、服务监控和策略管理等功能。

换言之，Istio 是运行在分布式应用程序之上的 非侵入式（无代码入侵）的服务网格系统，是一套非侵入式一站式服务治理解决方案。

Istio 的目的：更好的解决服务治理问题。

实现原理：为每一个微服务部署一个 Sidecar，代理微服务之间的所有网络通信。

Connect, secure, control, and observe services.

连接、安全加固、控制和观察服务的开放平台。

• 连接：对网格内部的服务之间的调用所产生的流量进行智能管理，并以此为基础，为微服务的部署、测试和升级的操作提供保障。
• 安全：为网格内部的服务之间的调用提供认证、加密和鉴权支持，在不侵入代码的情况下，提高安全性。
• 控制：在控制面定制策略，在服务中实施。
• 观察：对服务之间的调用进行跟踪和测量，获取服务的状态信息。

三、Istio 的核心组件

Istio 主要分为两大部分

• 数据平面，称为 SideCar，可以想象成是旧式三轮摩托车的挂斗。Sidecar 通过注入的方式和业务容器共存在同一个 Pod 中，一方面，可以实现对业务容器流量的监控；另一方面，受到控制面组件的控制，会向控制面输出日志、跟踪和监控数据。
• 控制平面，Istio 的核心，管理 Istio 的所有功能。控制面的主要组件包括 Pilot、Citadel、Mixer、Gallery

官网给出的 Istio 架构图：

图中的 Proxy 就是 Sidecar 模式的代理实例。

3.1、Pilot

Pilot 是 Istio 的主要控制点，用于管理 Istio 的流量，具体的流量劫持是通过 Sidecar 实现的。

Pilot 的主要任务：

• 从注册中心获取服务信息，完成服务发现过程；
• 读取 Istio 的各项控制配置，转化之后发送给数据面进行实施。

Pilot 的工作示意：

• 用户通过 kubectl 或 istioctl 在 Kubernetes 上创建 CRD 资源，对 Istio 的控制平面发出指令；
• Pilot 监听 CRD 中的 config、rbac、networking 以及 authentication 资源，检测到资源对象变更之后，针对设计到的服务（Service），将指令发送给对应 Service 的 Sidecar；
• Sidecar 根据指令更新自身配置，更新配置修正通信行为。

3.2、Mixer

Mixer 的主要任务：

• 预检
• 汇报

Mixer 的工作流程：

• 用户将 Mixer 的配置发送到 Kubernetes 中；
• Mixer 通过对 Kubernetes 资源的监听，获取配置的变化；
• 网格中服务在调用前，都会向 Mixer 发出预检请求，查看调用是否允许执行。在每次调用之后，也都会发出报告信息，向 Mixer 汇报在调用过程中产生的监控跟踪数据。

3.3、Citadel

Citadel 是堡垒的意思，在 Istio 中用于证书管理。

集群中启用服务之间的加密之后，Citadel 负责为集群中的各个服务在统一的 CA 条件下生成证书，并发送给各个服务的 Sidecar，服务之间的 TLS 依赖这些证书完成校验过程。

3.4、Sidecar (Envoy)

Sidecar 是 Istio 中的数据面，负责控制面对网格控制的实际执行。

默认的 Sidecar 是由 Envoy 派生出来的，其他类似的反向代理软件也可以代替 Envoy 担当这一角色。

Sidecar 如何实现流量劫持？

在 Istio 的默认实现中， Istio 利用 istio-init 初始化容器中的 iptables 指令，对所在的 Pod 的流量进行劫持，从而接管 Pod 中应用的通信过程，这样就获得了通信的控制权，达到控制面控制的最终目的。

在 Kubernetes 的 Pod 内，多个容器之间共享网络，这也是 Sidecar 实现流量劫持的基础。Sidecar 在加入 Pod 之后，原来的源容器 → 目的容器的直接通信方式，多经历了从 Sidecar 中转发的一层，这样使得通信过程中的控制和观察成为可能。