top of page
Search

Ingress service types in Kubernetes

Updated: Feb 15, 2024

Kubernetes, the popular container orchestration platform, offers a powerful built-in configuration object known as Ingress for managing HTTP load balancing. In this guide, we'll delve into the intricacies of Kubernetes Ingress, its features, configuration, and practical examples.


Ingress Overview

Ingress serves as a crucial component for managing external connectivity to Kubernetes services. Key points to note:

  • Ingress facilitates the routing of HTTP traffic based on defined rules.

  • It supports SSL termination, enhancing security for incoming connections.

  • Name-based virtual hosting is enabled, allowing multiple websites to be hosted on a single IP address.


Ingress Resource and Configuration

The Ingress resource plays a pivotal role in configuring load balancers or proxy servers within a Kubernetes cluster. Detailed information includes:

  • Ingress specifications are defined within the resource, controlling traffic routing.

  • Rules specified within the Ingress resource dictate how incoming requests are processed.


Here's an example configuration demonstrating the setup of an Ingress resource:

--- 
apiVersion: extensions/v1beta1
kind: Ingress
metadata: 
  name: app-ingress
spec: 
  rules: 
    - 
      http: 
        paths: 
          - 
            backend: 
              serviceName: app-service
              servicePort: 80
            path: /

Ingress resource solely supports rules for steering communications protocol (HTTP)traffic. The Ingress specification has all the data required to put together a load balancer or proxy server. most significantly, it contains a listing of rules matched against all incoming requests.


Ingress rules

Ingress rules are pivotal in determining how traffic is directed within a Kubernetes cluster. Key insights include:

  • Ingress exclusively supports rules for managing HTTP traffic.

  • The Ingress specification encompasses all necessary data to configure load balancers or proxy servers.

  • A list of rules is matched against incoming requests to facilitate effective traffic management.


Ingress Service Types in Kubernetes

  1. Single Service Ingress:  Used when there's a need to create a default backend without any specific routing rules.

  2. Simple Fanout: Enables distributing traffic among different services based on specific URI paths.

  3. Name-based Virtual Hosting: Allows hosting multiple websites or services on the same IP address by distinguishing them based on the hostname in the HTTP header.

  4. Ingress Controller: Translates Ingress resource specifications into configuration settings for load balancers or proxy servers.

  5. Annotation and Ingress Class: Ensures that the appropriate Ingress controller is utilized to manage the traffic routing defined in the Ingress resource.


1. Single Service Ingress

Single Service Ingress refers to a type of Ingress configuration within Kubernetes that doesn't involve any specific routing rules and directs all incoming traffic to a single Kubernetes service.


The primary purpose of Single Service Ingress is to establish a default backend for routing incoming traffic with simplicity. It allows for a straightforward configuration where all requests are forwarded to a designated service without any conditions or path-based routing.

--- 
apiVersion: extensions/v1beta1
kind: Ingress
metadata: 
  name: frontend-ingress
spec: 
  backend: 
    serviceName: frontend-service
    servicePort: 80

apiVersion: Specifies the version of the Ingress resource.


kind: Indicates the type of Kubernetes resource, which is Ingress in this case.


metadata: Contains metadata about the Ingress resource, such as its name.


name: Specifies the name of the Ingress resource, which is "frontend-ingress" in this example.


spec: Specifies the configuration details for the Ingress.

  • backend: Defines the backend configuration for routing all traffic.

  • serviceName: Specifies the name of the Kubernetes service to which traffic should be directed, which is "frontend-service" in this case.

  • servicePort: Specifies the port of the backend service to which traffic should be directed, which is port 80 in this example.


In the above code:

This Ingress configuration does not contain any explicit rules for routing traffic based on paths or hosts.


Instead, it defines a default backend using the "backend" field under the "spec" section.


All incoming traffic to this Ingress will be automatically directed to the specified service ("frontend-service") on port 80.


Single Service Ingress simplifies the configuration process by eliminating the need for specifying complex routing rules.


It is commonly used when there's a need to set up a default backend for handling all incoming requests without any specific conditions or path-based routing requirements.


Use Cases:

Single Service Ingress is particularly useful in scenarios where:

  • Default Backend Requirement: There's a need to establish a default backend to handle all incoming traffic without any specific routing rules or conditions. This could be necessary when setting up a catch-all endpoint for handling requests that don't match any specific paths or hosts.

  • Simplicity and Ease of Configuration: When the goal is to keep the configuration simple and straightforward, Single Service Ingress provides an uncomplicated solution by eliminating the need for complex routing rules.


