基于gRPC 的无代理服务网格

2022-05-17

567

本文介绍一下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 通信的示意图

尽管不使用代理进行数据平面的通信，但它仍然需要代理来初始化和与控制平面通信。首先，代理在启动时生成一个引导文件，就像它为 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 应用程序。

性能

操作步骤