Kubernetes Ingress Tutorial

What is Ingress in Kubernetes?

Ingress in Kubernetes serves as the gateway that allows external HTTP and HTTPS routes to access services within the cluster. Traffic direction is governed by rules specified in the Ingress resource.

A straightforward example involves an Ingress directing all its traffic to a single Service. In practical scenarios, Ingress can be configured to provide services with external URLs, perform load balancing, terminate SSL/TLS encryption, and enable name-based virtual hosting. The responsibility of fulfilling the Ingress falls on the Ingress controller, often utilizing a load balancer. Alternatively, the edge router or additional front ends may assist in handling the incoming traffic.

However, it's important to note that Ingress does not expose arbitrary ports or protocols. If other services, apart from HTTP and HTTPS, need internet exposure, Kubernetes typically employs a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

Terminologies Used

Ingress in Kubernetes is an API object that facilitates external access to services running within the cluster. It serves as a traffic manager, directing incoming HTTP and HTTPS requests to the appropriate services based on specified rules and configurations.

• Node:
  In the context of Kubernetes, a node refers to a worker machine within a cluster. It plays a crucial role in executing tasks and running containerized applications managed by Kubernetes. Notably, nodes are typically isolated from the public internet in common Kubernetes deployments, focusing on internal communication within the cluster.
• Cluster:
  A cluster in Kubernetes represents a collection of nodes that work together to run containerized applications. It forms the core infrastructure for managing and orchestrating these applications efficiently. While nodes handle the application workload, the cluster provides the overarching framework for coordination and management.
• Edge router:
  An edge router is a networking component responsible for enforcing the firewall policy for the Kubernetes cluster. It acts as the gateway, regulating the flow of traffic between the cluster and the external world. The edge router can either be managed by a cloud provider or a physical hardware device, depending on the deployment setup.
• Cluster network:
  The cluster network is a vital set of connections, which can be either logical or physical, enabling seamless communication among the nodes within the Kubernetes cluster. It adheres to the Kubernetes networking model, facilitating efficient data exchange and coordination between various components.
• Service:
  In Kubernetes, a service represents an essential abstraction that identifies a group of pods using label selectors. Services enable stable endpoints for accessing the pods, providing a reliable way to interact with the application components. It's important to note that services usually have virtual IPs, limiting their reachability to within the cluster network, unless explicitly configured otherwise.

What is Ingress Class in Kubernetes?

In Kubernetes, an Ingress Class is a way to define and select the Ingress controller that should be used to manage the incoming traffic for a specific Ingress resource. It allows you to have multiple Ingress controllers running in your cluster, each specializing in handling different types of traffic or having specific configurations.

When you create an Ingress resource, you can specify the desired Ingress Class using the kubernetes.io/ingress.class annotation. The Ingress controller with a matching class name will be responsible for processing the rules and configurations defined in that Ingress resource.

In Kubernetes, the IngressClass resource plays a pivotal role in managing how Ingress resources handle external traffic. Here are some important points to understand about the IngressClass:

• IngressClass Scope:
  The IngressClass resource has a cluster-wide scope, meaning it can be utilized by Ingress resources from any namespace within the Kubernetes cluster. This flexibility enables different Ingress resources in various namespaces to make use of the same Ingress controller or opt for different controllers based on their specific requirements. It allows for better customization and segregation of traffic management.
• Deprecated Annotation:
  In earlier versions of Kubernetes, the kubernetes.io/ingress.class annotation was employed to specify the Ingress controller for an Ingress resource. However, this approach has been deprecated in favor of using the IngressClass resource for a more structured and extensible association. By embracing IngressClass, Kubernetes aims to improve the overall management and configuration of Ingress controllers, ensuring better compatibility with evolving features.
• Default IngressClass:
  A Kubernetes cluster can have a default IngressClass set. This default class serves as a fallback option for Ingress resources that do not explicitly specify any particular IngressClass. When an Ingress resource lacks a specified class, it will automatically be handled and managed by the default controller associated with the default IngressClass. It ensures that all Ingress resources, even those without a specified class, can still be routed and processed correctly. If no default IngressClass is defined, Ingress resources without a specified class will not be processed by any Ingress controller, leading to potential issues with traffic routing.

