Mastering Ingress in Kubernetes: Routing Traffic Like a Pro
Ingress exists to expose HTTP and HTTPS routes from outside your Kubernetes cluster to the services running within it. This is essential for managing traffic efficiently and securely. By defining rules on the Ingress resource, you can control how incoming requests are routed. Unlike other services, Ingress does not expose arbitrary ports or protocols, focusing solely on HTTP and HTTPS traffic. For other types of traffic, you would typically use a Service of type NodePort or LoadBalancer.
The Ingress resource is defined with several important parameters. The spec section contains the routing rules, while defaultBackend specifies the backend service that handles requests that do not match any defined rules. You must have an Ingress controller in place to satisfy the Ingress; simply creating an Ingress resource without a controller is ineffective. Be mindful of the ingressClassName—if omitted, a default class should be defined to avoid confusion.
In production, you need to be aware of several key considerations. Always review your Ingress controller's documentation for specific caveats. If you don't specify .spec.rules, you must define .spec.defaultBackend. Otherwise, the handling of unmatched requests is left to the ingress controller, which can lead to unexpected behavior. The Ingress API has been stable since Kubernetes v1.19, so you can rely on its consistency as you build your applications.
Key takeaways
- →Define routing rules in the `spec` section of the Ingress resource.
- →Set `defaultBackend` to handle unmatched requests effectively.
- →Ensure an Ingress controller is deployed to make the Ingress resource functional.
- →Review your Ingress controller's documentation for specific handling of requests.
- →Specify `ingressClassName` to avoid ambiguity in routing.
Why it matters
Ingress is critical for managing external access to your services, enabling efficient traffic routing and enhancing security. Misconfigurations can lead to downtime or security vulnerabilities, impacting user experience and system reliability.
Code examples
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4 name: minimal-ingress
5spec:
6 ingressClassName: nginx-example
7 rules:
8 - http:
9 paths:
10 - path: /testpath
11 pathType: Prefix
12 backend:
13 service:
14 name: test
15 port:
16 number: 801apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4 name: ingress-resource-backend
5spec:
6 defaultBackend:
7 resource:
8 apiGroup: k8s.example.com
9 kind: StorageBucket
10 name: static-assets
11 rules:
12 - http:
13 paths:
14 - path: /icons
15 pathType: ImplementationSpecific
16 backend:
17 resource:
18 apiGroup: k8s.example.com
19 kind: StorageBucket
20 name: icon-assets1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4 name: ingress-wildcard-host
5spec:
6 rules:
7 - host: "foo.bar.com"
8 http:
9 paths:
10 - pathType: Prefix
11 path: "/bar"
12 backend:
13 service:
14 name: service1
15 port:
16 number: 80
17 - host: "*.foo.com"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 docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Deploying Dragonfly Lightweight: P2P Distribution Without the Database Overhead
Tired of heavyweight database stacks slowing down your deployments? Discover how a lightweight Dragonfly deployment leverages Kubernetes primitives like ConfigMaps and headless Services for efficient P2P distribution. This approach simplifies your architecture while maintaining performance.
K8gb: Elevating Global Load Balancing in Kubernetes
K8gb is now a CNCF incubating project, marking a significant step in cloud-native global server load balancing. It automates traffic management and ensures seamless failover using Kubernetes-native health checks and CoreDNS.
TCPRoute and UDPRoute in Gateway API v1.6: What You Need to Know
The Gateway API v1.6 marks a significant step forward with TCPRoute and UDPRoute graduating to standard status. These resources allow you to route traffic based solely on protocol and port, simplifying your networking configurations in Kubernetes.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.