GitOps
Continuous Deployment für Kubernetes: Der einzige Weg in den Cluster ist ein Commit.
copebit baut seit 2018 Container-Plattformen, mit Docker, Kubernetes und ECS. Mit wachsenden Clustern und steigender Anzahl Services liessen sich zwei Dinge nicht mehr skalieren: grosse Terraform-Stacks und Push-basierte CD-Pipelines, die Credentials mit Zugriff in den Cluster benötigten.
Deshalb haben wir Continuous Delivery und die Operationen im Cluster auf GitOps umgestellt. Deployments wurden schneller, inkrementell und risikoärmer, und dasselbe Modell bildet heute die Basis der Plattformen, die wir bauen.
So funktioniert es
Flux behandelt Git als einzige Quelle der Wahrheit für Infrastruktur- und Anwendungskonfiguration und gleicht den laufenden Cluster kontinuierlich damit ab. Änderungen erreichen Kubernetes deklarativ, und die Deployment-Historie schreibt sich von selbst.
Git-Hosting ist wichtiger, als Teams erwarten, denn ein stabiles Repository macht den Betrieb stabil. Wir nutzen GitLab.com oder GitHub.com, oder eine selbst gehostete Alternative. Secrets bleiben im AWS Secrets Manager oder in HashiCorp Vault, und der Flux-Status erscheint direkt in GitLab, wo Entwickler bereits arbeiten.
Sicherer Betrieb
Flux holt Änderungen ab, nichts wird in den Cluster gepusht. Cluster bleiben vollständig privat ohne exponierten Endpunkt, und DevOps-Engineers arbeiten mit reduzierten Berechtigungen, weil Git die Schnittstelle ist.
Pull-basiert
Flux läuft als Kubernetes-Controller, der mit einem Git-Repository verbunden ist. Änderungen werden als native Kubernetes-Objekte über Standard-Manifeste angewendet, ohne zusätzliche Abstraktionsschicht dazwischen.
Vollständige Kontrolle
Der Cluster gleicht sich kontinuierlich mit dem Repository ab, und alles, was von Hand geändert wird, wird automatisch zurückgesetzt. Das ist die Immutability-Firewall: Der einzige Weg hinein ist ein Commit, sodass Configuration Drift sich nirgends verstecken kann.
Native Developer Tools
Entwickler committen, reviewen und mergen in den Tools, die sie bereits nutzen. Sobald der Review abgeschlossen ist, holt der Controller die Änderung in den Cluster. Es gibt keine neue Konsole zu lernen.
Deployment-Optionen
Kubernetes-Manifeste, Helm Charts und Kustomize-Dateien. Flux synchronisiert neben Git auch aus Helm-Registries und anderen OCI-konformen Repositories, und dieselben Artefakttypen funktionieren auch mit anderen GitOps-Controllern wie ArgoCD.
Änderungen über Umgebungen hinweg befördern
Git-Branching-Strategien führen eine Änderung nacheinander durch Staging, dann prod-eu, dann prod-us. Jede Umgebung gleicht sich mit ihrem eigenen Branch ab, sodass sich eine Änderung in einer Umgebung bewährt, bevor sie die nächste erreicht, und ein Rollback ein Revert ist statt eines Incidents.
Ändern Sie Cluster noch von Hand?
Die meisten GitOps-Reviews beginnen mit der Frage, was passiert, wenn jemand den Cluster direkt bearbeitet.