mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-06-11 09:02:53 +00:00
119 lines
3.1 KiB
Markdown
119 lines
3.1 KiB
Markdown
---
|
|
title: "Overview"
|
|
linkTitle: "Overview"
|
|
weight: 1
|
|
type: docs
|
|
description: >
|
|
Introduction to Kustomize
|
|
---
|
|
|
|
{{< alert color="success" title="TL;DR" >}}
|
|
- Kustomize helps customizing config files in a template free way.
|
|
- Kustomize provides a number of handy methods like generators to make customization easier.
|
|
- Kustomize uses patches to introduce environment specific changes on an already existing standard config file without disturbing it.
|
|
{{< /alert >}}
|
|
|
|
Kustomize provides a solution for customizing Kubernetes resource configuration free from templates and DSLs.
|
|
|
|
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](https://www.gnu.org/software/make), in that what it does is declared in a file,
|
|
and it's like [sed](https://www.gnu.org/software/sed), in that it emits edited text.
|
|
|
|
## 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_.
|
|
|
|
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`.
|
|
|
|
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
|
|
|
|
```sh
|
|
kustomize build ~/someApp/overlays/production
|
|
```
|
|
|
|
The YAML can be directly `applied` to a cluster:
|
|
|
|
```sh
|
|
kustomize build ~/someApp/overlays/production | kubectl apply -f -
|
|
```
|
|
|