What Is an Ingress Controller? Explained by Wallarm
Ingress is a k8s API object. It enables clusters' services to communicate with external traffic or serve the incoming requests as required. Here, in the case of production-grade solutions, external traffic generally comes through HTTP/HTTPS in general.
As this communication can make or break things for your Kubernetes (or other types of containerized) applications, you must have extensive knowledge of Ingress and k8s-Ingress Controller before anything else. Read this article to acquire the same.
Intention behind the Existence of Kubernetes Ingress
Before we move to the actual subject, e.g. Ingress, let’s talk about why it is required.
Do you know about Kubernetes? It is an open-source system for container orchestration. Developers use k8s to launch their containerized apps as this solution helps them automate application deployment, management, and scaling.
Now, k8s clusters has pods - the tiniest unit of your applications. With their nature being cohesive and dynamic, pod’s creation, state change and destruction could be a matter of seconds. So, k8s services were created. Besides handling multiple other functions, they also keep track of pods and their virtual IP address.
Each pod has a selector label that defines its group or cluster. Pods are allowed to communicate within its cluster as per its label or cluster IP address. But when it comes to external services, Pods or Pod groups cannot do it (default setting).
Due to the lack of this provision, external networks or requests cannot reach Pods directly. So, how will the communication happen?
Ingress comes in handy here. It is an API object having the ability to forward external requests to pods/groups. Though powerless when standalone, Ingress works as a configuration request for the corresponding ingress controller. The latter makes decisions regarding external traffic’s routing to and fro the cluster's internal components via Ingress.
If Ingress is the gate, consider Ingress Controller as the gatekeeper that operates this gate. He (it) has the knowledge of who should pass this gate, what should exit this gate, and what requires rejection.
Got a quick idea? Let’s get into technical details now.
What is an Ingress?
Ingress acts as a means of collaboration between internal & external services for your clusters. From load-balancing to terminating the SSL connection and taking care of name-based virtual hosting, it has to take care of a lot of things. So, as the number of clusters in your organization increases, Ingress becomes more and more crucial.
As we’d stated prior to this section, Ingress is like a gate/door. It is essential, but it is powerless when standalone. So, if you just create an Ingress Resource and expect it to work, it won’t do. You’ll require placing an Ingress Controller to activate it for functioning.
Though there is a good number of related solutions in the market (you can read about a few of these in the next section), it is suggested that you choose the one, which fits the reference specifications.
To figure out how your controller will work, you must go through its documentation. It is a wise idea because each solution operates differently.
See the smallest-possible example of an Ingress Resource below:
To clarify, your resource must have the following fields:
apiVersion: It comprises the details about the API’s version;
kind: It has the details about the type of resource;
Metadata: The name of your resource and its annotations are passed through this field;
spec: Details like Ingrss’s path, class, services, service port, etc. are specific here.
Ingress Controller - Everything you Must Know
By now, you already understood that an Ingress essentially requires a controller to function. The task of controller is to instruct & manage Ingress resources so that it could operate hassle-freely.
While other k8s controllers are a part of the kube-controller-manager binary, Ingress Controllers are explicitly mentioned. They are not automatically initiated within the cluster.
Here is a quick list of your top options in this regard:
- Nginx Ingress Controller for k8s is needed as a proxy when you are using NGINX as your webserver. It specializes in load balancing and reducing your app's routing-related troubles. This production-grade controller is a performance-oriented pick when you need a bridge for your k8s services and external services.
- Kong Ingress Controller has NGINX in its core, so its features are obviously more than a simple Nginx-controller deployment. It can help you check your service's health, deploy plugins, and do load balancing. Kong utilizes CRDs and k8s-native tooling to achieve so. This feature-rich option with gRPC capability is a good choice for GKE.
- AWS Ingress Controller makes the most-preferred pick when it comes to the EKS cluster (default). Also known as AWS ALB, it can help you handle internal as well as external access (HTTPS/HTTP) to your k8s services.
Remember, always deploy the k8s Ingress-controller suitable for your clusters’ needs. See the complete list.
Connection between Ingress Controllers & Resources
Ingress is one among the core k8s concepts. Though it is not a default deployment, it is essential for hassle-free operations in multi-cluster and other distributed deployments. Kubernetes, through Ingress, attains the capabilities for host/name/URL based HTTP routing, which is an abstraction efficiency of a higher level.
An Ingress Controller, a third-party proxy service, takes care of ingress’s deployment. It is the one that reads and processes the information received/forwarded by an Ingress Resource. As per the controller selector, your resource may have diverse or extra fields specifying the Ingress’s functioning.
Now that you’ve understood how these 2 terms are connected, let’s talk about how their existence impacts a Kubernetes cluster. To be more particular, let’s see what makes it crucial to use a Controller with a resource in the case of Kubernetes.
- Controller can Improve the Stability for Ingress
Ingress resource, from v1.1 to 18, is a part of k8s. It’s because of the fact that it is less well-designed and has its dependency. If you want an Ingress resource to function in your cluster, you must make sure that it has a controller.
- Controller can Solve the Scalability and Security Issues for Ingress
An Ingress Resource is inherently less scalable. Its definition requires domain, TLS, and routing path or k8s services’ details in order to operate.
Now, as these details are with different teams in an organization in general, the blue/green testing and version management for the resource becomes a complicated task.
Making an ingress resource global won’t solve it but will only act as a security threat. The best solution is to use an advanced Ingress Controller with multi-role configuration abilities. Resource scaling can be simplified using such a proxy solution.
Comparison of Ingress Controller with Other Services
Now that you have understood how controllers solve various problems for Ingress resources, let us tell you another secret. Ingress is not the only way to allow interaction between pods and external traffic. K8s has other provisions too. However, with an Ingress Controller, Ingress makes the best choice for this operation.
In this section, you will learn about Ingress Controller vs Load Balancer and other similar services that interact with the external traffic. More precisely, we will discuss how Ingress differs from its alternative services.
Ingress Vs NodePort
NodePort is a basic k8s function and requires no edit in the firewall rules, unlike an Ingress Controller proxy service. However, if you are running on any public Cloud service (e.g., Google), you may need to modify a few settings to support NodePort’s advanced features.
In the case of Kubernetes, each of your cluster nodes has a particular open NodePort, which sits in a virtual machine. When you wish to expose a service, its IP is used for the node in question.
If your cluster node has no port specified, k8s will select a random node (From 30000 to 32767) when its requirement arrives. Though convenient, it is not a good solution as the system will choose a non-standard port (standard ports for HTTP and HTTPS are 80 and 443) for the external traffic.
Unlike in the case of Ingress, NodePort’s random selection of ports makes it tough to specify the firewall rules for networked systems. So, it can be used as an option for staging level URLs when the product is not yet ready. NodePort even makes a nice choice for creating advanced-level Ingress models. However, when it comes to its deployment in production-grade URLs, we won’t suggest using NodePort directly.
Ingress Vs ClusterIP
Just like NodePort, ClusterIP service is also created automatically for your cluster. It makes the internal communication within the k8s cluster. This means, unlike Ingress, this service can only be used by the same cluster’s pods.
Ingress Vs Load Balancer
Among all the above-explained options, load-balancers share the most number of similarities with Ingress controllers. They are third-party solutions and help kubernetes applications manage the traffic. To make it simple for you, a load balancer is closer to being an alternative service for Ingress.
You can enable the load-balancing service for your Kubernetes cluster and an external solution will be deployed when the traffic threshold is reached. This service will simply divert the external data packets to a different service in your cluster if the designation service is dealing with a huge pool already.
The drawbacks, here, are:
- Not all cloud environments support this service type;
- It adds to the cost without offering as many benefits as Ingress Controller offers;
- Load balancers do not analyze the traffic and may make multiple services face congestion during a DDoS attack.
Ingress Vs Service Mesh
Service Mesh is another very famous implementation when it comes to microservices or containerized solutions. It’s so popular and effective that CNCF’s 2020 Survey has enlisted it among the top adoptions among enterprises for the year.
Though service-mesh is a great pick from security point of view, Ingress Controllers have an upper hand over for multiple reasons, such as:
- You must have a well-formed DevOps team to manage service meshes. If you do not have one already, it will add to the financial burden of your business.
- If your enterprise processes are not full-established, adding a service mesh will not be a good idea. It will be less impactful and more costly.
- Troubleshooting Ingress is easier than troubleshooting service meshes.
To summarize this section, for organizations with full-fledged arrangements for frequent solution update through CI/CD pipeline, service mesh will make a better choice.
Ingress, with its controller, can manage the traffic for your k8s application. However, it lacks traffic analysis capabilities. So, your API object will let all kinds of traffic packets pass through it. So, no matter if a DDoS attack is on its way, the ingress-controller won’t notice or care.
Wish to enable traffic analysis? A controller integrated with the Wallarm platform, a one-stop solution for API Security, can be a useful option here. Let us give you a quick brief on how to get started with it.
- Your Kubernetes project must be leveraging the Community Ingress NGINX Controller, a version below 1.4.0
- You will need Helm Package Manager to begin with Wallarm Ingress Controller. The authority to download the IP addresses from the GCP Storage is also essential.
- You must also have k8s v1.20 or above running and credentials for the Wallarm US/EU Cloud. Meanwhile, also check that the access to Wallarm charts and Docker repositories are not blocked by your Firewall.
- Getting Started
If you are using the Wallarm platform already, you can just install the Wallarm’s Ingress Controller and activate traffic analysis with it. That’s it. Now you are all set to analyze the controller’s operations.
Besides the above, as you can also report public IPs, block IPs as you prefer, and manage your Intress Controller processes more actively with Wallarm.
If you are using Kubernetes, optimal use of ingress-controllers can significantly simplify your cluster-related operations. From the performance of clusters to their observability and security posture - everything will be at a better level with Ingress’s placement in your tech stack. In fact, with increasing traffic and cluster count, they become more than essential for any k8s project.
While using these controllers is suggested, please note that all existing controller products do not have the same capabilities. So, you must be very specific while choosing one for your requirement. A less-secure solution may cause security havocs and bring shame to your business.
Go with an Ingress Controller that could do load balancing alongside traffic control and analysis for your multi-cloud configuration. Wallarm’s Kubernetes Ingress Controller is a perfect solution for this. It comes with extended capabilities for API security so that your overall applications faces no external threats via Ingress. So, go on and try it today.
Subscribe for the latest news
Our recent webinar with the industry overview and product demo.
Solution brief on protecting apps and APIs with Wallarm.