Deploying Applications to Production

Creating namespaces

It might seem strange to start with production. It would make more sense to deploy it first to a development environment, promote it to staging, and only then run it in production. From the application lifecycle perspective, that would be, more or less, the correct flow of events. Nevertheless, we’ll start with production, because that’s the easiest use case. Because the default values match what we want to have in production, we can deploy the application to production as is, without worrying about the tweaks we’ll have to make for development and staging environments.

Normally, we’d split environments into different namespaces or even different clusters. But because the latter would require us to create new clusters, and since we want to keep the cost to the bare minimum, we’ll stick with namespaces as a way to separate the environments. The process is mostly the same if we run multiple clusters. The only substantial difference would be in kubeconfig, which would need to point to the desired Kube API.

We’ll start by creating the production namespace.

Adding dependencies

Let’s imagine that we don’t know whether the application has any dependencies, so first we’ll retrieve the list and see what we might need.

We ...