GitOps-Architektur

Die Plattform wird vollständig über GitOps betrieben.

Git beschreibt den gewünschten Zustand der Infrastruktur und Anwendungen. FluxCD synchronisiert diesen Zustand kontinuierlich auf alle Cluster.

Überblick

Die GitOps-Architektur besteht aus drei Ebenen:

  • Cluster

  • Module

  • Kubernetes-Ressourcen

Die Orchestrierung erfolgt durch FluxCD.

Architekturdiagramm

architecture
GitOps Architektur

Reconciliation-Modell

Jeder Cluster besitzt eine eigene FluxInstance.

Die FluxInstance synchronisiert ausschließlich den jeweiligen Clusterpfad.

FluxInstance
     |
     +-- clusters/home.tamay.cloud
     |
     +-- clusters/tamay.cloud
     |
     +-- clusters/test.tamay.cloud

Dadurch kann jeder Cluster unabhängig betrieben werden.

Cluster-Ebene

Die Cluster-Verzeichnisse bilden die Composition Layer der Plattform.

Sie enthalten:

  • Infrastruktur-Komponenten

  • Anwendungen

  • Abhängigkeiten

  • Cluster-spezifische Parameter

Der Cluster entscheidet, welche Module installiert werden.

Die eigentliche Implementierung liegt ausschließlich in den Modulen.

Modul-Ebene

Module beschreiben die technische Implementierung einer Komponente.

Beispiel:

modules/infrastructure/traefik
modules/infrastructure/cilium
modules/apps/immich
modules/apps/paperless-ngx

Module sind grundsätzlich clusterunabhängig.

Eine konkrete Installation entsteht erst durch ein Overlay.

Deployment-Ebene

Die eigentliche Bereitstellung erfolgt über Flux Kustomizations.

Beispiel:

Cluster Kustomization
        |
        v
Overlay
        |
        v
Base + Components
        |
        v
Rendered Resources
        |
        v
Cluster

Plattform-Abhängigkeiten

Abhängigkeiten werden explizit modelliert.

Beispiele:

cert-manager
        |
        +-- cert-manager-webhook-hetzner

cilium
        |
        +-- cilium-config

garage-operator
        |
        +-- garage-buckets

victoria-metrics-operator
        |
        +-- victoria-metrics-stack

Dadurch bleiben Bereitstellung und Aktualisierung deterministisch.

Parameterisierung

Cluster-spezifische Werte werden über postBuild.substitute bereitgestellt.

Beispiele:

  • Hostnamen

  • Storage-Klassen

  • Cluster Issuer

  • Backup-Ziele

Dies reduziert die Anzahl notwendiger Overlays und hält Module generisch.

Secret Management

Secrets werden verschlüsselt im Repository gespeichert.

Die Entschlüsselung erfolgt während der Reconciliation über SOPS.

Encrypted Secret
       |
       v
FluxCD
       |
       v
SOPS
       |
       v
Kubernetes Secret

Unverschlüsselte Zugangsdaten werden nicht im Repository gespeichert.

Designprinzipien

  • Git ist die einzige Quelle der Wahrheit.

  • Die Cluster definieren Kompositionen.

  • Module definieren Implementierungen.

  • Overlays definieren konkrete Ausprägungen.

  • FluxCD führt die Synchronisation aus.

  • SOPS schützt sensible Informationen.

  • Abhängigkeiten werden deklarativ modelliert.

Verwandte Dokumente