...
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 $ kubectl apply -f cafe-secret.yaml |
At this point we check that the Pods and the associated services have been created
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: cafe-ingress spec: # tls: - hosts: - cafe.example.com secretName: cafe-secret rules: - host: cafe.example.com http: paths: # Let's ignore # - hosts: - path: /tea # and comment # Use- cafe.example.com/tea to target "tea" services backend: # these lines # secretName: cafe-secret serviceName: tea-svc # Enterfor the service namemoment rules: - host: cafe.example.com servicePorthttp: 80 # Enter the port number on which the service is listeningpaths: - path: /coffeetea # Use cafe.example.com/coffeetea to target "coffeetea" services backend: serviceName: coffeetea-svc # Enter the service name servicePort: 80 # Enter the port number on which the service is listening |
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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
# In the ADDRESS column there is the FIP of the ingress node $ kubectl get ing -n nginx-ingress NAME - path: /coffee # Use cafe.example.com/coffee to target "coffee" services backend: CLASS serviceName: HOSTScoffee-svc # Enter the service name ADDRESS servicePort: 80 PORTS AGE cafe-ingress# Enter the port number on which the service is listening |
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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
# In the ADDRESS column there is the FIP <none>of the cafe.example.com 131.154.97.164 80, 443 20h |
Let's move to the browser
ingress node
$ kubectl get ing -n nginx-ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
cafe-ingress <none> cafe.example.com 131.154.97.164 80, 443 20h |
Let's move to the browser
We prove that everything works by moving to the browser. Since the cafe.example.com site is not registered on a DNS, we have to insert a line in the /etcWe prove that everything works by moving to the browser. Since the cafe.example.com site is not registered on a DNS, we have to insert a line in the /etc/hosts file of our local machine (example on Windows the full path is C:\Windows\System32\drivers\etc\hosts)
...
| Panel | ||
|---|---|---|
| ||
Server address: 10.10.94.71:8080 # IP:port Server name: tea-69c99ff568-68bnr Date: 23 # Name of the invoked pod Date: 23/Sep/2020:13:20:22 +0000 # Current date and time URI: /tea Request ID: c2c8de16a55223239bdedee5abe4a8a4 |
These two web pages, while very simple, assure us that the addressing mechanism works correctly.
Configuring TLS certificate
If you pay attention to the address bar, you will notice the message "your connection to this site is not secure". Our goal is to secure the connection. This will show itself visually with the appearance of the small padlock in the address bar.
First, we need to get the certificate for our site (cafe.example.com), which will come in handy shortly. We then create a new Kubernetes component, called Secret. To create it we use the cafe-secret.yaml file, which we had previously set aside, replacing the keys already present with those obtained from the certificate (in the next sub-paragraph there is a little insight into this aspect).
| Code Block | ||||
|---|---|---|---|---|
| ||||
apiVersion: v1
kind: Secret
metadata:
name: cafe-secret
namespace: nginx-ingress # Warning! The namespace of the Secret and of the ingress resource must match
type: kubernetes.io/tls
data:
tls.crt: <new_base64_encoded_cert>
tls.key: <new_base64_encoded_key> |
Once you have entered the two keys, we are ready to create the resource
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ kubectl apply -f cafe-secret.yaml
secret/cafe-secret created
$ kubectl get secret -n nginx-ingress
NAME TYPE DATA AGE
cafe-secret kubernetes.io/tls 2 2m8s |
Now we need to de-comment the lines in cafe-ingress.yaml, related to the TLS protocol, and perform a replace of the component. Returning to the browser we should note that now "the connection is protected", as evidenced by the appearance of the padlock next to the address bar.
Learn more about the tls.crt and tls.key keys
You may have noticed the particular wording "base64_encoded" inside the cafe-secret.yaml. In fact, it is necessary to insert the keys with a certain coding. We take our two keys, obtained with the certificate, and apply the following command
| Code Block | ||||
|---|---|---|---|---|
| ||||
$ base64 -w 0 cafe.example.com.pem
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUhDakNDQlBLZ0F3SUJBZ0lRR0J6emlZVDR0V3BpT...
$ base64 -w 0 cafe.example.com.key
LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBdjFyQzdvWVh3YU5yc... |
We just have to paste the output of the .pem file into the tls.crt field and the output of the .key file into the tls.key fieldThese two web pages, while very simple, assure us that the addressing mechanism works correctly.
Uninstall the Ingress Controller
All the components created in this guide share the nginx-ingress namespace, so if we want to remove everything in one go, just type
...