Organizzazione dei componenti Cyberwatch in nodepool

Questa pagina descrive i vincoli da considerare per distribuire i componenti di Cyberwatch su più gruppi di nodi (nodepool) di un cluster Kubernetes. Integra la guida Distribuzione di Cyberwatch su un cluster Kubernetes esistente ed è rivolta ai cluster composti da più nodi.

Il chart Helm non impone alcuna ripartizione: per impostazione predefinita, tutti i componenti possono essere eseguiti sullo stesso nodo o sullo stesso nodepool. Ripartire i componenti in base al profilo di carico può tuttavia consentire di:

garantire risorse stabili ai componenti di dati (database, code dei job);
assorbire i picchi di carico delle analisi e delle scansioni senza degradare l’interfaccia web;
applicare regole di filtraggio di rete differenziate in base ai flussi emessi da ciascun gruppo di nodi.

La suddivisione dipende dalle convenzioni del cluster, nel rispetto dei vincoli di posizionamento descritti di seguito.

Prerequisiti

Il campo global.storageClass deve essere definito nel file values.yml.
Senza StorageClass, il chart Helm crea volumi di tipo hostPath locali a un nodo: tutti i componenti devono quindi essere eseguiti sullo stesso nodo e non è possibile alcuna ripartizione.
Il campo node.name deve essere definito, come richiesto su qualsiasi cluster con più nodi.

Vincoli di posizionamento

Alcuni vincoli sono imposti dal chart Helm e devono essere rispettati durante la definizione dei nodepool:

web e sidekiq-node sono inseparabili: il chart impone al container sidekiq-node di essere eseguito sullo stesso nodo di un container web. Questi due componenti devono quindi puntare allo stesso nodepool. Se vengono distribuite più repliche di web, le repliche di sidekiq-node si ripartiscono sui nodi che ospitano un container web.
third-parties, se attivato, è inseparabile da web, nginx, sidekiq e sidekiq-node: questi componenti condividono infatti un volume che può essere montato solo su un unico nodo, e devono quindi essere eseguiti tutti sullo stesso nodo. La guida alla distribuzione su un cluster esistente disattiva questo componente (thirdParties.enabled: false), eliminando così questo vincolo.
Caso di un’architettura Cyberwatch multinodo (master/satellite): quando node.type: master è definito, il database e Redis sono esposti ai nodi satellite tramite hostPort (3306 e 6379) sui nodi che ospitano i container db e redis. I nodi del nodepool che ospita questi componenti devono quindi essere raggiungibili dai nodi satellite. Vedere la guida Distribuzione di un nodo satellite Cyberwatch su un cluster Kubernetes esistente.
Le risorse allocate per impostazione predefinita a ciascun componente (requests e limits) sono consultabili nel file di configurazione predefinito del chart Helm:
```
helm show values oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart
```

Le connessioni verso gli asset monitorati (SSH, WinRM, discovery di rete) sono emesse dal container sidekiq-node; le scansioni dei siti web e i download delle immagini dei container dai container web-scanner e container-scanner. Le regole di filtraggio di rete devono tenere conto dei nodepool su cui sono posizionati questi componenti.

Implementazione

Identificare i label che distinguono i nodepool.
Se il cluster è gestito da un provider cloud, sui nodi sono già presenti dei label, ad esempio cloud.google.com/gke-nodepool (GKE), eks.amazonaws.com/nodegroup (EKS) o kubernetes.azure.com/agentpool (AKS).
In caso contrario, applicare un label ai nodi di ciascun nodepool:
```
kubectl label nodes <nom-du-nœud> nodepool=cyberwatch-app
```
I label di un nodo possono essere verificati con:
```
kubectl get nodes --show-labels
```
Compilare il campo nodeSelector di ciascun componente nel file values.yml, in base alla ripartizione scelta.

Applicare la configurazione:

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

Verificare la ripartizione dei pod sui nodi:
```
kubectl -n cyberwatch get pods -o wide
```

Applicazione a un’istanza esistente

L’aggiunta di campi nodeSelector su un’istanza già distribuita comporta la ricreazione dei pod interessati, e quindi un’interruzione del servizio per la durata della nuova distribuzione.

I volumi persistenti dei componenti con stato (db, redis, elasticsearch, container-scanner) devono essere accessibili dai nodi del nodepool di destinazione. A seconda del sistema di storage, un volume può essere associato a una zona o a un nodo specifico: in tal caso, puntare a un nodepool incompatibile lascia il pod nello stato Pending. Verificare i vincoli di topologia della StorageClass utilizzata prima di spostare questi componenti.

Regolare la capacità dei nodepool

Il numero di repliche dei componenti senza stato si configura con i campi replicaCount oppure tramite un autoscaling orizzontale (HPA). Per ulteriori informazioni, consultare la documentazione degli HPA.