跳到主要内容
版本:3.9.x

使用 Azure Blob Storage 实现数据面高可用

在本指南中,你将学习如何在 API7 企业版中使用 Azure Blob Storage 作为外部配置存储,来配置数据面(DP)的高可用性。API7 支持两种验证网关节点以访问 Blob Storage 的方法:

  1. Workload Identity – 使用用户分配的托管身份(user-assigned managed identity),为网关 Pod 授予安全的访问权限,无需使用静态凭证。
  2. Storage Account Access Key – 使用存储账户(storage account)名称和密钥进行身份验证。

这两种方法都允许网关节点在控制面(CP)不可用时,从外部存储中获取配置并继续处理流量。

使用 Workload Identity

此方法利用用户分配的 Azure 托管身份,允许 API7 网关 Pod 安全地访问 Blob Storage,而无需在配置中嵌入静态凭证。

准备 Azure 资源

你需要在 Azure 上准备以下资源:

  • 一个包含所有相关资源的资源组(resource group)。
  • 一个用于部署 API7 网关实例的 AKS 集群。
  • 一个 Azure 存储账户(storage account)。
  • 在该存储账户中创建的两个 Blob 容器:
    • 一个容器用于存储网关组的动态配置,例如 keyring(密钥环)和发现数据。
    • 一个容器用于存储网关资源配置,例如路由(routes)和服务(services)。
  • 一个用户分配的托管身份(user-assigned managed identity),用于 Workload Identity 和 Service Connector 配置。
  • 一个通过 Service Connector 创建的服务连接,用于将 AKS 集群安全连接到 Azure Storage。

资源组

资源组是用于管理 Azure 资源的逻辑容器。

创建一个自定义名称的 Azure 资源组,用于存放所有相关资源。关于创建资源组的详细说明,请参考官方 Azure 文档:Azure CLIAzure Portal

AKS 集群

Azure Kubernetes Service(AKS)提供了一个托管的 Kubernetes 环境,用于部署和运行 API7 企业版网关实例,包括流量网关节点(traffic gateway nodes)和备份网关节点(backup gateway node)。

在前面创建的资源组中创建一个 AKS 集群。

An AKS cluster

关于创建集群的详细说明,请参考官方 Azure 文档:Azure CLIAzure Portal

Azure 存储账户和 Blob 容器

创建一个 Azure 存储账户,用于存储 API7 企业版网关实例的配置数据。

Storage account

在存储账户中,创建两个 Blob 容器(以下容器名称仅为示例):

  1. fallback-cp-data - 用于备份网关组的动态配置,例如 keyring 和发现数据。
  2. fallback-cp-config - 用于备份网关资源配置,例如路由和服务。

稍后在部署网关时将会引用该存储账户和容器名称。

Two Blob containers

关于创建存储账户和 Blob 容器的详细说明,请参考官方 Azure 文档:Azure Storage 账户Blob 容器

托管身份

创建一个用户分配的托管身份,以启用 AKS 工作负载的 Workload Identity。在创建 Service Connector 时将使用此身份,从而允许网关实例无需使用静态凭证即可安全地向 Azure 资源进行身份验证。

A managed identity

关于创建用户分配托管身份的详细说明,请参考官方 Azure 文档:Azure CLIAzure Portal

服务连接

使用 Azure Service Connector 创建一个服务连接,将 AKS 集群与 Azure 存储账户安全地链接起来。此连接允许 API7 企业版网关实例使用用户分配的托管身份访问 Blob 容器,而无需配置静态凭证。

按照官方 Azure 文档 使用 Service Connector 创建服务连接 中的说明进行操作。

important

请确保服务连接配置在与部署网关实例相同的 Kubernetes 命名空间内。

Service Connection Basics tab configuration

Service Connection Authentication tab configuration

创建连接后,Service Connector 页面会显示有关新连接的详细信息,包括服务账号(service account)和密钥(secret)名称。

Service connection information

记下 Kubernetes 服务账号和密钥名称,以及 Service Connector 提供的环境变量名称:

# Kubernetes 服务账号和密钥名称
sc-api7cpfallbackblob-secret
sc-account-192b25f6-3b23-44a5-9157-efa0954b8f30

# Service Connector 提供的相应环境变量
AZURE_STORAGEBLOB_RESOURCEENDPOINT # Blob 存储资源端点 URL
AZURE_STORAGEBLOB_CLIENTID # 用于身份验证的托管身份客户端 ID

