2025-12-14Hünkar Döner

Managing Kubernetes Manifests with Kustomize

KubernetesKustomizeDevOpsIaCEKS
M

Managing Kubernetes Manifests with Kustomize

In the world of Kubernetes, there are many ways to manage resources. Unlike template-based tools like Helm, Kustomize offers a template-free, declarative approach to managing Kubernetes manifest files (YAML). It allows you to maintain your "Base" manifests untouched while applying changes via "Overlays", making cross-cutting changes, and easily propagating these changes across different environments (Dev, Test, Prod).

A Basic Example: Deployment

For example, let's say you have a standard deployment.yaml for a checkout application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
  labels:
    app.kubernetes.io/name: checkout
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: checkout
  template:
    metadata:
      labels:
        app.kubernetes.io/name: checkout
    spec:
      containers:
        - name: checkout
          image: "public.ecr.aws/aws-containers/retail-store-sample-checkout:1.2.1"
          ports:
            - containerPort: 8080

Applying Changes (Patching)

This file might have already been applied. However, let's say you want to horizontally scale this component and increase the replica count from 1 to 3. Instead of manually editing the original YAML file, we can use Kustomize to update the spec/replicas field.

To do this, we create a kustomization.yaml file and define a patch:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../../base-application/checkout
patches:
  - path: deployment.yaml
    target:
      kind: Deployment
      name: checkout

And the content of the patch file deployment.yaml only contains the changed parts:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 3

Applying the Changes

You can use the built-in support within kubectl to apply this kustomization. The kubectl kustomize command shows you the final YAML file that will be generated:

kubectl kustomize ~/environment/eks-workshop/modules/introduction/kustomize

The output of this command is the full manifest ready to be applied to Kubernetes. You can pipe the output directly to kubectl apply:

kubectl kustomize ~/environment/eks-workshop/modules/introduction/kustomize | kubectl apply -f -

Or more practically, you can apply the directory directly using the -k flag:

kubectl apply -k ~/environment/eks-workshop/modules/introduction/kustomize

Dynamic Variables with Envsubst

Kustomize works with pure YAML and does not directly support variable substitution (templating). However, in some cases, you may need to inject environment variables such as Amazon EKS cluster name or AWS region into manifests.

A common pattern in this case is to use it with the envsubst tool:

kubectl kustomize ~/environment/eks-workshop/base-application   | envsubst | kubectl apply -f -

This command chain first generates the YAML with Kustomize, then replaces variables like $EKS_CLUSTER_NAME with their actual values using envsubst, and finally applies it to Kubernetes.

Kustomize simplifies configuration management without dealing with complex template languages and provides an excellent foundation for GitOps processes.