Maximizing Your App Performance with Azure Kubernetes Ingress Controller

Kubernetes has revolutionized the way we manage containerized applications, making it easier than ever to deploy, scale, and manage complex microservices architectures. But while Kubernetes provides a powerful platform for running applications, it can be challenging to expose those applications to the outside world. That’s where Kubernetes Ingress comes in – a powerful and flexible way to manage external access to services running in a Kubernetes cluster. With Ingress, you can define routing rules for incoming traffic, making it easy to expose your services to the outside world and enabling a wide range of use cases for cloud-native applications. Maximizing Your App Performance with Azure Kubernetes Ingress Controller is an essential guide for anyone seeking to unlock the full potential of their Azure Kubernetes deployment and achieve maximum performance, scalability, and reliability for their applications. In this article, we’ll explore Services in Kubernetes, Kubernetes Ingress and its features, Kubernetes Ingress Controller, and the various ingress controllers available.

Table of Content:

1. What are Services in Kubernetes?
2. What is Kubernetes Ingress?
3. What is Kubernetes Ingress Controller?
4. Kubernetes Ingress Features
   • Context path-based routing
   • Host-based routing
   • TLS/SSL Termination
5. Types of Kubernetes Ingress Controller
   • NGINX Ingress Controller
   • Traefik
   • HAProxy Ingress
   • Ambassador
   • EnRoute
   • Istio Ingress
6. Conclusion

What are Services in Kubernetes?

Kubernetes service is a fundamental building block of a Kubernetes cluster, used to provide a stable network endpoint for accessing a set of pods in a deployment or replica set.

The primary purpose of a Kubernetes service is to abstract away the underlying details of how pods are accessed within a cluster, such as their IP addresses or the ports they are listening on. By defining a service, you can ensure that requests to the service are properly load-balanced across all available pods and that the service remains available even as pods are added or removed.

In addition to load balancing, Kubernetes services also provide a way to expose pods externally to the cluster, such as through a load balancer or NodePort. Services can also be used to provide secure communication between pods by defining a service with a ClusterIP and setting up Network Policies. There are three types of services in Kubernetes:

1. ClusterIP Service
2. NodePort Service
3. LoadBalancer Service

1. ClusterIP Service

ClusterIP Service is used inside a Kubernetes cluster. It cannot be reached from outside the cluster and it is not routable on an external network. The objects that are running inside the Kubernetes cluster can connect to the ClusterIP service. This type of service is used for communication between different Pods.

In the above diagram, to communicate to back-end pods back-end cluster-IP service is used. Now internally traffic goes to any of the back-end pods. All the communication to Redis PODs goes via the Redis cluster IP service.

Limitation of ClusterIP:

1. The client cannot connect from outside. So, the application which is running inside the Kubernetes cluster is of no use.

2. NodePort Service

The NodePort allows external access to the pod running on Kubernetes. It allocates one available port inside the Node. The incoming traffic to this specific port is sent to the service, and then it can reach the pod. This way external clients can enter through the node (server which hosts the Pod).

When we expose a service using a NodePort, it will open all the worker nodes or server nodes. Also, NodePort builds on the ClusterIP service. This means that when you create a NodePort there is a ClusterIP created. Traffic forwarded to the NodePort is actually redirected to the ClusterIP first and then to the Pods.

Limitations of NodePort:

1. The client should know the IP address of the server node.
2. As NodePort will open all the server nodes, a large number of services will run inside the cluster which can cause security concerns.

3. LoadBalancer

Kubernetes LoadBalancer service is a type of service that provides external access to a set of pods by creating a load balancer in a cloud provider’s infrastructure.

When you create a LoadBalancer service in Kubernetes, the cloud provider automatically provisions a load balancer (in Azure it is Azure Load balancer) and configures it to route traffic to the pods associated with the service. This allows you to expose your application externally to the internet or other networks, and distribute incoming traffic across multiple pods.

The LoadBalancer service is typically used when you need to provide external access to your application, such as for a web application or API. By creating a LoadBalancer service, you can expose your application to the internet, and the service will automatically distribute incoming traffic to the pods behind it.

