Neu in Argo CD

Argo CD 3.5 bringt Helm 4 statt Helm 3. Die OCI-Implementierung ist strenger: Plain-HTTP-Registries brauchen jetzt --insecure-oci-force-http am Repo, und zwar auch für OCI-Abhängigkeiten aus Chart.yaml, die unter Helm 3 ohne Registrierung funktionierten. Ein gesetztes spec.source.helm.version: v3 wird ignoriert, kann aber stehen bleiben.

Die Oberfläche wechselt von React 16 auf 19. UI-Extensions, die gegen die alte UI gebaut wurden, laden mit einem TypeError nicht mehr, bis sie neu gebaut sind und react/jsx-runtime externalisieren. Wer keine UI-Extensions installiert hat, ist nicht betroffen.

Bei aktivierter Impersonation greifen die ServiceAccounts aus destinationServiceAccounts nicht mehr nur beim Sync, sondern bei allen API-Server-Operationen: Logs ansehen, Events listen, Ressourcen löschen, Resource Actions ausführen. Diese ServiceAccounts brauchen entsprechend get, list, patch, create und delete, sonst brechen UI-Aktionen weg.

Mit go-git 5.19 baut Argo CD die SSH-Authentifizierung auch für Repositories ohne konfigurierte Credentials selbst und prüft den Host-Key gegen die ConfigMap argocd-ssh-known-hosts-cm, nicht mehr gegen ~/.ssh/known_hosts oder $SSH_KNOWN_HOSTS im repo-server-Container. Wer known_hosts ins Image gebacken oder per Volume gemountet hat, trägt diese Host-Keys vor dem Upgrade in die ConfigMap ein. Repositories mit Credentials und reine HTTPS-Setups sind nicht betroffen.

Die GnuPG-Signaturprüfung wird durch das allgemeinere Subsystem Source Integrity ersetzt, konfiguriert über sourceIntegrity im AppProject. Für den Source Hydrator gibt es zusätzlich eine als Alpha gekennzeichnete Integritätsprüfung der Dry Sources.

Ein Secret argocd-repo-server-mtls mit client-ca.crt, client.crt und client.key wird automatisch gemountet. mTLS aktiviert sich, sobald das Secret existiert, ohne ConfigMap-Änderung oder zusätzliche Flags. Nicht kombinierbar mit --disable-tls.

Das Flag ist in argocd-server, application-controller und applicationset-controller deprecated und funktioniert in 3.5 nur noch mit Warnung; ab 3.6 darf es entfallen. In v3.6.0-rc1 ist das Flag weiterhin vorhanden und nur als deprecated markiert. Ersatz ist der explizite Pfad --repo-server-ca-cert-path, beim notifications-controller heißen beide Flags mit Präfix argocd- (--argocd-repo-server-strict-tls, --argocd-repo-server-ca-cert-path). Ebenfalls deprecated: signatureKeys im AppProject sowie verifyResult in der REST-API.

Argo CD speichert die Kubernetes-Version des Clusters vollständig statt nur als Major.Minor. ApplicationSets mit Cluster-Generator, die über argocd.argoproj.io/auto-label-cluster-info filtern, müssen auf argocd.argoproj.io/kubernetes-version im neuen Format umgestellt werden. Die Änderung ist auch in 3.3.3 enthalten (Backport).

Eine Application meldet Missing jetzt nur, wenn sämtliche Ressourcen fehlen, also typischerweise vor dem ersten Sync. Einzelne fehlende Ressourcen beeinflussen den Gesamtstatus nicht mehr. Automatisierung, die fehlende Ressourcen über die Health erkannt hat, muss auf den Sync-Status OutOfSync umgestellt werden.

Neu sind eine ApplicationSet-Watch-API, ein Health-Feld in status, eine listResourceEvents-API sowie Listenseite, Tree-View und Slide-out-Summary in der Oberfläche. Dazu kommen Cache-Synchronisierung im Controller und optimierter Zugriff auf Cluster-Secrets für größere Installationen.

In Dual-Stack-Clustern hatten die TXT-Abfragen zu massenhaften DNS-Queries, Timeouts und abstürzenden repo-servern geführt. Wer die Discovery braucht, schaltet sie in argocd-cmd-params-cm wieder ein.

Eine Annotation am Cluster stoppt die Reconciliation für genau diesen Cluster, was Wartungsfenster und Incident-Handling ohne Eingriff an den einzelnen Applications erlaubt.

Authentifizierung und HTTP-Handler sind jetzt OpenTelemetry-instrumentiert, der OTEL-Stack geht auf Semantic Conventions 1.40.0. Dadurch können sich Metriknamen und Attribute ändern: Grafana-Dashboards und Alerts prüfen.

Die ApplicationSet-CRD überschreitet die 262144-Byte-Grenze für die last-applied-Annotation. Manuelle Upgrades brauchen kubectl apply --server-side --force-conflicts, selbstverwaltete Installationen brauchen ServerSideApply=true in den syncOptions. Helm-Nutzer sind nicht betroffen.

Statt für jeden DRY-Commit einen hydrierten Commit zu pushen, merkt sich der Hydrator den zuletzt hydrierten DRY-SHA in einer Git-Note. Ein neuer Commit entsteht nur noch, wenn sich die Manifeste tatsächlich ändern. Automatisierung, die hydrierte Commits als Signal genutzt hat, muss auf die Git-Note umgestellt werden.

Vor 3.3 löschte der Hydrator bei jedem Lauf alle Dateien im konfigurierten Pfad, bevor er neu schrieb. Diese Logik ist entfernt, überzählige oder veraltete Dateien bleiben liegen. Wer auf die automatische Bereinigung gebaut hat, braucht jetzt einen eigenen Aufräumschritt.

Neu sind PreDelete-Hooks, ein Löschschutz für Application-Ressourcen und die Möglichkeit, clusterResourceWhitelist auf einzelne Ressourcennamen einzuschränken. Das Syncen auf eine abweichende Revision verlangt jetzt zusätzlich das Override-Recht.

Repositories lassen sich flach klonen, was bei großen Historien den repo-server entlastet. Die GitHub-App-Authentifizierung funktioniert ohne explizite installationId, und OIDC-Tokens werden im Hintergrund erneuert, statt den Nutzer auf die Login-Seite zu schicken.