kubectl create ns flux
export GHUSER="jstone28"
fluxctl install \
--manifest-generation=true \
--git-user=${GHUSER} \
--git-email=${GHUSER}@users.noreply.github.com \
[email protected]:${GHUSER}/flux-kustomize-example \
--git-path=staging \
--namespace=flux | kubectl apply -f -
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, staging
and
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.
staging
and production
are almost identical, they both deploy a
podinfo
service. However, we
have different requirments for each cluster:
- We want automated deployments for
staging
but not forproduction
since we want a rubber-stamp every change. However, we want to still be able to make the changes withfluxctl
. - Since we expect
production
to have a higher load thanstaging
, we want a higher replica range there.
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=true
to fluxd, in its container spec. -
Fork this repository and add the fork's URL as the
--git-url
flag for the fluxd container. -
Pick an environment to run (
staging
orproduction
) and ask Flux to use that environment by passing flag--git-path=staging
or--git-path=production
-
As usual, you need to make sure that the ssh key shown by
fluxctl identity
is added to the your github fork.
├── .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
base
contains the base manifests. The resources to be deployed instaging
andproduction
are almost identical to the ones described here.- the
staging
andproduction
directories make use ofbase
, with a few patches, to generate the final manifests for each environment:staging/kustomization.yaml
andproduction/kustomization.yaml
are Kustomize config files which indicate how to apply the patches.staging/flux-patch.yaml
andproduction/flux-patch.yaml
contain environment-specific Flux annotations and the container images to be deployed in each environment.production/replicas-patch.yaml
increases the number of replicas of podinfo in production.
.flux.yaml
is used by Flux to generate and update manifests. Its commands are run in the directory (staging
orproduction
). In this particular case,.flux.yaml
tells Flux to generate manifests runningkustomize build
and update policy annotations and container images by editingflux-patch.yaml
, which will implicitly applied to the manifests generated withkustomize build
.
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
reference documentation