Advantages:

  • Simplicity: Single Service Ingress offers a straightforward approach to routing traffic, making it easier to configure and manage compared to more complex routing configurations.

  • Default Backend Establishment: This allows for the creation of a default backend to handle all incoming traffic, ensuring that requests are not dropped if they do not match any specific rules.

  • Reduced Complexity: By eliminating the need for intricate routing rules, Single Service Ingress simplifies the overall configuration process, reducing the complexity involved in managing traffic routing within Kubernetes clusters.


Considerations:

  • Limited Flexibility: While Single Service Ingress provides simplicity and ease of configuration, it may not be suitable for scenarios requiring more granular control over traffic routing based on specific criteria such as paths or hosts.

  • Potential Overload: Directing all incoming traffic to a single service as a default backend could potentially lead to overload or scalability issues, especially if the service is not designed to handle high volumes of traffic.

  • Future Scalability: It's important to consider future scalability requirements when using Single Service Ingress. As the application grows and traffic patterns evolve, there may be a need to implement more sophisticated routing strategies to efficiently manage incoming requests.


Best Practices:

  • Monitor Traffic Patterns: Regularly monitor traffic patterns and performance metrics to ensure that the default backend configured through Single Service Ingress can handle incoming traffic effectively.

  • Plan for Scalability: Anticipate future scalability requirements and be prepared to evolve the Ingress configuration accordingly to accommodate increasing traffic volumes and changing application needs.

  • Combine with Other Ingress Types: While Single Service Ingress provides a simple default backend solution, consider combining it with other types of Ingress configurations, such as path-based routing or name-based virtual hosting, to achieve more comprehensive traffic management capabilities.


2. Simple fanout

Simple Fanout is a type of Ingress configuration in Kubernetes that routes incoming HTTP traffic to multiple services based on the requested HTTP URI.


The primary purpose of Simple Fanout is to distribute incoming traffic among multiple Kubernetes services based on specific URI paths. This allows for more granular control over how requests are handled and enables the implementation of different functionalities for different paths.

--- 
apiVersion: extensions/v1beta1
kind: Ingress
metadata: 
  name: simple-fanout-example
spec: 
  rules: 
    - 
      host: shopping.example.com
      http: 
        paths: 
          - 
            backend: 
              serviceName: clothes-service
              servicePort: 8080
            path: /clothes
          - 
            backend: 
              serviceName: House-service
              servicePort: 8081
            path: /kitchen

In this Simple Fanout configuration, incoming traffic with the hostname "shopping.example.com" is routed based on specific URI paths.


Requests with the "/clothes" path are directed to the "clothes-service" Kubernetes service on port 8080.


Requests with the "/kitchen" path are directed to the "house-service" Kubernetes service on port 8081.


Simple Fanout allows for the implementation of different functionalities for different paths under the same hostname, enabling more flexible routing configurations.


Use Cases:

  • Microservices Architecture: In a microservices-based application, different services may be responsible for handling requests related to different functionalities or features. Simple Fanout allows incoming requests to be routed to the appropriate service based on the requested URI path.

  • API Gateway: Simple Fanout can be used as part of an API gateway setup where incoming requests are directed to different backend services based on the API endpoints defined in the URI paths.

  • Content Delivery: For websites or applications serving different types of content (e.g., articles, images, videos), Simple Fanout can be used to route requests to different backend services handling each type of content.


Advantages:

  • Flexible Routing: Simple Fanout provides flexibility in routing traffic based on specific URI paths, allowing for the implementation of different functionalities or services for different parts of an application.

  • Scalability: By distributing traffic among multiple backend services, Simple Fanout supports scalability by allowing each service to scale independently to handle increasing loads for their respective paths.

  • Separation of Concerns: Simple Fanout enables a clean separation of concerns by allowing different backend services to handle requests related to different parts or features of an application.


Considerations:

  • Overhead: Distributing traffic among multiple backend services may introduce additional overhead compared to routing all traffic to a single service. It's essential to monitor performance metrics to ensure that the overhead is acceptable and does not impact overall application performance.

  • Configuration Complexity: As the number of backend services and routing rules increases, the configuration complexity of Simple Fanout may also increase. Careful planning and organization of routing rules are necessary to maintain a manageable configuration.


