基于gRPC 的无代理服务网格

2022-05-17

89

本文介绍一下Istio对gRPC的无代理服务网格功能的支持。

Istio 使用一组 API(统称为xDS API)动态配置其 Envoy sidecar 代理。这些 API 旨在成为通用数据平面。gRPC 项目对 xDS API 有重要的支持,这意味着您可以管理 gRPC 工作负载,而无需在工作负载中部署 Envoy sidecar。您可以在Megan Yahya的KubeCon EU2021演讲中了解有关集成的更多信息 。gRPC 支持的最新更新可以在他们的提案中找到。

Istio 1.11 增加了将 gRPC 服务直接添加到网格的实验性支持。我们支持基本的服务发现、一些基于 VirtualService 的流量策略和双向 TLS。


支持的功能

与 Envoy 相比,gRPC 中 xDS API 的当前实现在某些领域受到限制。以下功能应该可以使用,尽管这不是一个详尽的列表,并且其他功能可能具有部分功能:

基本服务发现。您的 gRPC 服务可以访问网格中注册的其他 pod 和虚拟机。


  • DestinationRule:
    • Subsets:您的 gRPC 服务可以根据标签选择器将流量拆分到不同的实例组。
    • 当前唯一loadBalancer支持的 Istio 是ROUND_ROBIN,consistentHash将在 Istio 的未来版本中添加(它由 gRPC 支持)。
    • tls设置仅限于DISABLE或ISTIO_MUTUAL。其他模式将被视为DISABLE.
  • VirtualService:
    • Header匹配和 URI 格式匹配/ServiceName/RPCName。
    • 重写destination host 和Subsets。
    • 加权流量转移。
  • PeerAuthentication:
    • 仅支持DISABLE和STRICT。其他模式将被视为DISABLE.
    • 未来版本中可能会支持自动 mTLS。


