NetBackup on OpenShift With Argo CD: What You Need

Argo CD can deploy the NetBackup Kubernetes operator to OpenShift because Argo CD can render Helm charts declaratively and NetBackup documents Helm based operator deployment on Red Hat OpenShift. The missing piece is that an ApplicationSet is only the GitOps mechanism that generates Argo CD Applications. It does not replace the NetBackup prerequisites for namespace, permissions, storage classes, snapshot classes, certificates, ports, data mover configuration, and NetBackup-side cluster registration.

That distinction answers the core uncertainty in the source case. The administrator already had Argo CD, an ApplicationSet, and the vendor operator package in Git, including Helm charts and values. The concern was whether it really could be that simple or whether hidden dependent files were missing.

What does ApplicationSet actually do in this deployment?

An Argo CD ApplicationSet generates one or more Argo CD Application resources from a template and generator. The generated Application is what points Argo CD at the NetBackup chart or Git path, supplies values, identifies the target OpenShift cluster, and chooses the destination namespace.

ApplicationSet is therefore an orchestration layer around Applications. It does not install NetBackup by itself and it does not replace Helm configuration.

Argo CD's own documentation is explicit that ApplicationSet templating is not intended to replace configuration management tools such as Helm or Kustomize. That matters here because the NetBackup package already contains Helm charts and values. Let Helm describe the vendor resources. Let ApplicationSet decide where and with which environment values those resources are deployed.

For broader cluster concepts and operational context, Mr.PlanB's Kubernetes guide is a useful companion while you keep the NetBackup-specific deployment tied to vendor documentation.

Can Argo CD use the vendor-supplied NetBackup Helm chart directly?

Yes, conceptually. Argo CD can use Helm charts as an application source and renders them with helm template; Argo CD then manages the resulting Kubernetes resources and application lifecycle.

The safer GitOps pattern is to keep the vendor supplied chart versioned and immutable, then store your environment-specific values separately. That makes upgrades easier because you can compare one vendor chart release with the next instead of maintaining a fork full of local edits.

If the vendor delivered the chart in a tar archive rather than a public Helm repository, place the approved chart content in a controlled Git or internal artifact repository according to your organization's software supply-chain policy. Do not quietly fetch a different chart version during sync.

Pin the exact NetBackup operator version. “Latest” is a poor choice for backup infrastructure because an operator upgrade can change CRDs, data mover behavior, storage requirements, or supported cluster versions.

What OpenShift prerequisites still exist outside Argo CD?

NetBackup documents OpenShift as a supported platform for the Kubernetes operator, but the cluster still needs the privileges and platform configuration required by that operator. Argo CD cannot invent those prerequisites after the manifests are applied.

At minimum, verify the operator namespace, service accounts and permissions, cluster access, required network paths, storage classes, CSI snapshot support, image registry access, and any security controls specific to OpenShift.

The operator also interacts with NetBackup primary and media infrastructure. That means DNS, certificates, tokens, firewall rules, and the data path from cluster workloads to the NetBackup environment have to work independently of Git synchronization.

A useful deployment test is to install the exact same vendor chart manually in a disposable namespace using the final values file. If that succeeds and Argo CD deployment fails, you have isolated the problem to GitOps packaging, permissions, hooks, or reconciliation behavior rather than NetBackup prerequisites.

Which storage settings are easy to miss?

Storage is one of the most important hidden dependencies because NetBackup Kubernetes protection can use CSI snapshots and temporary PVCs for backup data movement and restore workflows. Current documentation includes a storage map that associates storage classes with the appropriate VolumeSnapshotClass and, where required, separate storage classes for backup data movement or restore.

For OpenShift examples, the documentation shows CephFS and Ceph RBD storage classes mapped to matching snapshot classes. The exact names in your cluster will differ, but the principle does not.

Do not assume the default OpenShift storage class is automatically valid for NetBackup operations. Check the provisioner, volume mode, snapshot capability, binding behavior, and whether NetBackup requires a label or explicit storage mapping for the release you are deploying.

Test one PVC based workload before onboarding dozens of namespaces. A GitOps sync can be green while the first backup from snapshot still fails because the storage path was never validated.

What belongs in Git and what should stay outside Git?

Put declarative, non-secret configuration in Git: the ApplicationSet, Application source definition, pinned chart version, destination namespace, approved values files, storage class mappings that are safe to expose, sync policy, and environment overlays.

Keep secrets out of plain Git. NetBackup tokens, private keys, registration material, sensitive credentials, and certificate private material should flow through the organization's approved secret management process.

Certificates that are public trust material can be handled differently from private keys, but still document ownership and rotation. The operator is part of the backup control plane, so expired credentials can break protection silently if nobody monitors them.

Also keep generated runtime objects out of source control. Git should describe the desired configuration. It should not become a dump of every resource the operator creates dynamically during backup jobs.

Are Helm hooks and Argo CD sync behavior a risk?

They can be. Argo CD maps many Helm hooks to Argo CD hooks, but lifecycle behavior can differ from an operator installed interactively with Helm. If the vendor chart relies heavily on hooks, pre-install jobs, CRD ordering, or one-time configuration jobs, test those paths specifically.

Avoid enabling aggressive automated pruning until you understand which resources the NetBackup operator creates and owns. A resource that disappears from the rendered chart may be intentionally retained by the application or required for recovery state.

Use Argo CD sync waves or ordering only when the chart and prerequisites genuinely need them. For example, CRDs and required namespace or secret dependencies may need to exist before custom resources reconcile cleanly.

Do not solve every ordering problem by adding arbitrary sleeps. A backup operator should reach a stable desired state through explicit dependencies and readiness checks.

How should the NetBackup side be configured?

The OpenShift operator is only one side of the integration. NetBackup still needs to know about the cluster, discover namespaces and assets, use valid credentials or tokens, and connect the protected workloads to storage and media infrastructure.

That means a successful Argo CD sync is not your acceptance test. After the operator is healthy, confirm cluster registration in NetBackup, asset discovery, protection-plan assignment, snapshot creation, backup data movement, and restore.

The earlier NetBackup Nutanix compatibility guide covers a different platform, but the operational lesson is identical: installation success does not prove a supported and recoverable protection stack.

Record the NetBackup version, OpenShift version, CSI driver, storage platform, operator chart version, and media path together. Those versions form one backup system.

What should the first GitOps rollout look like?

Start with one non-production OpenShift cluster and one operator namespace. Pin the vendor chart, create one values file, and make Argo CD render the same resources you already proved manually.

Then validate in stages. First operator pods and CRDs. Then NetBackup registration. Then namespace discovery. Then one small PVC snapshot. Then one backup to the target storage. Finally, restore the workload into an isolated namespace and verify the recovered data.

Only after those steps should you generalize the ApplicationSet to multiple clusters. ApplicationSet is most valuable after one Application is known to be correct.

If you generate ten broken Applications at once, GitOps has made the error faster, not the deployment better.

What would I put in the repository?

I would keep the vendor NetBackup operator chart at a pinned version, an environment-specific values file, one Argo CD Application definition or an ApplicationSet template, and small overlays for cluster-specific storage and destination details. Secrets would come from the approved external secret mechanism.

I would not invent extra dependency manifests unless a prerequisite is clearly outside the vendor chart and owned by my platform team. OpenShift storage classes, CSI snapshot classes, namespaces, and cluster policy may already exist and should not be duplicated casually inside an application repository.

The source administrator was closer than it felt. Argo CD plus ApplicationSet plus the vendor chart can be enough for the deployment mechanism. The real work is proving that every NetBackup and OpenShift prerequisite exists before GitOps starts reconciling the chart.