GitOps auf den zweiten Cluster: ArgoCD reproduzierbar replizieren

Irgendwann kommt der zweite Cluster, und er soll dasselbe GitOps-Setup bekommen wie der erste. „Dann installier ich ArgoCD halt nochmal“ klingt trivial. In Wahrheit stecken die Fehler genau in den Unterschieden zwischen den beiden Clustern. Ich gehe die Replikation deshalb in der Reihenfolge durch, in der ich sie auch tatsächlich mache: erst die gemeinsame Basis als Code sichern, dann das Cluster-Spezifische sauber abtrennen, dann die Fallstricke im Betrieb.

Schritt 1: ArgoCD als Code, nicht aus dem Gedächtnis

Die erste Voraussetzung ist, dass die ArgoCD-Installation des ersten Clusters selbst in Git steht: die Helm-Values, die RBAC-Regeln, die Projekte. Nur dann bekommt der zweite Cluster reproduzierbar dasselbe, statt „so ähnlich wie ich es damals geklickt habe“. Wer die erste Installation nicht als Code hat, repliziert nicht, er rät.

Konkret meine ich damit die Werte, mit denen ArgoCD per Helm ausgerollt wird, die Zugriffsregeln, die festlegen wer im UI was darf (RBAC Configuration), und die ArgoCD-Projekte, die Anwendungen gruppieren und einschränken. Liegt das alles versioniert vor, ist der zweite Cluster im Kern ein zweiter Wert-Satz und keine neue Bastelrunde.

Schritt 2: Was pro Cluster anders ist

Die eigentliche Arbeit sind die Abweichungen. Der eine Cluster nutzt Traefik als Ingress, der andere nginx. Der eine braucht einen Proxy vor dem Repo-Server, der andere nicht. Der PodSecurity-Default ist strenger oder lockerer, die FQDNs sind andere. Wie streng ein Cluster Pods zulässt, richtet sich nach den Pod Security Standards, und genau dieser Default weicht zwischen zwei Clustern gern voneinander ab.

Diese cluster-spezifischen Werte gehören sauber getrennt in Overlays, nicht in die gemeinsame Basis. Ein Overlay ist eine dünne Schicht, die auf eine gemeinsame Basis nur die Unterschiede legt, statt alles zu duplizieren, in Kubernetes über Kustomize mit Bases und Overlays. Vermischt man beides, funktioniert der zweite Cluster „fast“, und das Debuggen der letzten zehn Prozent frisst mehr Zeit als der ganze Rest.

Schritt 3: Den Signing-Key nicht mitkopieren

Ein verlockender Fehler beim „1:1 nachbauen“ ist, Secrets und Signing-Keys gleich mitzukopieren. Genau das darf nicht passieren. Jeder Cluster bekommt seine eigenen Schlüssel und Secrets, einmal frisch angelegt. Kopierte Schlüssel sind ein Sicherheitsleck und schaffen ein Ownership-Chaos, in dem niemand mehr weiß, welcher Cluster mit wessen Schlüssel signiert. Wer ArgoCD nur gegen signierte Commits synchronisieren lässt, hinterlegt die zugehörigen öffentlichen Schlüssel deshalb pro Cluster neu (GnuPG signature verification).

Schritt 4: Adoptieren statt neu ausrollen

Auf dem zweiten Cluster laufen oft schon Workloads, von Hand oder per Katalog installiert. Die holt man deklarativ unter ArgoCD-Verwaltung, statt sie abzureißen und neu auszurollen. Wie dieses zerstörungsfreie Adoptieren funktioniert, habe ich im Beitrag Ein gewachsenes Cluster nach ArgoCD holen beschrieben.

Ehrlich: zwei Cluster sind mehr als doppelt

Ein zweiter Cluster ist nicht doppelt so viel Arbeit, sondern mehr, weil jede Abweichung ein Sonderfall ist, der gepflegt werden will. Die Disziplin, Gemeinsames und Cluster-Spezifisches konsequent zu trennen, entscheidet darüber, ob der dritte und vierte Cluster trivial werden oder jeder neue Cluster ein eigenes kleines Projekt bleibt.

Sie betreiben mehrere Umgebungen und wollen sie nicht jedes Mal von Hand nachbauen? Ich baue GitOps-Setups, die sich reproduzierbar auf weitere Cluster übertragen lassen, mit sauberer Trennung von Basis und Ausnahme. Mehr unter Infrastruktur & Cloud, das Erstgespräch ist unverbindlich.