Using Flux with Kustomize
Scenario and Goals
The following example makes use of Flux's manifest-generation feature together with Kustomize (and other such tooling, in theory).
For this example we assume an scenario with two clusters,
production. The goal is to levarage the full functionality of Flux (including
automatic releases and supporting all
fluxctl commands) to manage both
clusters while minimizing duplicated declarations.
production are almost identical, they both deploy a
podinfo service. However, we
have different requirments for each cluster:
- We want automated deployments for
stagingbut not for
productionsince we want a rubber-stamp every change. However, we want to still be able to make the changes with
- Since we expect
productionto have a higher load than
staging, we want a higher replica range there.
How to run the example
In order to run this example, you need to:
Deploy Flux version 1.13.0 or newer.
Make sure to pass the flag
--manifest-generation=trueto fluxd, in its container spec.
Fork this repository and add the fork's URL as the
--git-urlflag for the fluxd container.
Pick an environment to run (
production) and ask Flux to use that environment by passing flag
As usual, you need to make sure that the ssh key shown by
fluxctl identityis added to the your github fork.
How does this example work?
├── .flux.yaml ├── base │ ├── demo-ns.yaml │ ├── kustomization.yaml │ ├── podinfo-dep.yaml │ ├── podinfo-hpa.yaml │ └── podinfo-svc.yaml ├── staging │ ├── flux-patch.yaml │ └── kustomization.yaml └── production ├── flux-patch.yaml ├── kustomization.yaml └── replicas-patch.yaml
basecontains the base manifests. The resources to be deployed in
productionare almost identical to the ones described here.
productiondirectories make use of
base, with a few patches, to generate the final manifests for each environment:
production/kustomization.yamlare Kustomize config files which indicate how to apply the patches.
production/flux-patch.yamlcontain environment-specific Flux annotations and the container images to be deployed in each environment.
production/replicas-patch.yamlincreases the number of replicas of podinfo in production.
.flux.yamlis used by Flux to generate and update manifests. Its commands are run in the directory (
production). In this particular case,
.flux.yamltells Flux to generate manifests running
kustomize buildand update policy annotations and container images by editing
flux-patch.yaml, which will implicitly applied to the manifests generated with
I want to know more
For a more sophisticated example of using Flux with Kustomize for creating a multitenant cluster you can go to https://github.com/fluxcd/multi-tenancy .
For more details about how
.flux.yaml files work you can read the