Overview

• Kustomize is a Kubernetes configuration management tool that lets you customize YAML files for different environments without duplicating them. It solves the problem of maintaining multiple slightly different copies of the same config by allowing you to define a base configuration and overlay environment-specific changes like replica counts, labels, or images, making it easier to scale and manage infrastructure consistently

  • Example: You have deployment.yaml for three environments/namespaces, and each environment needs different number of replicas. It’s easy at first, but in the long run when more components are needed, misconfiguration and missing something is very likely, this is where Kustomize comes in

• File structure

  ~/someApp
  ├── base
  │   ├── deployment.yaml
  │   ├── kustomization.yaml
  │   └── service.yaml
  └── overlays
      ├── development
      │   ├── cpu_count.yaml
      │   ├── kustomization.yaml
      │   └── replica_count.yaml
      └── production
          ├── cpu_count.yaml
          ├── kustomization.yaml
          └── replica_count.yaml
  

• Kustomize comes built-in with kubectl so no other packages need to be installed. May still want to install the Kustomize CLI to get the latest version. It also does not require learning how to use any complex and hard to read templating systems (like helm)

• Kustomize is built into kubectl and uses a declarative approach without templating, while Helm uses Go templating for more dynamic, chart-based deployments

• kustomization.yaml file defines the base resources and overlays for customizing Kubernetes configurations in a Kustomize setup

  • Say in a directory you have nginx-depl.yml, nginx-svc.yml, and kustomization.yaml. The kustomization.yaml file would look like this:

    # Resources to be managed by Kustomize
    resources:
    	- nginx-depl.yml
    	- nginx-svc.yml
    
    # A builtin that applies specific label to all your resources, called transformer
    commonLabels:
    	company: KodeKloud
    

  • Kustomize looks for a kustomization file which contains a list of all Kubernetes manifests to manage and all of the customizations that should be applied

  • Check for more built-ins: https://kubectl.docs.kubernetes.io/references/kustomize/builtins/ (also known as transformers)

• You can manage directories in two ways

  • A single kustomization file that applies everything
  • Or create a kustomization.yaml file in each of the subdirectories and import only the resources within that directory

Transformers

• Transformers are plugins that modify Kubernetes resources, like changing labels, annotations, or names, without altering the original YAML files

  • Examples: namePrefix and nameSuffix transformers, which modify resource names, images transformer which can replace image or change tag for a container, and namespace transformers, which automatically apply a namespace to all resources

    

    Reference

  • If you want to apply the transformations for all manifests, add them into the root kustomization file, otherwise use subdirectories if you want to add transformations to specified manifests

  • https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs

Patches

• Patches let you override or modify specific fields in base resources without changing the original files, using strategic merge or JSON patches

  • To create a patch, 3 parameters must be provided:

    • Operation Type: add/remove/replace
    • Target: What resources should this patch be applied on (Kind, Namespace, Name, etc..)
    • Value: What is the value that will either be replaced or added with (only needed for add/replace operation types)

  • If you want to apply a configuration across the board (like adding a label, namespace, etc..), use a common transformer. However, if you wanna apply or change something on one specific object or just a couple of objects, you would use Patch (e.g., updating number of replicas)

  • Patch example

    

    Reference

    • Path is the object path (like metadata.name), can also target an index of a list/array (e.g., /spec/template/spec/containers/0). Check this video from Kodekloud’s CKA course on Udemy for more

  • There are two ways patches can be applied: Strategic merge patch merges changes based on Kubernetes resource structure, while JSON 6902 patch uses a precise, list-based syntax to apply exact changes at specific paths. It’s a matter of preference

    

    Reference

  • You can write patches inline like in previous examples or in a separate file

    # kustomization.yaml
    patches:
      - path: replica-patch.yaml
        target:
          kind: Deployment
          name: nginx-deployment
    ---
    # replica-patch.yaml
    - op: replace
      path: /spec/replicas
      value: 5
    

Overlay

• An overlay in Kustomize is a layer that customizes a base configuration for a specific environment by applying changes like patches, transformers, or variable overrides

• Structure example

  k8s/
  ├── base/
  │   ├── kustomization.yaml
  │   ├── nginx-depl.yaml
  │   ├── service.yaml
  │   ├── redis-depl.yaml
  ├── overlays/
  │   ├── dev/
  │   │   ├── kustomization.yaml
  │   │   └── config-map.yaml
  │   ├── stg/
  │   │   ├── kustomization.yaml
  │   │   └── config-map.yaml
  │   └── prod/
  │       ├── kustomization.yaml
  │       └── config-map.yaml
  

• Example

  

  Reference

  • You can have more than just patches, you can have new configs, new resources (e.g., deploy Grafana), etc.. be sure to include it in the resources in the environment’s kustomization file

Components

• Components provide the ability to define reusable pieces of configuration logic (resources + patches) that can be included in multiple overlays, they are useful in situations where applications support multiple optional features that need to be enabled only in a subset of overlays
• Components shine when you want reusable blocks of code where “components” can be imported into other overlays