NetBackup auf OpenShift mit Argo CD: Was Sie brauchen

Argo CD kann den NetBackup-Kubernetes-Operator auf OpenShift bereitstellen, weil Argo CD Helm-Charts deklarativ rendern kann und NetBackup eine Helm-basierte Operator-Bereitstellung auf Red Hat OpenShift dokumentiert. Was fehlt, ist die Erkenntnis, dass ein ApplicationSet nur der GitOps-Mechanismus ist, der Argo-CD-Applications erzeugt. Es ersetzt nicht die NetBackup-Voraussetzungen für Namespace, Berechtigungen, Storage-Classes, Snapshot-Classes, Zertifikate, Ports, Data-Mover-Konfiguration und die Cluster-Registrierung auf NetBackup-Seite.

Diese Unterscheidung beantwortet die zentrale Unsicherheit im Ausgangsfall. Der Administrator hatte bereits Argo CD, ein ApplicationSet und das Operator-Paket des Herstellers in Git, einschließlich Helm-Charts und Values. Die Sorge war, ob es wirklich so einfach sein konnte oder ob versteckte abhängige Dateien fehlten.

Was macht ApplicationSet in dieser Bereitstellung tatsächlich?

Ein Argo CD ApplicationSet erzeugt aus einem Template und einem Generator eine oder mehrere Application-Ressourcen von Argo CD. Die erzeugte Application ist es, die Argo CD auf das NetBackup-Chart oder den Git-Pfad verweist, Values liefert, den Ziel-OpenShift-Cluster festlegt und den Ziel-Namespace auswählt.

ApplicationSet ist somit eine Orchestrierungsebene rund um Applications. Es installiert NetBackup nicht selbst und ersetzt nicht die Helm-Konfiguration.

Die Dokumentation von Argo CD selbst stellt klar, dass ApplicationSet-Templating nicht dazu gedacht ist, Konfigurationsmanagement-Tools wie Helm oder Kustomize zu ersetzen. Das ist hier relevant, weil das NetBackup-Paket bereits Helm-Charts und Values enthält. Lassen Sie Helm die Hersteller-Ressourcen beschreiben. Lassen Sie ApplicationSet entscheiden, wo und mit welchen Umgebungs-Values diese Ressourcen bereitgestellt werden.

Für weiterführende Cluster-Konzepte und operativen Kontext ist der Kubernetes-Leitfaden von Mr.PlanB ein nützlicher Begleiter, während Sie die NetBackup-spezifische Bereitstellung eng an der Herstellerdokumentation ausrichten.

Kann Argo CD das vom Hersteller gelieferte NetBackup-Helm-Chart direkt verwenden?

Konzeptionell ja. Argo CD kann Helm-Charts als Application-Quelle verwenden und rendert sie mit helm template; anschließend verwaltet Argo CD die daraus entstehenden Kubernetes-Ressourcen und den Application-Lifecycle.

Das sicherere GitOps-Muster besteht darin, das vom Hersteller gelieferte Chart versioniert und unveränderlich zu halten und Ihre umgebungsspezifischen Values separat zu speichern. Das erleichtert Upgrades, weil Sie ein Hersteller-Chart-Release mit dem nächsten vergleichen können, statt einen Fork voller lokaler Anpassungen zu pflegen.

Hat der Hersteller das Chart als Tar-Archiv statt über ein öffentliches Helm-Repository geliefert, legen Sie den freigegebenen Chart-Inhalt gemäß der Software-Supply-Chain-Richtlinie Ihrer Organisation in einem kontrollierten Git- oder internen Artefakt-Repository ab. Ziehen Sie während der Synchronisierung nicht stillschweigend eine andere Chart-Version.

Pinnen Sie die exakte Version des NetBackup-Operators fest. „Latest" ist für Backup-Infrastruktur eine schlechte Wahl, weil ein Operator-Upgrade CRDs, Data-Mover-Verhalten, Storage-Anforderungen oder unterstützte Cluster-Versionen ändern kann.

Welche OpenShift-Voraussetzungen bestehen weiterhin unabhängig von Argo CD?

NetBackup dokumentiert OpenShift als unterstützte Plattform für den Kubernetes-Operator, aber der Cluster braucht weiterhin die von diesem Operator geforderten Berechtigungen und die Plattform-Konfiguration. Argo CD kann diese Voraussetzungen nicht herbeizaubern, nachdem die Manifeste angewendet wurden.

