概述
随着Nginx Ingress逐步停止维护，用户需将其迁移至新的网关方案。阿里云云原生API网关是一款集成流量网关、微服务网关和安全网关的统一网关产品，为Nginx Ingress用户提供平滑迁移路径及功能升级能力。
云原生API网关支持两种核心配置模式，以满足不同管理需求与使用场景：
监听K8s Ingress（Ingress模式）：网关作为APIG Ingress Controller运行，兼容Kubernetes Ingress资源以及APIG Ingress支持的Annotation，适用于希望延续Kubernetes原生工作流（如GitOps）的团队。
控制台配置API（API管理模式）：通过阿里云控制台或OpenAPI进行配置，提供完整的API生命周期管理、高级安全策略配置及API运营能力，适用于需要集中化治理和精细化管控的场景。
本文档将对比两种模式在功能特性、优势及适用场景方面的差异，辅助用户选择最优配置方案。
模式一：监听K8s Ingress（Ingress模式）
此模式将云原生API网关部署为Kubernetes集群的Ingress Controller，用于管理集群的南北向流量。
核心优势
平滑迁移：为Nginx Ingress用户提供将自建Nginx Ingress迁移至云原生API网关，最大程度降低迁移成本和业务中断风险。
保持K8s原生工作流：完全兼容Kubernetes Ingress资源和注解，团队可以继续使用kubectl apply、GitOps等现有工作流来管理路由规则。
功能增强：在兼容Nginx Ingress的基础上，提供了更强大的治理能力，如全局限流控制等。
适用场景
Nginx Ingress的存量用户迁移。以K8s为中心、依赖GitOps流程管理应用发布的团队。需要快速实现集群流量路由和基础治理的开发运维团队。
功能详情
APIG Ingress Controller 支持的完整 Ingress 能力请参考：APIG Ingress支持的AnnotationAPIG Ingress高级用法。
高度兼容Nginx Ingress注解
APIG Ingress（云原生API网关的Ingress Controller）支持绝大多数Nginx Ingress注解（据统计支持51种，覆盖90%的用户场景）。现有的K8s Ingress YAML文件无需大量修改即可迁移。
关键兼容注解示例：
功能类别 | 兼容的Nginx注解 (nginx.ingress.kubernetes.io/) |
路由与重写 | rewrite-target use-regex upstream-vhost |
流量切分 | canary canary-by-header canary-weight |
安全与跨域 | enable-cors cors-allow-methods ssl-redirect force-ssl-redirect |
超时与重试 | proxy-next-upstream proxy-next-upstream-tries |
IP访问控制 | whitelist-source-range |
1.2.2 功能增强 (Higress 注解）
此模式不仅兼容Nginx，同时通过higress.ingress.kubernetes.io/前缀注解提供了Nginx Ingress所不具备的高级功能，包括：
流量预热 Nginx的问题：无法实现此能力。
APIG Ingress解决：提供原生的higress.ingress.kubernetes.io/warmup注解，可以保证新节点上线时，流量在指定预热窗口内是逐步调大，充分保证新节点完成预热。
全局限流 Nginx的问题：nginx.ingress.kubernetes.io/limit-rps实现的是单Pod限流，总限制等于“限流值 × Pod数量”，难以精确控制。
APIG Ingress解决：higress.ingress.kubernetes.io/rate-limit提供跨所有网关实例的全局限流，可精确控制总QPS。
全局并发控制 Nginx的问题：缺乏简单有效的全局并发数控制。
APIG Ingress解决：higress.ingress.kubernetes.io/concurrency-limit提供全局并发数限制，保护后端服务免受瞬时流量冲击。
流量镜像 Nginx的问题：缺乏流量镜像能力，需要写 Lua 脚本。
APIG Ingress解决：提供原生的higress.ingress.kubernetes.io/mirror-target-service注解，可便捷地复制流量到测试服务，用于生产环境的影子测试。
控制台配置API（API管理模式）
此模式将云原生API网关作为一个中心化的API管理平台。用户通过阿里云控制台（或API/Terraform）来定义和管理API，实现从路由转发到API治理的升级。
核心优势
集中化治理：允许平台团队、架构师或安全团队从统一视图管理所有API，强制执行安全、合规和流量策略。
全生命周期管理：支持API从设计、开发、测试、发布到下线的完整生命周期，包括版本控制、发布审计和一键回滚。
高级安全能力：原生集成复杂的认证机制（如OIDC/JWT/自建认证鉴权）。
API运营与生态：支持API的消费者管理 、订阅关系和调用配额 ，赋能API经济。
适用场景
需要对API进行精细化、集中化治理的企业。对API安全身份认证有高要求的业务。需要管理API版本、进行灰度发布和审计的团队。构建开放平台，需要管理第三方开发者（消费者）及其调用配额的场景。
功能详情
完整的API生命周期管理
支持API的设计、开发、测试、发布及下线全周期管理，包括：
版本管理：支持API的多个版本（如v1/v2）同时在线，并可管理其发布状态 。
发布与回滚：提供API的发布历史记录，支持一键回滚到任一历史版本 。
高级的企业级安全
提供远超Ingress模式的基础安全能力，将复杂的认证逻辑从后端服务中剥离，包括：
丰富认证鉴权：原生支持JWT、OIDC，并能与阿里云IDaaS（应用身份服务）集成。
多层防御：深度集成WAF（Web应用防火墙）、支持mTLS双向认证、IP黑白名单及自定义安全插件。
强大的可扩展性
插件市场：提供丰富的官方插件（覆盖认证、安全、流量等），并支持用户上传自定义插件。
热更新：网关支持插件和配置的热更新，无需重启实例，保障业务高可用。
API运营与多源服务发现
API生态：提供“消费者管理”功能，可管理API的调用配额和订阅规则。
多源发现：后端服务不仅限于K8s集群，同时支持从Nacos、函数计算（FC）以及固定地址/域名等多种来源发现服务。
模式对比总结
维度 | 模式一：K8s Ingress模式 | 模式二：控制台API模式 |
核心定位 | K8s Ingress Controller，流量路由 | 统一API管理平台 |
配置方式 | K8s YAML | 阿里云控制台 / API / Terraform |
管理工作流 | GitOps / kubectl apply | UI/API驱动 |
Nginx迁移 | 提供一键式迁移工具。 | 需要重新定义API并配置策略 |
API生命周期 | 无。与K8s资源生命周期绑定 | 完整。支持设计、开发、测试、发布、版本、下线 |
扩展性 | 有限。受限于已支持的注解 | 高。丰富的插件市场 + 自定义插件热更新 |
服务发现 | K8s原生。自动发现K8s Service | 多源。支持K8s (ACK)、Nacos、FC、固定地址等 |
API运营 | 无 | 完整。支持消费者管理、订阅、配额管理 |
如何选择：推荐的迁移与演进路径
场景一：平滑迁移
适用对象：优先考虑迁移速度、希望保持现有K8s工作流的团队。
推荐方案：采用模式一：K8s Ingress模式。
实施步骤：
使用官方迁移工具将Nginx Ingress配置迁移至云原生API网关。
审查迁移报告，处理少量不兼容注解（可提交工单咨询）。
（可选）使用
higress.ingress.kubernetes.io/注解替换原有配置，以启用全局限流等高级功能。
场景二：新业务架构
适用对象：构建全新的API平台，或对安全、治理有高要求的企业。
推荐方案：采用控制台API模式。
实施步骤：
在控制台定义API、配置安全策略（如OIDC/JWT）和限流策略。
使用网关的服务发现能力，将API后端指向ACK集群中的Service或其他服务来源。
场景三：渐进式演进（推荐策略）
适用对象：绝大多数组织，既要解决存量迁移问题，又希望逐步提升治理能力。
推荐方案：从模式一开始，逐步演进至模式二。
实施步骤：
迁移：首先采用模式一（Ingress），完成所有Nginx Ingress的平滑迁移，快速解决Nginx EOL问题。
治理：识别出组织内的核心API（例如：对外的、高安全等级的、需精细化管理的API）。
演进：将核心API逐步“纳管”至模式二（控制台）。可以在控制台为相关API配置JWT认证、WAF防护、消费者配额等高级策略，而其他非核心API可以继续保留在模式一中运行。
路由优先级说明：
对于相同域名和相同路径的路由，控制台创建的API优先级会高于Ingress方式同步的路由，因此迁移过程中可以逐个在控制台上进行配置，如果发现有问题，也可以通过删除控制台配置立即恢复到Ingress模式。
路由优先级以单个路由为粒度进行控制，而非基于整个域名。因此，可在同一域名下对部分路径使用新控制台配置，其余路径仍沿用 Ingress 控制台的配置。建议仅将匹配条件相同的 Ingress 路由逐步迁移，并按路径逐级推进，避免一次性迁移整个域名的所有路由。
举例说明：
场景： 您有一个域名 example.com，需要从 Ingress 逐步迁移到控制台配置。
1. 初始状态（仅 Ingress 配置）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service-v1
port:
number: 8080
- path: /web
pathType: Prefix
backend:
service:
name: web-service-v1
port:
number: 80此时API网关自动生成的路由为：
/api → api-service-v1:8080
/web → web-service-v1:80
2. 迁移中（控制台配置 /api 路径）
在控制台为 example.com 创建路由，配置 /api 指向新版本服务 api-service-v2:8080。
此时合并后的实际路由顺序为：
1. /api → api-service-v2:8080 (控制台配置，优先匹配)
2. /api → api-service-v1:8080 (Ingress 配置，不会匹配到)
3. /web → web-service-v1:80 (Ingress 配置，正常生效)效果：
访问 example.com/api/* → 路由到 api-service-v2（控制台配置生效）
访问 example.com/web/* → 路由到 web-service-v1（Ingress 配置生效）
3. 发现问题，快速回退
如果发现 api-service-v2 存在异常，只需在控制台删除/api路由配置。
删除后的路由顺序：
1. /api → api-service-v1:8080 (Ingress 配置，立即恢复)
2. /web → web-service-v1:80 (Ingress 配置)效果： 流量立即回退到 Ingress 配置的 api-service-v1，无需修改 Ingress 或重启任何服务。
4. 完全迁移（控制台配置所有路径）
在控制台继续配置/web路径后：
1. /api → api-service-v2:8080 (控制台配置)
2. /web → web-service-v2:80 (控制台配置)
3. /api → api-service-v1:8080 (Ingress 配置，不会匹配到)
4. /web → web-service-v1:80 (Ingress 配置，不会匹配到)此时所有流量都由控制台配置控制，可以安全删除对应的 Ingress 配置。