Let's now add an important element to our cluster, in order to get closer and closer to creating an HA cluster.
In Kubernetes, an Ingress is a object that allows access to your Kubernetes services from outside the cluster. The ingress is made up of 2 parts: the kubernetes component that deals with directing external traffic to internal services is called the ingress controller, which obeys the rules present in the ingress resources. So, you configure access by creating a collection of rules, written in a file, that define which inbound connections reach which services. Without the use of the ingress, all the cluster services, to which one wishes to access from the outside, must be exposed to the internet. The advantage of the ingress consists, in fact, in exposing a single access point externally, which will take care of routing the traffic within the cluster.
First we added a new node to the cluster, which will take care of routing incoming requests to the appropriate services. This node will receive requests from the internet, so it must have a FIP. So, we created a new VM (Launch and manage instances) with a low-medium flavor, as it should only act as an ingress, and joined it to cluster (Building the cluster). We then assigned to the node, through a label, the "role" of ingress with the command
# Enter the node name and label. The optional "--overwrite" flag is used in case the value is already present $ kubectl label node <node_name> kubernetes.io/role=<label_value> [--overwrite] |
The addition of the label will be used later, to indicate on which node to install the input controller Pod. The same operation can also be performed on the other nodes, in order to obtain
# Note the "ROLES" column $ kubectl get node NAME STATUS ROLES AGE VERSION mycentos-0.novalocal Ready master 70d v1.19.1 mycentos-1.novalocal Ready worker 69d v1.19.1 mycentos-2.novalocal Ready worker 69d v1.19.1 mycentos-ing.novalocal Ready ingress 4d19h v1.19.1 |
Ingress Controller
As said previously, you must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect. There are several input controllers, here we will use one of the most used. Let's go, therefore, on the installation guide of the Nginx Ingress Controller for Kubernetes (an installation with Heml is also available on the same site).
Before continuing with step 2 of the guide, let's stop for a moment, because we need to make some small changes to the files in the folder we just cloned from the GitHub repo. The files in question are located here:
In the first file you only need to add the following line, which explains the FIP of the new node
kind: ConfigMap apiVersion: v1 metadata: name: nginx-config namespace: nginx-ingress data: . . . external-status-address: "<FIP_Node>" #----- Insert the FIP of the node between the quotes |
As for the other file, let's add these lines in the specification
spec:
.
.
.
spec:
hostNetwork: true #----- Thanks to this instruction the controller Pod will have the same IP as the node
nodeSelector: #----- The Pod will be created inside the node
kubernetes.io/role: ingress #----- with the role "ingress" |
and uncomment the following lines at the end of the file
args: - -nginx-configmaps=$(POD_NAMESPACE)/nginx-config - -default-server-tls-secret=$(POD_NAMESPACE)/default-server-secret # - -v=3 # Enables extensive logging. Useful for troubleshooting. - -report-ingress-status #----- Uncommented # - -external-service=nginx-ingress #- -enable-prometheus-metrics #- -global-configuration=$(POD_NAMESPACE)/nginx-configuration - -enable-leader-election #----- Uncommented #- -enable-custom-resources |
This last change will come in handy when we create the ingress resource component.