用 AI 辅助迁移，30 分钟把 ingress-nginx 配置搬到 Higress

2026-05-29 18 预计阅读时间：1 分钟
来源：infoq.com AI 摘要 原文链接

免责声明：本文为 AI 摘要整理，建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件，不作为官方说明。

预计阅读时间：10 分钟

Kubernetes 网关基础设施的迁移历来是体力活——逐条比对 Ingress 资源、手动转换注解、反复测试路由是否生效。CNCF 最近分享了一个案例：工程师借助 AI 辅助迁移工具，将 60 条 ingress-nginx 资源迁移到 Higress，全程仅用了大约 30 分钟。这不是噱头，而是 AI 在云原生基础设施现代化中的一次真实落地。

为什么要从 ingress-nginx 换到 Higress

ingress-nginx 是 Kubernetes 生态中最广泛使用的 Ingress 控制器，但它在多协议支持、插件扩展和跨集群统一管理上存在明显短板。Higress 由阿里云开源，基于 Envoy 内核，定位是"云原生 API 网关 + Ingress 控制器"二合一：

  • 同时兼容 Ingress API 和 Gateway API，不需要一次性切换标准；
  • 内置 Wasm 插件机制，认证、限流、鉴权等能力可热加载，无需重启网关；
  • 支持 Nacos/ZooKeeper 等 MCP 服务发现，适合微服务混合注册中心场景；
  • 全局配置+路由配置分离，多团队协作时冲突更少。

问题在于：存量 ingress-nginx 配置里大量使用 nginx-specific 注解（如 nginx.ingress.kubernetes.io/rewrite-target、nginx.ingress.kubernetes.io/proxy-body-size），这些注解在 Higress 里没有直接对应项，需要逐条理解语义再改写。60 条资源手动做这件事，少说也要一整天。

AI 如何加速迁移

迁移工具的核心思路并不复杂：把 ingress-nginx 资源喂给大模型，让它理解每条注解的实际意图，然后输出等价的 Higress 配置。关键在于如何让 AI 的输出可靠、可验证，而不是"看起来对但跑起来错"。

整个流程大致分三步：

  1. 资源收集——用 kubectl 导出集群中所有 Ingress 对象，按命名空间分组；
  2. 语义转换——AI 逐条解析注解，将 nginx 特有语义映射到 Higress 的 Ingress 注解或 Wasm 插件配置；
  3. 校验回放——生成的配置先在测试集群 dry-run，确认路由、TLS、重写等行为一致后再上线。

下面用一个具体例子走一遍。

实操：一条 ingress-nginx 资源的迁移

假设集群中有这样一条典型的 ingress-nginx 资源：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - web.example.com
      secretName: web-tls
  rules:
    - host: web.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-svc
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-svc
                port:
                  number: 80

这条资源包含四个 nginx 专有注解，语义分别是：正则路径重写、限制请求体大小、强制 HTTPS 跳转、启用正则匹配。迁移到 Higress 后，需要把注解替换为 Higress 支持的等价配置：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app
  namespace: production
  annotations:
    higress.io/rewrite-target: /$2
    higress.io/proxy-body-size: "50m"
    higress.io/ssl-redirect: "true"
    higress.io/use-regex: "true"
spec:
  ingressClassName: higress
  tls:
    - hosts:
        - web.example.com
      secretName: web-tls
  rules:
    - host: web.example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-svc
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-svc
                port:
                  number: 80

看起来改动不大？确实，对于这类注解有明确对应项的情况，迁移就是注解前缀从 nginx.ingress.kubernetes.io 改为 higress.io，加上 ingressClassName 从 nginx 改为 higress。但真实集群里的注解组合远比这复杂——有些注解在 Higress 中没有直接等价物，需要拆成 Wasm 插件或全局配置；有些正则表达式在 Envoy 路由引擎下的行为与 nginx 不同。这正是 AI 辅助的价值所在：它能识别语义差异并给出改写建议，而不是让你逐条翻文档。

批量迁移的脚本框架

以下是一个可以实际运行的批量迁移脚本骨架，用 kubectl 导出资源、调用 AI 接口做转换、再写入测试集群校验：

#!/usr/bash
# migrate-ingress-to-higress.sh
# 用法: ./migrate-ingress-to-higress.sh <namespace> <ai-endpoint>
# 前置: kubectl 已连接源集群和目标测试集群

