One Kubernetes Manifest for Dev, Staging, and Prod

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.

Prerequisites

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
• Parameters

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 replicas parameter.

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 4.

Wrapping Up

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.