裸金属多可用区部署多套Ingress Controller的实现方案及最佳实践问询

核心实现步骤 #

1. 部署zone-2的独立ingress-nginx集群 #

• 若两个可用区属于同一个K8s集群，部署zone-2的ingress-nginx时配置节点亲和规则，强制Pod调度到zone-2的节点上，避免跨可用区调度；若为两个独立集群，需要保证zone-2的集群中部署了和zone-1完全一致的后端服务副本。
• 为zone-2的ingress-nginx指定独立的ingress-class（例如nginx-zone2），和zone-1的ingress-class做区分，避免规则冲突。
• 为zone-2的ingress-nginx绑定专属公网IP，安全组、端口放行规则和zone-1的公网IP保持一致。
• 同一份业务Ingress资源可以同时匹配两个ingress-class（写两份Ingress配置分别指定对应class，或用支持多ingress-class的版本同时配置），保证两个可用区的流量进入后都能正确转发到后端服务。

2. 配置DNS负载均衡与故障切换 #

• 在Cloud DNS中为test.example.com配置多条A记录，分别指向zone-1和zone-2的公网IP，开启加权轮询策略，可根据两个可用区的承载能力设置权重，默认各设50%即可实现流量均匀拆分。
• 强制开启DNS健康检查能力：配置对两个公网IP的探活规则（例如探测/healthz接口或80/443端口连通性），当某一个可用区的ingress服务故障时，DNS会自动将故障IP从解析列表中摘除，所有流量自动切换到正常可用区，实现跨可用区容灾。

生产环境最佳实践 #

• 配置一致性保障：两套ingress-nginx的版本、限流/超时/重写等核心配置、TLS证书内容要完全一致，避免两边访问出现差异化的响应结果。
• 会话保持适配：如果业务有会话保持需求，不要依赖ingress层的IP哈希会话保持策略，改为在应用层通过Cookie实现会话绑定，避免DNS轮询导致用户请求在两个可用区间跳转出现会话丢失。
• 流量灰度切换：上线初期可以先将zone-2的DNS权重设置为10%，小流量验证业务访问完全正常之后再逐步调大权重，避免直接切流引发大面积故障。
• 监控与容灾演练：两套ingress-controller的请求量、错误率、响应耗时、节点状态等指标要统一监控，配置相同的告警规则；定期模拟单可用区故障，验证DNS自动切流的有效性。
• 路由规则优化：如果业务有就近访问需求，可以将DNS的轮询策略替换为地理/区域路由，让不同区域的用户自动访问距离更近的可用区入口，降低访问延迟。

内容的提问来源于stack exchange，提问作者Payam Khaninejad