从Nginx Controller迁移到ALB的平滑切换及停机风险咨询

首先明确一个前提：K8s本身没有内置的Ingress Controller自动迁移逻辑，不存在默认的「先删旧」或「先建新」的固定流程，整个迁移节奏完全由你手动控制，你可以根据业务对 downtime 的容忍度选择对应的操作方案。

推荐零停机操作流程 #

业界通用的低风险迁移方案走的是「先建后切再下线」的逻辑，具体步骤如下：

• 先完成ALB Ingress Controller的部署，确保其对应的IngressClass资源已经在集群中正常注册、状态可用
• 复制现有业务的Ingress配置，仅修改ingressClassName字段为ALB对应的Class值，新增一份独立的Ingress资源。此时旧Nginx Ingress和新ALB Ingress会同时生效，各自对应独立的对外入口，互不影响
• 先做ALB入口的可用性验证：通过绑定本地hosts将业务域名指向ALB的对外IP，验证所有路由规则、SSL证书、转发配置、后端服务连通性完全符合预期
• 切流量：将业务域名的DNS解析从旧Nginx Ingress的对外IP修改为ALB的IP，等待解析完全生效的窗口内，两个入口都可以正常承接流量，不会出现业务中断
• 下线旧资源：确认100%流量都已经切到ALB、业务稳定运行无异常后，再删除旧的Nginx Ingress Controller以及对应的旧Ingress资源

高风险操作说明 #

如果你选择直接修改现有Ingress的ingressClassName字段，会触发以下逻辑：
旧Nginx Ingress Controller会检测到Ingress不再属于自己管理的Class范围，自动清理对应的路由规则；同时新ALB Ingress Controller会检测到新的可管理Ingress，开始同步生成ALB的路由配置。这个同步过程通常有几秒到几十秒不等的规则空窗期，会出现业务访问中断，绝对不建议核心业务用这种方式操作。

额外注意点 #

• 迁移前需要将Ingress中Nginx专属的注解（格式为nginx.ingress.kubernetes.io/*）替换为ALB Ingress Controller支持的对应注解，避免路由规则不生效
• 核心业务迁移前务必在预发/测试环境完整演练一遍流程，确认所有配置兼容
• 迁移窗口内建议暂时关闭Ingress相关的自动同步/CI/CD任务，避免额外配置变更干扰迁移过程

内容的提问来源于stack exchange，提问作者Andrew Striletskyi