If you’re new to Kubernetes and need an easier way to manage multiple Kubernetes configurations, it’s worth taking a look at CloudTruth’s Kubernetes operator called KubeTruth.
Dynamically updating as ConfigMaps and Secrets within Kubernetes, KubeTruth provides an automated Kubernetes configuration management system. KubeTruth accesses CloudTruth parameters and dynamically creates Kubernetes ConfigMaps and Secrets resources for specific projects or environments when you need them.
Let’s take a look at CloudTruth’s KubeTruth and see how it can help manage the dozens of configuration items necessary for a typical dev/test/prod Kubernetes environment.
As the number of applications and services increases, the environments you must support grow larger, and managing their configurations becomes exponentially more difficult. Instead of managing each configuration, on its own, in multiple places, CloudTruth centralizes all that configuration in a single place.
Rather than directly storing and managing configuration items in variable holders like Kubernetes Secrets or ConfigMaps, KubeTruth enables you to define them in CloudTruth and have them synchronized to Kubernetes. Your application can continue to reference them in a Kubernetes native fashion, without having to change any existing access patterns.
Figure 1 shows how CloudTruth parameters (CloudTruth_Parameter1→Value1) are stored in a project (MyFirstProject).
KubeTruth acts as a tunnel between CloudTruth and a Kubernetes cluster. This tunnel allows you to organize and manage configuration across projects and environments using the rich set of capabilities that the CloudTruth UI provides. These values are then exposed to Kubernetes as ConfigMaps and Secrets within Kubernetes, as shown in Figure 2.
KubeTruth is available as a Helm package. Once you’ve added the CloudTruth repository as a source, you can install KubeTruth, as shown below. Once Kubernetes knows where to find KubeTruth, you can simply run “helm install,” providing the dedicated namespace, API key, and environment to install it in. See Figure 3.
## Tell Helm where to find the Kubetruth package
helm repo add cloudtruth https://packages.cloudtruth.com/charts
## Install the Kubetruth Helm package
helm install \
--create-namespace --namespace shanky-kubetruth \
--set appSettings.apiKey=XXXXXXX \
--set appSettings.environment=default \
kubetruth-install cloudtruth/kubetruth
Once KubeTruth installs, it will create ConfigMaps and Secrets for every CloudTruth project. As you can see in Figure 4, the ConfigMaps and Secrets created by default are easy to identify, as they are created with the label [app.kubernetes.io/managed-by:](http://app.kubernetes.io/managed-by:) kubetruth.
kubectl get secrets -n shanky-kubetruth -o wideOnce you’ve installed KubeTruth, it’s time to take it for a spin. Since KubeTruth interacts directly with CloudTruth through its API, you can now define CloudTruth parameters which will immediately be available in Kubernetes.
Figure 5 shows the newly created CloudTruth project, called MyFirstProject. This project has two parameters —CloudTruth_Parameter2 and CloudTruth_Parameter1 —added to the project.
Once created, you can now see these parameters are available within Kubernetes as ConfigMaps, as shown in Figure 6.
If you’re still wrangling configuration values across various projects and environments individually, it’s worth your time to check out CloudTruth and their Kubernetes integration. Having the ability to access configurations dynamically via Secrets and ConfigMaps is a major time-saver.