NAMESPACE="${1:?请指定命名空间}"
AI_ENDPOINT="${2:?请指定 AI 转换接口地址}"
OUTPUT_DIR="./migrated-${NAMESPACE}"

mkdir -p "$OUTPUT_DIR"

# 第一步：导出源集群 Ingress 资源
kubectl get ingress -n "$NAMESPACE" -o yaml > "$OUTPUT_DIR/source-ingresses.yaml"

# 用 yq 拆分每条 Ingress 为单独文件（便于逐条转换）
yq e '.items[] | select(.kind == "Ingress")' "$OUTPUT_DIR/source-ingresses.yaml" \
  | yq e -s '.metadata.name + ".yaml"' - > "$OUTPUT_DIR/"

# 第二步：逐条调用 AI 转换接口
for file in "$OUTPUT_DIR"/*.yaml; do
  name=$(yq e '.metadata.name' "$file")
  echo "转换: $name"
  curl -s -X POST "$AI_ENDPOINT" \
    -H "Content-Type: application/json" \
    -d "{\"ingress_yaml\": \"$(cat "$file" | base64)\"}" \
    | jq -r '.higress_yaml' | base64 -d \
    > "$OUTPUT_DIR/higress-${name}.yaml"
done

# 第三步：在测试集群 dry-run 校验
for file in "$OUTPUT_DIR"/higress-*.yaml; do
  echo "校验: $file"
  kubectl apply --dry-run=client -f "$file" -n "$NAMESPACE" 2>&1 \
    | tee "$OUTPUT_DIR/dryrun-$(basename "$file").log"
done

echo "迁移文件已输出到 $OUTPUT_DIR，请检查 dry-run 日志后再正式 apply"

运行前需要修改的地方：

  • AI_ENDPOINT 替换为你实际部署的转换服务地址，或者改用本地 LLM CLI 工具（如 ollama run）做离线转换；
  • yq 需要安装 v4+ 版本，用于 YAML 拆分和字段提取；
  • 测试集群需要提前安装 Higress Controller（helm install higress higress/higress -n higress-system）。

AI 辅助迁移的边界与风险

30 分钟迁移 60 条资源听起来很爽，但有几个现实问题不能忽略：

语义漂移——AI 对注解的理解可能和你的实际意图不一致。比如 nginx.ingress.kubernetes.io/affinity 在 nginx 里是基于 cookie 的会话亲和，Higress 的等价配置可能需要通过 Wasm 插件实现，行为细节（cookie 名称、过期策略）可能不同。必须逐条做流量对比测试。

正则差异——nginx 的正则引擎是 PCRE，Envoy 使用的是 RE2。RE2 不支持反向引用和部分高级特性。如果你的 Ingress 用了复杂正则，AI 生成的"等价"路径规则可能在 Envoy 下匹配行为不同。

灰度策略——不要一次性切换。建议在 Higress 配置中先只挂少量低流量路由，用镜像流量或按权重分流的方式验证行为一致后，再逐步把流量从 ingress-nginx 迁走。

AI 输出不可盲信——把 AI 当作"高级文档搜索 + 模板生成器"，而不是"全自动迁移机器人"。每条生成结果都需要人工 review，尤其是涉及 TLS 配置、认证策略和重写规则的资源。

迁移前的检查清单

动手之前，跑一遍这个清单能省下大量返工时间：

检查项 命令/方法
统计 Ingress 资源数量和命名空间分布 kubectl get ingress --all-namespaces --no-headers | wc -l
列出所有使用的 nginx 专有注解 kubectl get ingress --all-namespaces -o json | jq '.items[].metadata.annotations | keys[]' | sort -u
确认 Higress 版本支持哪些注解 查阅 Higress 官方文档注解对照表
检查正则路径是否有 RE2 不兼容的模式 人工 review path 字段中的正则表达式
测试集群 Higress Controller 是否就绪 kubectl get pod -n higress-system
准备流量对比方案（镜像或分流） 配置 Higress 的流量镜像插件

AI 辅助迁移把最耗时的"读注解、查文档、写等价配置"环节压缩到了分钟级，但"验证行为一致"这件事仍然需要工程师的判断力。工具提速，人把关——这才是正确的使用姿势。

# AI # InfoQ # Kubernetes # 云原生 # 全栈 # 数据工程

相关推荐