GitOps-Modell

Überblick

Die Plattform wird vollständig über GitOps betrieben.

Git ist die einzige Quelle der Wahrheit für Infrastruktur-, Plattform- und Anwendungskonfigurationen.

FluxCD synchronisiert den gewünschten Zustand kontinuierlich auf die Cluster.

Das GitOps-Modell orientiert sich an den Prinzipien von OpenGitOps.

Referenzen:

OpenGitOps Prinzipien

Die Plattform folgt den vier Kernprinzipien von OpenGitOps.

Deklarativ

Der gewünschte Zustand wird deklarativ beschrieben.

Beispiele:

  • Kubernetes Ressourcen

  • Helm Releases

  • Gateway API Ressourcen

  • Talos Konfigurationen

  • Infrastrukturdefinitionen

Der Clusterzustand wird nicht manuell aufgebaut, sondern vollständig aus den deklarativen Definitionen erzeugt.

Versioniert und unveränderlich

Alle Änderungen werden über Git verwaltet.

Eigenschaften:

  • Vollständige Historie

  • Nachvollziehbare Änderungen

  • Pull-Request basierter Änderungsprozess

  • Rollback über Git

Änderungen erfolgen ausschließlich über das Repository.

Pull-basiert

Cluster beziehen ihre Konfiguration selbstständig aus Git.

Verwendet wird:

  • FluxCD

Es existiert kein Push-basiertes Deployment aus CI-Pipelines.

Der Cluster entscheidet selbst, wann und wie Änderungen übernommen werden.

Kontinuierlich abgeglichen

FluxCD vergleicht kontinuierlich:

Gewünschter Zustand
            |
            v
Git Repository
            |
            v
Tatsächlicher Zustand
            |
            v
Kubernetes Cluster

Abweichungen werden automatisch erkannt und korrigiert.

Dies reduziert Konfigurationsdrift und erhöht die Reproduzierbarkeit der Plattform.

Source of Truth

Die Git-Repositories bilden die einzige Quelle der Wahrheit.

Folgende Änderungen erfolgen ausschließlich über Git:

  • Infrastruktur

  • Kubernetes Plattform

  • Anwendungen

  • Netzwerk

  • Storage

  • Monitoring

  • Security Konfigurationen

Direkte Änderungen im Cluster gelten als temporär und werden durch FluxCD überschrieben.

Quellcodeverwaltung

Alle Repositories werden auf Codeberg gehostet.

Änderungen erfolgen ausschließlich über Git.

Repository-Struktur

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

modules/
├── infrastructure
└── apps

Cluster-Struktur

Jeder Cluster besitzt zwei zentrale Bereiche:

cluster/
├── infrastructure
└── apps

Die Infrastruktur wird vor Anwendungen bereitgestellt.

Module

Module enthalten wiederverwendbare Konfigurationen.

Typische Beispiele:

  • cert-manager

  • external-dns

  • piraeus

  • velero

  • victoria-metrics

  • cilium

  • gateway-api

Anwendungen verwenden dieselbe Struktur mit Bases und Overlays.

Deployment-Ablauf

Git Commit
      |
      v
Codeberg
      |
      v
FluxCD
      |
      v
Kubernetes

Der tatsächliche Deploymentschritt wird nicht von der CI-Pipeline ausgeführt.

FluxCD erkennt Repository-Änderungen selbstständig und synchronisiert diese auf den Cluster.

Drift Detection

FluxCD prüft kontinuierlich, ob der tatsächliche Clusterzustand dem gewünschten Zustand entspricht.

Typische Beispiele:

  • Gelöschte Ressourcen

  • Manuell geänderte Deployments

  • Veränderte Service- oder Ingress-Konfigurationen

Abweichungen werden automatisch korrigiert.

Dadurch entsteht ein selbstheilendes System.

Architekturkonsequenzen

Vorteile:

  • Reproduzierbare Infrastruktur

  • Nachvollziehbare Änderungen

  • Einheitlicher Betriebsansatz

  • Konsistente Cluster-Konfigurationen

  • Automatische Drift-Korrektur

  • Vereinfachte Disaster Recovery

  • Schnelle Neuinstallation von Clustern

Nachteile:

  • Höhere Komplexität der Repository-Struktur

  • Manuelle Änderungen sind nicht dauerhaft

  • GitOps-Werkzeuge werden zu kritischen Plattformkomponenten