...
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 start with the installation procedure. Here we We will use the Nginx Ingress Controller guide as a reference. For more information, we recommend that you consult the official guide (an installation with Heml is also available on the same site).
We perform clone a download from GitHub of GitHub repository on the master, downloading the folder containing the necessary for the installation of the input controller and, once . Once finished, we move on to its entiretyinside
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ git clone https://github.com/nginxinc/kubernetes-ingress/ $ cd kubernetes-ingress/deployments $ git checkout v1.8.1 |
Before continuing, 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:
/kubernetes-ingress/deployments/common/nginx-config.yaml/kubernetes-ingress/deployments/deployment/nginx-ingress.yaml
In the first file you only need to add the following line, which explains the FIP of the new ingress node
| Code Block | ||||
|---|---|---|---|---|
| ||||
kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-config
namespace: nginx-ingress
data:
.
.
.
external-status-address: "<FIP_Node>" #----- Insert the FIP of the ingress node between the quotes |
As for the other file, let's add these lines in the specification
...
At the end, if all went well, we should get the input controller pod Pod (note that the default namespace is nginx-ingress)
| Code Block | ||||
|---|---|---|---|---|
| ||||
# Note that the Pod is present on the "ingress" node and has its own private IP
$ kubectl get pod -n nginx-ingress -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-ingress-68d7b4bfdd-mw479 1/1 Running 0 20h 192.168.100.13 mycentos-ing.novalocal |
...
We now present the ingress resource through a complete example, present in the directory downloaded from GitHub (/kubernetes-ingress/examples/complete-example). Let's move inside the complete-example directory and run the commands (we set aside the cafe-secret.yaml file for now)
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ ls cafe-ingress.yaml cafe-secret.yaml cafe.yaml dashboard.png README.md $ kubectl apply -f cafe.yaml |
...
Finally, we create the input resource with the usual command kubectl apply -f <file.yaml>, even if it is better to take a look at the contents of the .yaml file first.
| Info | ||
|---|---|---|
| ||
What we present here (one host with multiple path) is only one of the 2 ways in which incoming requests can be routed to the services present in the cluster. The other modality, present in the following sub-chapter, makes use of sub-domains to manage incoming requests. |
...
We verify that the ingress resource has been created correctly. The uncommented lines of the nginx-ingress.yaml file are used to make the FIP appear in the ADDRESS column.
...