Organisation des composants Cyberwatch en nodepools

Cette page décrit les contraintes à prendre en compte pour répartir les composants de Cyberwatch sur plusieurs groupes de nœuds (nodepools) d’un cluster Kubernetes. Elle complète le guide Déploiement de Cyberwatch sur un cluster Kubernetes existant et s’adresse aux clusters composés de plusieurs nœuds.

Le chart Helm n’impose aucune répartition : par défaut, tous les composants peuvent s’exécuter sur un même nœud ou un même nodepool. Répartir les composants par profil de charge peut néanmoins permettre :

de garantir des ressources stables aux composants de données (base de données, files de tâches) ;
d’absorber les pics de charge des analyses et des scans sans dégrader l’interface web ;
d’appliquer des règles de filtrage réseau différenciées selon les flux émis par chaque groupe de nœuds.

Le découpage relève des conventions du cluster, en respectant les contraintes de placement ci-dessous.

Prérequis

Le champ global.storageClass doit être défini dans le fichier values.yml.
Sans StorageClass, le chart Helm crée des volumes de type hostPath locaux à un nœud : tous les composants doivent alors s’exécuter sur le même nœud et aucune répartition n’est possible.
Le champ node.name doit être défini, comme requis sur tout cluster de plusieurs nœuds.

Contraintes de placement

Certaines contraintes sont imposées par le chart Helm et doivent être respectées lors de la définition des nodepools :

web et sidekiq-node sont indissociables : le chart impose au conteneur sidekiq-node de s’exécuter sur le même nœud qu’un conteneur web. Ces deux composants doivent donc cibler le même nodepool. Si plusieurs replicas de web sont déployés, les replicas de sidekiq-node se répartissent sur les nœuds hébergeant un conteneur web.
third-parties, s’il est activé, est indissociable de web, nginx, sidekiq et sidekiq-node : ces composants partagent alors un volume qui ne peut être monté que sur un seul nœud, et doivent donc tous s’exécuter sur le même nœud. Le guide de déploiement sur un cluster existant désactive ce composant (thirdParties.enabled: false), ce qui lève cette contrainte.
Cas d’une architecture multi-nœuds Cyberwatch (master/satellites) : lorsque node.type: master est défini, la base de données et Redis sont exposés aux nœuds satellites via des hostPort (3306 et 6379) sur les nœuds qui hébergent les conteneurs db et redis. Les nœuds du nodepool qui héberge ces composants doivent alors être joignables par les satellites. Voir le guide Déploiement d’un nœud satellite Cyberwatch sur un cluster Kubernetes existant.
Les ressources allouées par défaut à chaque composant (requests et limits) sont consultables dans le fichier de configuration par défaut du chart Helm :
```
helm show values oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart
```

Les connexions vers les actifs supervisés (SSH, WinRM, découvertes réseau) sont émises par le conteneur sidekiq-node ; les scans de sites web et les téléchargements d’images de conteneurs par les conteneurs web-scanner et container-scanner. Les règles de filtrage réseau doivent tenir compte des nodepools sur lesquels ces composants sont placés.

Mise en œuvre

Identifier les labels qui distinguent les nodepools.
Si le cluster est géré par un fournisseur cloud, des labels sont déjà présents sur les nœuds, par exemple cloud.google.com/gke-nodepool (GKE), eks.amazonaws.com/nodegroup (EKS) ou kubernetes.azure.com/agentpool (AKS).
Sinon, apposer un label sur les nœuds de chaque nodepool :
```
kubectl label nodes <nom-du-nœud> nodepool=cyberwatch-app
```
Les labels d’un nœud peuvent être vérifiés avec :
```
kubectl get nodes --show-labels
```
Renseigner le champ nodeSelector de chaque composant dans le fichier values.yml, selon la répartition choisie.

Appliquer la configuration :

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

Vérifier la répartition des pods sur les nœuds :
```
kubectl -n cyberwatch get pods -o wide
```

Application à une instance existante

L’ajout de champs nodeSelector sur une instance déjà déployée provoque la re-création des pods concernés, et donc une interruption de service le temps du redéploiement.

Les volumes persistants des composants avec état (db, redis, elasticsearch, container-scanner) doivent être accessibles depuis les nœuds du nodepool ciblé. Selon le système de stockage, un volume peut être rattaché à une zone ou à un nœud précis : dans ce cas, cibler un nodepool incompatible laisse le pod en état Pending. Vérifier les contraintes de topologie du StorageClass utilisé avant de déplacer ces composants.

Ajuster la capacité des nodepools

Le nombre de replicas des composants sans état se configure avec les champs replicaCount ou via un autoscaling horizontal (HPA). Voir la documentation des HPA pour plus d’informations.