Tigera Logo

Guides: Kubernetes Ingress

Kubernetes Ingress: Uses, Types, and Code Examples

What Is Kubernetes Ingress?

Kubernetes ingress is an API object that manages external access to services within a Kubernetes cluster, typically over HTTP and HTTPS. It allows users to define and configure how load balancing, SSL termination, and name-based virtual hosting occur for applications. By integrating with existing network infrastructure, Kubernetes ingress ensures consistent and secure user access to applications.

Unlike managing services independently, ingress provides a unified approach to handle multiple services, simplifying the management of routing rules. Ingress acts as an entry point, which can manage and enforce routing policies, SSL configurations, and traffic splits, all from a centralized resource. This reduces the overhead of configuring multiple external access points manually.

Kubernetes Ingress is widely considered as a legacy technology, now that the Kubernetes project has introduced the Gateway API. Refer to the Kubernetes Ingress vs. API Gateway section below to learn about the differences between these two technologies.

This is part of a series of articles about Kubernetes networking.

In this article:

What Is a Kubernetes Ingress Controller?

A Kubernetes ingress controller is responsible for fulfilling ingress rules. It routes external requests to services within the Kubernetes cluster based on the specified ingress configurations. The controller is a daemon that uses these rules to determine how to load balance, route, and handle traffic.

There are several ingress controllers available, each with varying features and performance capabilities. Popular options include NGINX, HAProxy, and Traefik. They often provide features like custom metrics and additional security controls beyond basic ingress functionality.

Related content: Read our guide to Kubernetes security

Kubernetes Ingress vs Kubernetes Egress

Kubernetes ingress and egress serve distinct roles in managing network traffic.

An ingress handles incoming connections and routes external requests to services within the cluster, focusing on securing and managing access to applications. It centers on connecting users to applications.

An egress manages outbound connections from within the cluster to external services, controlling the destination-specific access of pods. Egress is crucial for interactions initiated by services within the cluster. Controlling egress traffic is vital for security, allowing only authorized communication with external systems.

Learn more in our detailed guide to Kubernetes egress

Kubernetes Ingress vs Kubernetes API Gateway

Kubernetes API Gateway was developed to address limitations within Kubernetes Ingress by providing a standardized model for traffic management across different ingress controllers. Unlike Ingress, which focuses on HTTP traffic, the Gateway API introduces resource objects that enable more advanced traffic control and flexibility.

With support for both L4 and L7 protocols, it provides a more comprehensive solution for network traffic management within Kubernetes. By allowing the use of new resource objects like GatewayClass, Gateway, and HTTPRoute, the Gateway API enables advanced routing, traffic management features, and improved portability across different controller implementations.

Key differences between Kubernetes Ingress and Gateway API:

  • Protocol support: Ingress only supports L7 protocols like HTTP and HTTPS, requiring custom extensions for non-L7 protocols. API Gateway natively supports both L4 (e.g., TCP, UDP) and L7 protocols.
  • Portability: Ingress definitions are vendor-specific, with unique syntax and features. Gateway API creates a consistent standard across all compliant controllers, reducing the need for custom configurations and enabling easy migration.
  • Traffic management: Ingress has limited built-in traffic management, requiring extensions for features like request mirroring or A/B testing. API Gateway provides built-in support for these advanced capabilities and fine-grained metrics.
  • Resource object definitions: Ingress does not introduce new resource objects, whereas Gateway API introduces multiple new objects, including GatewayClass, Gateway, and HTTPRoute, offering more granular control over traffic rules and capabilities.
  • Routing customization: Ingress is limited to path or host-based routing. API Gateway allows for route customization based on various factors, including arbitrary header fields, paths, and hosts.
  • Extensibility: Enhancing features like authentication or rate limiting in Ingress typically requires custom annotations. In API Gateway, these capabilities are built into the specification, providing a simpler approach to extending functionality.

Related content: Read our guide to Kubernetes Gateway API

Primary Uses of Kubernetes Ingress

Using Kubernetes ingress can offer several advantages.

Load Balancing

