kustomize-examples
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
lza_menace 58a30358b6 init 4 years ago
base init 4 years ago
images init 4 years ago
overlays init 4 years ago
Brewfile init 4 years ago
README.md init 4 years ago

README.md

Kustomize Example

The intention of this repo is to showcase some of the capabilities of Kustomize. I have adapted one of the examples from the Kustomize Github repo; the rest can be found here: https://github.com/kubernetes-sigs/kustomize/tree/master/examples

Bases vs Overlays

Bases

When you run kustomize the "base" is loaded into memory and if any "overlays" exist that match they are merged over top of your "base" configuration. The "base" is the core module which defines the container infrastructure and their properties.

In this example, my base consists solely of the "hello" Golang application and Kubernetes objects for deployment, service, and configmap.

base
├── hello
│   ├── configMap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
└── kustomization.yaml

I could deploy this as-is to a cluster by running kustomize build base | kubectl apply -f -, but I would miss out on being able to make minor adjustments to account for variances between environments. Maybe you want labels to reflect the environment it's running in; maybe things should be in a different namespace; maybe you want different environment variables or secrets.

Enter overlays.

Overlays

Overlays are where you can make those minor adjustments that build upon the base. In this example I've setup overlays for each environment, though I've seen them used for particular clusters or namespaces; use it however makes the most sense.

overlays
├── production
│   ├── deployment.yaml
│   └── kustomization.yaml
└── staging
    ├── kustomization.yaml
    └── map.yaml

Staging

For the staging overlay I'm adjusting the labels and annotations to reflect the staging environment. Also, I'm using a different configmap for the "hello" application whch is referenced in the base deployment; this will reflect in the output when reaching the service at the load balancer via HTTP.

Now I can apply staging specific resources to my cluster by running kustomize build overlays/staging | kubectl apply -f -. Compare the diffs between the rendered base and rendered staging overlay:

Production

For the production overlay I'm adjusting the labels and annotations as well as bumping deployment replicas and injecting a new environment variable.

Apply it with kustomize build overlays/production | kubectl apply -f -. Now compare the diffs between rendered base and rendered production overlay:

Staging vs Production

Finally, comparing diffs between staging and production helps to see the differences between them.

Further Reading

I found these links helpful in my evaluation of tooling which ultimately lead to my recommendations: