Zero-Downtime Migration: From Ingress NGINX to Envoy Gateway
In the world of Kubernetes, ensuring zero downtime during migrations is a critical concern. When transitioning from Ingress NGINX to Envoy Gateway, the challenge lies in maintaining service availability while shifting traffic. This migration approach allows you to run both the Ingress and the HTTPRoute at the same time, using weighted DNS records to manage traffic without a hard cutover. This means you can confidently test the new configuration while still serving requests through the old one.
The process involves using ExternalDNS and AWS Route 53 to set up weighted DNS records. Initially, you assign a high weight to the Ingress and zero to the HTTPRoute. This configuration makes the HTTPRoute live but not yet receiving traffic. Once you’re confident in the new setup, you simply swap the weights. This method avoids the need to create or delete DNS records, making the transition smooth and controlled. For instance, you might set the Ingress weight like this: external-dns.alpha.kubernetes.io/aws-weight: "100" and the HTTPRoute like this: external-dns.alpha.kubernetes.io/aws-weight: "0". After the swap, you can revert easily if any issues arise, as there’s no resource to redeploy or DNS record to recreate.
In production, this method is straightforward but requires careful monitoring during the transition. The rollback process is particularly advantageous, allowing you to revert changes quickly if anything goes wrong. This migration strategy is effective and minimizes risk, but always ensure you have proper observability in place to catch any potential issues early.
Key takeaways
- →Leverage weighted DNS records to manage traffic during migration.
- →Run Ingress and HTTPRoute simultaneously to ensure zero downtime.
- →Use ExternalDNS and AWS Route 53 for effective DNS management.
- →Easily roll back changes by swapping DNS weights if issues arise.
Why it matters
In production environments, maintaining uptime during migrations is non-negotiable. This approach allows teams to transition between systems without impacting user experience, which is critical for service reliability.
Code examples
external-dns.alpha.kubernetes.io/aws-weight: "100"external-dns.alpha.kubernetes.io/aws-weight: "0"# Ingress
external-dns.alpha.kubernetes.io/aws-weight: "0"
#HTTPRoute
external-dns.alpha.kubernetes.io/aws-weight: "100"When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsUnified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.
Try Better Stack free →Mastering Ingress Request Tracing for Multi-Tenant SaaS on Kubernetes
In a multi-tenant SaaS environment, understanding request flows is crucial for maintaining performance and reliability. By implementing end-to-end ingress request tracing, you can track customer requests through your services using Trace IDs and Span IDs.
Building a Cloud Native Platform: Kairos, k0rdent, and bindy in Action
Creating a cloud native platform from scratch can be daunting. With Kairos, you get an immutable Linux distribution that boots from OCI images, ensuring consistency. Dive into how k0rdent and bindy enhance your Kubernetes management and DNS operations.
Mastering EKS Container Network Observability for Inter-AZ Traffic
Understanding inter-AZ and NAT gateway traffic is crucial for optimizing your Kubernetes workloads. With EKS Container Network Observability, you gain pod-level insights into network traffic, enabling better performance tuning and troubleshooting. Dive into how to leverage this powerful feature effectively.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.