Skip to main content
Accessing applications from outside a Kubernetes cluster is essential for serving users at scale. Kubernetes uses an abstraction called Ingress to route external HTTP/HTTPS traffic to services within the cluster. By defining hostname- and path-based rules, Ingress acts as a reverse proxy or load balancer, enabling:
  • Multiple services under a single IP
  • SSL/TLS termination at the edge
  • Name-based virtual hosting
The image is a diagram illustrating the concept of Kubernetes Ingress, showing the flow from a client through an ingress-managed load balancer, routing rules, and services to pods within a Kubernetes cluster.
Creating an Ingress resource has no effect until you deploy an Ingress Controller, which watches those resources and configures the edge component—such as NGINX or a cloud load balancer—to implement your routing rules.
The image is a diagram illustrating the flow of traffic through an ingress controller in a Kubernetes cluster, showing components like the client, ingress-managed load balancer, routing rule, and pods.
Ingress Controllers run as pods in your cluster, providing scalability and self-healing. Many offer SSL/TLS termination, authentication, and DNS integration. Some popular controllers include:
ControllerFeatures
NGINX Ingress ControllerWidely adopted, rich annotation support
TraefikDynamic configuration, Let’s Encrypt
HAProxy IngressHigh performance, advanced routing rules
Cloud platforms like AWS, GKE, and AKS also provide managed controllers that integrate with their load balancers and DNS services.

​
Ingress vs. Service

AspectService (NodePort/LoadBalancer)Ingress
ProtocolsTCP/UDP, HTTPHTTP/HTTPS only
Port ExposureArbitrary portsPorts 80 and 443
RoutingNoneHost- and path-based
TLS TerminationNot supportedBuilt-in at the edge
Virtual HostingNoName-based
Services are straightforward to configure, but Ingress provides greater control over HTTP traffic management, security, and virtual hosting.

​
Anatomy of an Ingress Resource

An Ingress resource uses the standard Kubernetes schema: apiVersion, kind, metadata, and spec. Key spec fields include:
  1. Ingress Rules
  2. Default Backend
  3. Resource Backend
  4. Path Types
  5. Annotations
  6. TLS Configuration

​
1. Ingress Rules

Rules map hostnames and URL paths to specific services and ports. You can route different paths or domains to separate backends.
The image is a diagram about "The Ingress Resource" with a highlighted section on "Ingress Rules," indicating it directs traffic based on hostname and URL path.

​
2. Default Backend

The default backend handles requests that don’t match any rule, forwarding them to a specified service and port.
The image is a diagram about "The Ingress Resource" with a highlighted section on "Default Backend," explaining it handles unmatched traffic by directing it to a default service and port.

​
3. Resource Backend

You can reference another Kubernetes resource (in the same namespace) instead of a service. Mixing service and resource in the same backend is invalid.
Resource backends were supported in earlier APIs (e.g., networking.k8s.io/v1beta1) but are not part of the current networking.k8s.io/v1 spec. Controller support varies.
The image is a slide titled "The Ingress Resource" with a menu on the left highlighting "Resource Backend" and a description on the right explaining its function in Kubernetes.

​
4. Path Types

Path types determine how the Ingress Controller matches request URLs:
Path TypeBehavior
ExactMatches the full path exactly
PrefixMatches based on the URL prefix
ImplementationSpecificController-defined matching logic
The image is a diagram explaining "The Ingress Resource" with a focus on "Path Types," detailing three types: Exact, Prefix, and Implementation Specific, each with a brief description.

​
5. Annotations

Annotations enable controller-specific features like SSL redirection, URL rewrites, or rate limiting.
The image is a diagram about "The Ingress Resource" with a menu on the left listing options like "Ingress Rules" and "Annotations," and a highlighted section explaining how to customize ingress behavior.

​
6. TLS Configuration

Specify TLS by referencing Kubernetes Secrets that store certificates and private keys. This configures HTTPS at the Ingress gateway.
The image is a diagram about "The Ingress Resource" with a menu on the left listing options like "Ingress Rules" and "SSL/TLS Configurations," and a lock icon on the right indicating support for HTTPS using TLS certificates.

​
Minimal Ingress Example

This example defines a defaultBackend for unmatched requests and a rule that routes example.com/web* (prefix match) to web-service:80. 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
spec:
  defaultBackend:
    service:
      name: default-service
      port:
        number: 80
  rules:
  - host: "example.com"
    http:
      paths:
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
All traffic not matching /web is sent to default-service:80.

​
Common Ingress Patterns

  • Single-Service Ingress: Routes all traffic to one backend.
  • Simple Fan-Out: Path-based routing to multiple services.
  • Name-Based Virtual Hosting: Hostname-based routing for multiple domains.
  • TLS/SSL Termination: Decrypts HTTPS at the edge and forwards HTTP to services.
The image lists four types of ingress: Single-Service Ingress, Simple Fanout, Name-Based Virtual Hosting, and SSL/TLS Termination, alongside a blue hexagonal icon with arrows and "ing" text.
Controller support and advanced features may vary. Use annotations or Custom Resource Definitions (CRDs) to extend behavior.

​
Key Benefits of Ingress

The image lists the benefits of ingress, including centralized traffic management, enhanced security, flexible routing, scalability, and integration with cloud providers.
  • Centralized traffic management through a single entry point
  • Simplified certificate handling with edge SSL/TLS termination
  • Flexible path- and host-based routing for complex architectures
  • Auto-scaling and high availability via Kubernetes controllers
  • Native integration with cloud load balancers, DNS, and managed certificates
Ingress gives you powerful, centralized control over external HTTP/HTTPS access to your Kubernetes workloads. Next, we’ll dive into Ingress Controllers and deployment strategies.

Watch Video