Load balancing is a feature provided by Kubernetes ingress that improves application performance and availability. By distributing incoming traffic across multiple backend pods, ingress ensures that no single pod becomes a bottleneck. This supports dynamic scaling, where additional pods can be added without user intervention.

Kubernetes ingress handles both layer 7 (application layer) and layer 4 (transport layer) load balancing. Through algorithms, it can balance traffic based on round-robin or other strategies, depending on the needs of the application.

SSL/TLS Termination

SSL/TLS termination in Kubernetes ingress improves security by offloading encryption and decryption tasks from application services to the ingress layer. This reduces the computational load on backend services. Ingress takes charge of managing SSL certificates, simplifying the deployment process while ensuring security practices are in place.

Using ingress for SSL/TLS termination also enables easier certificate updates and renewals. Administrators can manage SSL configurations centrally, applying updates across multiple services simultaneously.

Centralized Access Control

Centralized access control via Kubernetes ingress simplifies the management of user permissions and traffic policies. By providing a single entry point, it consolidates access control configurations, reducing the complexity associated with managing separate firewall rules for each service.

Ingress enables control over incoming requests, allowing administrators to define rules based on IP ranges, request headers, or paths. This is important for deploying secure, multi-tenant environments where access requirements may vary.

For pod-to-pod and cluster-wide traffic controls that complement ingress-level access rules, see our guide to kubernetes network policy.

URL-Based Routing

URL-based routing allows precise traffic distribution to various services based on request paths. This feature is helpful for microservices architectures where different parts of an application are separate services. By specifying URL patterns, administrators can direct traffic to the appropriate service endpoints.

This routing capability allows easier version upgrades and service scaling. Services can be independently deployed and modified without impacting the overall system. Ingress makes this possible by interpreting and enforcing routing rules, automatically directing user requests to the appropriate destinations based on the defined URL paths.

Tips from the Expert

In my experience, here are tips that can help you better work with Kubernetes ingress:

  1. Optimize for low-latency traffic with HTTP2/GRPC support:

    Enable HTTP2 or gRPC in your ingress controller when handling microservices or real-time applications. These protocols are more efficient for low-latency communication and can significantly reduce overhead compared to HTTP 1.1, especially in environments with many small requests.

  2. Use external DNS providers for dynamic ingress updates:

    Integrate external DNS providers with Kubernetes ingress to automatically handle DNS updates when services scale or ingress rules change. This prevents manual DNS adjustments and ensures seamless scalability and service availability.

  3. Leverage mutual TLS for enhanced security:

    Mutual TLS (mTLS) can provide stronger security by requiring both the client and server to authenticate each other. This is crucial for internal services, especially in multi-tenant environments where service communication needs to be tightly controlled.

  4. Implement rate limiting at the ingress layer:

    While ingress handles traffic distribution, adding rate limiting at the ingress level can help protect your services from DDoS attacks or abuse. This can be done with ingress annotations or by integrating with a service mesh like Istio that supports fine-grained traffic control.

  5. Offload authentication and authorization to ingress:

    Instead of embedding authentication/authorization logic in each service, centralize it at the ingress layer. Use tools like OAuth2 proxies or JWT token validation directly within the ingress configuration to enforce security policies before traffic reaches your services.

Profile Picture

Peter Kelly

VP of Engineering

Peter Kelly is VP of Engineering at Tigera and Site Leader for Tigera's EMEA office in Cork, Ireland. He is responsible for all of Tigera’s Engineering teams and operations. Peter has two decades of experience in software development, including recently building control plane technology for open-source proxies at NGINX and later F5 Networks, where he held engineering leadership positions. Peter has a degree in Computer Science and a Masters in Advanced Software Engineering.

Types of Ingress

There are three main types of Kubernetes Ingress: single service, simple fanout, and name-based virtual hosting.

Single Service Ingress

Single service ingress directs all external traffic to a single Kubernetes service. This is the simplest form of ingress, where no routing rules exist, and the configuration points directly to a specific application endpoint. It is suitable for straightforward applications requiring a direct path for user requests.

Simple Fanout Ingress