未来版本可能支持其他功能,包括故障、重试、超时、镜像和重写规则。其中一些功能正在等待 gRPC 中的实现,而其他功能则需要在 Istio 中进行支持。gRPC 中 xDS 功能的状态可以在官方github仓库中找到(https://github.com/grpc/grpc/blob/master/doc/grpc_xds_features.md)。Istio 的支持状态将在未来的官方文档中存在。

这些功能是实验性的。随着时间的推移,标准 Istio 功能将随着整体设计的改进而得到支持。


架构概述

gRPC 服务如何与 istiod 通信的示意图

gRPC 服务如何与 istiod 通信的示意图


尽管不使用代理进行数据平面的通信,但它仍然需要代理来初始化和与控制平面通信。首先,代理在启动时生成一个引导文件,就像它为 Envoy 生成引导程序一样。这告诉gRPC库如何连接istiod,它可以在哪里找到数据平面通信的证书,以及要发送到控制平面的元数据。接下来,代理充当xDS代理,istiod代表应用程序连接和验证。最后,代理获取并轮换数据平面流量中使用的证书。


更改应用程序代码

本节介绍 gRPC 在 Go 中的 XDS 支持。其他语言也有类似的 API。


要在 gRPC 中启用 xDS 功能,您的应用程序必须进行一些必要的更改。您的 gRPC 版本至少应为1.39.0.


更改客户端

导入将在 gRPC 中注册 xDS 解析器和平衡器。它应该添加到您的 main包中或在同一个包中调用grpc.Dial.

更改客户端


创建 gRPC 连接时,URL 必须使用该xds:///方案。


此外,对于 (m)TLS 支持,必须将一个特殊TransportCredentials选项传递给DialContext. 允许我们在FallbackCredsistiod 不发送安全配置时成功。


更改服务器端

要支持服务器端配置,例如 mTLS,必须进行一些修改。


首先,我们使用一个特殊的构造函数来创建GRPCServer:


如果您protoc生成的 Go 代码已过期,您可能需要重新生成它以与 xDS 服务器兼容。您生成RegisterFooServer的函数应如下所示:


最后,与客户端更改一样,我们必须启用安全支持:


Kubernetes 部署

假设你的应用程序代码是兼容的,Pod 只需要注解inject.istio.io/templates: grpc-agent。这会添加一个运行上述代理的 sidecar 容器,以及 gRPC 用于查找引导文件和启用某些功能的一些环境变量。

对于 gRPC 服务器,您的 Pod 也应该被注释proxy.istio.io/config: '{"holdApplicationUntilProxyStarts": true}' 以确保在初始化 gRPC 服务器之前代理内 xDS 代理和引导文件已准备好。


例子

在本指南中,您将部署echo,一个已经支持服务器端和客户端无代理 gRPC 的应用程序。使用此应用程序,您可以尝试配置一些支持 mTLS 的流量策略。


先决条件

本指南要求在继续之前安装Istio (1.11+) 控制平面。


部署应用程序

创建一个启用注入的命名空间echo-grpc。接下来部署应用程序和服务的两个实例echo。


确保两个 pod 正在运行:


测试 gRPC 解析器

首先,端口转发17171到其中一个 Pod。此端口是非 xDS 支持的 gRPC 服务器,允许从端口转发的 Pod 发出请求。


接下来,我们可以一次发起 5 个请求:


您还可以对短名称使用类似 Kubernetes 的域名解析:


使用DestinationRule创建Subsets

首先,为每个版本的工作负载创建一个Subset。


配置VirtualService策略

使用上面定义的子集,您可以将 80% 的流量发送到特定版本:


现在,发送一组共 10 个请求:


响应应主要包含v2响应:


启用 mTLS

由于在 gRPC 中启用安全性需要对应用程序本身进行更改,所以 Istio 自动检测 mTLS 支持的传统方法是不可靠的。因此,初始版本需要在客户端和服务器上显式启用 mTLS。


要启用客户端 mTLS,请应用DestinationRulewithtls设置:


现在尝试调用尚未为 mTLS 配置的服务器将失败。


要启用服务器端 mTLS,请应用PeerAuthentication.

以下策略强制对整个命名空间使用 STRICT mTLS。


应用策略后,请求将开始成功。


限制

初始版本有几个限制,可能会在未来的版本中修复:


  • 不支持自动mTLS,也不支持许可模式。相反,我们需要在服务器上使用STRICT,在客户端使用ISTIO_MUTUAL的明确mTLS配置。Envoy能够在迁移的过程中使用STRICT模式。
  • grpc.Serve(listener)或grpc.Dial("xds:///...")在编写引导程序或 xDS 代理准备好之前调用可能会导致失败。holdApplicationUntilProxyStarts可以用来解决这个问题,或许应用程序可以更健壮地应对这些故障。
  • 如果支持xDS的gRPC服务器使用mTLS,那么你将需要确保你的健康检查可以绕过这个问题。要么使用一个单独的端口,要么你的健康检查客户端需要一种方法来获得适当的客户端证书。
  • 如果gRPC 中 xDS 的实现与 Envoy 版本不匹配。某些行为可能会有所不同,并且某些功能可能会丢失。gRPC的功能状态提供了更多详细信息。确保测试任何 Istio 配置实际上适用于您的无代理 gRPC 应用程序。


性能

操作步骤


  • 使用基于 Go 的负载测试应用程序 Fortio
    • 稍作修改,以支持 gRPC 的 XDS 功能 (PR)
  • 资源:
    • 具有 3 个节点的 GKE 1.20 集群e2-standard-16(每个节点 16 个 CPU + 64 GB 内存)
    • Fortio 客户端和服务器应用程序:1.5 个 vCPU,1000 MiB 内存
    • Sidecar(istio-agent 和可能的 Envoy 代理):1 个 vCPU,512 MiB 内存
  • 测试的工作负载类型:
    • 基线:没有使用 Envoy 代理或无代理 xDS 的常规 gRPC
    • Envoy:标准 istio-agent + Envoy 代理 sidecar
    • 无代理:gRPCxds:///在客户端使用 xDS gRPC 服务器实现和解析器
    • PeerAuthentication通过和启用/禁用 mTLSDestinationRule



潜伏

p50延迟对比图


p99延迟对比图


使用无代理 gRPC 解析器时延迟略有增加。与 Envoy 相比,这是一个巨大的改进,仍然允许高级流量管理功能和 mTLS。


istio-proxy 容器资源使用情况



尽管我们仍然需要一个代理,但该代理只使用了不到 0.1% 的完整 vCPU,并且只有 25 MiB 的内存,这还不到运行 Envoy 所需内存的一半。

这些指标不包括 gRPC 在应用程序容器中的额外资源使用情况,主要用于展示在此模式下运行时 istio-agent 对资源使用的影响。


--------------------------------------------------------

行云创新

· 全国领先的一站式云原生开发平台厂商,国家高新技术企业

· 上汽、格力、华为、中信银行等各行业头部企业信赖

· 阿里云战略投资企业

行云创新是云原生领域的佼佼者,其产品在广西贵港智慧城市、长三角产学研一体化创新平台、海尔工业互联网、中信银行核心系统建设等项目中起到关键的支撑作用。同时,作为信创工委会成员,行云打造业界领先的“信创与非信创统管、一键向信创迁移”的方案,并在某大型国有银行取得了良好的实践效果。


SolarMesh,高效可视化微服务治理平台

基于 Istio 及容器技术,提供流量监控和管理,提供完善的非侵入式服务治理解决方案。帮助企业在纷繁复杂的微服务调度中快速定位问题,增强研发效率。

SolarMesh,让服务网格不再难学难用,让服务网格在企业落地更加平滑、安全、稳定。


SolarMesh,社区版免费下载地址>


-----------------------------------------------------


原文出处:Istio官方 https://istio.io/latest/blog/2021/proxyless-grpc/



技术交流
我们建了一个云原生技术交流群,里面有来自Oracle、Citrix、华为、腾讯等国内外云计算专家,立即扫码,拉你进群。目前已有1000+开发者加入我们......
云原生厂商 云原生技术服务商
在云原生时代,行云创新致力于通过赋能开发者,实现企业快速迭代与交付,大幅提升创新效率。
免费试用