既然有了Kubernetes，为什么还需要Istio？

如果您听说过Service Mesh并尝试过Istio，您可能会有以下问题：

为什么 Istio 运行在 Kubernetes 上？

Kubernetes 和服务网格在云原生应用架构中分别扮演什么角色？

Istio 在哪些方面对Kubernetes进行了扩展？它解决了什么问题？

Kubernetes、Envoy 和 Istio 之间是什么关系？

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

Kubernetes 本质上是通过声明性配置进行应用程序生命周期管理，而服务网格本质上是提供应用程序间流量、安全管理和可观察性。如果你已经使用 Kubernetes 搭建了一个稳定的应用平台，那么如何为服务之间的调用设置负载均衡和流量控制呢？这就是服务网格发挥作用的地方。

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

本文包含以下内容：

kube-proxy 作用的描述。

Kubernetes 对于微服务管理的局限性。

介绍 Istio 服务网格的功能。

Kubernetes、Envoy 和 Istio 服务网格中一些概念的比较。

Kubernetes 与服务网格

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

流量转发

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

服务发现

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

服务网格的缺点

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

服务网格的优点

kube-proxy 设置是全局的，无法对每个服务进行精细控制，而服务网格通过 sidecar 代理将流量控制从 Kubernetes 的服务层中取出，从而实现更大的弹性。

Kube-Proxy 的缺点

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

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

Kubernetes 社区提供了一种使用 Deployment 进行灰度发布方法，这本质上是一种通过修改 pod 标签将不同 pod 分配给部署服务的方法。

Kubernetes Ingress 与 Istio 网关

如上所述，kube-proxy 只能在 Kubernetes 集群内路由流量。Kubernetes 集群的 Pod 位于 CNI 创建的网络中。入口（在 Kubernetes 中创建的资源对象）是为了集群外部的通信而创建的。它由位于 Kubernetes 边缘节点上的入口控制器驱动，负责管理南北流量。Ingress 必须对接各种 Ingress Controller，例如nginx ingress 控制器。Ingress仅适用于HTTP流量，使用简单。它只能通过匹配有限数量的字段（例如服务、端口、HTTP 路径等）来路由流量。这使得无法路由 MySQL、Redis 和各种 RPC 等 TCP 流量。这就是为什么你会看到人们在入口资源注释中编写 nginx 配置语言。直接路由南北流量的唯一方法是使用服务的 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 基本术语。

Downstream：下游主机连接 Envoy，发送请求，接收响应；即发送请求的主机。

Upstream：上游主机接收来自 Envoy 的连接和请求并返回响应；即接收请求的主机。

Listener：Listener 是一个命名的网络地址（例如端口、UNIX 域套接字等）；下游客户端可以连接到这些侦听器。Envoy 向下游主机公开一个或多个侦听器以进行连接。

Cluster：集群是 Envoy 连接的一组逻辑上相同的上游主机。Envoy 通过服务发现来发现集群的成员。或者，可以通过主动健康检查来确定集群成员的健康状态。Envoy 通过负载均衡策略决定集群中的哪个成员来路由请求。

Envoy 中可以设置多个监听器，每个监听器可以设置一个过滤器链（过滤器链表），并且过滤器是可扩展的，以便我们可以更轻松地操纵流量的行为——例如设置加密、私有 RPC 等。

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

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

流量管理：这是Istio最基本的功能。

策略控制：启用访问控制系统、遥测捕获、配额管理、计费等。

可观察性：在 sidecar 代理中实现。

安全身份验证：Citadel 组件执行密钥和证书管理。

Istio 中的流量管理

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

网关：网关描述了运行在网络边缘的负载均衡器，用于接收传入或传出的 HTTP/TCP 连接。

VirtualService：VirtualService 实际上将 Kubernetes 服务连接到 Istio 网关。它还可以执行其他操作，例如定义一组在寻址主机时应用的流量路由规则。

DestinationRule：DestinationRule 定义的策略决定流量经过路由后的访问策略。简而言之，它定义了流量的路由方式。其中，这些策略可以定义为负载均衡配置、连接池大小和外部检测（用于识别并驱逐负载均衡池中不健康的主机）配置。

EnvoyFilter：EnvoyFilter 对象描述代理服务的过滤器，可以自定义 Istio Pilot 生成的代理配置。这种配置一般初级用户很少使用。

ServiceEntry：默认情况下，Istio 服务网格中的服务无法发现网格之外的服务。ServiceEntry 允许将其他条目添加到 Istio 内的服务注册表中，从而允许网格中自动发现的服务访问并路由到这些手动添加的服务。

Kubernetes、xDS、Istio

回顾了 Kubernetes 的 kube-proxy 组件、xDS 和 Istio 中流量管理的抽象之后，现在让我们仅在流量管理方面对这三个组件/协议进行比较（请注意，这三个组件并不完全相同）。

要点

Kubernetes 的本质是应用程序生命周期管理，特别是部署和管理（伸缩、自动恢复、发布）。

Kubernetes 为微服务提供了可扩展且高弹性的部署和管理平台。

服务网格基于透明代理，通过 sidecar 代理拦截服务之间的流量，然后通过控制平面配置管理它们的行为。

服务网格将流量管理与 Kubernetes 解耦，无需 kube-proxy 组件来支持服务网格内的流量；通过提供更接近微服务应用程序层的抽象来管理服务间流量、安全性和可观察性。

xDS 是服务网格配置的协议标准之一。

服务网格是 Kubernetes 中服务的更高级别抽象。

概括

如果说Kubernetes 管理的对象是 Pod，那么 Service Mesh 管理的对象就是服务，所以只要用 Kubernetes 来管理微服务，然后应用 Service Mesh 就可以了。如果您甚至不想管理服务，那么可以使用像Knative这样的无服务器平台。