Types of Ingress

There are multiple types of ingress:

• Ingress backed by a single Service:
  This type of ingress in kubernetes allows you to route incoming traffic from external sources to a single Kubernetes Service within the cluster. The Ingress resource defines rules to match the incoming requests, and based on the specified hostnames or paths, the traffic is forwarded to the backend Service. It's a straightforward and common use case where all the external requests are directed to a single backend service.
• Simple fanout:
  In this type of ingress in kubernetes, incoming traffic is distributed or "fanned out" to multiple backend Services based on different paths. Each path in the Ingress resource corresponds to a specific backend Service. This allows you to have different services handling different parts of your application based on the URL path of the incoming request.
• Name-based virtual hosting:
  Name-based virtual hosting enables you to host multiple websites or applications on the same IP address, distinguished by their domain names. This type of ingress in Kubernetes can be achieved using by defining rules that match different hostnames, and each hostname is associated with a specific backend Service. This way, a single Ingress controller can handle traffic for multiple domains and route it to the appropriate services based on the hostname in the HTTP request.
• TLS (Transport Layer Security):
  This type of ingress in kubernetes is used to secure the communication between the client and the server using encryption. By configuring TLS in the Ingress resource, you can enable SSL/TLS termination at the Ingress controller, allowing encrypted traffic to be decrypted at the controller and then forwarded to the backend Service over an unencrypted connection. This is especially useful when you want to offload the SSL/TLS decryption process from your backend services.

Hostname WildCards

Hostname wildcards, also known as wildcard hostnames or wildcard DNS, are a feature used in the DNS (Domain Name System) configuration to match multiple subdomains or hostnames with a single wildcard entry. Instead of specifying individual subdomains explicitly, a wildcard character (*) is used to represent any subdomain that matches the specified pattern.

For example, if you have a domain example.com and you want to handle all subdomains under it, such as app.example.com, api.example.com, blog.example.com, etc., you can use a wildcard entry like "*.example.com" in your DNS configuration. This wildcard will match any subdomain under example.com, and requests to any subdomain will be directed to the same server or IP address.

In the context of ingress in kubernetes, hostname wildcards are often used to simplify the configuration when you have multiple subdomains that need to be routed to the same backend Service. Instead of creating separate Ingress rules for each subdomain, you can use a wildcard hostname in the Ingress resource to handle all subdomains with a single rule.

For instance, consider the following Ingress rule:

With this wildcard Ingress rule, all incoming requests to any subdomain under example.com will be directed to the my-service backend Service. This makes it convenient to handle a large number of subdomains under a single parent domain without the need for explicit configuration of each subdomain.

Ingress Resource

Ingress resource in Kubernetes is an API object that provides external access to services running within the cluster. It acts as a layer 7 (application layer) load balancer, routing incoming HTTP and HTTPS traffic to the appropriate services based on the defined rules and configurations.

Ingress Rules:

Ingress rules are the heart of the Ingress resource. Each rule defines how traffic should be routed based on the requested hostname and path. The rules consist of host and http sections. The host specifies the domain name for which the rule should apply, and the http section defines the paths and backend services that should handle the incoming requests.

DefaultBackend:

The default backend is a special configuration within the Ingress resource. It is used when an incoming request does not match any of the defined rules. Instead of returning an error, the request is forwarded to the default backend service. This allows you to provide a fallback behavior for requests that don't match any specific routing rules.

Path Types:

In Kubernetes, there are two types of path matching for Ingress rules:

• Prefix Path:
  The request is matched to the backend service if the requested URL path starts with the specified prefix. For example, a prefix path of "/app" would match requests to "/app", "/app/page", "/app/resource", etc.
• Exact Path:
  The request is matched to the backend service only if the requested URL path exactly matches the specified path. For example, an exact path of "/app" would match requests to "/app" but not to "/app/page" or "/app/resource".

Examples:

Here are some examples of Ingress resources:

In this example, the Ingress resource has two rules, one for paths starting with "/app" and another for paths starting with "/api". Requests to "example.com/app" will be forwarded to the app service, and requests to "example.com/api" will be forwarded to the api-service. If a request doesn't match any of these paths, it will be directed to the default service specified in the defaultBackend section.