Deploying to a New Namespace

Altering the deployment definition#

As we explained in Creating a new Namespace lesson, the main objective of the deployment is to provide a means to test the release. It should remain hidden from our users.

The users should be oblivious to the existence of the new Deployment and continue using the release 1.0 until we are confident that 2.0 works as expected.

Just as before, we used sed to alter the image definition. This time, we’re deploying the tag 2.0.

Apart from changing the image tag, we also modified the host. This time, the Ingress resource will be configured with the host 2.0.go-demo-2.com. That will allow us to test the new release using that domain while our users will continue seeing the production release 1.0 through the domain go-demo-2.com.

Verification#

Let’s confirm that the rollout finished.

The output is as follows.

As you can see, we rolled out the Deployment go-demo-2-api, along with some other resources. That means that we have two sets of the same objects with the same name. One is running in the default Namespace, while the other (release 2.0) is running in the testing Namespace.

Before we celebrate the successful deployment of the new release without affecting production, we should verify that both are indeed working as expected.

If we send a request to go-demo-2.com, we should receive a response from the release 1.0 running in the default Namespace.

The output is as follows.

If, on the other hand, we send a request to 2.0.go-demo-2.com, we should get a response from the release 2.0 running in the testing Namespace.

The output is as follows.

Concluding remarks#

The result we accomplished through different Namespaces is very similar to what we’d expect by using separate clusters. The main difference is that we did not need to complicate things by creating a new cluster. We saved time and resources by using a new Namespace instead.

If this would be a “real world” situation, we’d run functional and other types of tests using the newly deployed release. Hopefully, those tests would be automated, and they would last for only a few minutes. We’ll skip the testing part since it’s not within the scope of this chapter. Instead, we’ll imagine that the tests were executed and that they were successful.

Communication is an important subject when working with Namespaces, so in the next lesson, we’ll spend a few moments exploring it.

Try it yourself#

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