May 18, 2022
One Kubernetes Manifest for Dev, Staging, and Prod
Written by: Michael Levan
Kubernetes brings a ton of capability for the cloud-native and even on-prem world. The way it does that for developers and DevOps pros is by utilizing Kubernetes manifests, which give you the ability to deploy several different types of applications, specs, and functionality.
However, there’s one problem; you have to manage multiple manifests for every environment that you have.
Until now! In this blog post, you’ll learn how CloudTruth helps you to have one Kubernetes manifest for dev, staging, and prod.
To follow along with this blog post in a hands-on fashion, you’ll need the following:
- A CloudTruth account, which you can sign up for free here.
- The CloudTruth CLI installed and configured, which you can learn how to do here.
- Kubetruth set up and configured. Kubetruth is the Kubernetes operator for CloudTruth.
Creating a Kubernetes Manifest
First things first; to templatize a Kubernetes manifest, you’ll need a Kubernetes manifest. In this section, you’ll create a Kubernetes manifest to be used across dev, staging, and production.
In a standard environment without CloudTruth, you’d have a Kubernetes manifest that has most of the values hard-coded in it. You could have an environment variables file, but that’s just more management in source control.
Below is an example of a Kubernetes manifest without CloudTruth.
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx labels: run: nginx spec: ports: - port: 80 protocol: TCP
Although the manifest above works fine, the problem is that everything is hard-coded. To list a few examples:
- The replicas are hard-coded at
2. In a dev, staging, and production environment, chances are this value can be different. For example, a dev environment is fine with two replicas, but for staging and production, you want at least 3-4.
- The image version is hard-coded as
latest. For many containerized environments, teams want to use specific versions of a Docker image across environments. Dev, for example, will probably use the latest feature-rich Docker image. Production may not be ready for it yet.
Instead of using that method, you can use the CloudTruth method. Below is the Kubernetes manifest with the parameters.
apiVersion: apps/v1 kind: Deployment metadata: name: namespace: default labels: app: spec: replicas: selector: matchLabels: app: template: metadata: labels: app: spec: containers: - name: image: : ports: - containerPort: --- apiVersion: v1 kind: Service metadata: name: labels: run: spec: ports: - port: protocol: TCP selector: run:
Notice the values that have curly brackets and parameter names inside. For example,
Those parameters can be set within your CloudTruth environments, which you’ll see in the next section. Save the Kubernetes manifest above in any directory you wish and call it
deployment.yaml. You’ll use this in the upcoming section.
Creating a Template in CloudTruth
To create a Kubernetes manifest template in CloudTruth, you first need:
- A CloudTruth project
Below is an example that you can use. It creates a project called
kubernetes-manifest and creates parameters with values.
cloudtruth projects set kubernetes-manifest cloudtruth --project kubernetes-manifest parameter set --value nginx app_name cloudtruth --project kubernetes-manifest parameter set --value 3 replicas cloudtruth --project kubernetes-manifest parameter set --value 80 port cloudtruth --project kubernetes-manifest parameter set --value nginx image_name cloudtruth --project kubernetes-manifest parameter set --value latest nginx_version
Running the above, you’ll see an output similar to the screenshot below in CloudTruth.
Next, you can push the Kubernetes manifest template to CloudTruth by running the following command:
The problem is that those parameters are set for the default environment. In the next section, you’ll learn how to set up parameters for multiple environments.
Using The Template Across Environments
Now that you have a Kubernetes manifest template, you can update values for the parameters across multiple environments. For example, let’s take the
Notice how in the screenshot below it’s using
3 as the default and the default is picked up across multiple environments.
Instead of having the default as
3 for every environment, you can update the value by clicking on the environment and editing the value. For example, you can set the
development environment to have
2 replicas and the production environment to have
Having multiple Kubernetes manifests throughout multiple environments can be a major headache for DevOps teams. Instead of having multiple Kubernetes manifests to manage throughout dev, staging, and prod, you should simply have one that you don’t have to worry about. CloudTruth not only helps in making manifests available for multiple environments, but you can parameterize each piece of config data for any environment.