This repository demonstrates how Flux can be leveraged for centralized management of multiple clusters and multiple tenants per cluster. A management cluster is responsible for managing resource synchronization to workload clusters by means of applying Flux Kustomizations using each cluster's kubeconfig file.
This implementation defines several roles that reflect different use cases and permissions:
- Platform Administrator: This is the most powerful role having access to the management cluster's repository. The platform admin creates workspaces and attaches clusters to be managed.
- Workspace Administrator: This role grants access to an individual workspace's repository, managing all applications deployed to clusters in that workspace.
- Cluster Administrator: This role grants access to a repository reconciled by a single cluster, allowing to deploy per-cluster applications.
A workspace is considered as the primary grouping of multiple clusters. One cluster can only be part of one workspace. All resources managed as part of a workspace (e.g. applications to be deployed) are synchronized across all clusters in that workspace, i.e. all clusters in a workspace will receive the same set of resources specific to that workspace.
The second layer of grouping is by tenants. Each cluster may host multiple tenants. Each tenant can only be part of one workspace.
This is the central cluster managing all attached workload clusters.
This is a cluster attached to and managed by the management cluster.
All of the following commands spin up kind clusters. Make sure you have the following commands installed:
First spin up the control plane cluster:
./create-management-cluster.shThen, create a workload cluster:
./create-and-attach-kind-cluster.sh -n attached -w devNow you have two clusters running, a management cluster and a workload cluster. Both are synchronized using (several branches of) this Git repository.
This is a diagram showing the various Flux resources created on the management cluster and on workload clusters.
