Cloud Native Computing Foundation
·
从Ingress NGINX到Envoy Gateway的零停机迁移
内容提要
随着Kubernetes网络向Gateway API演进，许多团队正在评估从Ingress NGINX迁移的策略。本文案例研究了在AWS上成功迁移到Envoy Gateway的过程，强调了实现零停机的重要性。通过加权DNS记录，团队确保了流量平稳过渡，避免了请求丢失。Gateway API 1.5的ListenerSet资源将进一步改善基础设施与应用之间的分离。
关键要点
-
随着Kubernetes网络向Gateway API演进，许多团队正在评估从Ingress NGINX迁移的策略。
-
Ingress NGINX控制器在Kubernetes生态系统中广泛部署，但缺乏安全补丁和新特性，Gateway API是合理的下一步选择。
-
选择Envoy Gateway作为迁移目标，经过对多个Gateway API实现和迁移方法的评估。
-
在迁移过程中，使用加权DNS记录确保流量平稳过渡，避免请求丢失。
-
Gateway API 1.5引入ListenerSet资源，进一步改善基础设施与应用之间的分离。
-
迁移过程中，确保在切换时不丢失请求是关键，使用加权DNS记录实现零停机。
-
生产环境中出现的多命名空间模型挑战在Gateway API 1.5中得到解决，ListenerSet资源允许应用团队定义自己的监听器。
延伸问答
为什么要从Ingress NGINX迁移到Gateway API？
因为Ingress NGINX缺乏安全补丁和新特性，而Gateway API是更具表现力的规范，能够提供更好的功能和灵活性。
如何确保在迁移过程中实现零停机？
通过使用加权DNS记录，确保在切换时流量平稳过渡，避免请求丢失。
Envoy Gateway的选择依据是什么？
选择Envoy Gateway是因为它符合我们的长期需求，支持mTLS和请求缓冲，并且是CNCF项目，具备生产就绪性。
Gateway API 1.5引入了哪些新特性？
Gateway API 1.5引入了ListenerSet资源，允许应用团队定义自己的监听器，从而改善基础设施与应用之间的分离。
在迁移过程中遇到了哪些挑战？
主要挑战是多命名空间模型，之前的Gateway API要求在Gateway和HTTPRoute级别都定义主机名，导致基础设施与应用的关注点混淆。
如何测试Envoy Gateway的迁移效果？
通过在内部基础设施上进行测试，使用监控脚本记录HTTP状态码，确保迁移过程中没有请求失败。
