Cluster Bootstrapping for the Flux2 Multi-Tenancy project involves setting up and configuring Flux in a cluster using various methods. This explanation will cover the possible options with examples for each option, using the provided documentation and code snippets.
Flux Bootstrapping
Flux bootstrapping deploys Flux on a cluster using GitOps. The flux bootstrap command pushes Flux manifests to a Git repository and deploys Flux on the cluster. The following options are available for flux bootstrap:
--author-email: author email for Git commits--author-name: author name for Git commits (default “Flux”)--branch: Git branch (default “main”)--ca-file: path to TLS CA file used for validating self-signed certificates--cluster-domain: internal cluster domain (default “cluster.local”)--commit-message-appendix: string to add to the commit messages, e.g. ‘[ci skip]’
For example, to bootstrap Flux using GitHub, run:
flux bootstrap github \
--interval 10s \
--owner scottrigby --personal \
--repository flux-for-helm-users \
--branch main \
--path=clusters/dev
This command connects to the GitHub repository, clones the specified branch, generates component manifests, and commits sync manifests to the repository.
Cluster Bootstrapping with Sharding
Flux sharding and horizontal scaling involve configuring multiple instances of Flux controllers to manage tens of thousands of applications. To enable horizontal scaling, each controller is deployed multiple times with a unique label selector, which is used as the sharding key.
To bootstrap multiple controller instances and shard the reconciliation of Flux resources, follow these steps:
- Create a Git repository and clone it locally.
- Create the file structure required by bootstrap:
mkdir -p clusters/my-cluster/flux-system
- Define the number of shards and spin up a Flux controller instance for each shard.
Flux Bootstrapping for Git Servers
To control multiple clusters from the same Git repository, set a unique path per cluster, such as clusters/staging and clusters/production. Each cluster path should contain a flux-system namespace directory generated by bootstrap.
For example:
clusters/
├── staging # <- path=clusters/staging
│ └── flux-system # <- namespace dir generated by bootstrap
│ ├── gotk-components.yaml
│ ├── gotk-sync.yaml
│ └── kustomization.yaml
└── production # <- path=clusters/production
└── flux-system
Flux Multi-Tenancy
The Flux2 Multi-Tenancy project provides a guide for Helm users transitioning from the Helm Operator to the Helm Controller. The Helm Controller is part of Flux v2 and offers multi-cluster management.
For more information on Flux multi-tenancy, refer to the Flux 2 Multi-Tenancy Guide.
Security Best Practices
Running multiple Flux instances within the same cluster is supported by means of sharding. It is recommended to have additional instances of both Kustomize and Helm controllers that focus on applying platform level changes, which do not compete with Tenants’ changes.
For more information on Flux security best practices, refer to the Flux Security Best Practices documentation.
Optional Components
Flux includes optional components that can be installed during bootstrapping. These components include:
- Source Controller
- Kustomize Controller
- Helm Controller
- Notification Controller
- Image Automation Controller
To install optional components, use the --components flag with flux bootstrap git. For example:
flux bootstrap git \
--cluster-domain cluster.internal \
--components=source-controller,kustomize-controller,helm-controller
This command installs the Source, Kustomize, and Helm controllers during bootstrapping.
For more information on Flux optional components, refer to the Flux Optional Components documentation.