Best Practices:

  • Path Organization: Organize URI paths logically and consider the granularity of routing rules to maintain a clear and understandable configuration.

  • Monitoring and Scaling: Monitor traffic patterns and performance metrics to identify potential bottlenecks and scale backend services accordingly to handle increasing loads.

  • Security Considerations: Implement appropriate security measures, such as access control and authentication, for each backend service to ensure the security of the application.


3. Name-based virtual hosting

Name-based virtual hosting is a method used to route HTTP traffic to multiple hostnames based on the hostname specified in the HTTP request. This allows a single server to host multiple websites or services, each identified by its own hostname.


Instead of relying on IP addresses, name-based virtual hosting routes incoming requests based on the hostname specified in the HTTP request's Host header.


The primary purpose of name-based virtual hosting is to enable a server to serve multiple websites or services using a single IP address. This method is particularly useful in scenarios where resources are shared among multiple domains or when different services need to be hosted on the same server.


Implementation in Kubernetes Ingress:

In Kubernetes, name-based virtual hosting is implemented using the Ingress resource, which defines rules for routing traffic to backend services based on hostnames and paths.


Each Ingress rule specifies a hostname and its corresponding HTTP routing configuration, including paths and backend services.


Example Configuration:

--- 
apiVersion: extensions/v1beta1
kind: Ingress
metadata: 
  name: name-virtual-host-ingress
spec: 
  rules: 
    - 
      host: shopping.example.com
      http: 
        paths: 
          - 
            backend: 
              serviceName: clothes-service
              servicePort: 8080
            path: /clothes
          - 
            backend: 
              serviceName: House-service
              servicePort: 8081
            path: /kitchen
    - 
      host: music.example.com
      http: 
        paths: 
          - 
            backend: 
              serviceName: Hindi-service
              servicePort: 9090
            path: /hindhi
          - 
            backend: 
              serviceName: English-service
              servicePort: 9091
            path: /english

In this configuration, there are two different hostnames specified: "shopping.example.com" and "music.example.com".


Requests with the hostname "shopping.example.com" are routed to the specified backend services based on the specified paths ("/clothes" and "/kitchen").


Similarly, requests with the hostname "music.example.com" are routed to different backend services based on different paths ("/hindhi" and "/english").


This allows the server to host multiple websites or services, each accessible via its own hostname.


Benefits and Use Cases:

  • Resource Efficiency: Name-based virtual hosting allows for efficient utilization of server resources by enabling multiple websites or services to share the same IP address and server resources.

  • Cost-effectiveness: By hosting multiple sites or services on a single server, organizations can reduce infrastructure costs associated with maintaining separate servers for each domain or service.

  • Scalability: Name-based virtual hosting facilitates easy scaling as new websites or services can be added without the need for additional IP addresses or servers.

  • Use Cases: Common scenarios where name-based virtual hosting is beneficial include hosting multiple domains on the same server, serving different versions of an application based on subdomains, and hosting a combination of static and dynamic content under different hostnames.


Best Practices:

  • Clear Organization: Organize hostnames and paths logically to ensure clarity and maintainability of the Ingress configuration.

  • Monitoring and Scaling: Regularly monitor traffic patterns and performance metrics to identify potential bottlenecks and scale backend services accordingly.

  • Security Considerations: Implement appropriate security measures, such as TLS termination and access control, to protect hosted websites or services.


4. Ingress controller

An Ingress Controller is a Kubernetes resource responsible for implementing the Ingress specifications, which define rules for routing external HTTP and HTTPS traffic to services within the cluster.


Ingress controllers act as intermediaries between external traffic and services running inside the cluster, managing traffic routing, SSL termination, and other functionalities defined in the Ingress resource.


Importance and Role:

  • Enabling External Access: Ingress controllers play a vital role in enabling external access to services deployed within the Kubernetes cluster, allowing external clients to communicate with applications running inside the cluster.

  • Traffic Management: Ingress controllers handle traffic routing based on rules defined in the Ingress resource, directing incoming requests to appropriate backend services based on specified criteria such as hostnames and paths.

Ingress controller in kubernetes

Ingress controllers are integrated into the Kubernetes ecosystem and typically run as part of the Kube-controller-manager, which is responsible for managing various controllers within the cluster.


In most Kubernetes deployments, Ingress controllers are automatically started along with the cluster initialization process, ensuring seamless operation without manual intervention.


Popular Ingress Controller Options:

  • NGINX Ingress Controller: Provided and supported by NGINX, Inc., the NGINX Ingress Controller is a widely used and robust solution for managing HTTP and HTTPS traffic in Kubernetes clusters. It offers features such as SSL termination, load balancing, and advanced routing capabilities.

  • Contour: Contour is an Envoy-based Ingress controller provided and supported by Heptio. It leverages the capabilities of Envoy Proxy for efficient traffic management and offers features such as HTTP/2 support and WebSocket routing.

  • Traefik: Traefik is a fully-featured Ingress controller that provides support for Let's Encrypt integration, secrets management, HTTP/2, and WebSocket protocols. It also offers commercial support by Continuous, making it a popular choice for production environments.

  • Ambassador API Gateway: Ambassador is an Envoy-based API Gateway and Ingress controller with support from Datawire. It offers features such as rate limiting, authentication, and observability for managing API traffic in Kubernetes clusters.

  • Citrix Ingress Controller: Citrix provides an Ingress Controller specifically designed for its hardware (MPX), virtualized (VPX), and containerized (CPX) Application Delivery Controllers (ADC). It offers advanced traffic management features suitable for bare-metal and cloud deployments.

  • F5 BIG-IP Controller: F5 Networks offers the F5 BIG-IP Controller for Kubernetes clusters, providing support and maintenance for integrating Kubernetes deployments with F5's industry-leading BIG-IP Application Delivery Controllers.

  • Gloo: Gloo is an open-source Ingress controller supported by solo.io, leveraging Envoy Proxy for managing API traffic. It offers features such as API gateway functionality and enterprise support for organizations requiring advanced traffic management capabilities.

  • HAProxy Ingress Controller: HAProxy Technologies offers the HAProxy Ingress Controller for Kubernetes, providing support for HAProxy Enterprise features and DevOps-friendly configurations for managing HTTP and HTTPS traffic.


5. Annotation and Ingress Class

Annotations are key-value pairs that provide additional metadata or instructions to Kubernetes resources. In the context of Ingress resources, annotations are used to specify configuration details or to associate the Ingress resource with a particular Ingress controller.


Ingress Class

Ingress Class is a Kubernetes resource introduced in Kubernetes version 1.18 to allow multiple Ingress controllers to be deployed within a cluster. Each Ingress controller is associated with a specific Ingress Class, and Ingress resources are annotated with the appropriate Ingress Class to specify which controller should handle the routing rules defined in the Ingress.


Importance and Role:

  • Multi-controller Deployment: Annotation and Ingress Class support the deployment of multiple Ingress controllers within a Kubernetes cluster, allowing organizations to choose the most suitable controller for their specific requirements.

  • Controller Selection: By annotating Ingress resources with the appropriate Ingress Class, administrators can specify which Ingress controller should manage the routing rules defined in the Ingress resource.


Annotating Ingress Resources:

--- 
metadata: 
  annotations: 
    kubernetes.io/ingress.class: nginx
  name: my-ingress

In this example, the Ingress resource is annotated with kubernetes.io/ingress.class: nginx, indicating that the routing rules defined in this Ingress resource should be handled by the NGINX Ingress controller.


Default Ingress Provider:

If the kubernetes.io/ingress.class annotation is not defined in the Ingress resource, the cloud provider may use a default Ingress provider. It's important to specify the appropriate Ingress Class to ensure that the desired controller handles the traffic routing.


Best Practices:

  • Consistent Naming Convention: Adopt a consistent naming convention for Ingress resources and Ingress Classes to simplify management and troubleshooting.

  • Clear Documentation: Document the purpose and configuration details of each Ingress resource, including the associated Ingress Class, to facilitate collaboration among team members and ensure proper configuration.


Considerations:

  • Controller Compatibility: Ensure that the selected Ingress controller supports the features and functionality required by the application or service being deployed.

  • Resource Management: Monitor resource utilization and performance metrics of Ingress controllers to optimize resource allocation and ensure reliable operation.



Conclusion

Understanding the various Ingress service types in Kubernetes is essential for effectively managing external access to services within the cluster. Whether utilizing NodePort, LoadBalancer, or Ingress, each type offers distinct advantages and use cases. NodePort provides simplicity and accessibility, LoadBalancer offers scalability and automation, while Ingress provides advanced routing capabilities.

Commentaires

bottom of page