In addition to distributing traffic, the LoadBalancer service can also perform health checks on the pods to ensure that they are running and responding to requests. If a pod becomes unavailable, the load balancer will stop sending traffic to that pod until it becomes available again.

Limitations of Load Balancer:

1. We require a separate load balancer for every single service.
2. Each time you create a service with a load balancer, the cloud will create a new cloud load balancer (In this case it is Azure Load balancer) with a different IP address. This will increase the cost of using the load balancer.
3. Load Balancer will only inspect and will distribute the traffic based on the destination port. It will not distribute the traffic based on the application.

Now, to solve all the above problems in Kubernetes networking, Kubernetes Ingress and Kubernetes Ingress Controller are used.

What is Kubernetes Ingress?

Let’s understand what is Kubernetes Ingress with an example. Suppose we are using a load balancer service as per the below diagram:

In the diagram, you will see that there is a load balancer outside the AKS. A public IP address is assigned to the particular application (client’s application). So, whenever a client will try to access an application the traffic comes via a public IP address to the load balancer. Then load balancer distributes the traffic to a particular app based on which IP address the traffic is coming from. If it is Public IP address 1 then traffic will go to App 1 and so on.

So long story short If there are 100 applications, then the load balancer will need to have 100 IP addresses (Each IP address for a particular application).

So to solve the load balancer problem, Kubernetes Ingress is used. Several features of Ingress will help you to solve this problem. Continue reading this article to understand.

What is Azure Kubernetes Ingress Controller?

Kubernetes Ingress is an API object that manages external IP access to services in a cluster, typically exposing outside HTTP and HTTPS routes to services inside the cluster. A set of rules the ingress resource defines controls traffic routing. Ingress may be configured to offer services SSL/TLS termination, traffic load balancing, externally-reachable URLs, and routing services (context-based routing and host-based routing).

Ingress controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources. It is a specialized load balancer. An ingress controller serves as a bridge between Kubernetes and external services by abstracting the complexity of Kubernetes application traffic routing away.

These are the typical functions of Kubernetes Ingress Controller:

• Continuously monitor the Kubernetes pods, and as pods are added or removed from service, automatically update load balancing rules
• Accept outside traffic and load balance it to containers running inside the Kubernetes platform.
• Manage in-cluster egress traffic for services that need to communicate with outside services.
• Use the Kubernetes API to deploy Ingress resources and configuration files.

There are many reasons why Kubernetes Ingress Controller is important over Load Balancer Services. Some of them are:

1. Ingress resources are less expensive than the alternatives.
2. It helps you to simplify the exposition of services with routing rules.
3. Ingress controllers provide features such as ACME (Automatic Certificate Management Environment), middleware, and load balancing
4. You can also improve the observability of a platform, granting an added level of control with the Kubernetes Ingress controller.
5. Every ingress controller supports a set of annotations that configure specific features supported by the software.

Azure Kubernetes Ingress Features

An Ingress provides the following features:

• Context Path-Based Routing
• Host Based Routing
• TLS/ SSL Termination

Context Path-Based Routing

Context path-based routing is one of the best features of Kubernetes Ingress that allows you to route incoming traffic to different backend services based on the URL path request by the client. When you define an Ingress resource that includes context path-based routing rules, Kubernetes uses an ingress controller to intercept incoming requests and examine the URL path. The ingress controller then uses the path information to route the requests to the appropriate backend service.

For example, if you have two backend services running in your Kubernetes cluster. One handles requests for the root URL path (/). Other handles request for a specific URL path (e.g. /Microsoft). You could use context path-based routing to route traffic to the appropriate service based on the requested path.

