Validating the Application

Checking for Ingress controller#

Before we go into more experiments, we’re going to verify whether our application is accessible from outside the cluster and whether we can send requests to it. And we can do that easily by first checking whether we have an Ingress controller?

We don’t have it. As you almost certainly know, without Ingress, or a variation of it, our application is not accessible from outside of the cluster. So, we need to create Ingress resources. For that, we need to install Ingress in our cluster.

Installing Ingress#

We’re going to use nginx Ingress simply because it is the most commonly used one.

Let’s apply the mandatory resources for nginx Ingress first.

Next, we’re going to apply the additional definitions that vary from one platform to another.

You might be using Minikube or Docker Desktop or EKS or AKS or GKE or something completely different. Instructions will differ from one Kubernetes platform to another. No matter the flavor, all those commands will do the same thing. They will install nginx Ingress specific to the selected Kubernetes platform, and they will retrieve the IP through which we’ll be able to access the applications.

If you are not using one of the Kubernetes distributions I tested, you might need to pick one of those that are closest to yours, and you might need to modify one of the commands.

For Minikube#

Please execute the commands that follow if you are using Minikube.

For Docker Desktop#

Please execute the commands that follow if you are using Docker Desktop.

For GKE or AKS#

Please execute the commands that follow if you are using GKE or AKS.

For EKS#

Please execute the commands that follow if you are using EKS.

Ingress should be up and running, and we retrieved its address. In most cases, that address is provided by an external load balancer.

To be on the safe side, we’ll output the retrieved Ingress host and double-check that it looks OK.

If your output is showing an IP or an address, you’re done, and we can move on. On the other hand, if the output is empty, you were probably too hasty, and the external load balancer was not yet created by the time you exported INGRESS_HOST. To mitigate that, re-run the export command, and the echo should not be empty anymore.

Inspecting the Ingress resources#

Now that Ingress controller is up and running and that we know its IP or its address, we are going to deploy Ingress resource that is tied to our application. Let’s take a look at it first.

The output is as follows.

---

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: go-demo-8
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: go-demo-8.acme.com
    http:
      paths:
      - backend:
          serviceName: go-demo-8
          servicePort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: go-demo-8
  labels:
    app: go-demo-8
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: go-demo-8

We can see that we have two resources defined. We have Ingress that will forward all the requests entering our cluster, as long as the address of the host of those requests is go-demo-8.acme.com. All the requests coming to that host will be forwarded to the service go-demo-8 on port 80.

Further on, we can see below that we have the Service defined as well. It is also called go-demo-8. The type is ClusterIP, meaning that only internal communication is allowed to that service. Remember, Ingress picks up external communication and forwards it to that service. Service will be accessible on port 80, and the targetPort, the port of our application, is 8080. Finally, we have the selector app: go-demo-8. So this service will forward the request to all the Pods with the matching labels.

All that was very basic, and I didn’t go into detail. I’m assuming that you already have at least elemental knowledge of Kubernetes. You’ll know that you do if the things we did so far in this section were boring.

Applying the definition#

Let’s apply that definition.

Sending a request to confirm#

Finally, we’re going to send a request to our application to validate whether it is indeed accessible through the Ingress controller. To do that, we need to simulate the host because you almost certainly don’t have go-demo-8.acme.com configured as a domain. To circumvent that, we’re going to fake the host by sending a curl request with injected Host: go-demo-8.acme.com header.

We sent a request to the external load balancer, or whatever is our Ingress host, and we injected the hostname go-demo-8.acme.com header so that Ingress thinks that it is coming from that domain.

It worked! The application responded, so we know that everything was set up correctly. Now we can go back to chaos experiments.

In the next lesson, we will carry out another chaos experiment to check the health of all instances in all the apps in a specific namespace.