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. Dabei hilft es zu wissen, dass ein ApplicationSet nur der GitOps-Mechanismus ist, der Argo-CD-Applications erzeugt. Die NetBackup-Voraussetzungen für Namespace, Berechtigungen, Storage-Classes, Snapshot-Classes, Zertifikate, Ports, Data-Mover-Konfiguration und die Cluster-Registrierung auf NetBackup-Seite bleiben davon unberührt.

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. Er fragte sich, 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 verweist Argo CD auf das NetBackup-Chart oder den Git-Pfad, liefert Values, legt den Ziel-OpenShift-Cluster fest und wählt den Ziel-Namespace aus. ApplicationSet ist also eine Orchestrierungsebene rund um Applications, die NetBackup weder selbst installiert noch die Helm-Konfiguration ersetzt.

Die Dokumentation von Argo CD sagt ausdrücklich, dass ApplicationSet-Templating Konfigurationsmanagement-Tools wie Helm oder Kustomize nicht ersetzen soll. Das ist hier relevant, weil das NetBackup-Paket bereits Helm-Charts und Values enthält. Helm beschreibt also die Hersteller-Ressourcen, und ApplicationSet entscheidet, wo und mit welchen Umgebungs-Values sie 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.

Sicherer ist das GitOps-Muster, bei dem das vom Hersteller gelieferte Chart versioniert und unverändert bleibt und Ihre umgebungsspezifischen Values separat liegen. 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. Während der Synchronisierung sollte keine andere Chart-Version unbemerkt nachgezogen werden.

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 Berechtigungen und die Plattform-Konfiguration, die dieser Operator verlangt. 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. DNS, Zertifikate, Tokens, Firewall-Regeln und der Datenpfad von Cluster-Workloads zur NetBackup-Umgebung müssen deshalb unabhängig von der Git-Synchronisierung funktionieren.

Ein nützlicher Bereitstellungstest ist, genau dasselbe Hersteller-Chart manuell in einem Wegwerf-Namespace mit der finalen Values-Datei zu installieren. Gelingt das, während die Bereitstellung über Argo CD fehlschlägt, liegt das Problem bei GitOps-Paketierung, Berechtigungen, Hooks oder Reconciliation-Verhalten und nicht bei den NetBackup-Voraussetzungen.

Welche Storage-Einstellungen werden leicht übersehen?

Storage gehört zu den 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 bleibt gleich.

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?

In Git gehört deklarative Konfiguration ohne Geheimnisse: das ApplicationSet, die Application-Quelldefinition, die gepinnte Chart-Version, der Ziel-Namespace, freigegebene Values-Dateien, unbedenklich offenzulegende Storage-Class-Zuordnungen, die Sync-Policy und Umgebungs-Overlays.

Geheimnisse haben in reinem Git nichts zu suchen. 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, aber auch für sie sollten Sie Eigentümerschaft und Rotation dokumentieren. Der Operator ist Teil der Backup-Control-Plane, und abgelaufene Anmeldedaten können den Schutz unbemerkt brechen, wenn niemand sie überwacht.

Auch generierte Laufzeitobjekte gehören nicht in die Versionskontrolle. Git sollte die gewünschte Konfiguration beschreiben und keine Ablage für jede 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.

Willkürliche Sleeps sind keine Lösung für Reihenfolgeprobleme. 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.

Ein erfolgreicher Argo-CD-Sync taugt deshalb nicht als Abnahmetest. Sobald der Operator gesund ist, bestätigen Sie 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 dieselbe: Eine erfolgreiche Installation 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, denn zusammen bilden sie 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, danach die NetBackup-Registrierung und die Namespace-Discovery, anschließend einen kleinen PVC-Snapshot und ein Backup in den Ziel-Storage. Zum Schluss stellen Sie den Workload in einem isolierten Namespace wieder her und prüfen die wiederhergestellten Daten.

Erst nach diesen Schritten sollten Sie das ApplicationSet auf mehrere Cluster verallgemeinern. Am meisten bringt ApplicationSet, wenn eine Application nachweislich korrekt ist; wer auf einen Schlag zehn defekte Applications erzeugt, hat mit GitOps nur den Fehler beschleunigt.

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.

Zusätzliche Abhängigkeits-Manifeste würde ich nur anlegen, wenn eine Voraussetzung klar außerhalb des Hersteller-Charts und in der Verantwortung meines Platform-Teams liegt. 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. Der größere Teil der Arbeit ist der Nachweis, dass jede NetBackup- und OpenShift-Voraussetzung existiert, bevor GitOps beginnt, das Chart zu reconcilen.