Quick Example
1. Define a Registry (External Datasource)
yaml
apiVersion: operator.kubernetes-tenants.org/v1 kind: TenantRegistry metadata: name: my-saas-registry spec: source: type: mysql mysql: host: mysql.default.svc.cluster.local port: 3306 database: tenants table: tenant_data username: tenant_reader passwordRef: name: mysql-secret key: password syncInterval: 30s valueMappings: uid: tenant_id hostOrUrl: domain activate: is_active1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2. Create a Template
yaml
apiVersion: operator.kubernetes-tenants.org/v1 kind: TenantTemplate metadata: name: web-app spec: registryId: my-saas-registry deployments: - id: app-deployment nameTemplate: "{{ .uid }}-app" spec: apiVersion: apps/v1 kind: Deployment spec: replicas: 2 template: spec: containers: - name: app image: "nginx:latest" env: - name: TENANT_ID value: "{{ .uid }}" - name: DOMAIN value: "{{ .host }}"1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
3. Automatic Tenant Provisioning
The operator automatically creates Tenant CRs for each active row:
yaml
apiVersion: operator.kubernetes-tenants.org/v1 kind: Tenant metadata: name: acme-web-app spec: uid: acme templateRef: web-app registryId: my-saas-registry # ... auto-populated resources status: desiredResources: 10 readyResources: 10 failedResources: 0 conditions: - type: Ready status: "True"1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Architecture
System Overview
Database Support
* MySQL: Fully supported (v1.0+) * PostgreSQL: Planned for v1.2
Reconciliation Flow
Key Features
🎯 Three-Controller Design
- TenantRegistry Controller: Syncs database (e.g., 1m interval) → Creates/Updates/Deletes Tenant CRs
- TenantTemplate Controller: Validates template-registry linkage and invariants
- Tenant Controller: Renders templates → Resolves dependencies → Applies resources via SSA
📦 CRD Architecture
- TenantRegistry: Defines external datasource, sync interval, value mappings
- TenantTemplate: Blueprint for resources (Deployments, Services, Ingresses, etc.)
- Tenant: Instance representing a single tenant with status tracking
🔧 Advanced Capabilities
- Multi-template support: One registry → multiple templates
- Custom-resource friendly: Render and apply arbitrary CRs once their CRD exists in the cluster
- Garbage collection: Auto-delete when rows removed or activate=false
- Drift detection: Event-driven watches with auto-correction
- Smart requeue: 30-second intervals for fast status reflection
- Resource readiness: 11+ resource types with custom checks
- Finalizers: Safe cleanup respecting deletion policies
Supported Versions & Upgrade Policy
- Compatibility philosophy: The operator relies only on GA/stable Kubernetes APIs and controller-runtime patterns, so it is not tightly coupled to a specific cluster release and is designed to work across the supported upstream version skew.
- Validated range: End-to-end tests and production verification currently cover Kubernetes clusters from v1.28 through v1.33, with live production tenants running on v1.33 today. Earlier or newer versions are expected to function, but validate in a staging environment before rolling out broadly.
- Upgrade guidance: Review the Helm chart values.yaml and the release notes, then use helm upgrade --install to perform rolling upgrades. Any breaking changes or API removals are called out explicitly in the release notes and CHANGELOG.
| v1.28 | ✅ Validated |
| v1.29 | ✅ Validated |
| v1.30 | ✅ Validated |
| v1.31 | ✅ Validated |
| v1.32 | ✅ Validated |
| v1.33 | ✅ Validated |
| Other GA releases | ⚠️ Expected |
.png)


