在生产环境中的 Kubernetes 上运行自托管网关的指南

可用性

若要在生产环境中运行自托管网关，需要考虑几个方面。 例如，它应以高度可用的方式进行部署，使用配置备份处理临时断开连接等。

本文提供了有关如何在 Kubernetes 上为生产工作负载运行自托管网关以确保它能够顺畅可靠地运行的指导。

访问令牌

如果没有有效的访问令牌，自承载网关将无法从关联的 API 管理服务的终结点访问和下载配置数据。 访问令牌的有效期最长为 30 天。 必须在到期前重新生成令牌，并手动或通过自动化方式用新令牌配置群集。

自动刷新令牌时，请使用此管理 API 操作生成新令牌。 有关管理 Kubernetes 机密的信息，请参阅 Kubernetes 网站。

自动缩放

虽然我们提供了有关自承载网关的最小副本数的指导，但我们建议你对自承载网关使用自动缩放，以更主动地满足流量需求。

可以通过两种方式水平自动缩放自承载网关：

• 根据资源使用情况（CPU 和内存）自动缩放
• 根据每秒的请求数自动缩放

这可通过本机 Kubernetes 功能实现，或者通过使用 Kubernetes Event-driven Autoscaling (KEDA) 来实现。 KEDA 是一种 CNCF Incubation 项目，致力于简化应用程序自动缩放。

基于资源的自动缩放

借助 Kubernetes，可以使用水平 Pod 自动缩放器根据资源使用情况自动缩放自承载网关。 它使你能够定义 CPU 和内存阈值，以及要横向扩展或纵向扩展的副本数。

一种替代方法是使用 Kubernetes Event-driven Autoscaling (KEDA)，它使你能够根据各种缩放器缩放工作负载，包括 CPU 和内存。

基于流量的自动缩放

Kubernetes 不会为基于流量的自动缩放提供现成的机制。

Kubernetes Event-driven Autoscaling (KEDA) 提供了多种方法来帮助进行基于流量的自动缩放：

• 如果 Kubernetes 入口中的指标在 Prometheus 或 Azure Monitor 中可用，则可使用现成的缩放机制基于这些指标进行缩放
• 可以安装 HTTP 附加组件（在 beta 版本中提供），并根据每秒的请求数进行缩放。

配置备份

为自承载网关容器配置本地存储卷，使其能够保留最新下载配置的备份副本。 如果连接断开，则存储卷可以在重启时使用备份副本。 卷装载路径必须是 /apim/config 且必须由组 ID 1001 拥有。 请参阅 GitHub 上的示例。 若要了解 Kubernetes 中的存储，请参阅 Kubernetes 网站。 若要更改已装载路径的所有权，请参阅 Kubernetes 网站上的 securityContext.fsGroup 设置。

容器映像标记

Azure 门户中提供的 YAML 文件使用“最新”标记。 此标记始终引用自承载网关容器映像的最新版本。

请考虑在生产环境中使用特定版本的标记，以避免无意中升级到较新版本。

可以下载可用标记的完整列表。

容器资源

默认情况下，Azure 门户中提供的 YAML 文件不指定容器资源请求。

无法可靠地预测和建议每个容器 CPU 和内存资源的容量以及支持特定工作负载所需的副本数量。 有许多影响因素，例如：

• 运行群集的特定硬件。
• 虚拟化的存在情况和类型。
• 并发客户端连接的数量和速率。
• 请求速率。
• 已配置策略的种类和数量。
• 有效负载大小以及有效负载是进行缓冲还是流式传输。
• 后端服务延迟。

建议最初将资源请求设置为两个内核和 2 个 GiB。 执行负载测试并根据结果纵向/横向扩展或缩减。

自定义域名和 SSL 证书

如果对 API 管理终结点使用自定义域名，尤其是对管理终结点使用自定义域名时，你可能需要更新 <gateway-name>.yaml 文件中的 config.service.endpoint 的值，将默认域名替换为自定义域名。 请确保可以从 Kubernetes 群集中自承载网关的 pod 访问管理终结点。

在这种情况下，如果管理终结点使用的 SSL 证书不是由已知 CA 证书签名的，则必须确保自承载网关的 Pod 信任 CA 证书。