When a client sends a request to your Kubernetes Ingress with a specific URL path (e.g. http://example.com/Microsoft), the ingress controller looks at the path information in the request and compares it to the path rules defined in your Ingress resource. If the path matches a defined rule (e.g. the rule for /Microsoft), the ingress controller routes the request to the backend service specified in the rule.

Host Based Routing

Host-based routing allows you to route incoming traffic to different backend services based on the hostname specified in the request. When you define an Ingress resource in Kubernetes that includes host-based routing rules, Kubernetes uses an ingress controller to examine the hostname specified in incoming requests and uses it to route the request to the appropriate backend service.

For example, if you have multiple web applications running on different domains or subdomains (e.g. sapp1.microsoft.com, sapp2.microsoft.com, sapp3.microsoft.com), you could use host-based routing to route traffic to the appropriate backend service based on the domain or subdomain specified in the request.

When a client sends a request to your Kubernetes Ingress with a specific hostname (e.g. http://sapp1.microsoft.com), the ingress controller looks at the host information in the request and compares it to the host rules defined in your Ingress resource. If the host matches a defined rule (e.g. the rule for sapp1.microsoft.com), the ingress controller routes the request to the backend service specified in the rule.

TLS/ SSL Termination

TLS is called – Transport Layer Security and SSL is called Secure Sockets Layer.

TLS/SSL termination is a process in which a secure connection between a client and a server is established using the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocol. This secure connection encrypts all data transmitted between the client and server to ensure confidentiality and integrity.

In TLS/SSL termination, a device or software called a load balancer, proxy server, or application delivery controller (ADC) is placed between the client and server. This device terminates the TLS/SSL connection from the client and decrypts the traffic, allowing it to inspect and manipulate the traffic before forwarding it to the backend server.

TLS/SSL termination is commonly used in web applications and services to offload the resource-intensive task of SSL/TLS encryption and decryption from the backend servers. It can also be used to enforce security policies, such as restricting access to certain resources or filtering out malicious traffic, before allowing the traffic to reach the backend servers.

For example in the above diagram, if you want to secure your web applications with SSL/TLS encryption, you can use TLS/SSL termination at the Ingress service to offload the resource-intensive task of decrypting the incoming traffic and route it to the appropriate backend service. This eliminates the need to configure SSL/TLS encryption on each backend service individually which will be costly.

Types of Azure Kubernetes Ingress Controller

There are several Kubernetes ingress controllers available for Kubernetes with their own features and capabilities. Here are some of the most popular ones:

1. NGINX Ingress Controller
2. Traefik
3. HAProxy Ingress
4. Ambassador
5. EnRoute
6. Istio Ingress

1. Nginx Ingress Controller

This is one of the most widely used ingress controllers for Kubernetes. It supports a variety of load-balancing algorithms, SSL termination, and custom error pages. It also provides a rich set of annotations that can be used to customize the behavior of the ingress controller.

2. Traefik

Traefik is a modern HTTP reverse proxy and load balancer that is widely used as an ingress controller for Kubernetes. It supports dynamic configuration, automatic service discovery, SSL termination, and advanced traffic management features. It also provides a dashboard for monitoring and managing the ingress controller.

3. HAProxy Ingress

HAProxy is a fast and reliable TCP and HTTP load balancer that can be used as an ingress controller for Kubernetes. It supports SSL termination, TCP and HTTP health checks, and advanced traffic management features like sticky sessions and request rate limiting.

4. Ambassador

Ambassador provides advanced traffic management features like load balancing, SSL termination, and rate limiting for applications. Built on top of the Envoy proxy, Ambassador provides a flexible and scalable platform for managing ingress traffic to your Kubernetes cluster. It also supports a wide range of protocols including HTTP, TCP, and gRPC.

5. EnRoute

EnRoute is an open-source Kubernetes Ingress controller that provides traffic management capabilities for applications. It also supports header manipulation, request and response transformation, and content-based routing. Enroute provides a range of plugins that are used to extend its functionality. These plugins include support for authentication and authorization, observability, and more.

6. Istio Ingress

Istio is an open-source service mesh platform that provides a flexible and powerful platform for managing external traffic to your Kubernetes cluster. It also provides security features like mutual TLS authentication and JWT validation, enabling you to secure your ingress traffic and protect your applications from external threats.

Conclusion

Kubernetes Ingress is a flexible way to manage external access to services running in a Kubernetes cluster. Ingress provides a way to manage incoming traffic, making it an easy way to expose services to the outside world. Ingress is implemented by an ingress controller, which is responsible for processing ingress resources and forwarding traffic to the appropriate services in the cluster.