Organització dels components de Cyberwatch en nodepools

Aquesta pàgina descriu les restriccions que cal tenir en compte per repartir els components de Cyberwatch entre diversos grups de nodes (nodepools) d’un clúster Kubernetes. Complementa la guia Desplegament de Cyberwatch en un clúster Kubernetes existent i està destinada als clústers formats per diversos nodes.

El chart de Helm no imposa cap repartiment: per defecte, tots els components es poden executar en un mateix node o en un mateix nodepool. Tanmateix, repartir els components per perfil de càrrega pot permetre:

garantir recursos estables als components de dades (base de dades, cues de tasques);
absorbir els pics de càrrega de les anàlisis i dels escanejos sense degradar la interfície web;
aplicar regles de filtratge de xarxa diferenciades segons els fluxos que emet cada grup de nodes.

La divisió depèn de les convencions del clúster, sempre que es respectin les restriccions de col·locació següents.

Requisits previs

El camp global.storageClass s’ha de definir al fitxer values.yml.
Sense StorageClass, el chart de Helm crea volums de tipus hostPath locals a un node: aleshores tots els components s’han d’executar al mateix node i no és possible cap repartiment.
El camp node.name s’ha de definir, tal com es requereix en qualsevol clúster de diversos nodes.

Restriccions de col·locació

El chart de Helm imposa algunes restriccions que s’han de respectar en definir els nodepools:

web i sidekiq-node són indissociables: el chart obliga el contenidor sidekiq-node a executar-se al mateix node que un contenidor web. Per tant, aquests dos components han de tenir com a destinació el mateix nodepool. Si es despleguen diverses rèpliques de web, les rèpliques de sidekiq-node es reparteixen entre els nodes que allotgen un contenidor web.
third-parties, si està activat, és indissociable de web, nginx, sidekiq i sidekiq-node: aleshores aquests components comparteixen un volum que només es pot muntar en un sol node i, per tant, s’han d’executar tots al mateix node. La guia de desplegament en un clúster existent desactiva aquest component (thirdParties.enabled: false), cosa que elimina aquesta restricció.
Cas d’una arquitectura de Cyberwatch de diversos nodes (master/satellites): quan es defineix node.type: master, la base de dades i Redis s’exposen als nodes satèl·lit mitjançant hostPort (3306 i 6379) als nodes que allotgen els contenidors db i redis. Aleshores, els nodes del nodepool que allotja aquests components han de ser accessibles des dels satèl·lits. Vegeu la guia Desplegament d’un node satèl·lit de Cyberwatch en un clúster Kubernetes existent.
Els recursos assignats per defecte a cada component (requests i limits) es poden consultar al fitxer de configuració per defecte del chart de Helm:
```
helm show values oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart
```

Les connexions cap als actius supervisats (SSH, WinRM, descobriments de xarxa) les emet el contenidor sidekiq-node; els escanejos de llocs web i les baixades d’imatges de contenidors, els contenidors web-scanner i container-scanner. Les regles de filtratge de xarxa han de tenir en compte els nodepools en què es col·loquen aquests components.

Implementació

Identifiqueu les etiquetes (labels) que distingeixen els nodepools.
Si el clúster el gestiona un proveïdor de núvol, els nodes ja tenen etiquetes, per exemple cloud.google.com/gke-nodepool (GKE), eks.amazonaws.com/nodegroup (EKS) o kubernetes.azure.com/agentpool (AKS).
Si no, poseu una etiqueta als nodes de cada nodepool:
```
kubectl label nodes <nom-du-nœud> nodepool=cyberwatch-app
```
Les etiquetes d’un node es poden comprovar amb:
```
kubectl get nodes --show-labels
```
Ompliu el camp nodeSelector de cada component al fitxer values.yml, segons el repartiment triat.

Apliqueu la configuració:

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

Comproveu el repartiment dels pods entre els nodes:
```
kubectl -n cyberwatch get pods -o wide
```

Aplicació a una instància existent

Afegir camps nodeSelector en una instància ja desplegada provoca que es tornin a crear els pods afectats i, per tant, una interrupció del servei mentre dura el nou desplegament.

Els volums persistents dels components amb estat (db, redis, elasticsearch, container-scanner) han de ser accessibles des dels nodes del nodepool de destinació. Segons el sistema d’emmagatzematge, un volum pot estar vinculat a una zona o a un node concret: en aquest cas, si s’escull un nodepool incompatible, el pod es queda en estat Pending. Comproveu les restriccions de topologia de la StorageClass utilitzada abans de traslladar aquests components.

Ajustar la capacitat dels nodepools

El nombre de rèpliques dels components sense estat es configura amb els camps replicaCount o mitjançant un escalat automàtic horitzontal (HPA). Vegeu la documentació dels HPA per a més informació.