Utalization of the Ingress Controller

Now we want to make our guestbook available with SSL and by a fancy hostname instead of an random IP of the Load-Balancer-Service.

1. NOT REQUIRED: Deploy Ingress Controller

In case you are going through this Lab within Thinkports Kubernetes Workshop, you do not need to deploy an Ingress Controller yourself. Thinkport will provide an NGINX Ingress Controller for you beforehand. It is sufficient, when you get a quick overview of how to implement your Ingress Resources in the provided Controller. Feel free to inspect the provisioned Ingress Controller and continue with Section 2. If you want to work through the creation of an Ingress Controller yourself, feel free to take this first chapter as a reference.

Optional: Deploy nginx Ingress Controller

We need an Ingress Controller that will later apply our desired routing rules.

Remember that we write our rules into the Ingress Resource, while we deploy an Ingress Controller that enforces them.

We choose the community version of the NGINX controller for this example.

Follow the instructions on the Getting Started Document. You may either make use of the Helm-Chart or copy the provided yaml-files for the NGINX Deployment.

Create a new namespace, ingress-nginx for the controller.

HINT

Paste the path provided in the documentation into your browser to take a look at the blueprints for the whole NGINX Deployment!

When done, check the objects that have been created in the default and new ingress-nginx namespace. Name all types of created resources that you can find.

Now, especially check, which external IP has been assigned to the NGINX Deployment's Load Balancer Service.

HINT

You find the description how to test the Ingress Controller in the documentation under the Online Testing section.

$ kubectl get services ingress-nginx-controller --namespace=ingress-nginx

This newly created service will replace our previous Load Balancer.

When the service is ready and the externalIP has been assigned, make a new DNS entry, pointing to that IP Address!

---

2. Create an Ingress Resource

The Ingress Controller is deployed and needs to bind to an Ingress Resource, which holds rules to apply. Within the workshop we are using NGINX for Ingress routing.

Create an Ingress Resource in the mongo namespace with the following specs:

name: ingress-resource
host: [hostname]
backend: example-service-cip
service port: 80

HINT

1. Get help for the imperative command:

Solution

$ kubectl create ingress ingress-resource --help

2. Use the imperative command:

Solution

$ kubectl create ingress ingress-resource --rule [your-favorite-hostname].[your-cluster].f1.k8s.workshop.thinkport.cloud/*=example-service-cip:80 --dry-run=client -o yaml > ingress-resource.yaml

3. Lookup the examples from the Kubernetes Documentation for the declarative approach
4. Take kubernetes/9 - Networking/1-ingress-resource.yaml as a reference

Notice that we declared an annotation. This annotation is specific for the NGINX Ingress Controller. If you were to deploy an Ingress Controller yourself, check for controller-specific configuration.

The example-svc-cip under the backend spec points to the service, which exposes our application. Later we will change the Load Balancer Service for the guestbook application to a Cluster IP Service of that name.

But first let us talk through the Ingress Resource. Can you explain the rule that has been defined here?

---

3. Apply changes to the Application

As this is a fairly simple setup with just one application backend, we do not need to add any other rules to the Ingress Resource. All functionality is currently handled by the example application Deployment.

For production ready applications we would consider splitting the features of the app into several Deployments. Then we could route to them by defining more rules on the Ingress Resource.

Another option is to define several hostnames within the resource.

But for now we just want to connect the example-app Deployment.

Therefore, delete the example-svc-lb Load Balancer Service. As a replacement, create the Cluster IP Service we mentioned earlier:

name: example-service-cip
type: ClusterIP
port: 80
targetPort: 8080
selector: app = example-app

HINT

1. Use the imperative command:

Solution

$ kubectl expose deploy example-app --port 80 --target-port 8080 --name example-service-cip --dry-run=client -o yaml > clusterIP-service.yaml

2. Check the generated yaml and make sure everything is fine, before deploying it
1. Take kubernetes/9 - Networking/2-clusterIP-service.yaml as a reference

Now everything should be in place. We can access the guestbook application via the DNS entry or the external IP of the ingress-nginx-controller Load Balancer Service!

Check if the application is still working.

Though now two Cluster IP Services - one for the application backend and one for the mongoDB - are active.

Bonus Task

BONUS: If you deployed the mongo-express client earlier, change the mongo-express-svc-lb Service to a clusterIP type Service.

SOLUTION

- Take kubernetes/9 - Networking/3-mongo-express-svc-clusterIP.yaml as a reference

Try to create an Ingress resource that serves the mongo-express-service at express.[your-cluster].f1.k8s.workshop.thinkport.cloud.

SOLUTION

- Full example under kubernetes/9 - Networking/4-mongo-express-ingress.yaml

---