Zum Inhalt springen
shellyshale

Zweiter Cluster, ein Argo CD

Kundenseiten laufen auf einem eigenen Cluster, verwaltet vom Argo CD des Homelabs. Nächster Schritt ist Redundanz über zwei Cluster.

Warum

Die Prototypen und Kundenseiten von Kavent liefen anfangs im selben Cluster wie meine privaten Dienste. Das ist bequem, aber ein Fehler auf der einen Seite trifft die andere mit. Seit Mitte Oktober 2026 laufen sie auf einem eigenen Cluster mit drei Knoten auf einem zweiten Proxmox-Host.

Aufbau

Kein zweites Argo CD: Der neue Cluster ist im bestehenden registriert, die Applications zeigen nur auf ein anderes Ziel. Jede Seite hat ein Kustomize-Overlay für diesen Cluster und ein mit dessen Schlüssel versiegeltes Pull-Secret für die Registry. Neue Images rollt ein kleiner CronJob aus, der den Digest von latest beobachtet.

In Arbeit: Primary und Secondary

Das Ziel: Jede echte Kundenseite läuft in zwei Clustern, in einem als Primary, im anderen warm als Secondary. Umgeschaltet wird über den DNS-Eintrag der Kundendomain, von einem Tunnel auf den anderen. Eine Prüfung pro Cluster fragt jede Minute den Health-Endpunkt ab und schaltet nach drei Fehlschlägen um.

Das Gerüst des Repos steht, eingehängt ist noch nichts. Was davon in der Praxis trägt, steht hier, sobald es läuft.

Bisher gelernt

Die Ingress-Konfiguration eines Cloudflare-Tunnels lässt sich per API nur als Ganzes ersetzen. Wer eine Route hinzufügen will und die Liste nicht vorher liest, löscht alle anderen. Vor jedem Schreiben prüfe ich deshalb, ob die Auffangregel am Ende noch da ist; beim Umschalten fasse ich die Tunnel-Konfiguration gar nicht an.