Despliegue del operador de NetBackup en OpenShift con Argo CD

Argo CD puede desplegar el operador de Kubernetes de NetBackup en OpenShift porque es capaz de procesar charts de Helm de forma declarativa y NetBackup documenta la instalación de su operador en Red Hat OpenShift mediante Helm. Lo que resulta fácil pasar por alto es que un ApplicationSet no es más que el mecanismo GitOps que genera recursos Application de Argo CD. Los prerrequisitos de NetBackup siguen siendo obligatorios en cuanto a espacio de nombres, permisos, clases de almacenamiento, clases de snapshot, certificados, puertos, configuración del data mover y registro del clúster en la consola de NetBackup.

Esto resuelve la principal incertidumbre del caso de origen. El administrador ya disponía de Argo CD, un ApplicationSet y el paquete del operador del fabricante en Git, incluyendo los charts de Helm y sus valores. La duda radicaba en si el proceso era realmente tan directo o si faltaban archivos de dependencias ocultos.

¿Qué hace en realidad ApplicationSet en este despliegue?

Un ApplicationSet de Argo CD genera uno o más recursos Application a partir de una plantilla y un generador. La Application generada es la que indica a Argo CD la ruta del chart de NetBackup o del repositorio Git, suministra los valores, identifica el clúster OpenShift de destino y selecciona el espacio de nombres correspondiente.

ApplicationSet actúa por tanto como una capa de orquestación alrededor de las Applications. No instala nada por sí mismo y la configuración de Helm sigue siendo necesaria.

La propia documentación de Argo CD señala explícitamente que las plantillas de ApplicationSet no pretenden sustituir herramientas de gestión de configuración como Helm o Kustomize. Esto resulta determinante en este caso porque el paquete de NetBackup ya incorpora charts de Helm y sus archivos de valores. Deja que Helm defina los recursos del fabricante y permite que ApplicationSet determine dónde y con qué valores de entorno se despliegan.

Para ampliar conceptos de clúster y contexto operativo, la guía de Kubernetes de Mr.PlanB sirve como referencia complementaria mientras mantienes el despliegue específico de NetBackup ceñido a la documentación oficial.

¿Puede Argo CD usar directamente el chart de Helm suministrado por NetBackup?

Conceptualmente, sí. Argo CD puede utilizar charts de Helm como origen de la aplicación y los procesa mediante helm template; a partir de ahí, gestiona los recursos de Kubernetes resultantes y el ciclo de vida de la aplicación.

El patrón más seguro en GitOps consiste en conservar el chart oficial versionado e inmutable, almacenando los valores específicos de tu entorno por separado. Esto simplifica las actualizaciones porque permite contrastar una nueva versión del chart del fabricante frente a la anterior en lugar de arrastrar un fork repleto de modificaciones locales.

Si el fabricante suministró el chart en un archivo comprimido en vez de un repositorio público de Helm, aloja el contenido del chart aprobado en un repositorio Git controlado o en un gestor interno de artefactos, según la política de cadena de suministro de software de tu organización. No permitas que una sincronización descargue sin avisar una versión distinta del chart.

Fija la versión exacta del operador de NetBackup. Utilizar "latest" es una mala práctica en infraestructura de backup, ya que una actualización del operador puede modificar los CRD, el comportamiento del data mover, los requisitos de almacenamiento o las versiones compatibles del clúster.

¿Qué prerrequisitos de OpenShift persisten al margen de Argo CD?

NetBackup contempla OpenShift como plataforma compatible para el operador de Kubernetes, pero el clúster debe contar previamente con los privilegios y la configuración de plataforma que dicho operador necesita. Argo CD no puede inventar esos prerrequisitos tras aplicar los manifiestos.

Como mínimo, verifica el espacio de nombres del operador, las cuentas de servicio y sus permisos, los accesos al clúster, las rutas de red obligatorias, las clases de almacenamiento, la compatibilidad con snapshots CSI, el acceso al registro de imágenes y cualquier control de seguridad específico de OpenShift.

El operador también interactúa con los servidores principales y de medios de NetBackup. Esto implica que el DNS, los certificados, los tokens, las reglas de firewall y el flujo de datos desde las cargas del clúster hacia el entorno de NetBackup deben funcionar al margen de la sincronización de Git.

Una prueba práctica de despliegue consiste en instalar manualmente el mismo chart del fabricante en un espacio de nombres temporal utilizando el archivo de valores definitivo. Si esa prueba tiene éxito pero el despliegue con Argo CD falla, habrás acotado el problema al empaquetado GitOps, los permisos, los hooks o la sincronización, descartando los prerrequisitos de NetBackup.

¿Qué parámetros de almacenamiento son fáciles de pasar por alto?

El almacenamiento representa una de las dependencias ocultas más determinantes, ya que la protección de Kubernetes en NetBackup suele recurrir a snapshots CSI y PVC temporales para el movimiento de datos y las restauraciones. La documentación vigente incluye un mapa de almacenamiento que vincula clases de almacenamiento con la correspondiente VolumeSnapshotClass y, si procede, clases separadas para el movimiento de datos o la restauración.

En ejemplos para OpenShift, la documentación ilustra clases de almacenamiento CephFS y Ceph RBD asociadas a sus clases de snapshot correspondientes. Los nombres exactos variarán en tu clúster, pero la correspondencia opera bajo la misma lógica.

No asumas que la clase de almacenamiento predeterminada de OpenShift es automáticamente válida para NetBackup. Revisa el aprovisionador, el modo de volumen, la capacidad de snapshot, el comportamiento de vinculación y si NetBackup exige etiquetas o un mapeo explícito en la versión que estás desplegando.