Simple fanout ingress provides routing capabilities to multiple services based on URL paths. This type of ingress allows different parts of an application to be served independently, supporting modular service architectures like microservices. Each path in the URL specifies a different service, allowing diverse application components to coexist and interact.

Name-Based Virtual Hosting

Name-based virtual hosting allows Kubernetes ingress to direct traffic based on hostnames. This method supports applications that require hosting multiple domains on the same ingress resource, enabling efficient use of resources and simplifying DNS management. It is advantageous for SaaS providers supporting multiple tenants with distinct domain names.

When ingress patterns extend across more than one cluster — for example, to serve tenants from multiple regions — see our guide to kubernetes multi cluster networking.

Kubernetes Ingress Examples

Example 1: Minimal Ingress Resource

The simplest form of Kubernetes Ingress is one that directs traffic to a single service without any complex routing rules. Here’s an example of a minimal Ingress resource:

apiVersion: networking.k8s.io/v1

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

In this configuration:

  • apiVersion, kind, and metadata define the type and name of the Ingress resource.
  • The annotations field is specific to the chosen Ingress controller. For instance, the nginx.ingress.kubernetes.io/rewrite-target annotation rewrites all incoming requests to the specified path.
  • The spec field defines the routing rules. In this case, all traffic directed to /web will be forwarded to the web-service service on port 80.
  • The ingressClassName specifies that the nginx Ingress controller should manage this resource.

This example highlights how simple routing can be achieved by defining basic HTTP paths and directing traffic to a service without requiring a complex setup.

Example 2: Ingress with Host-Based and Path-Based Rules

A more advanced use case involves defining different routing rules based on both hostname and URL path. This is useful for applications that support multiple services under various domains:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-service-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: service1.mydomain.com
    http:
      paths:
      - path: /service1
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80
      - path: /service2
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 80
  - host: service3.mydomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service3
            port:
              number: 80

In this configuration:

  • The first rule applies to requests coming to example.com. It routes traffic based on the URL paths /service1 and /service2, forwarding requests to different backend services (service1 and service2).
  • The second rule applies to traffic directed to another.com, routing all requests to service3 at the root (/).

This setup illustrates how Kubernetes Ingress can handle more complex routing scenarios, making it suitable for microservices architectures where different components require separate routing logic based on hostnames and paths.

Example 3: Ingress with Resource Backend

In addition to routing to services, Kubernetes Ingress can also direct traffic to other resources, such as object storage backends. Here’s an example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: api.mydomain.com
      kind: FileStorage
      name: cdn-content
  rules:
    - http:
        paths:
          - path: /images
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: api.mydomain.com
                kind: FileStorage
                name: images

In this example:

  • The defaultBackend directs all unmatched traffic to a resource backend, in this case, a FileStorage named cdn-content.
  • The rule specifies that traffic to /images is routed to a different FileStorage called images.

This is useful for routing traffic to object storage resources, such as static assets or files hosted in an external storage service.

Kubernetes Ingress with Calico

The Calico Ingress Gateway leverages the Kubernetes Gateway API, offering several advantages over traditional ingress controllers:

  • Advanced Traffic Management: Facilitates complex routing policies
  • Modular and Extensible Architecture: Separates the actual gateway from routing rules enabling the organization to adapt to evolving networking requirements.
  • Improved Portability and Consistency: Ensures seamless operation across different Kubernetes implementations.
  • Role-Based Management and Multi-Tenancy: Simplifies access control and enables efficient resource sharing.
  • Broader Use Cases: Supports non-HTTP protocols, enabling flexibility in handling diverse traffic types.
  • Future-Proof Design: Aligns with vendor-neutral standards to avoid vendor lock-in.

Calico ingress gateway

In addition to fully supporting the Kubernetes Gateway API spec, Calico Ingress Gateway also plans to add robust security and observability for ingress traffic, such as:

  • Workload-Based WAF: Protects ingress pods with granular, application-specific security.
  • Deep Packet Inspection (DPI): Detects malicious payloads.
  • DDoS Protection: Shields Kubernetes clusters from distributed denial-of-service attacks.
  • Dynamic Service and Threat Graph: Offers better visibility into traffic patterns and improved status reporting.

Next steps:

X