部署备份网关节点

在 API7 控制台(Dashboard)中,进入 网关实例(Gateway Instances)> 添加网关实例(Add Gateway Instance)。切换到 Kubernetes 选项卡,并在生成部署脚本之前填写以下详细信息:

  • 自定义 Helm 发布名称。
  • 指定网关将要部署的命名空间。
  • 指定 Azure Service Connector 生成的 Kubernetes 服务账号。

Backup gateway node details

点击 生成(Generate) 来生成部署脚本。你应该能看到 serviceAccount.name 已经设置在了 helm upgrade 命令中。接下来,手动将下方高亮的 --set 标志添加到 helm upgrade 命令中:

helm upgrade --install -n default --create-namespace api7-backup-gateway-node api7/gateway \
--set ... \ # other parameters
--set "serviceAccount.name=sc-account-192b25f6-3b23-44a5-9157-efa0954b8f30" \
--set "apisix.extraEnvVarsSecret=sc-api7cpfallbackblob-secret" \
--set 'apisix.podLabels.azure\.workload\.identity\/use=true' \
--set "nginx.envs[0]=AZURE_STORAGEBLOB_RESOURCEENDPOINT" \
--set "nginx.envs[1]=AZURE_STORAGEBLOB_CLIENTID" \
--set "deployment.fallback_cp.interval=60" \
--set "deployment.fallback_cp.mode=write" \
--set "deployment.fallback_cp.azure_blob.account_name=fallbackcpdocs" \
--set "deployment.fallback_cp.azure_blob.resource_container=fallback-cp-data" \
--set "deployment.fallback_cp.azure_blob.config_container=fallback-cp-config"

❶ 将 Service Connector 创建的 Kubernetes Secret 中的环境变量注入网关 Pod。请使用你的服务连接中的 Kubernetes Secret 名称进行更新。

❷ 添加所需的 Pod 标签以启用网关 Pod 的 Azure Workload Identity。

❸ 将 Azure Blob Storage 资源端点和客户端 ID 作为环境变量暴露给 NGINX。

❹ 以秒为单位配置配置备份的时间间隔。

❺ 将网关配置为备用写入模式,允许其定期将从控制面(CP)获取的配置导出到外部存储。

❻ 指定用于存储回退 CP 配置的 Azure 存储账户名称。请将其更新为你在服务连接中使用的存储账户名称。

❼ 指定存储资源和配置数据的 Blob 容器名称。

在 Azure Portal 中,导航至你的 AKS 集群,按照门户上的说明连接集群,然后运行更新后的部署脚本来部署备份网关节点。

检查 Pod 的状态和日志,确保没有与 Azure Blob 容器连接相关的错误。

验证

在本节中,你将验证配置数据是否已成功备份到 Blob 容器,并确保在控制面(CP)不可用时,流量网关节点能够使用回退配置继续运行。

检查 Blob 容器中的数据备份

在 Azure Portal 中,导航至你的 Azure 存储账户并打开相应的容器。验证数据是否已写入 fallback-cp-datafallback-cp-config 容器中。

fallback-cp-data container file

fallback-cp-config container file

你应该能看到备份网关节点定期更新了配置文件,这表明从控制面(CP)获取的配置已被成功备份。

确保流量网关节点使用回退配置

假设控制面(CP)变得不可用,你需要将数据面(DP)的流量节点配置为从外部存储获取配置。

无论你是更新现有的流量网关节点还是启动新的节点,都可以从 API7 控制台生成部署脚本,并在 helm upgrade 命令中手动添加以下高亮的 --set 标志:

helm upgrade --install -n default --create-namespace api7-traffic-gateway-node api7/gateway \
--set ... \ # other parameters
--set "etcd.host[0]=https://INVALID_DOMAIN:7943" \
--set "serviceAccount.name=sc-account-192b25f6-3b23-44a5-9157-efa0954b8f30" \
--set "apisix.extraEnvVarsSecret=sc-api7cpfallbackblob-secret" \
--set 'apisix.podLabels.azure\.workload\.identity\/use=true' \
--set "nginx.envs[0]=AZURE_STORAGEBLOB_RESOURCEENDPOINT" \
--set "nginx.envs[1]=AZURE_STORAGEBLOB_CLIENTID" \
--set "deployment.fallback_cp.azure_blob.account_name=fallbackcpdocs" \
--set "deployment.fallback_cp.azure_blob.resource_container=fallback-cp-data" \
--set "deployment.fallback_cp.azure_blob.config_container=fallback-cp-config"

