When you’re working with anything Kubernetes-related, chances are you’re working with a Kubernetes manifest. Kubernetes parameters include secrets and ConfigMaps.
The manifest could be for:
and so much more.
Other than creating the Kubernetes cluster itself, pretty much anything else that you do with Kubernetes as a developer, DevOps engineer, or SRE is going to be around deploying applications from a Kubernetes manifest. The thing about Kubernetes manifests is they have values that need to change.
In this blog post, you’ll learn about the old way to deal with Kubernetes manifest parameters and how CloudTruth can be the new and improved way for your organization.
Kubernetes Parameters The Old Way
Let’s say you have a standard
service Kubernetes manifest that looks like the below code.
apiVersion: v1 kind: Service metadata: name: djangoapp spec: selector: app: djangoapp type: NodePort ports: - protocol: TCP port: 8080 targetPort: 8080
Not only are there two parameters that you need to keep up to date, the team needs to know the values, and you have to store that information somewhere (engineering wiki, source control, wherever else), but you also need to have environment variables configured.
To configure environment variables, you’ll need to put them into your Kubernetes manifest in one way or another. One of those ways is in the code below:
env: - name: port value: "8080"
env configuration above, you’ll have to constantly manage those values to confirm they’re what you wanted in the first place.
Sure, there are
.env files for environment variables, but then you have to manage yet another configuration file. The more
.env files you have, the more developers and engineers will have to manage them in source control. It ends up becoming a nightmare to not only keep them up to date but to have everyone on the team know which environment variables they should be using and when they need to be updated.
In short, there are absolutely ways to manage values (like ports or Docker image names), but it’s a major headache.
The Same Manifest For Multiple Projects
Taking a look again at the
service Kubernetes manifest above, it’s a pretty standard manifest for a service. In fact, a lot of the
service manifests look exactly like that. The biggest component that you’re specifying is pretty much the deployment/app name, the selector which is the deployment/app, the app port, and the target port.
Because it’s such a standard manifest, wouldn’t it be great to have the ability to use that standard manifest across every single one of your projects?
In the next two sections, you’ll learn how CloudTruth makes using the manifest across every project ridiculously easy.
Create Kubernetes Parameters With CloudTruth
With CloudTruth, you don’t have to worry about managing
.env files or adding
env parameters into Kubernetes manifests. Instead, you only have to worry about parameters that exist in CloudTruth (and managing them is easy).
Let’s take the
service manifest from above. With CloudTruth, it’ll look like this:
apiVersion: v1 kind: Service metadata: name: spec: selector: app: type: NodePort ports: - protocol: TCP port: targetPort:
Notice how there are now keys that have brackets around them. Those are the parameter names in CloudTruth. Then, all you have to do is create the parameters in CloudTruth that hold the values. The commands to do that are below:
cloudtruth --project project_name parameter set --value nginx app_name cloudtruth --project project_name parameter set --value 8080 port
and just like that, you no longer have to worry about environment variables roaming around a Kubernetes manifest that are hard-coded or managing a million
.env files. It’s all stored in CloudTruth for you!
Update Kubernetes Parameters With CloudTruth
You may be thinking to yourself well, what if I want to update the values? Do I have to log into CloudTruth and update them?
Nope! You simply run the same
parameter set CloudTruth CLI command from above and the command updates the value for you. For example, the below command will change the
cloudtruth --project project_name parameter set --value 443 port