Kubernetes - Ingress - Straight to the point

For those who have never used ingress in their operation, now is the time! This article presents some features and basic concepts so that, by the end, you can carry out your first implementation.

Introduction

In this article, we will address in a simplified and objective way concepts about using ingress in the daily routine of a Kubernetes cluster operator. For those who have never used it in their operation, now is the time. We will present here some features and basic concepts so that, at the end of the article, you can carry out your first implementation.

What is a Service?

Before we talk about ingress, we first need to understand some basic concepts, such as the service.

Service is a load balancer that makes a request to the kube-apiserver, receiving a list of application endpoints and directing traffic to the pods. By default, the service works with a "round robin" balancing strategy. There are basically three types of services: "ClusterIP", "NodePort", and "LoadBalancer". Let's understand a little about each of them.

ClusterIP: the default service type, which enables communication only through the SDN created for pod communication.

NodePort: a service that exposes a port on each node of the cluster that has a running pod of the application; its access method is via "IP + port" (xxx.xxx.xxx.xxx:port), having a default port limit range that can be used (30000–32767).

LoadBalancer: a type of service that balances load directly into the cluster, however to use this resource you need to have scaled integration with a "load balancing" service. If you use a cloud provider this can be done simply, just ensure that your nodes have permission to execute this integration; whereas in an on-premise environment, it is necessary to have an appliance that integrates with your cluster. An important point about this type of service is that a new component of the loadbalancer type is generated for each application, meaning be careful when using it, so as not to generate considerable costs in cloud environments.

What is Ingress?

Getting straight to the point, Ingress is a Kubernetes object that allows us to externalize services of a cluster, meaning it is a way to abstract internal cluster services for the external public (client). With Ingress we can work with HTTP/HTTPS protocols, SSL/TLS, traffic routing, load balancing, access control, websocket, and etc. All this using only a single integration with the loadbalancer service.

How does ingress work?

Ingress basically consists of two components, ingress controller and ingress resource.

Ingress controller is the interpreter of the ingress resource. If you use a managed Kubernetes service like GKE, EKS, and AKS, these services already have their native ingress controller, which can be changed to one of your preference. There are several types of ingress controllers, two suggestions described in the Kubernetes documentation are Nginx ingress and GCE, both being maintained and supported by the Kubernetes community. There are also other excellent options in this link; choose one of your preference or that best suits your needs.

Ingress resource is a component that allows us to describe how we want to externalize our services, whether we will use SSL/TLS, where we will direct traffic routing, whether we will have access control, websocket, etc.

What is the relationship between Service and Ingress?

When a request is sent by our client to the cluster, this request is received and first arrives at the ingress controller, which checks what rules exist for that request in the ingress resource, which in turn directs it to the corresponding service and routing it to the node that contains a pod of the application. When we use Ingress, we usually use the ClusterIP type of services, keeping our application a bit more secure, as all communication logic is performed by the ingress controller.

Below is an image that abstracts the functioning of both components very well:

What kind of problem can we solve using ingress ?

Just as important as learning about new technologies is knowing what problem we can solve with them. A very common problem we can quickly solve with ingress is externalizing multiple services via a single endpoint.

To better exemplify its usage, let's create a common situation in a daily operation; I will demonstrate an example using paths.

“Suppose you have three applications in the microservices model and deployed all of them in a Kubernetes cluster, but now you need to create a service that allows exposing these applications through a single endpoint for cost reasons, another point is that each application has a path for access ("/login", "/cadastro" and "/monitor").”

Our goal will be to create an endpoint "exemplo.com/{\"login\", \"cadastro\" and \"monitor\"}" with each path of the applications and provide access to our clients. Two points to consider are cost and maintainability.

We saw that using only the "service" in isolation is not a good approach, and also that having loadbalancers for each entry is financially unfeasible, thus Ingress proves to be the ideal solution concentrating accesses into a single endpoint, like setting up centralization, and facilitating maintenance or updates.

Let's get practical

Well, up until now we've talked a lot about the theoretical part, so let's move on to practice.

In this example, we will use the nginx ingress controller , because it is a simple controller and recommended in the official documentation; its implementation will be in two ways: one via helm and another manual.

Implementation via Helm

1 - Here we are going to install the ingress controller. I created a namespace called “ingress” for better organization.

Kubernetes -Ingress

Now verify if the service ingress has an “EXTERNAL-IP” assigned to it.

kubectl -n ingress get svc nginx-ingress-controller

2 - Now let's configure our ingress resource, we must apply these settings within the namespace of the application in question, in this case my application is in the namespace “myapp”.

cat << EOF | kubectl create -f -

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: app-ingress

namespace: myapp

annotations:

kubernetes.io/ingress.class: nginx # here we are defining which type of ingress class we will use

spec:

rules:

- http: exemplo.com # here we define our domain and/or subdomain, in case you don't have a URL you can remove dns and make the call directly through the IP.

http:

paths:

- path: /login # application path

backend:

serviceName: login-svc # application service name

servicePort: 80

- path: /cadastro

backend:

serviceName: cadastro-svc

servicePort: 8080

- path: /monitor

backend:

serviceName: monitor-svc

servicePort: 80

EOF

3 - Now it can be verified through the following URLs.

curl http://exemplo.com

curl http://exemplo.com/login

curl http://exemplo.com/castro

curl http://exemplo.com/monitor

Implementation

There are some specific configurations that are linked to your cloud provider or bare-metal, check the link for further questions.

1- For manual implementation, some configurations like RBAC, service creation, deployments, etc., are necessary; its default namespace is “ingress-nginx”

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud/deploy.yaml

2- Now let's configure our ingress resource, we must apply these settings within the namespace of the application in question, in this case my application is in the namespace “myapp”.

cat << EOF | kubectl create -f -

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: app-ingress

namespace: myapp

annotations:

kubernetes.io/ingress.class: nginx # here we are defining which type of ingress class we will use

spec:

rules:

- http: exemplo.com # here we define our domain and/or subdomain, in case you don't have a URL you can remove dns and make the call directly through the IP.

http:

paths:

- path: /login # application path

backend:

serviceName: login-svc # application service name

servicePort: 80

- path: /cadastro

backend:

serviceName: cadastro-svc

servicePort: 8080

- path: /monitor

backend:

serviceName: monitor-svc

servicePort: 80

EOF

3 - Now it can be verified through the following URLs.

curl http://exemplo.com

curl http://exemplo.com/login

curl http://exemplo.com/castro

curl http://exemplo.com/monitor

Final considerations

Using ingress is a component that will elevate the maturity of your cluster. As we have seen, it is not a "seven-headed beast", its use is simple and intuitive. If you made it this far, I thank you, I hope you have succeeded in the implementation and stay tuned for the next chapters.

Author: Kaio Cersar F. Santos