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.
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: 8080Not 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"With the 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.
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.
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 portand 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!
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 portfrom 8080 to 443.
cloudtruth --project project_name parameter set --value 443 port