Overlays und Components

Die Repository-Struktur basiert auf den Empfehlungen von Kustomize und wurde für den Multi-Cluster-Betrieb mit FluxCD angepasst.

Ziel ist die Wiederverwendbarkeit von Konfigurationen bei gleichzeitig minimaler Duplizierung und klarer Trennung von Verantwortlichkeiten.

Überblick

Jedes Modul folgt grundsätzlich derselben Struktur:

module/
├── base/
├── components/
├── overlays/
└── optional: crds/

Die einzelnen Ebenen erfüllen unterschiedliche Aufgaben.

Ebene Zweck

Base

Grundlegende Installation einer Anwendung oder Infrastruktur-Komponente

Components

Optionale und wiederverwendbare Erweiterungen

Overlays

Cluster-spezifische Ausprägung einer Installation

CRDs

Separat verwaltete Custom Resource Definitions

Architekturmodell

Die Plattform verwendet kein klassisches Dev-/Stage-/Prod-Modell.

Stattdessen werden Overlays primär verwendet, um Cluster-spezifische Konfigurationen abzubilden.

Beispiele:

overlays/
├── home.tamay.cloud/
├── tamay.cloud/
└── test.tamay.cloud/

Die Cluster stellen unterschiedliche Betriebsumgebungen mit unterschiedlichen Anforderungen dar.

Ein Overlay beschreibt daher eine konkrete Installation einer Komponente innerhalb eines bestimmten Clusters.

Base

Die Base beschreibt die grundlegende Installation.

Sie enthält keine cluster-spezifischen Werte und sollte unverändert in mehreren Clustern verwendbar sein.

Typische Inhalte:

  • Namespace

  • HelmRelease

  • OCIRepository

  • Deployments

  • Services

  • Standardkonfiguration

Beispiel:

traefik/
└── base/
    ├── helmrelease.yaml
    ├── namespace.yaml
    └── ocirepository.yaml

Die Base beantwortet die Frage:

Wie wird diese Komponente grundsätzlich installiert?

Components

Components sind optionale Erweiterungen einer Installation.

Sie modellieren Funktionsblöcke, die unabhängig vom Zielcluster mehrfach verwendet werden können.

Typische Anwendungsfälle:

  • Monitoring

  • Backups

  • Zusätzliche Datenbanken

  • Öffentliche Erreichbarkeit

  • Image Automation

  • Erweiterte Storage-Anbindungen

Beispiel:

components/
└── monitoring/

Components werden nicht direkt deployt, sondern von einem Overlay eingebunden.

Die Frage lautet:

Welche zusätzlichen Funktionen sollen aktiviert werden?

Overlays

Overlays repräsentieren die tatsächliche Installation einer Komponente auf einem Cluster.

Ein Overlay kombiniert:

  • Base

  • Components

  • Cluster-spezifische Konfiguration

Beispiel:

traefik/
└── overlays/
    └── tamay.cloud/
        ├── kustomization.yaml
        └── values-traefik.yaml

Die Frage lautet:

Wie soll diese Komponente auf diesem Cluster betrieben werden?

Typische Anpassungen innerhalb eines Overlays:

  • Domains

  • Hostnamen

  • Replikationsfaktoren

  • Storage-Klassen

  • Ressourcen-Limits

  • Helm Values

  • Netzwerk-Einstellungen

  • Backup-Konfigurationen

Beispiel: Traefik

Die Traefik-Struktur verdeutlicht das verwendete Muster.

traefik/
├── base
├── components
│   └── monitoring
├── crds
└── overlays
    └── tamay.cloud

Dabei ergibt sich folgende Schichtung:

overlays and components

Die Base installiert Traefik.

Die Component erweitert Traefik um Monitoring-Funktionen.

Das Overlay definiert die Konfiguration für den Cluster tamay.cloud.

CRDs

Einige Komponenten erfordern Custom Resource Definitions (CRDs).

Diese werden bewusst getrennt vom eigentlichen Deployment verwaltet.

Beispielsweise:

traefik/
└── crds/

Dadurch ergeben sich mehrere Vorteile:

  • Unabhängige Aktualisierung von CRDs

  • Geringere Abhängigkeiten zwischen Releases

  • Vereinfachte Fehleranalyse

  • Bessere Kontrolle über Breaking Changes

Dieses Muster wird insbesondere bei Helm-basierten Komponenten verwendet.

Deployment-Modell

Die endgültige Konfiguration entsteht durch die Kombination mehrerer Ebenen.

Base
  +
Components
  +
Overlay
  =
Cluster Deployment

Das entspricht dem von Kustomize empfohlenen Ansatz:

  • Gemeinsame Ressourcen in Bases

  • Wiederverwendbare Erweiterungen in Components

  • Umgebungsspezifische Anpassungen in Overlays

Anwendungen und Infrastruktur

Die gleiche Struktur wird sowohl für Anwendungen als auch für Infrastruktur-Komponenten eingesetzt.

Beispiel:

modules/apps/

und

modules/infrastructure/

Dadurch existiert ein einheitliches Betriebsmodell für die gesamte Plattform.

Entscheidungsregeln

Base

Wenn die Konfiguration grundsätzlich für mehrere Cluster verwendbar ist.

Component

Wenn eine Funktion optional und mehrfach wiederverwendbar ist.

Overlay

Wenn die Konfiguration ausschließlich für einen bestimmten Cluster gilt.

CRD

Wenn Ressourcen unabhängig vom eigentlichen Deployment verwaltet werden sollen.

Best Practices

  • Bases möglichst generisch halten.

  • Cluster-Namen ausschließlich in Overlays verwenden.

  • Overlays möglichst klein halten.

  • Wiederkehrende Funktionalität als Component modellieren.

  • Components voneinander unabhängig halten.

  • CRDs getrennt vom eigentlichen Deployment verwalten.

  • Cluster-spezifische Werte niemals in Bases pflegen.

Vorteile

  • Wiederverwendbare Konfigurationen

  • Geringe Duplizierung

  • Einheitliche Multi-Cluster-Verwaltung

  • Klare Trennung von Verantwortlichkeiten

  • Skalierbarkeit auf weitere Cluster

  • Vereinfachte Wartung und Fehleranalyse

Referenzen

Die Struktur orientiert sich an den Empfehlungen von Kustomize:

  • Kustomize Concepts

  • Bases und Overlays

  • Components

  • Declarative Configuration Management

Weitere Informationen: