NOTE: This guide is for using kustomize
in kubectl
which uses a old version of kustomize
this means your writing a lot of deprecated
codes like using bases
.
Kustomize
is a standalone tool to customize Kubernetes objects through a kustomization
file. It has been part of kubectl
since v1.14
These examples are based on using the built in version of kubectl
but it is strongly suggested to migrate away and use the latest version.
Run kustomization file
To apply
or delete
a set of manifests
you use the -k
command
kubectl apply -k k8s/my-app/overlays/production/
View generated output of kustomization
To view the manifest
that gets generated from kustomize
you can the below command pointing at the the base
or overlays/env
folder
kubectl kustomize k8s/my-app/overlays/production/
base settings
Below are examples of the base
kustomization
file
resources
This is the most basic usage of kustomization
. Allowing you to deploy a namespace
and other manifests
at the same time
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: confluence
resources:
- ./namespace.yml
- ./storage.yml
- ./deployment.yml
- ./service.yml
overlays settings
Below are examples of overlays for various manifests and options.
image or tag
Update the tag of the image pulled via overlay:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
images:
- name: nginx
newTag: 1.19
You could also update the image as well via if you say need to use a different repository
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
images:
- name: nginx # note this is the image: tag not the name of the container
newName: <NEW ECR PATH>/nginx
newTag: 3.4.5
patchesStrategicMerge
If you need to update a value of a manifest
file from the base, the easist way is to create a new file in the overlays/env
folder and reference it via patchesStrategicMerge
.
The file will need to re-create
the yml
down to the value
you are overwriting
for example:
deployment example
A common issue will be updating the env
variables for the pods
in a deplyment
for each overlay
this can be done via creating a file (Below could is called: db-deployment.yml
) containing your env
settings like:
apiVersion: apps/v1
kind: Deployment
metadata:
name: confluence
spec:
template:
spec:
containers:
- name: app
env:
- name: ATL_JDBC_URL
value: "jdbc:postgresql://my-prod-rds-server:5432/db"
- name: ATL_JDBC_USER
value: "postgres"
and then add a patchesStrategicMerge
section to kustomization.yml
and reference the file db-deployment.yml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patchesStrategicMerge:
- db-deployment.yml
service example
Another example would be updating the arn
for a certificate in each overlay
. Again you would simply create a new file in overlays/env
folder (In this example its called arn-serivce.yml
)
arn-service.yml
will copy all yml
from the base
serivce
but ignore all other values that are set so would look like:
apiVersion: v1
kind: Service
metadata:
name: dos
namespace: dos
annotations:
service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:eu-west-2:xx:certificate/xxx
Again you would update kustomization.yml
in the overlays/env
to reference the new resource
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patchesStrategicMerge:
- arn-service.yml
config-maps
You can either write the configmap
into the kustomization
file or keep it in an external file. I prefer the later:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patchesStrategicMerge:
- config-map.yml