Prüfen Sie mindestens den Operator-Namespace, Service-Accounts und Berechtigungen, Cluster-Zugriff, erforderliche Netzwerkpfade, Storage-Classes, CSI-Snapshot-Unterstützung, Image-Registry-Zugriff sowie alle OpenShift-spezifischen Sicherheitskontrollen.

Der Operator interagiert außerdem mit der NetBackup-Primary- und Media-Infrastruktur. Das bedeutet, dass DNS, Zertifikate, Tokens, Firewall-Regeln und der Datenpfad von Cluster-Workloads zur NetBackup-Umgebung unabhängig von der Git-Synchronisierung funktionieren müssen.

Ein nützlicher Bereitstellungstest besteht darin, genau dasselbe Hersteller-Chart manuell in einem Wegwerf-Namespace mit der finalen Values-Datei zu installieren. Gelingt das, schlägt aber die Bereitstellung über Argo CD fehl, haben Sie das Problem auf GitOps-Paketierung, Berechtigungen, Hooks oder Reconciliation-Verhalten eingegrenzt, statt auf NetBackup-Voraussetzungen.

Welche Storage-Einstellungen werden leicht übersehen?

Storage ist eine der wichtigsten versteckten Abhängigkeiten, weil der NetBackup-Kubernetes-Schutz für Backup-Datenbewegung und Restore-Workflows CSI-Snapshots und temporäre PVCs verwenden kann. Die aktuelle Dokumentation enthält eine Storage-Zuordnung, die Storage-Classes der passenden VolumeSnapshotClass zuordnet und, wo erforderlich, separate Storage-Classes für Backup-Datenbewegung oder Restore vorsieht.

Als OpenShift-Beispiele zeigt die Dokumentation CephFS- und Ceph-RBD-Storage-Classes, die passenden Snapshot-Classes zugeordnet sind. Die genauen Namen in Ihrem Cluster werden abweichen, das Prinzip aber nicht.

Gehen Sie nicht davon aus, dass die Standard-Storage-Class von OpenShift automatisch für NetBackup-Vorgänge gültig ist. Prüfen Sie den Provisioner, den Volume-Modus, die Snapshot-Fähigkeit, das Binding-Verhalten und ob NetBackup für das von Ihnen bereitgestellte Release ein Label oder eine explizite Storage-Zuordnung verlangt.

Testen Sie einen PVC-basierten Workload, bevor Sie Dutzende Namespaces onboarden. Ein GitOps-Sync kann grün sein, während das erste Backup aus einem Snapshot trotzdem fehlschlägt, weil der Storage-Pfad nie validiert wurde.

Was gehört in Git und was sollte außerhalb von Git bleiben?

Legen Sie deklarative Konfiguration ohne Geheimnisse in Git ab: das ApplicationSet, die Application-Quelldefinition, die gepinnte Chart-Version, den Ziel-Namespace, freigegebene Values-Dateien, unbedenklich offenzulegende Storage-Class-Zuordnungen, die Sync-Policy und Umgebungs-Overlays.

Halten Sie Geheimnisse aus reinem Git heraus. NetBackup-Tokens, private Schlüssel, Registrierungsmaterial, sensible Anmeldedaten und private Zertifikatsdaten sollten über den freigegebenen Secret-Management-Prozess der Organisation laufen.

Zertifikate, die öffentliches Trust-Material sind, können anders behandelt werden als private Schlüssel — dokumentieren Sie aber trotzdem Eigentümerschaft und Rotation. Der Operator ist Teil der Backup-Control-Plane, weshalb abgelaufene Anmeldedaten den Schutz stillschweigend brechen können, wenn niemand sie überwacht.

Halten Sie außerdem generierte Laufzeitobjekte aus der Versionskontrolle heraus. Git sollte die gewünschte Konfiguration beschreiben. Es sollte nicht zu einer Ablage jeder Ressource werden, die der Operator während Backup-Jobs dynamisch erzeugt.

Sind Helm-Hooks und das Sync-Verhalten von Argo CD ein Risiko?

Das können sie sein. Argo CD bildet viele Helm-Hooks auf Argo-CD-Hooks ab, aber das Lifecycle-Verhalten kann sich von einem interaktiv mit Helm installierten Operator unterscheiden. Verlässt sich das Hersteller-Chart stark auf Hooks, Pre-Install-Jobs, CRD-Reihenfolge oder einmalige Konfigurations-Jobs, testen Sie genau diese Pfade.

