I collected some points by which we can easily understand why ingress and how its work?
It is little difficult to understand what is ingress and ingress controller, but by reading this blog we get quick idea what and how ingress and ingress controller works
What is an Ingress?
An Ingress is a Kubernetes resource that allows traffic to come into your Kubernetes cluster. The external traffic could be via HTTP or HTTPS to a service running within your Kubernetes cluster. The service is exposed by your Ingress to allow inbound traffic.
Ingress provides externally available URLs, performs load balancing, terminates SSL/TLS, and offers name-based virtual hosting.
Here’s an example of an Ingress configuration file:
Host is specified as localhost, so the rule applies to the host. If a host is not specified, then all inbound HTTP traffic goes through the IP address.
Path can consist of multiple rules; in the example above, the path rule points to a Service within the Backend definition.
Backend is a combination of Service and port, as seen above.
An Ingress controller is needed to satisfy the Ingress you created, as it handles all routing logic.
What is Ingress Controller?
You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
Ingress controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources. The load balancer can be a software load balancer running in the cluster or a hardware or cloud load balancer running externally. Different load balancers require different Ingress controller implementations.
In order to Ingress resource work, the cluster must have an ingress controller running.
You can deploy any number of ingress controllers within a cluster.
There are many different Ingress controllers, and there’s support for cloud-native load balancers (from GCP, AWS, and Azure).
e.g. Nginx, Ambassador, EnRoute, HAProxy, AWS ALB, AKS Application Gateway
An Ingress controller is a daemon running in a Pod that watches the /ingresses endpoint on the API server. When a new endpoint is created, the daemon uses the configured set of rules to allow traffic into a service.
A controller uses Ingress Rules to handle traffic to and from outside the cluster.
There are many Ingress controllers (and I’ll cover some of them later in this post). Any tool capable of reverse proxying traffic should work, so you can even build your own if you’re so inclined.
Why Ingress controller?
When there is no Ingress controller available in a Kubernetes cluster, and you want to expose individual services to external traffic, one option is indeed to create a load balancer for each service. This approach involves provisioning a separate load balancer for each service that needs to be exposed externally. Each load balancer is associated with a specific service, directing traffic to the pods backing that service.
Resource Consumption: Provisioning a separate load balancer for each service can be resource-intensive, especially in terms of cost and management overhead. It may not be feasible or cost-effective, especially in environments with a large number of services.
Scalability Concerns: Managing multiple load balancers for each service can become complex and difficult to scale, especially as the number of services and external traffic patterns grow. It may lead to inefficiencies and challenges in managing the infrastructure.
While creating a load balancer for each service is technically possible, it may not be the most efficient or scalable approach, especially in production environments. In such cases, using an Ingress controller to manage external traffic routing and load balancing can provide a more centralized, flexible, and scalable solution.
Load balancers can only route to one service at a time since they are defined per service. This contrasts with an ingress, which can route to several services inside the cluster.
How Ingress Controller works?
In a typical Kubernetes setup with an Ingress controller, the traffic flow generally goes as follows:
External Traffic: External clients, such as users accessing a website or API, send requests to the Kubernetes cluster. These requests are typically directed to a specific IP address associated with the load balancer.
Load Balancer: The load balancer, which serves as the entry point for external traffic, receives these incoming requests. Its role is to distribute these requests across the backend instances or pods that host the services within the Kubernetes cluster.
Ingress Controller: The load balancer forwards the incoming requests to the Ingress controller deployed within the Kubernetes cluster. The Ingress controller acts as the traffic manager for incoming requests, interpreting the rules defined in the Ingress resources.
Ingress Resources: Ingress resources define how incoming traffic should be routed to different services within the cluster based on various criteria such as hostnames, paths, or header values. These rules are specified in the Ingress resources by the cluster administrator.
Routing to Services: Based on the rules defined in the Ingress resources, the Ingress controller determines how to route incoming requests to the appropriate backend services or pods within the Kubernetes cluster.
Backend Service: Finally, the Ingress controller forwards the requests to the backend service or pod that hosts the application or service associated with the requested hostname, path, or other criteria specified in the Ingress resource.
So, to summarize, the traffic first goes to the load balancer, which then forwards it to the Ingress controller within the Kubernetes cluster. The Ingress controller then routes the traffic to the appropriate backend service based on the rules defined in the Ingress resources.
why a load balancer is typically created when you use an Ingress?
When you use an Ingress resource in Kubernetes, it defines how external traffic should be routed to services within the cluster. The Ingress resource itself doesn't directly handle traffic but rather serves as a configuration for the Ingress controller to manage external access.
Routing External Traffic: An Ingress resource specifies rules for routing incoming traffic based on criteria such as hostnames, paths, or header values. These rules determine how external requests should be directed to different services within the Kubernetes cluster.
Load Balancer Integration: In many Kubernetes environments, an Ingress controller is responsible for implementing the rules defined in the Ingress resource. The Ingress controller monitors changes to Ingress resources and dynamically configures the underlying load balancer or routing infrastructure to route external traffic according to these rules.
Load Balancing: The load balancer serves as the entry point for external traffic, distributing incoming requests across multiple backend instances or pods of the services specified in the Ingress rules. This load balancing ensures high availability, scalability, and fault tolerance by evenly distributing traffic and directing requests to healthy instances.
Dynamic Configuration: The Ingress controller dynamically configures the load balancer based on changes to Ingress resources. When you create or update an Ingress resource, the Ingress controller communicates with the cloud provider's APIs to provision or update the load balancer's configuration accordingly.
Automatic Provisioning: In many cloud-based Kubernetes environments (e.g., AWS, GCP, Azure), the integration between the Ingress controller and the cloud provider's load balancing service allows for automatic provisioning of load balancers. This simplifies the process of exposing services to external traffic by abstracting away the complexities of managing the underlying networking infrastructure.
In summary, a load balancer is created when you use an Ingress to provide a scalable, reliable, and centralized way to route external traffic to services within the Kubernetes cluster. The Ingress controller dynamically configures and manages the load balancer based on the rules defined in the Ingress resources, providing a flexible and efficient solution for managing external access.
Can we use one load balancer for multiple ingress controller?
In Kubernetes, it's common to use a single load balancer to handle traffic for multiple Ingress controllers. This approach is feasible and often preferred for several reasons:
Resource Efficiency: Provisioning multiple load balancers for each Ingress controller can be resource-intensive and costly, especially in cloud environments where load balancers may have associated costs.
Simplified Networking: Using a single load balancer simplifies networking configurations and reduces complexity. It provides a centralized entry point for external traffic, making it easier to manage and monitor traffic flows.
Better Resource Utilization: Consolidating multiple Ingress controllers behind a single load balancer allows for better resource utilization and scalability. The load balancer can distribute traffic efficiently across the Ingress controllers and their associated backend services.
Scalability: A single load balancer can handle a large volume of traffic and scale horizontally as needed. This ensures that the infrastructure can accommodate increased traffic loads without introducing additional complexities.
High Availability: Load balancers often come with built-in high availability features, such as health checks and failover mechanisms. Using a single load balancer ensures that these features are leveraged effectively across all Ingress controllers.
To achieve this setup, you would typically configure your load balancer to route traffic to multiple backend services, each corresponding to a different Ingress controller. The Ingress controllers, in turn, would route traffic to the appropriate backend services within the Kubernetes cluster based on the rules defined in the Ingress resources.
Overall, using a single load balancer for multiple Ingress controllers is a common and practical approach that provides scalability, efficiency, and simplified management of external traffic in Kubernetes environments.
0 Comments