OpsCanary
Back to daily brief
kubernetesnetworkingPractitioner

Mastering Ingress in Kubernetes: Routing Traffic Like a Pro

5 min read Kubernetes DocsApr 21, 2026
PractitionerHands-on experience recommended

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

YAML
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: 80
YAML
1apiVersion: 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-assets
YAML
1apiVersion: 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 docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.