Hello readers, In this blog, we’ll see kustomize which is a neat simple tool that allows you to kustomize and template your resource manifest.
it lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as-is.
so I’ve got my 3 nodes Kubernetes cluster which is based on Rancher’s k3d.
kubectl get nodes
So the idea is to start with a template manifest and then start kustomizing that manifest file depending on where you want to deploy.
kubectl create deploy nginx --image nginx --dry-run=client -o yaml > deployment.yaml
it’ll create a very simple deployment manifest for you.
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx
and if you want to deploy what we normally do:
kubectl create -f .
All right now, what I’m gonna do is to create a file called kustomization. yaml
resources: - deployment.yaml commonLabels: owner: yamika
so if you’re using Kustomize either use its binary (which we’ll see later ) or use the built-in kubectl command.
it will expect a file called kustomization.yaml so that’s required in this file is the list of resources that you’re going to deploy.
you can include other files and even subdirectories also in the form of a list in kustomization.yml like below:
resources: - deployment.yaml - service.yaml - /build/src/nginx.yml
After it without touching the deployment.yml, I’m gonna update it through kustomization.yaml
so and the only kustomization I’m doing is adding the label to all the resources that I’m deploying
through this kustomization.yaml
In this case, we’ve only one deployment.yaml so all the resources that deployment is gonna create the deployment itself the replica set, the pods, the containers everything will have this label owner is linked in so now how about deploying this in our cluster by downloading the binaries.
tar zxf kustomize_v3.8.5_linux_amd64.tar.gz
sudo mv kustomize /usr/local/bin
before applying the kustomization.yaml make sure the same deployment isn’t running. I deleted that’s why.
kustomize build .
now you have this resulting file so you can apply it in your Kubernetes cluster.
and you can see the label owner has been applied to my deployment manifest.
kubectl create -k . kubectl get deploy
kubectl get all
you can see our nginx is deployed so what kustomization we did, we added the labels owner as yamika
to all our resources to verify it.
kubectl get all --show-labels
kubectl delete -k .
so what else we can do? so imagine you’ve got different environments like a production environment, staging environment or testing environment and so on. and you want to use the same manifest but you want to customize it depending on in which environment you want to deploy.
let me show you how you can do that:
in dev/kustomization.yaml only change I’m doing here is I’m prefixing all the resources with the name dev- and prod-
bases: - ../../base namePrefix: dev-
bases: - ../../base namePrefix: prod-
and base have the same deployment and kustomization.
in addition to that previous kustomization now I’m adding one more kustomization which is adding a name prefix. so all the resources will have name prefix as defined.
kustomize build overlays/dev
kustomize build overlays/prod
we didn’t copy the deployment.yaml it’s in the base directory. we just have the kustomization we want to apply and just refer it uses the bases.
After it let’s try and deploy it:
kubectl create -k overlays/dev
kubectl create -k overlays/prod
kubectl get all