Aktivieren Sie kein aggressives automatisches Pruning, solange Sie nicht verstehen, welche Ressourcen der NetBackup-Operator erzeugt und besitzt. Eine Ressource, die aus dem gerenderten Chart verschwindet, kann von der Anwendung absichtlich beibehalten werden oder für den Wiederherstellungszustand erforderlich sein.

Verwenden Sie Argo-CD-Sync-Waves oder eine bestimmte Reihenfolge nur, wenn das Chart und die Voraussetzungen sie wirklich benötigen. CRDs sowie erforderliche Namespace- oder Secret-Abhängigkeiten müssen zum Beispiel unter Umständen existieren, bevor Custom Resources sauber reconcilen.

Lösen Sie nicht jedes Reihenfolgeproblem durch das Hinzufügen willkürlicher Sleeps. Ein Backup-Operator sollte einen stabilen Sollzustand durch explizite Abhängigkeiten und Readiness-Checks erreichen.

Wie sollte die NetBackup-Seite konfiguriert werden?

Der OpenShift-Operator ist nur eine Seite der Integration. NetBackup muss weiterhin über den Cluster Bescheid wissen, Namespaces und Assets erkennen, gültige Anmeldedaten oder Tokens verwenden und die geschützten Workloads mit Storage- und Media-Infrastruktur verbinden.

Das bedeutet, dass ein erfolgreicher Argo-CD-Sync nicht Ihr Abnahmetest ist. Bestätigen Sie, sobald der Operator gesund ist, die Cluster-Registrierung in NetBackup, die Asset-Discovery, die Zuweisung des Protection Plans, die Snapshot-Erstellung, die Backup-Datenbewegung und die Wiederherstellung.

Der frühere NetBackup-Nutanix-Kompatibilitätsleitfaden behandelt eine andere Plattform, aber die operative Lehre ist identisch: Ein erfolgreiches Installieren beweist noch keinen unterstützten und wiederherstellbaren Schutz-Stack.

Halten Sie NetBackup-Version, OpenShift-Version, CSI-Treiber, Storage-Plattform, Operator-Chart-Version und Media-Pfad gemeinsam fest. Diese Versionen bilden zusammen ein Backup-System.

Wie sollte das erste GitOps-Rollout aussehen?

Beginnen Sie mit einem Nicht-Produktions-OpenShift-Cluster und einem Operator-Namespace. Pinnen Sie das Hersteller-Chart, erstellen Sie eine Values-Datei und lassen Sie Argo CD dieselben Ressourcen rendern, die Sie bereits manuell nachgewiesen haben.

Validieren Sie dann in Stufen. Zuerst Operator-Pods und CRDs. Dann die NetBackup-Registrierung. Dann die Namespace-Discovery. Dann einen kleinen PVC-Snapshot. Dann ein Backup in den Ziel-Storage. Stellen Sie den Workload abschließend in einem isolierten Namespace wieder her und prüfen Sie die wiederhergestellten Daten.

Erst nach diesen Schritten sollten Sie das ApplicationSet auf mehrere Cluster verallgemeinern. ApplicationSet ist am wertvollsten, nachdem eine Application nachweislich korrekt ist.

Wenn Sie auf einen Schlag zehn defekte Applications erzeugen, hat GitOps den Fehler beschleunigt, nicht die Bereitstellung verbessert.

Was würde ich im Repository ablegen?

Ich würde das NetBackup-Operator-Chart des Herstellers auf einer gepinnten Version halten, dazu eine umgebungsspezifische Values-Datei, eine Argo-CD-Application-Definition oder ein ApplicationSet-Template sowie kleine Overlays für clusterspezifische Storage- und Zieldetails. Secrets kämen aus dem freigegebenen externen Secret-Mechanismus.

Ich würde keine zusätzlichen Abhängigkeits-Manifeste erfinden, es sei denn, eine Voraussetzung liegt klar außerhalb des Hersteller-Charts und in der Verantwortung meines Platform-Teams. OpenShift-Storage-Classes, CSI-Snapshot-Classes, Namespaces und Cluster-Policy existieren möglicherweise bereits und sollten nicht leichtfertig innerhalb eines Application-Repositorys dupliziert werden.

Der Administrator im Ausgangsfall war näher dran, als es sich anfühlte. Argo CD plus ApplicationSet plus das Hersteller-Chart können für den Bereitstellungsmechanismus ausreichen. Die eigentliche Arbeit besteht darin, nachzuweisen, dass jede NetBackup- und OpenShift-Voraussetzung existiert, bevor GitOps beginnt, das Chart zu reconcilen.