There is a better way to Kustomize Kubernetes deployments for multiple environments by using a centralized parameter and secret store with templating.
Prerequisites
To follow along with this blog post, you should have the following:
A CloudTruth account. If you don’t have one, you can sign up for free here.
A code editor, like VS Code
What is Kustomize?
In many organizations, you’ll see multiple environments, sometimes including:
Development
Staging (or UAT)
Production
Each of those environments has configurations that need to be created, managed, and maintained. It can be a hassle as it’s more deployment configurations, parameters, config data, and code to manage.
Kustomize gives the ability to segregate environments (like dev, staging, and prod) and have configuration files that are specific to each environment. The configuration files are called kustomization.yaml. Then, the Kustomize configuration files point to a “base” configuration, which is essentially a bunch of Kubernetes Manifests. Kustomize then changes the “base” configuration of the Kubernetes Manifests with the values from the Kustomize configuration files.
Below are two screenshots for a visual representation.
How To Use Kustomize
To use Kustomize, you need three things:
A folder hierarchy (like in the screenshot above)
Kubernetes Manifest(s)
One or multiple (depending on how many environments you have) kustomization.yaml files
First, create three directories called base, overlays, and dev
Next, inside of the base directory, create two files:
deployment.yaml
kustomization.yaml
Inside of the deployment.yaml, add the following Kubernetes Manifest:
You’ve created two things; the Kubernetes Manifest that Kustomize will look for and the Kustomize config file that tells Kustomize what Kubernetes Manifests you want to use.
Next, inside of the dev directory, create a new file called kustomization.yaml and add the following code:
What the above kustomization.yaml file is doing is pointing to the base directory, which is where the Kuberentes Manifest and Kustomize config base files live. Then, it’s specifying in the configuration that for the nginx-deployment app, only add one replica.
Now, you can run kustomize build and see the output, specifying only one replica.
How about Configuration Data?
Here’s what Kustomize doesn’t solve:
You still have multiple environment/parameter/config data files
You have to have multiple directory structures for different stages (dev, staging, prod, etc.)
There’s no central way to pass in config data/parameters from one centralized location
Kustomize focuses on replacing values instead of managing values for each environment/stage
Although the above is great and Kustomize is an amazing tool, you still need a way to centrally manage the config data that you’re passing in. You can use both Kustomize and CloudTruth to segregate environments, config files, and manage multiple parameters.
Taking a look at the screenshot below, you can see that:
There’s a project called kustomize
There’s a parameter called replicaCount that has a value of 1 Kubernetes replica
This means that using CloudTruth, Kustomize will look at CloudTruth to retrieve the replicaCountvalue for the k8s manifest.
Inside of the kustomization.yaml file, you’d specify the CloudTruth parameter name replicaCount in two curly brackets, as shown in the code snippet below:
The last step is to run the CloudTruth command below to:
Specify what project you want to pull a parameter from
The environment
Specify the command you want to run. In this case, it’s the kustomize build command
cloudtruth --project "kustomize" --env development run -- kustomize build
The output would be a Kubernetes Manifest that contains the 1 replica.
Wrapping Up
In the DevOps world today, there are a million tools to choose from. Because of that, you may sometimes see that tools are chosen that can do a job, but may not be the right fit. However, combined with other tools and platforms, they become a perfect match.
If you’d like to get started with CloudTruth today, there is a free forever version here.