Organización de los componentes de Cyberwatch en nodepools

Esta página describe las restricciones a tener en cuenta para distribuir los componentes de Cyberwatch en varios grupos de nodos (nodepools) de un clúster Kubernetes. Completa la guía Despliegue de Cyberwatch en un cluster Kubernetes existente y está dirigida a clústeres compuestos por varios nodos.

El chart Helm no impone ninguna distribución: por defecto, todos los componentes pueden ejecutarse en un mismo nodo o en un mismo nodepool. Sin embargo, distribuir los componentes según el perfil de carga puede permitir:

garantizar recursos estables a los componentes de datos (base de datos, colas de tareas);
absorber los picos de carga de los análisis y escaneos sin degradar la interfaz web;
aplicar reglas de filtrado de red diferenciadas según los flujos emitidos por cada grupo de nodos.

La segmentación depende de las convenciones del clúster, respetando las restricciones de ubicación indicadas a continuación.

Requisitos previos

El campo global.storageClass debe estar definido en el archivo values.yml.
Sin StorageClass, el chart Helm crea volúmenes de tipo hostPath locales a un nodo: en ese caso, todos los componentes deben ejecutarse en el mismo nodo y no es posible ninguna distribución.
El campo node.name debe estar definido, como se requiere en cualquier clúster de varios nodos.

Restricciones de ubicación

Algunas restricciones son impuestas por el chart Helm y deben respetarse al definir los nodepools:

web y sidekiq-node son inseparables: el chart impone que el contenedor sidekiq-node se ejecute en el mismo nodo que un contenedor web. Por lo tanto, estos dos componentes deben apuntar al mismo nodepool. Si se despliegan varias réplicas de web, las réplicas de sidekiq-node se distribuyen en los nodos que alojan un contenedor web.
third-parties, si está activado, es inseparable de web, nginx, sidekiq y sidekiq-node: estos componentes comparten entonces un volumen que solo puede montarse en un único nodo, por lo que todos deben ejecutarse en el mismo nodo. La guía de despliegue en un clúster existente desactiva este componente (thirdParties.enabled: false), lo que elimina esta restricción.
Caso de una arquitectura multinodo Cyberwatch (maestro/satélites): cuando node.type: master está definido, la base de datos y Redis se exponen a los nodos satélite mediante hostPort (3306 y 6379) en los nodos que alojan los contenedores db y redis. Los nodos del nodepool que aloja estos componentes deben ser accesibles desde los satélites. Véase la guía Despliegue de un nodo satélite Cyberwatch en un clúster Kubernetes existente.
Los recursos asignados por defecto a cada componente (requests y limits) se pueden consultar en el archivo de configuración por defecto del chart Helm:
```
helm show values oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart
```

Las conexiones hacia los activos supervisados (SSH, WinRM, descubrimientos de red) son emitidas por el contenedor sidekiq-node; los escaneos de sitios web y las descargas de imágenes de contenedores por los contenedores web-scanner y container-scanner. Las reglas de filtrado de red deben tener en cuenta los nodepools en los que se colocan estos componentes.

Implementación

Identificar las etiquetas (labels) que distinguen los nodepools.
Si el clúster es gestionado por un proveedor cloud, ya existen etiquetas en los nodos, por ejemplo cloud.google.com/gke-nodepool (GKE), eks.amazonaws.com/nodegroup (EKS) o kubernetes.azure.com/agentpool (AKS).
Si no, añadir una etiqueta a los nodos de cada nodepool:
```
kubectl label nodes <nombre-del-nodo> nodepool=cyberwatch-app
```
Las etiquetas de un nodo pueden verificarse con:
```
kubectl get nodes --show-labels
```
Rellenar el campo nodeSelector de cada componente en el archivo values.yml, según la distribución elegida.

Aplicar la configuración:

helm -n cyberwatch upgrade cyberwatch oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart -f values.yml

Verificar la distribución de los pods en los nodos:
```
kubectl -n cyberwatch get pods -o wide
```

Aplicación a una instancia existente

La adición de campos nodeSelector en una instancia ya desplegada provoca la recreación de los pods afectados, y por tanto una interrupción del servicio durante el tiempo del redespliegue.

Los volúmenes persistentes de los componentes con estado (db, redis, elasticsearch, container-scanner) deben ser accesibles desde los nodos del nodepool objetivo. Según el sistema de almacenamiento, un volumen puede estar vinculado a una zona o a un nodo concreto: en ese caso, apuntar a un nodepool incompatible deja el pod en estado Pending. Verifique las restricciones de topología del StorageClass utilizado antes de mover estos componentes.

Ajustar la capacidad de los nodepools

El número de réplicas de los componentes sin estado se configura con los campos replicaCount o mediante un autoscaling horizontal (HPA). Consulte la documentación de los HPA para más información.