部署高可用环境
以高可用(HA)方式部署 API7 网关,可以消除控制面(CP)和数据面(DP)中的单点故障。本指南介绍部署生产级高可用环境所需的前置条件、架构和具体步骤。
如需了解相关概念,请参阅高可用性。
本页介绍如何部署高可用拓扑。部署完成后,可使用以下配置和管理指南进行日常运维:
部署前,请规划能够在故障期间维持集群可用性的外围基础设施:
- 自带高可用或托管故障转移机制的外部 PostgreSQL 部署。
- 分别位于控制面和数据面前端的负载均衡器。
- 控制台和 DP Manager 端点所需的 TLS 证书,以及数据面节点所需的 mTLS 证书。
- 每次只重启一个节点,并在继续操作前验证流量的维护流程。
架构概览
高可用部署包括:
- 共享一个 PostgreSQL 数据库、并由负载均衡器提供前端入口的多个控制面节点(控制台 + DP Manager)。
- 位于一个或多个网关组中、并由负载均衡器提供前端入口的多个数据面节点。
- (可选)备用网关节点:定期将配置导出到外部存储(AWS S3 或 Azure Blob Storage),使数据面在控制面中断时仍具备弹性。
前置条件
部署检查清单
安装或扩容任何高可用节点前,请完成以下准备工作:
- 准备外部 PostgreSQL 实例或集群,并确认自动故障转移由 API7 网关之外的系统负责。
- 为控制面和数据面负载均衡器预留稳定的 DNS 名称或虚拟 IP。
- 准备控制台和 DP Manager 端点所需的 TLS 证书。如果数据面节点通过 mTLS 连接,还需准备部署流程所需的 CA 和节点证书。
- 确认每个控制面节点使用相同的 PostgreSQL DSN,并且每个数据面节点都通过同一个 DP Manager 端点连接到同一个网关组。
API7 网关依赖 PostgreSQL 的可用性,但不会替你配置 PostgreSQL 复制、主库提升或备份。请将数据库高可用视为控制面高可用的前置条件。
最少节点数
| 组件 | 最少节点数 | 说明 |
|---|---|---|
| 控制面 | 2 | 每个节点运行控制台和 DP Manager |
| 数据面 | 2 | 每个节点运行 API7 网关 |
| PostgreSQL | 托管实例或高可用集群 | 高可用配置不在本指南范围内;请参阅 PostgreSQL 高可用 |
硬件要求
| 组件 | CPU | 内存 | 磁盘 |
|---|---|---|---|
| 控制面 | 4 核 | 8 GB | 40 GB |
| 数据面 | 4 核 | 8 GB | 20 GB |
详细要求请参阅系统要求。
网络端口
确保组件之间可以访问以下端口:
| 服务 | 端口 | 协议 | 说明 |
|---|---|---|---|
| 控制台 | 7080 / 7443 | HTTP / HTTPS | 控制台 UI 和 Admin API |
| DP Manager | 7900 / 7943 | HTTP / HTTPS | 数据面管理 |
| 网关(HTTP) | 9080 | HTTP | API 流量 |
| 网关(HTTPS) | 9443 | HTTPS | API 流量 |
| 网关状态 | 7085 | HTTP | 健康检查端点 |
| PostgreSQL | 5432 | TCP | 数据库 |
| Prometheus | 9090 | HTTP | 指标(可选) |
负载均衡器和 TLS
在生产高可用环境中,应为每条流量路径配置稳定的前端入口:
| 端点 | 常见前端 | 用途 |
|---|---|---|
| 控制台 | Ingress、内部负载均衡器或反向代理 | 运维人员访问控制台和 Admin API |
| DP Manager | 集群内部 Service 或内部负载均衡器 | 为数据面节点提供稳定的 mTLS 地址 |
| 数据面 | 外部负载均衡器或 Ingress Controller | 客户端 API 流量 |
在 Kubernetes 中,控制面 Chart 已经为控制台和 DP Manager 分别创建 Service。常见做法是保持 dashboard_service.type: ClusterIP,通过 Ingress 或内部代理暴露控制台,同时将 dp_manager_service 保持为稳定的内部端点。如果数据面节点从集群外部连接,请通过内部负载均衡器或其他稳定的私有前端暴露 DP Manager。
控制面高可用
API7 控制台和 DP Manager 都是无状态应用程序,所有配置均存储在 PostgreSQL 中。要实现高可用,请在负载均衡器后部署多个实例。
所有控制面副本必须共享:
- 同一个 PostgreSQL 数据库。
- 相同的许可证状态和控制台配置。
- 面向运维人员和数据面节点的稳定端点。
- Kubernetes (Helm)
- Docker
在 Helm 配置中设置副本数并保持 Service 前端稳定,以扩展控制面:
dashboard:
# ❶
replicaCount: 2
dp_manager:
# ❷
replicaCount: 2
postgresql:
# ❸
builtin: false
dashboard_service:
# ❹
type: ClusterIP
dp_manager_service:
# ❺
type: ClusterIP
dashboard_configuration:
database:
dsn: "postgres://api7ee:$DB_PASSWORD@your-pg-ha-endpoint:5432/api7ee"
dp_manager_configuration:
database:
dsn: "postgres://api7ee:$DB_PASSWORD@your-pg-ha-endpoint:5432/api7ee"
❶ 至少部署 2 个控制台副本以实现冗余。
❷ 至少部署 2 个 DP Manager 副本。
❸ 禁用内置 PostgreSQL,并让控制面连接外部高可用数据库。
❹ 将控制台放在稳定的前端之后,例如 Ingress、内部代理或 LoadBalancer Service。
❺ 为同一网关组中的所有数据面节点提供一个稳定的 DP Manager 地址。
如果同一个 Helm Release 中仍启用了开发者门户,还需将 developer_portal_configuration.database.dsn 设置为同一个 PostgreSQL 端点,或者在该 Release 中禁用开发者门户。
安装或升级 Helm Release:
helm upgrade --install api7ee3 api7/api7ee3 -f values.yaml -n api7 --create-namespace
如果在控制台自身终止 TLS,请使用 dashboard.keyCertSecret 配置控制台证书。如果改为在 Ingress 或负载均衡器上终止 TLS,请确保后端端口只能从可信网络访问。
为了在 Kubernetes 上获得更可靠的调度分布,还可配置 dashboard.topologySpreadConstraints 和 dp_manager.topologySpreadConstraints,让副本落在不同的工作节点或可用区。
在每台控制面主机上同时运行控制台和 DP Manager 容器。
控制台(dashboard-config.yaml):
server:
listen:
host: "0.0.0.0"
port: 7080
database:
dsn: "postgres://api7ee:$DB_PASSWORD@your-pg-ha-endpoint:5432/api7ee"
docker run -d --name api7-dashboard \
-p 7080:7080 \
-v $(pwd)/dashboard-config.yaml:/app/conf/config.yaml \
api7/api7-ee-3-integrated:latest
DP Manager(dp-manager-config.yaml):
server:
listen:
host: "0.0.0.0"
port: 7900
database:
dsn: "postgres://api7ee:$DB_PASSWORD@your-pg-ha-endpoint:5432/api7ee"
docker run -d --name api7-dp-manager \
-p 7900:7900 \
-v $(pwd)/dp-manager-config.yaml:/app/conf/config.yaml \
api7/api7-ee-dp-manager:latest
在控制面主机前部署负载均衡器(例如 NGINX 或 HAProxy),将流量分发到各个控制台和 DP Manager 实例。
为负载均衡器配置被动或主动健康检查,并在将用户或数据面节点指向负载均衡器之前,确认后端池包含所有控制面节点。
所有控制台和 DP Manager 实例都必须连接到同一个 PostgreSQL 数据库。PostgreSQL 高可用(主从复制、Patroni,或 Amazon RDS、Azure Database、Google Cloud SQL 等托管服务)属于独立事项,应根据数据库提供商的文档进行配置。
数据面高可用
数据面节点是无状态的:它们从控制面接收配置并独立处理流量。请在负载均衡器后部署多个节点。
为实现可预测的故障转移行为,请确保:
- 每个节点都属于同一个网关组。
- 负载均衡器仅向健康节点转发流量。
- 尽可能将节点分散到不同故障域,例如不同主机、可用区或 Kubernetes 工作节点。
健康检查配置
每个网关节点都提供用于健康监控的状态端点:
| 端点 | 方法 | 说明 |
|---|---|---|
/status | GET | 网关正在运行时返回 200 |
/status/ready | GET | 网关已准备好接收流量时返回 200 |
状态端点默认监听 7085 端口。请配置负载均衡器定期检查该端点,例如每 10–30 秒检查一次。
如果只需确认网关进程仍在运行,请使用 /status。如果希望负载均衡器只向仍可连接 DP Manager 的节点路由流量,请使用 /status/ready。
如果你的运维模式允许数据面节点在控制面短暂中断期间继续使用缓存配置提供服务,检查 /status 可让这些节点继续接收流量。如果希望在 DP Manager 连接丢失时让负载均衡器停止路由流量,请使用 /status/ready。有关详细权衡,请参阅配置就绪和存活探针。
部署多个数据面节点
- Kubernetes (Helm)
- Docker
将以下面向高可用的配置添加到 api7/gateway Chart 所使用的 values.yaml 文件中:
api7ee:
status_endpoint:
# ❶
enabled: true
ip: 0.0.0.0
port: 7085
apisix:
# ❷
replicaCount: 3
podDisruptionBudget:
# ❸
enabled: true
minAvailable: 1
affinity:
# ❹
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- gateway
topologyKey: kubernetes.io/hostname
gateway:
# ❺
readinessProbe:
httpGet:
path: /status/ready
port: 7085
livenessProbe:
httpGet:
path: /status
port: 7085
❶ 在 7085 端口暴露状态端点,以便 Kubernetes 和外部健康检查程序验证节点状态。
❷ 至少运行 2 个数据面副本以实现高可用;如果希望在维护期间保留更多容量,可从 3 个副本起步。
❸ 使用 PodDisruptionBudget,避免自愿中断一次驱逐所有网关 Pod。
❹ 将 Pod 分散到不同工作节点,以降低单节点故障的影响。
❺ 分别使用就绪和存活检查,让调度器和负载均衡器停止向未就绪节点发送流量。
请选择符合环境要求的 Service 暴露方式。在托管 Kubernetes 中,设置 gateway.type: LoadBalancer 是创建数据面前端的常见方式。如果已有 Ingress Controller 或外部 L4/L7 负载均衡器,请保留符合该设计的 Service 类型,并让前端指向网关 Service。
在多台主机上运行网关容器。每个容器都连接 DP Manager 以接收配置:
docker run -d --name api7-gateway \
-p 9080:9080 \
-p 9443:9443 \
-v $(pwd)/gateway-config.yaml:/usr/local/apisix/conf/config.yaml \
api7/api7-ee-3-gateway:latest
在所有网关主机前部署负载均衡器。配置健康检查轮询 http://<host>:7085/status 或 http://<host>:7085/status/ready,并从后端池中移除不健康节点。
有关健康检查和弹性行为的详细信息,请参阅数据面高可用性。