Repository Structure for Flux2 Multi-Tenancy
This guide explains the repository structure for the Flux2 Multi-Tenancy project. It covers different ways of structuring repositories and provides examples for each option.
Ways of structuring your repositories
Flux provides several approaches to organizing repositories for a smooth GitOps experience.
Monorepo
In a monorepo approach, all your Kubernetes manifests are stored in a single Git repository. The various environments-specific configs are all stored in the same branch (e.g. main).
Example structure (kustomize overlays):
├── apps
│ ├── base
│ ├── production
│ └── staging
├── infrastructure
│ ├── base
│ ├── production
│ └── staging
└── clusters
├── production
└── staging
Each cluster state is defined in a dedicated dir (e.g. clusters/production) where the specific apps and infrastructure overlays are referenced.
Delivery
The delivery process is similar to the monorepo one. The main difference is the separation of concerns, where the platform admin team handles the change management of the infrastructure, but delegates the apps delivery to the dev teams.
Repo per app
It is common to use the same repository to store both the application source code and its deployment manifests.
Security Documentation
The Flux2 Multi-Tenancy project provides detailed information on the roles and permissions for this multi-tenancy approach. Flux follows Kubernetes best RBAC practices, which forbid cross-namespace references to potential sensitive data.
GitHub Actions Manifest Generation
Flux uses one branch per Kustomization, and to trigger an update, you must write to a deploy branch or tag. The YAML manifests to deploy are sourced from just one branch.
Source API reference v1beta2
The GitRepositoryInclude specifies a local reference to a GitRepository which Artifact (sub-)contents must be included, and where they should be placed.
Flux from End-to-End
This guide describes the flow of data through Flux, from End to End, and how Flux users can expect their change to flow through the stages of its life as a commit.
Code Documentation
The code documentation for the Flux2 Multi-Tenancy project is not provided in the given links.
Code Snippets
The code snippets are not directly related to the repository structure but provide additional context on how to use Flux with Kyverno policies and multi-tenancy.
infrastructure/kyverno-policies/verify-git-repositories.yaml
This snippet shows a Kyverno policy that verifies Git repositories.
tenants/base/dev-team/sync.yaml
This snippet is an example of a sync configuration for a dev team.
tenants/base/dev-team/rbac.yaml
This snippet is an example of RBAC configuration for a dev team.
