Creating Ingress Resources Based on Domains

Refactoring the definition#

We’ll try to refactor our devops-toolkit Ingress definition so that the Controller forwards requests coming from the devopstoolkitseries.com domain. The change should be minimal, so we’ll get down to it right away.

When compared with the previous definition, the only difference is in the additional entry host: devopstoolkitseries.com. Since that will be the only application accessible through that domain, we also removed the path: / entry.

Applying the new definition#

Let’s apply the new definition.

What would happen if we send a similar domain-less request to the Application? We’re sure you already know the answer, but we’ll check it out anyways.

The output is as follows.

There is no Ingress resource defined to listen to /. The updated Ingress will forward requests only if they come from devopstoolkitseries.com.

Since it’s not feasible to give you access to the DNS registry of devopstoolkitseries.com. So you cannot configure it with the IP of your cluster. Therefore, we won’t be able to test it by sending a request to devopstoolkitseries.com.

What we can do is to “fake” it by adding that domain to the request header.

The output is as follows.

Now that Ingress received a request that looks like it’s coming from the domain devopstoolkitseries.com, it forwarded it to the devops-toolkit Service which, in turn, load balanced it to one of the devops-toolkit Pods. As a result, we got the response 200 OK.

Just to be on the safe side, we’ll verify whether go-demo-2 Ingress still works.

We got the famous hello, world! response, thus confirming that both Ingress resources are operational. Even though we “faked” the last request as if it’s coming from acme.com, it still worked. Since the go-demo-2 Ingress does not have any host defined, it accepts any request with the path starting with /demo.

Try it yourself#

A list of all the commands used in the lesson is given below.