❶ 通过设置一个无效的 ETCD 主机来模拟控制面(CP)不可用的情况。

❷ 指定由 Azure Service Connector 创建的 Kubernetes 服务账号。请更新为你的服务账号名称。

❸ 将 Service Connector 创建的 Kubernetes Secret 中的环境变量注入网关 Pod。请使用你的服务连接中的 Kubernetes Secret 名称进行更新。

❹ 添加所需的 Pod 标签以启用网关 Pod 的 Azure Workload Identity。

❺ 将 Azure Blob Storage 资源端点和客户端 ID 作为环境变量暴露给 NGINX。

❻ 指定用于存储回退 CP 配置的 Azure 存储账户名称。请将其更新为你在服务连接中使用的存储账户名称。

❼ 指定存储资源和配置数据的 Blob 容器名称。

在 Azure Portal 中,导航至你的 AKS 集群,按照门户上的说明连接集群,然后运行更新后的部署脚本来部署或升级流量网关节点。该节点现在应基于 Azure Blob Storage 中存储的配置进行操作。

要验证安装,请向网关发送请求。响应内容应当反映出之前在控制面中定义的配置,包括所有你已配置的路由、服务和插件等。

这确认了流量网关节点能够正确使用回退配置,并且即使在控制面不可用时也可以继续处理流量。

使用存储账户和访问密钥

此方法使用 Azure 存储账户名称和访问密钥来验证网关 Pod,需要管理静态凭证。

准备 Azure 资源

按照链接的文档创建和配置必要的 Azure 资源:

部署备份网关节点

在 API7 控制台(Dashboard)中,进入 网关实例(Gateway Instances)> 添加网关实例(Add Gateway Instance)。切换到 Docker 选项卡,填写备份网关节点的名称,然后点击 生成(Generate) 生成部署脚本。

在正在运行的网关中,将 fallback_cp 配置添加到网关的配置文件中:

conf/config.yaml
deployment:
fallback_cp:
interval: 60
mode: "write"
azure_blob:
account_name: your-storage-account-name
account_key: your-storage-account-key
config_container: fallback-cp-config
resource_container: fallback-cp-data

❶ 以秒为单位配置配置备份的时间间隔。

❷ 将网关配置为备用写入模式,允许其定期将从控制面(CP)获取的配置导出到外部存储。

❸ 替换为你的存储账户名称和访问密钥。

❹ 替换为用于存储资源和配置数据的 Blob 容器名称。

重新加载网关实例以使配置更改生效。检查网关日志,确保没有与 Azure Blob 容器连接相关的错误。

网关应作为备份节点开始运行,并定期将配置推送到 Blob 容器中。

验证

在本节中,你将验证配置数据是否已成功备份到 Blob 容器,并确保在控制面(CP)不可用时,流量网关节点能够使用回退配置继续运行。

检查 Blob 容器中的数据备份

在 Azure Portal 中,导航至你的 Azure 存储账户并打开相应的容器。验证数据是否已写入 fallback-cp-datafallback-cp-config 容器中。

fallback-cp-data container file

fallback-cp-config container file

你应该能看到备份网关节点定期更新了配置文件,这表明从控制面(CP)获取的配置已被成功备份。

确保流量网关节点使用回退配置

假设控制面(CP)变得不可用,你需要将数据面(DP)的流量节点配置为从外部存储获取配置。

无论你是更新现有的流量网关节点还是启动新的节点,在正在运行的流量网关节点中,将 fallback_cp 配置添加到网关的配置文件中:

conf/config.yaml
deployment:
role: data_plane
role_data_plane:
config_provider: json
fallback_cp:
azure_blob:
account_name: your-storage-account-name
account_key: your-storage-account-key
config_container: fallback-cp-config
resource_container: fallback-cp-data

❶ 将网关配置为在 standalone 模式下运行。

❷ 替换为你的存储账户名称和访问密钥。

❸ 替换为用于存储资源和配置数据的 Blob 容器名称。

重新加载网关实例以使配置更改生效。网关应开始在 standalone 模式下运行,并从 Blob 容器获取配置。

要验证安装,请向网关发送请求。响应内容应当反映出之前在控制面中定义的配置,包括所有你已配置的路由、服务和插件等。

这确认了流量网关节点能够正确使用回退配置,并且即使在控制面不可用时也可以继续处理流量。