In the previous blog post, What Is Kubetruth, you learned all about why CloudTruth created Kubetruth and how it can work for you in any environment to ensure parameters, secrets, and variables have a source of truth. Now that you know what Kubetruth is, it’s time to configure it for use.
In this blog post, you’ll learn how to configure Kubetruth in under five minutes to get your Kubernetes cluster connected to CloudTruth.
To follow along with this blog post, you’ll learn:
- A Kubernetes cluster. This can either be in the cloud, on-prem, or even using Minikube/Docker Desktop on your local computer
First things first, you’ll need a project in CloudTruth and some parameters for Kubernetes.
For the purposes of this blog post, you can create a new CloudTruth project called
cloudtruth --project kubernetes-secrets
Next, create some new parameters in the
kubernetes-secretsproject. Notice how the parameters can be anything from the name of a Docker image to ports. In this case, the parameters are for an Nginx Kubernetes deployment.
cloudtruth --project kubernetes-secrets parameter set --value nginx app_name cloudtruth --project kubernetes-secrets parameter set --value 3 replicas cloudtruth --project kubernetes-secrets parameter set --value 80 port cloudtruth --project kubernetes-secrets parameter set --value nginx image_name cloudtruth --project kubernetes-secrets parameter set --value latest nginx_version
When you log into CloudTruth, you’ll be able to see the new project and parameters.
Create A Kubernetes Manifest
For Kubetruth to push parameter updates to your environment, it needs to be able to see parameters and a Kubernetes manifest. In the previous section, you set up the CloudTruth project and parameters. In this section, you’ll create a Kubernetes manifest and send it to CloudTruth.
In the Kubernetes manifest below, you’ll see that it’s running a Deployment spec that calls out the parameter names that you created in the previous section. Any parameter with curly brackets around it means that’s a value that CloudTruth will consume. For example
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:
Save the above manifest in a location of your choosing and name it
Ensure that you’re in the directory that you saved the
deployment.yaml to via your terminal.
Push the Kubernetes manifest to CloudTruth by running the following command which does the following:
- Sets your CloudTruth project
- Tells CloudTruth that you’re setting a new template
- Giving the name of the Kubernetes manifest
- Naming it
cloudtruth --project 'kubernetes-secrets' template set --body deployment.yaml deployment
You’ll now see the Kubernetes manifest in the templates section of CloudTruth underneath your project.
In the previous sections, you set up:
- CloudTruth parameters
- A Kubernetes manifest that will ingest the parameters
Now it’s time to dive into setting up KubeTruth.
In the same directory that the
deployment.yamlKubernetes manifest exists in from the previous section, create a new file called
Add in the Kubernetes operator configuration which you’ll find below and does the following:
- Gives Kubetruth access to look at Deployments, ReplicaSets, Pods, and Services
- Defines the project selector. For example, on line 27, you’ll see that the
kubernetes-secretsproject is defined.
- Defines what type of templates to utilize. For example, you’ll see under
resource_templateson line 28 that you can use Deployment and Service specs.
# Applying deployment resources requires additional permissions rbac: additionalRoleRules: - apiGroups: ["", "extensions", "apps"] resources: ["deployments", "replicasets", "pods", "services"] verbs: ["*"] # Kubetruth is configured using a CustomResourceDefinition called # ProjectMapping, which allows one to specify how the operator # transforms the data from your CloudTruth projects into kuberenetes # resources projectMappings: # Define the root project mapping, skipping all projects except for the # example we care about root: scope: "root" environment: default skip: true # Define an override ProjectMapping to enable deployment of CloudTruth projects named k8s* k8s-deploy: scope: "override" skip: false # For the project selector, you have to choose the CloudTruth project ## Example below project_selector: "kubernetes-secrets" resource_templates: deployment: '' service: ''
Once the Kubernetes operator is saved, you can install the Kubetruth Helm Chart. The Kubetruth Helm Chart configures the
ctdeploytest-values.yaml to run as an Operator on the Kubernetes cluster. The Operator looks for the Kubernetes manifest template inside of your CloudTruth project along with the parameters.
Ensure to set an API key from your CloudTruth org.
helm repo add cloudtruth https://packages.cloudtruth.com/charts/ helm install --values ctdeploytest-values.yaml --set appSettings.apiKey=$CLOUDTRUTH_API_KEY kubetruth cloudtruth/kubetruth
In a few minutes, you’ll see the Nginx configuration running as a Kubernetes deployment inside of your Kubernetes cluster.
One of the best things about Kubernetes is the ability to extend its features using open-source methodologies. CloudTruth utilized this to create Kubetruth, which has the goal of making Kubernetes easier for you in any environment.
If you’d like to get started with CloudTruth today, there is a free forever version here.
Here’s a short video on this topic: