Top Related Projects
Issue tracker and mirror of kubectl code
Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
The Kubernetes Package Manager
Declarative Continuous Deployment for Kubernetes
Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
Pulumi - Infrastructure as Code in any programming language 🚀
Quick Overview
Kustomize is a Kubernetes configuration management tool that allows users to customize raw, template-free YAML files for multiple purposes, leaving the original files untouched and usable as-is. It helps manage complex Kubernetes deployments by providing a way to create, compose, and customize collections of Kubernetes resources.
Pros
- Allows for template-free customization of Kubernetes manifests
- Supports overlay-based configuration management
- Integrates well with existing Kubernetes workflows and tools
- Provides a declarative approach to configuration management
Cons
- Learning curve for users new to Kubernetes or configuration management
- Limited support for complex logic or conditional statements
- May require additional tooling for advanced use cases
- Can become complex with large-scale deployments
Code Examples
- Basic kustomization.yaml file:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
This example defines a basic kustomization that includes a deployment and service, adding a "dev-" prefix to all resources.
- Patching a deployment:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
patches:
- target:
kind: Deployment
name: my-app
patch: |-
- op: replace
path: /spec/replicas
value: 3
This example patches a deployment named "my-app" to set the number of replicas to 3.
- Using a ConfigMapGenerator:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: my-config
literals:
- FOO=bar
- BAZ=qux
This example generates a ConfigMap named "my-config" with two key-value pairs.
Getting Started
-
Install Kustomize:
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash -
Create a kustomization.yaml file in your project directory:
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - deployment.yaml - service.yaml -
Apply the kustomization to your cluster:
kustomize build . | kubectl apply -f -
This will build the kustomization and apply it to your Kubernetes cluster.
Competitor Comparisons
Issue tracker and mirror of kubectl code
Pros of kubectl
- Comprehensive CLI tool for managing Kubernetes clusters
- Integrated with Kubernetes core, ensuring compatibility
- Supports a wide range of operations beyond configuration management
Cons of kubectl
- Limited customization capabilities for complex deployments
- Requires verbose YAML configurations for advanced scenarios
- Less focus on configuration management and templating
Code Comparison
kubectl:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
spec:
containers:
- name: nginx
image: nginx:1.14.2
kustomize:
resources:
- deployment.yaml
patchesStrategicMerge:
- update-replicas.yaml
- update-image.yaml
Key Differences
- kubectl is a general-purpose Kubernetes management tool, while kustomize focuses on configuration customization
- kustomize allows for easier management of environment-specific configurations
- kubectl applies configurations directly, whereas kustomize generates customized YAML files
Use Cases
- Use kubectl for general cluster management and simple deployments
- Choose kustomize for managing complex, multi-environment deployments with shared base configurations
Integration
kustomize functionality is now integrated into kubectl (since v1.14), allowing users to leverage both tools' strengths:
kubectl apply -k ./
This command applies kustomize-style configurations using kubectl, combining the benefits of both tools.
Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
Pros of Flux
- Provides complete GitOps workflow with automated synchronization
- Supports multi-tenancy and RBAC out of the box
- Includes built-in monitoring and alerting capabilities
Cons of Flux
- Steeper learning curve due to more complex architecture
- Requires additional components and CRDs to be installed in the cluster
- May be overkill for simpler deployment scenarios
Code Comparison
Kustomize example:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
Flux example:
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: podinfo
namespace: flux-system
spec:
interval: 5m
path: "./kustomize"
prune: true
sourceRef:
kind: GitRepository
name: podinfo
Kustomize focuses on templating and patching Kubernetes manifests, while Flux provides a complete GitOps solution with automated reconciliation. Kustomize is simpler and more lightweight, making it easier to adopt for basic use cases. Flux offers more advanced features like automated deployments, multi-tenancy, and built-in monitoring, but comes with increased complexity and resource requirements.
The Kubernetes Package Manager
Pros of Helm
- Templating engine allows for dynamic configuration and reusability
- Package management with versioning and rollback capabilities
- Extensive ecosystem with a large library of pre-built charts
Cons of Helm
- Steeper learning curve due to its templating language and chart structure
- More complex setup and maintenance compared to Kustomize
- Potential security risks if not properly configured, especially with third-party charts
Code Comparison
Helm Chart (values.yaml):
replicaCount: 3
image:
repository: nginx
tag: latest
Kustomize (kustomization.yaml):
resources:
- deployment.yaml
patchesStrategicMerge:
- replica-count.yaml
Both Helm and Kustomize are popular tools for managing Kubernetes manifests, but they have different approaches. Helm uses a templating system and package management, while Kustomize focuses on patching and overlays. Helm is more feature-rich but complex, whereas Kustomize is simpler and follows a declarative approach. The choice between them depends on specific project requirements and team preferences.
Declarative Continuous Deployment for Kubernetes
Pros of Argo CD
- Provides a complete GitOps solution for Kubernetes deployments
- Offers a user-friendly web UI for visualizing and managing application deployments
- Supports automated sync and rollback of applications
Cons of Argo CD
- More complex setup and configuration compared to Kustomize
- Requires additional resources to run as a separate service in the cluster
Code Comparison
Kustomize (kustomization.yaml):
resources:
- deployment.yaml
- service.yaml
patchesStrategicMerge:
- patch.yaml
Argo CD (application.yaml):
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
source:
repoURL: https://github.com/example/repo.git
path: kustomize
kustomize:
namePrefix: dev-
While Kustomize focuses on templating and patching Kubernetes manifests, Argo CD provides a complete GitOps solution that can incorporate Kustomize as part of its deployment process. Argo CD offers more features for managing the entire application lifecycle, including automated syncing and rollbacks, while Kustomize is primarily a tool for customizing Kubernetes manifests.
Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
Pros of Terraform
- Broader scope: Manages various cloud providers and services beyond Kubernetes
- State management: Tracks and manages infrastructure state for easier updates and rollbacks
- Extensive provider ecosystem: Supports a wide range of third-party integrations
Cons of Terraform
- Steeper learning curve: More complex syntax and concepts to master
- Less Kubernetes-native: Requires additional setup for Kubernetes-specific resources
- Potential for state drift: Discrepancies can occur between desired and actual infrastructure state
Code Comparison
Kustomize (YAML-based):
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
Terraform (HCL):
resource "kubernetes_deployment" "example" {
metadata {
name = "example-deployment"
}
spec {
replicas = 3
}
}
Kustomize focuses on customizing Kubernetes manifests, while Terraform provides a more general-purpose infrastructure-as-code solution. Kustomize uses YAML for configuration, making it more familiar to Kubernetes users. Terraform uses its own HCL language, which is more versatile but requires additional learning. Kustomize is lightweight and Kubernetes-specific, while Terraform offers broader infrastructure management capabilities at the cost of increased complexity.
Pulumi - Infrastructure as Code in any programming language 🚀
Pros of Pulumi
- Supports multiple programming languages (Python, JavaScript, Go, etc.) for infrastructure as code
- Offers a more flexible and powerful approach to infrastructure management
- Provides state management and drift detection out of the box
Cons of Pulumi
- Steeper learning curve, especially for those new to programming
- Requires more setup and configuration compared to Kustomize
- May be overkill for simple Kubernetes deployments
Code Comparison
Kustomize example:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
Pulumi example (Python):
import pulumi
from pulumi_kubernetes.apps.v1 import Deployment
from pulumi_kubernetes.core.v1 import Service
deployment = Deployment(...)
service = Service(...)
Kustomize focuses on declarative YAML configurations, while Pulumi allows for programmatic infrastructure definition using familiar programming languages. Kustomize is more lightweight and Kubernetes-specific, whereas Pulumi offers a broader scope for managing various cloud resources beyond Kubernetes.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
kustomize
kustomize lets you customize raw, template-free YAML
files for multiple purposes, leaving the original YAML
untouched and usable as is.
kustomize targets kubernetes; it understands and can
patch kubernetes style API objects. It's like
make, in that what it does is declared in a file,
and it's like sed, in that it emits edited text.
This tool is sponsored by sig-cli (KEP).
kubectl integration
To find the kustomize version embedded in recent versions of kubectl, run kubectl version:
> kubectl version --client
Client Version: v1.31.0
Kustomize Version: v5.4.2
The kustomize build flow at v2.0.3 was added to kubectl v1.14. The kustomize flow in kubectl remained frozen at v2.0.3 until kubectl v1.21, which updated it to v4.0.5. It will be updated on a regular basis going forward, and such updates will be reflected in the Kubernetes release notes.
| Kubectl version | Kustomize version |
|---|---|
| < v1.14 | n/a |
| v1.14-v1.20 | v2.0.3 |
| v1.21 | v4.0.5 |
| v1.22 | v4.2.0 |
| v1.23 | v4.4.1 |
| v1.24 | v4.5.4 |
| v1.25 | v4.5.7 |
| v1.26 | v4.5.7 |
| v1.27 | v5.0.1 |
For examples and guides for using the kubectl integration please see the kubernetes documentation.
Usage
1) Make a kustomization file
In some directory containing your YAML resource files (deployments, services, configmaps, etc.), create a kustomization file.
This file should declare those resources, and any customization to apply to them, e.g. add a common label.
base: kustomization + resources
kustomization.yaml deployment.yaml service.yaml
+---------------------------------------------+ +-------------------------------------------------------+ +-----------------------------------+
| apiVersion: kustomize.config.k8s.io/v1beta1 | | apiVersion: apps/v1 | | apiVersion: v1 |
| kind: Kustomization | | kind: Deployment | | kind: Service |
| commonLabels: | | metadata: | | metadata: |
| app: myapp | | name: myapp | | name: myapp |
| resources: | | spec: | | spec: |
| - deployment.yaml | | selector: | | selector: |
| - service.yaml | | matchLabels: | | app: myapp |
| configMapGenerator: | | app: myapp | | ports: |
| - name: myapp-map | | template: | | - port: 6060 |
| literals: | | metadata: | | targetPort: 6060 |
| - KEY=value | | labels: | +-----------------------------------+
+---------------------------------------------+ | app: myapp |
| spec: |
| containers: |
| - name: myapp |
| image: myapp |
| resources: |
| limits: |
| memory: "128Mi" |
| cpu: "500m" |
| ports: |
| - containerPort: 6060 |
+-------------------------------------------------------+
File structure:
~/someApp âââ deployment.yaml âââ kustomization.yaml âââ service.yaml
The resources in this directory could be a fork of someone else's configuration. If so, you can easily rebase from the source material to capture improvements, because you don't modify the resources directly.
Generate customized YAML with:
kustomize build ~/someApp
The YAML can be directly applied to a cluster:
kustomize build ~/someApp | kubectl apply -f -
2) Create variants using overlays
Manage traditional variants of a configuration - like development, staging and production - using overlays that modify a common base.
overlay: kustomization + patches
kustomization.yaml replica_count.yaml cpu_count.yaml
+-----------------------------------------------+ +-------------------------------+ +------------------------------------------+
| apiVersion: kustomize.config.k8s.io/v1beta1 | | apiVersion: apps/v1 | | apiVersion: apps/v1 |
| kind: Kustomization | | kind: Deployment | | kind: Deployment |
| commonLabels: | | metadata: | | metadata: |
| variant: prod | | name: myapp | | name: myapp |
| resources: | | spec: | | spec: |
| - ../../base | | replicas: 80 | | template: |
| patches: | +-------------------------------+ | spec: |
| - path: replica_count.yaml | | containers: |
| - path: cpu_count.yaml | | - name: myapp |
+-----------------------------------------------+ | resources: |
| limits: |
| memory: "128Mi" |
| cpu: "7000m" |
+------------------------------------------+
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
Take the work from step (1) above, move it into a
someApp subdirectory called base, then
place overlays in a sibling directory.
An overlay is just another kustomization, referring to the base, and referring to patches to apply to that base.
This arrangement makes it easy to manage your
configuration with git. The base could have files
from an upstream repository managed by someone else.
The overlays could be in a repository you own.
Arranging the repo clones as siblings on disk avoids
the need for git submodules (though that works fine, if
you are a submodule fan).
Generate YAML with
kustomize build ~/someApp/overlays/production
The YAML can be directly applied to a cluster:
kustomize build ~/someApp/overlays/production | kubectl apply -f -
Community
Code of conduct
Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.
Top Related Projects
Issue tracker and mirror of kubectl code
Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
The Kubernetes Package Manager
Declarative Continuous Deployment for Kubernetes
Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
Pulumi - Infrastructure as Code in any programming language 🚀
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot