In this lesson, you will learn how to abstract external traffic routing away from individual Service definitions to gain granular control over your infrastructure.
The Problem: Tight Coupling
In basic Kubernetes setups, your Service acts as both the internal load balancer and the gateway for external traffic. When you define an Ingress or a Service of type LoadBalancer that points directly to a specific deployment, you create a rigid dependency. If you need to change how traffic is routed—such as implementing header-based routing, path rewrites, or global rate limiting—you often have to modify the Service manifests themselves, which risks destabilizing internal communication between pods.
The Solution: Decoupling via Ingress Controllers
By using an Ingress Controller as an independent traffic management layer, you decouple the "entry point" from the "service backend." Instead of your application services handling the complexities of incoming HTTP/HTTPS traffic, the Ingress Controller acts as a dedicated traffic cop.
Think of it this way: your Service resources should only care about grouping pods together internally, while your Ingress resources—managed by the controller—handle the external traffic logic.
# A simple Ingress that routes traffic without needing
# complex logic inside the backend Service definition.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: api.example.com
http:
paths:
- path: /v1
pathType: Prefix
backend:
service:
name: user-service # Points to the backend, not the logic
port:
number: 80
Why This Matters for GitOps
When you decouple traffic management, your Service manifests remain static, focusing solely on internal pod discovery. Meanwhile, your traffic routing rules (like canary weights or path-based routing) live in separate Ingress or Gateway resources. This modularity allows your Argo CD pipelines to update traffic routing configurations independently of your application deployment manifests. You can scale your traffic strategy, introduce WAF policies, or modify routing rules without ever touching the core application code or the pods' internal service configuration.
Key Takeaway: By moving routing logic into an independent Ingress layer, you decouple infrastructure concerns from application logic, allowing for safer, more flexible traffic manipulation without modifying your internal service definitions.