Planning Rollouts with Routes vs. Ingress in Kubernetes
When rolling out new versions of services in Kubernetes, managing external traffic carefully is crucial to ensure smooth transitions, avoid downtime, and maintain a great user experience. Routes (in OpenShift) and Ingress (in standard Kubernetes) both provide ways to control traffic flow, but their approaches to handling rollouts differ slightly.
Let’s walk through how to plan rollouts using both Routes and Ingress!
🎯 Rollouts with Ingress (Kubernetes)
Ingress provides a flexible, configurable way to control how traffic reaches your services. For rollouts, you can leverage various techniques like Blue-Green Deployments, Canary Releases, or Traffic Splitting using annotations, custom Ingress controllers, or third-party tools like Istio or NGINX.
Key Approaches:
- Blue-Green Deployment:
• Deploy the new version alongside the current one (two versions run simultaneously).
• Switch traffic from the old version to the new one by modifying the Ingress rules to point to the new service.
- Canary Deployment:
• Gradually shift a small percentage of traffic to the new version.
• Use annotations in your Ingress controller (like NGINX) to define weight-based traffic splitting between old and new versions.
- Ingress Controllers & Traffic Splitting:
• NGINX Ingress Controller supports traffic splitting through annotations that define how much traffic goes to each service version.
• Istio or other service meshes can also provide finer-grained traffic control and observability.
Example (Canary Release using NGINX Ingress):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
rules:
- host: example.com
http:
paths:
- path: /
backend:
service:
name: old-service
port:
number: 80
- path: /
backend:
service:
name: new-service
port:
number: 80
This configuration routes 10% of traffic to the new-service and 90% to the old-service, allowing you to monitor the new version before fully switching over.
Planning Steps:
-
Deploy the new version as a separate service.
-
Update Ingress annotations to control traffic flow between the old and new versions.
-
Monitor performance and adjust traffic weights as needed.
-
Once satisfied, shift all traffic to the new service and remove the old one.
🎯 Rollouts with Routes (OpenShift)
Routes in OpenShift are simpler but still powerful for managing rollouts. OpenShift doesn’t have native traffic-splitting functionality built into Routes, but you can achieve it through custom configurations using labels, Route sharding, or third-party tools.
Key Approaches:
- Blue-Green Deployment:
• Create two Routes: one for the old version and one for the new version.
• Gradually shift traffic by updating the DNS or switching the active Route.
- Canary Deployment via Weighting:
• OpenShift supports weighted Route traffic splitting, where you can direct a percentage of traffic to each service version by setting weights on the Route objects.
- Route Sharding:
• Create separate Routes for each version of the service, then adjust traffic routing at the DNS or load balancer level.
Example (Weighted Route in OpenShift):
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: canary-route
spec:
host: example.com
to:
kind: Service
name: new-service
weight: 10
alternateBackends:
- kind: Service
name: old-service
weight: 90
tls:
termination: edge
This configuration directs 10% of traffic to new-service and 90% to old-service. As with Ingress, this approach allows you to gradually shift traffic to the new version while monitoring performance.
Planning Steps:
-
Deploy the new version and create a corresponding Route.
-
Adjust Route weights to control how much traffic goes to each version.
-
Monitor the rollout and tweak the weights as needed.
-
Once stable, shift all traffic to the new Route and remove the old one.
🔑 Best Practices for Rollouts:
• Monitor closely: Whether using Ingress or Routes, monitor your services’ health and performance during rollouts to catch any issues early.
• Gradual rollouts: Avoid switching all traffic at once—use a canary or blue-green approach to minimize risk.
• Rollback readiness: Always be prepared to roll back to the previous version if issues arise.
• Automation tools: Leverage CI/CD tools (like ArgoCD or Jenkins) to automate rollouts and rollbacks, making the process smoother and faster.
🚀 Which to Use:
• If you’re using standard Kubernetes, Ingress with traffic-splitting annotations or service mesh tools (like Istio) gives you more flexibility.
• If you’re on OpenShift, Routes provide a more straightforward way to manage rollouts, especially with built-in weight-based traffic control.
Both methods ensure that your Kubernetes services are ready for smooth, zero-downtime rollouts. Happy deploying! 🎉
Imported from rifaterdemsahin.com · 2025