Kubernetes is itself an open platform. You can create any type of configuration you want for it, extend the capabilities, and even look at the source code to see how it works underneath the hood. Because of that, creating new ways to work with Kubernetes and other software products is possible.
In this blog post, you’ll learn how Kubernetes Operators work and how CloudTruth implements them.
What’s a Kubernetes Operator / Controller?
With any platform, big or small, there are always additions that you want to see and use. With closed-source platforms, you typically have to put in some type of feature request. With open-source platforms, you can write the integration yourself. Whether you’re creating a pull request to contribute to code or you’re writing your own API to create a new implementation that’ll be used internally, you have the ability to extend capabilities.
Kubernetes Controllers allow you to do exactly that. In short, a Controller allows you to extend the capabilities of the Kubernetes API. As new ways of working with Kubernetes comes out, like using Ingress Controllers or Service Meshes, the capability has to be added to Kubernetes. The reason why is because newer capabilities didn’t already exist in Kubernetes, but the design of Controllers fixes this problem.
For example, the way that you write Deployment specs or Pod specs in a Kubernetes Manifest is because a Controller exists in the Kubernetes API for this functionality. KubeTruth is a Controller.
What’s Kubetruth and How Does It Work?
In the previous section, you learned about Kubernetes Controllers and why they’re useful. It essentially extends the functionality of Kubernetes. KubeTruth is doing exactly that; extending the functionality of Kubernetes to interact with CloudTruth.
KubeTruth is an integration that allows you to push updates to Kubernetes resources via CloudTruth. The updated resources could be anything from:
- Environment variables
- Docker image names
- PersistentVolumes names
and literally, any other value that you can store in Kubernetes. The great thing about KubeTruth is that it’s not just about one type of parameter resource. You can store and use any type you’d like.
To make things as simplistic as possible, there is a Kubernetes Helm Chart that you can use to install KubeTruth in any Kubernetes cluster. After it’s installed, there’s a short and sweet configuration file that you can use to update things like what CloudTruth projects you want to pull parameters/secrets from to use in your Kubernetes cluster.
KubeTruth Use Cases
Now that you know what Kubernetes Controllers are, what KubeTruth is, and why you’d use it, let’s think about two common scenarios of why you’d use CloudTruth and Kubernetes.
The first and most common scenario in many cases is Kubernetes Secrets. Kubernetes Secrets can be a major pain because even though they’re secrets, you still have to write them in a Kubernetes Manifest and store that Kubernetes Manifest somewhere. Wherever you store it, the values of the Secrets will be in plain text. The second pain point is with the standard out-of-the-box default Secrets method, called Opaque, Kubernetes Secrets aren’t encrypted by default. When using CloudTruth, you don’t have to worry about storing plain-text secrets or unencrypted environments. Instead, you can store Secrets (and any other type of value) within CloudTruth.
The second common scenario is utilizing one Kubernetes Manifest for every environment. By default, if you want to use one Kubernetes Manifest for say, Dev, Staging, and Prod, you have to write and manage environment variable files. Creating, managing, and maintaining them can be a major time sink. Instead, you can store parameters and any other value inside of CloudTruth. You can also push the Kubernetes Manifest up to CloudTruth using Templates. That way, the Manifest is stored in CloudTruth and you can compare your parameters based on environment, making it easy to read and understand what values are going to what environment.
Wrapping Up – Check out our Kubernetes Operator
Kubernetes enablement is a core focus at CloudTruth. After all, as engineers, we know that managing Kubernetes secrets, environment variables, and configs can be a major pain. With KubeTruth, the goal is to ease that pain and make it almost non-existent.
If you’d like to get started with Kubetruth, feel free to take a look at the GitHub repo found here.