如果你听说过服务网格，并尝试过 Istio ，你可能有以下问题。

1. 为什么 Istio 要在 Kubernetes 上运行？
2. Kubernetes 和服务网格在云原生应用架构中分别扮演什么角色？
3. Istio 扩展了 Kubernetes 的哪些方面？它解决了哪些问题？
4. Kubernetes、Envoy 和 Istio 之间是什么关系？

本文将带大家了解 Kubernetes 和 Istio 的内部工作原理。此外，我会介绍 Kubernetes 中的负载均衡方法，并解释为什么有了 Kubernetes 后还需要 Istio。

Kubernetes 本质上是通过声明式配置来实现应用生命周期管理，而服务网格本质上是提供应用间的流量、安全管理和可观察性。如果你已经使用 Kubernetes 搭建了一个稳定的应用平台，那么如何设置服务间调用的负载均衡和流量控制？是否有这样一个通用的工具或者说平台（非 SDK），可以实现？这就需要用到服务网格了。

Envoy 引入了 xDS 协议，这个协议得到了各种开源软件的支持，比如 Istio、MOSN 等。Envoy 将 xDS 贡献给服务网格或云原生基础设施。Envoy 本质上是一个现代版的代理，可以通过 API 进行配置，在此基础上衍生出许多不同的使用场景–比如 API Gateway、服务网格中的 sidecar 代理和边缘代理。

本文包含以下内容。

• kube-proxy 的作用描述。
• Kubernetes 在微服务管理方面的局限性。
• Istio 服务网格的功能介绍。
• Kubernetes、Envoy 和 Istio 服务网格中一些概念的比较。

Kubernetes vs Service Mesh

下图显示了 Kubernetes 中的服务访问关系和服务网格（每个 pod 模型一个 sidecar）。

Kubernetes vs Service Mesh

流量转发

Kubernetes 集群中的每个节点都部署了一个 kube-proxy 组件，该组件与 Kubernetes API Server 进行通信，获取集群中的服务信息，然后设置 iptables 规则，将服务请求直接发送到对应的 Endpoint（属于同一组服务的 pod）。

服务发现

Service Discovery

Istio 可以跟踪 Kubernetes 中的服务注册，也可以在控制平面中通过平台适配器与其他服务发现系统对接；然后生成数据平面的配置（使用 CRD，这些配置存储在 etcd 中），数据平面的透明代理。数据平面的透明代理以 sidecar 容器的形式部署在每个应用服务的 pod 中，这些代理都需要请求控制平面同步代理配置。代理之所以 “透明”，是因为应用容器完全不知道代理的存在。过程中的 kube-proxy 组件也需要拦截流量，只不过 kube-proxy 拦截的是进出 Kubernetes 节点的流量–而 sidecar 代理拦截的是进出 pod 的流量。

服务网格的劣势

由于 Kubernetes 的每个节点上都运行着很多 pod，所以在每个 pod 中放入原有的 kube-proxy 路由转发功能，会增加响应延迟–由于 sidecar 拦截流量时跳数更多，消耗更多的资源。为了对流量进行精细化管理，将增加一系列新的抽象功能。这将进一步增加用户的学习成本，但随着技术的普及，这种情况会慢慢得到缓解。

服务网格的优势

kube-proxy 的设置是全局的，无法对每个服务进行细粒度的控制，而 service mesh 通过 sidecar proxy 的方式将 Kubernetes 中的流量控制从服务层中抽离出来–可以实现更大的弹性。

Kube-proxy 的不足之处

首先，如果转发的 pod 不能正常服务，它不会自动尝试其他 pod。每个 pod 都有一个健康检查机制，当一个 pod 出现健康问题时，kubelet 会重启 pod，kube-proxy 会删除相应的转发规则。另外，节点 Port 类型的服务不能添加 TLS 或更复杂的消息路由机制。

Kube-proxy 实现了一个 Kubernetes 服务的多个 pod 实例之间的流量负载均衡，但如何对这些服务之间的流量进行精细化控制–比如将流量按百分比划分给不同的应用版本（这些应用版本都是同一个服务的一部分，但在不同的部署上），或者做金丝雀发布（灰度发布）和蓝绿发布？

Kubernetes 社区给出了一个使用 Deployment 做金丝雀发布 的方法，本质上是通过修改 pod 的标签来给部署的服务分配不同的 pod。

Kubernetes Ingress vs Istio Gateway

如上所述，kube-proxy 只能在 Kubernetes 集群内路由流量。Kubernetes 集群的 pod 位于 CNI 创建的网络中。Ingress 是在 Kubernetes 中创建的资源对象，用于集群外部的通信。它由位于 Kubernetes 边缘节点上的入口控制器驱动，负责管理南北向流量。Ingress 必须与各种 Ingress 控制器对接，比如 nginx ingress 控制器 和 traefik 。Ingress 只适用于 HTTP 流量，使用简单。它只能通过匹配有限的字段来路由流量——如服务、端口、HTTP 路径等。这使得它无法对 TCP 流量进行路由，如 MySQL、Redis 和各种 RPC。这就是为什么你会看到人们在 ingress 资源注释中写 Nginx 配置语言的原因（注：使用 Nginx Ingress Controller 可以通过 配置 ConfigMap 和 Service 的方式 来变通支持 TCP 和 UDP 流量转发）。直接路由南北流量的唯一通行方法是使用服务的 LoadBalancer 或 NodePort，前者需要云厂商支持，后者需要额外的端口管理。

Istio Gateway 的功能与 Kubernetes Ingress 类似，它负责进出集群的南北流量。Istio Gateway 描述了一个负载均衡器，用于承载进出服务网格边缘的连接。该规范描述了一组开放端口和这些端口所使用的协议，以及用于负载均衡的 SNI 配置等。Gateway 是一个 CRD 扩展，它也重用了 sidecar 代理的功能；详细配置请参见 Istio 网站 。

Envoy

Envoy 是 Istio 中默认的 sidecar 代理。Istio 基于 Enovy 的 xDS 协议扩展了其控制平面。在讨论 Envoy 的 xDS 协议之前，我们需要先熟悉 Envoy 的基本术语。下面是 Envoy 的架构图。

Envoy 架构图

基础概念

以下是 Enovy 中你应该知道的基本术语。

• 下游。下游主机连接到 Envoy，发送请求，并接收响应，即发送请求的主机。
• 上游：上游主机。上游主机接收来自 Envoy 的连接和请求，并返回响应；即接收请求的主机。
• Listener：监听器。监听器是一个命名的网络地址（如端口、UNIX 域套接字等）；下游客户端可以连接到这些监听器。Envoy 将一个或多个监听器暴露给下游主机进行连接。
• 集群。集群是一组逻辑上相同的上游主机，Envoy 连接到它们。Envoy 通过服务发现来发现集群的成员。可以选择通过主动的健康检查来确定集群成员的健康状态。Envoy 通过负载均衡策略来决定集群中哪个成员的请求路由。

在 Envoy 中可以设置多个监听器，每个监听器可以设置一个过滤链（过滤链表），而且过滤链是可扩展的，这样我们可以更方便地操纵流量的行为–比如设置加密、私有 RPC 等。

xDS 协议是由 Envoy 提出的，是 Istio 中默认的 sidecar 代理，但只要实现了 xDS 协议，理论上也可以作为 Istio 中的 sidecar 代理 —— 比如蚂蚁集团开源的 MOSN 。

[

image

Istio 是一个功能非常丰富的服务网格，包括以下功能。

• 流量管理。这是 Istio 最基本的功能。
• 策略控制。实现访问控制系统、遥测采集、配额管理、计费等功能。
• 可观察性。在 sidecar 代理中实现。
• 安全认证。由 Citadel 组件进行密钥和证书管理。

Istio 中的流量管理

Istio 中定义了以下 CRD 来帮助用户进行流量管理。

• 网关。网关描述了一个运行在网络边缘的负载均衡器，用于接收传入或传出的 HTTP/TCP 连接。
• 虚拟服务（VirtualService）。VirtualService 实际上是将 Kubernetes 服务连接到 Istio 网关。它还可以执行额外的操作，例如定义一组流量路由规则，以便在主机寻址时应用。
• DestinationRule。DestinationRule 定义的策略决定了流量被路由后的访问策略。简单来说，它定义了流量的路由方式。其中，这些策略可以定义为负载均衡配置、连接池大小和外部检测（用于识别和驱逐负载均衡池中不健康的主机）配置。
• EnvoyFilter。EnvoyFilter 对象描述了代理服务的过滤器，可以自定义 Istio Pilot 生成的代理配置。这种配置一般很少被主用户使用。
• ServiceEntry。默认情况下，Istio 服务 Mesh 中的服务无法发现 Mesh 之外的服务。ServiceEntry 可以在 Istio 内部的服务注册表中添加额外的条目，从而允许 Mesh 中自动发现的服务访问并路由到这些手动添加的服务。

Kubernetes vs xDS vs Istio

在回顾了 Kubernetes 的 kube-proxy 组件、xDS 和 Istio 对流量管理的抽象后，现在我们仅从流量管理的角度来看看这三个组件 / 协议的比较（注意，三者并不完全等同）。

Kubernetes	xDS	Istio service mesh
Endpoint	Endpoint	WorkloadEntry
Service	Route	VirtualService
kube-proxy	Route	DestinationRule
kube-proxy	Listener	EnvoyFilter
Ingress	Listener	Gateway
Service	Cluster	ServiceEntry

核心观点

• Kubernetes 的本质是应用生命周期管理，具体来说就是部署和管理（伸缩、自动恢复、发布）。
• Kubernetes 为微服务提供了一个可扩展、高弹性的部署和管理平台。
• 服务网格是基于透明代理，通过 sidecar 代理拦截服务之间的流量，然后通过控制平面配置管理它们的行为。
• 服务网格将流量管理与 Kubernetes 解耦，不需要 kube-proxy 组件来支持服务网格内的流量；通过提供更接近微服务应用层的抽象来管理服务间的流量、安全性和可观察性。
• xDS 是服务网格的协议标准之一。
• 服务网格是 Kubernetes 中服务的一个更高层次的抽象。

总结

如果说 Kubernetes 管理的对象是一个 pod，那么服务网格管理的对象就是一个服务，所以用 Kubernetes 管理微服务，然后应用服务网格就可以了。如果你连服务都不想管理，那就用 Knative 这样的无服务器平台，不过这是后话