生产环境换 Gateway API:别把 TLS 证书搞崩
来源:dev.to — 2026-11-01
📋 概述
Ingress NGINX 已进入维护模式,GatewayClass、Gateway、HTTPRoute 也都 GA 了,下一次集群升级是个不错的迁移理由。但「换掉 ingress controller」这句话藏着一堆风险:TLS 监听里一个拼写错误,生产环境所有浏览器都会看到证书错误。作者给出的策略是不做大爆炸式切换——让 Gateway API 与旧的 Ingress NGINX 并存,一次只搬一个主机名,按权重慢慢切流,每一步都验证证书链。控制器用 Envoy Gateway,证书交给 cert-manager,但这套模式对任何符合规范的实现都适用。文章把三个对象的分工讲得很清楚:集群级 GatewayClass 归平台团队,Gateway 是监听器放在基础设施命名空间,HTTPRoute 归应用团队放在自己的命名空间,跨命名空间的引用必须由 ReferenceGrant 显式放行。
🔑 核心要点
三件事让这次迁移与换镜像不同 :TLS 终结的位置要搬、公网 IP 会变(DNS 变更不可原子回滚)、nginx.ingress.kubernetes.io 注解无法自动翻译。
并存是规范允许的设计 :同一个集群里 Ingress 和 Gateway 可以服务同一个主机名,这正是可以逐个搬家的杠杆。
职责边界映射到组织结构 :平台团队管 GatewayClass 与 Gateway,应用团队只写自己的 HTTPRoute,跨命名空间的 Secret 引用必须显式授权。
OpenShift 上要先查 CRD 归属 :4.19 起 Ingress Operator 可能自行管理 Gateway API 的 CRD,直接 apply 会与运维器打架。
💡 金句
Replace your ingress controller is a sentence that hides a lot of risk: a single typo in a TLS listener and every browser in production gets a certificate error.译:「换掉你的 ingress controller」这句话藏着大量风险:TLS 监听里一个拼写错误,生产环境所有浏览器都会看到证书错误。
👍 0
❤️ 点赞
👎 0
沉底
← 返回 dev.to 首页