DNS 策略

DNS 名称解析对于自承载网关是否能连接到 Azure 中的依赖项并将 API 调用分派到后端服务起着关键作用。

Azure 门户中提供的 YAML 文件将应用默认的 ClusterFirst 策略。 此策略可导致群集 DNS 未解析的名称解析请求转发到从节点继承的上游 DNS 服务器。

若要了解 Kubernetes 中的名称解析，请参阅 Kubernetes 网站。 请考虑根据你的设置自定义 DNS 策略或 DNS 配置。

外部流量策略

Azure 门户中提供的 YAML 文件将externalTrafficPolicy对象上的 externalTrafficPolicy 字段设置为 Local。 这样可以保留调用方 IP 地址（可在请求上下文中访问）并禁用跨节点负载均衡，从而消除由此引起的网络跃点。 请注意，在每个节点的网关 Pod 数不相等的部署中，此设置可能导致流量的不对称分布。

高可用性

自托管网关是基础结构中的关键组件，并且必须具有高可用性。 但是，失败也可能会发生。

请考虑防范自托管网关中断。

防范节点故障

若要防止由于数据中心或节点发生故障而受到影响，请考虑使用 Kubernetes 群集，该群集使用可用性区域实现节点级别的高可用性。

借助可用性区域，可以通过使用以下内容，针对区域中的节点计划自托管网关的 pod：

• Pod 拓扑分布约束（建议 - Kubernetes v1.19+）
• Pod 反相关性

防范 pod 中断

由于手动 pod 检测、节点维护等多种原因，Pod 可能会中断。

请考虑使用 Pod 中断预算，在任何给定时间强制实现最少数量的 Pod。

HTTP(S) 代理

自托管网关通过使用传统的 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 环境变量提供对 HTTP(S) 代理的支持。

配置完成后，自托管网关将自动为后端服务的所有出站 HTTP(S) 请求使用代理。

从版本 2.1.5 或更高版本开始，自托管网关提供与请求代理相关的可观测性：

• API 检查器将在使用 HTTP(S) 代理及其相关交互时显示其他步骤。
• 提供详细日志以指示请求代理行为。

本地日志和指标

自承载网关根据关联的 API 管理服务中的配置设置，向 Azure Monitor 和 Azure Application Insights 发送遥测。 当与 Azure 的连接暂时丢失时，到 Azure 的遥测流将中断，并且在中断期间数据将丢失。

请考虑使用 Azure Monitor 容器见解监视容器或设置本地监视，以确保能够在 Azure 连接中断期间观察 API 流量并防止遥测丢失。

命名空间

Kubernetes 命名空间有助于在多个团队、项目或应用程序之间划分单个群集。 命名空间提供了资源和名称的范围。 它们可以与资源配额和访问控制策略相关联。

Azure 门户提供了在“默认”命名空间中创建自承载网关资源的命令。 此命名空间为自动创建，存在于每个群集中且无法删除。 请考虑在生产环境中将自承载网关创建和部署到单独的命名空间中。

副本数

适合生产的最小副本数为 3 个，最好与高度可用的实例计划相结合。

默认情况下，使用“RollingUpdate”部署策略部署自承载网关。 检查默认值并考虑显式设置 maxUnavailable 和 maxSurge 字段，尤其是在使用大量副本时。

性能

建议将容器日志减少为警告 (warn) 以提高性能。 有关详细信息，请参阅自承载网关配置参考。

请求限制

可以使用 API 管理 rate-limit 或 rate-limit-by-key 策略启用自承载网关中的请求限制。 通过在 Kubernetes 部署中公开以下端口来发现实例，将速率限制计数配置为在群集节点中的网关实例之间同步：

• 端口 4290 (UDP)，用于速率限制同步
• 端口 4291 (UDP)，用于将检测信号发送到其他实例

安全性

自托管网关能够在 Kubernetes 中以非 root 身份运行，因此客户可以安全地运行该网关。

以下是自托管网关容器的安全性上下文示例：

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

后续步骤

• 若要详细了解自承载网关，请参阅自承载网关概述。