TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
🧠 USE CASE
Kubernetes Ingress Vs Gateway API
If you’re still deploying Kubernetes workloads using Ingress and haven’t explored the Gateway API yet, you might be missing out on more flexible traffic control and multi-protocol support.
Let’s go beyond the usual definitions and dive into practical distinctions that impact real deployments.
1. Ingress
Most Kubernetes deployments today use Ingress to expose HTTP(S) traffic. It works, but it has notable caveats:
Tied to HTTP: No built in support for TCP, UDP, or gRPC.
Cluster scoped: You configure Ingress at the cluster level, making it less flexible for multi-team or multi-tenant scenarios.
Limited Extensibility: Annotations and custom CRDs are needed for advanced use cases like rate limiting, header modifications, and multi-tenancy.
No Fine grained Routing Control: Ingress only supports host/path-based routing, meaning complex routing logic often needs workarounds with annotations or controller specific features.
Network Policies Conflicts: Ingress does not inherently respect NetworkPolicy configurations, leading to cases where traffic gets routed despite restrictive policies.
2. Gateway API
The Gateway API is not just a replacement for Ingress, it’s an evolution that provides multi-protocol support, better delegation, and extensibility.
Here’s what makes it a game changer:
Multi protocol support: Native support for HTTP, TCP, UDP, and gRPC (
HTTPRoute,TCPRoute,UDPRoute). This means you can define traffic rules beyond just HTTP(S).Namespace scoped delegation: Unlike Ingress, Gateway API allows defining multiple Gateways within a namespace, making it ideal for multi-tenant architectures.
Separation of Concerns: In Ingress, application teams often depend on cluster admins to configure traffic policies. With Gateway API, cluster admins manage Gateways while app teams manage their own
HTTPRoute,TCPRoute, orUDPRouteobjects.Policy Enforcement: Supports first class policy objects like rate limiting, traffic splitting, retry policies, and more (without relying on annotations).
Standardization Across Vendors: Unlike Ingress, which has different behaviors depending on the controller (NGINX, Traefik, etc.), the Gateway API aims to standardize behaviors across implementations.
When to Use What?
Scenario | Use Ingress | Use Gateway API |
|---|---|---|
Basic web apps (HTTP/S only) | ✅ | ✅ |
Multi-team, multi-tenant setups | ❌ | ✅ |
TCP, UDP, gRPC traffic | ❌ | ✅ |
Fine grained routing & delegation | ❌ | ✅ |
Avoiding controller specific annotations | ❌ | ✅ |
Enterprise scale traffic policies | ❌ | ✅ |
Practical Migration Considerations
Thinking of migrating from Ingress to Gateway API?
Here are key steps to ensure a smooth transition:
If you rely heavily on annotations (e.g., rate limiting, redirects), map them to Gateway API equivalent policies.
Not all controllers fully support Gateway API yet. Kong, Traefik, Istio, and Contour have good support, but check for missing features.
You can run both Ingress and Gateway API in parallel and migrate gradually.
Test with
HTTPRoute,TCPRoute, andUDPRouteconfigurations before full cutover.Ensure NetworkPolicy rules align with Gateway API routing.
My 2 Cents:
If your workload is simple HTTP based traffic, Ingress still gets the job done. But if you’re dealing with much more complex traffic, the Gateway API is the future. Start experimenting with it in a non prod environment and stay ahead of the curve!
You may even like:
Looking to promote your company, product, service, or event to 40,000+ Cloud Native Professionals? Let's work together.