Prueba primero una carga basada en PVC antes de dar de alta decenas de espacios de nombres. La sincronización en GitOps puede mostrarse en verde mientras que el primer backup desde snapshot falla debido a una ruta de almacenamiento no validada.

¿Qué debe residir en Git y qué debe quedar fuera?

Guarda en Git la configuración declarativa que no contenga secretos: el ApplicationSet, la definición del origen de la Application, la versión fijada del chart, el espacio de nombres de destino, los archivos de valores aprobados, los mapeos de clases de almacenamiento seguros de publicar, las políticas de sincronización y los overlays por entorno.

Mantén los secretos fuera de Git en texto plano. Los tokens de NetBackup, claves privadas, datos de registro, credenciales sensibles y material privado de certificados deben gestionarse mediante el mecanismo de custodia de secretos aprobado por la organización.

Los certificados que constituyan material público de confianza pueden gestionarse de otra forma respecto a las claves privadas, pero aun así documenta su titularidad y rotación. El operador forma parte del plano de control del backup; por ello, unas credenciales caducadas pueden interrumpir la protección sin que nadie lo perciba.

Excluye asimismo del control de versiones los objetos generados en tiempo de ejecución. Git debe reflejar la configuración deseada y no convertirse en un vertedero de cada recurso creado dinámicamente por el operador durante las tareas de backup.

¿Suponen un riesgo los hooks de Helm y el comportamiento de sincronización de Argo CD?

Pueden suponerlo. Argo CD traduce muchos hooks de Helm a hooks propios, pero el ciclo de vida puede diferir respecto a un operador instalado interactivamente con Helm. Si el chart del fabricante depende fuertemente de hooks, tareas previas a la instalación, orden en los CRD o trabajos de configuración de ejecución única, valida esas fases con especial detalle.

Evita habilitar una depuración automática (prune) agresiva hasta comprender qué recursos crea y gestiona el operador de NetBackup. Un recurso que desaparezca del chart procesado puede estar conservado deliberadamente por la aplicación o ser imprescindible para mantener el estado de recuperación.

Recurre a sync waves o directivas de orden en Argo CD solo cuando el chart y los prerrequisitos lo exijan realmente. Por ejemplo, los CRD y las dependencias de espacio de nombres o secretos deben existir antes de que los recursos personalizados puedan reconciliarse correctamente.

No soluciones los problemas de secuencia introduciendo pausas arbitrarias. Un operador de backup debe alcanzar un estado deseado estable mediante dependencias explícitas y comprobaciones de disponibilidad.

¿Cómo debe configurarse la parte de NetBackup?

El operador en OpenShift cubre solo un extremo de la integración. NetBackup necesita registrar el clúster, descubrir espacios de nombres y activos, utilizar credenciales o tokens válidos y conectar las cargas de trabajo protegidas con la infraestructura de almacenamiento y medios.

Por ello, una sincronización exitosa en Argo CD no sirve como prueba de aceptación. Una vez comprobada la salud del operador, valida el registro del clúster en NetBackup, el descubrimiento de activos, la asignación de planes de protección, la generación de snapshots, la transferencia de datos y la restauración.

La guía de compatibilidad de NetBackup y Nutanix aborda otra plataforma distinta, pero el principio es idéntico: una instalación completada no demuestra una arquitectura de protección compatible y recuperable.

Registra de forma conjunta la versión de NetBackup, la versión de OpenShift, el controlador CSI, la plataforma de almacenamiento, la versión del chart del operador y la ruta hacia los servidores de medios. Todas esas piezas conforman un único sistema de backup.

¿Cómo debería ser el primer despliegue GitOps?

Comienza con un clúster de OpenShift de pruebas y un único espacio de nombres para el operador. Fija el chart del fabricante, genera un archivo de valores y haz que Argo CD procese los mismos recursos que ya validaste manualmente.

A continuación, verifica por etapas: primero los pods del operador y los CRD, luego el registro en NetBackup, el descubrimiento del espacio de nombres, una pequeña snapshot de un PVC y una copia hacia el almacenamiento de destino. Finalmente, restaura la carga de trabajo en un espacio de nombres aislado y valida los datos recuperados.

Solo después de superar estos pasos conviene generalizar el ApplicationSet hacia múltiples clústeres. El ApplicationSet aporta valor cuando se sabe con certeza que una Application individual funciona. Si generas diez Applications rotas a la vez, GitOps solo te habrá servido para replicar el mismo error con mayor rapidez.

¿Qué incluiría en el repositorio?

Mantendría el chart del operador de NetBackup del fabricante en una versión fijada, un archivo de valores específico por entorno, la definición de una Application de Argo CD o una plantilla de ApplicationSet, y pequeños overlays para los detalles de destino y almacenamiento de cada clúster. Los secretos provendrían del mecanismo externo aprobado.

No añadiría manifiestos adicionales de dependencias a menos que un prerrequisito quede claramente fuera del chart del fabricante y recaiga bajo la responsabilidad de mi equipo de plataforma. Las clases de almacenamiento de OpenShift, las clases de snapshot CSI, los espacios de nombres y las políticas del clúster ya suelen existir y no deben duplicarse sin criterio dentro del repositorio de una aplicación.

El administrador del caso de origen estaba más cerca de la solución de lo que parecía. La combinación de Argo CD, ApplicationSet y el chart del fabricante basta como mecanismo de despliegue. La mayor parte del trabajo radica en certificar que cada prerrequisito de NetBackup y OpenShift esté resuelto antes de que GitOps comience a sincronizar el chart.