Organization of Cyberwatch components in nodepools

This page describes the constraints to consider when distributing Cyberwatch components across multiple node groups (nodepools) in a Kubernetes cluster. It complements the guide Deploy Cyberwatch on an existing Kubernetes cluster and is intended for clusters composed of multiple nodes.

The Helm chart does not enforce any distribution: by default, all components can run on the same node or within the same nodepool. However, distributing components by workload profile can allow you to:

guarantee stable resources for data components (database, job queues);
absorb load spikes from analyses and scans without degrading the web interface;
apply differentiated network filtering rules according to the traffic emitted by each node group.

The breakdown depends on the cluster’s conventions, while respecting the placement constraints below.

Prerequisites

The global.storageClass field must be defined in the values.yml file.
Without a StorageClass, the Helm chart creates hostPath volumes that are local to a node: all components must then run on the same node and no distribution is possible.
The node.name field must be defined, as required on any multi-node cluster.

Placement constraints

Some constraints are imposed by the Helm chart and must be respected when defining nodepools:

web and sidekiq-node are inseparable: the chart requires the sidekiq-node container to run on the same node as a web container. These two components must therefore target the same nodepool. If multiple web replicas are deployed, the sidekiq-node replicas are distributed across the nodes hosting a web container.
third-parties, if enabled, is inseparable from web, nginx, sidekiq, and sidekiq-node: these components then share a volume that can only be mounted on a single node, and must therefore all run on the same node. The deployment guide for an existing cluster disables this component (thirdParties.enabled: false), which removes this constraint.
In a multi-node Cyberwatch architecture (master/satellites): when node.type: master is defined, the database and Redis are exposed to satellite nodes via hostPort (3306 and 6379) on the nodes hosting the db and redis containers. The nodes in the nodepool hosting these components must then be reachable by the satellites. See the guide Deploying a Cyberwatch satellite node on an existing Kubernetes cluster.
The default resources allocated to each component (requests and limits) can be viewed in the default configuration file of the Helm chart:
```
helm show values oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart
```

Connections to supervised assets (SSH, WinRM, network discoveries) are initiated by the sidekiq-node container; website scans and container image downloads by the web-scanner and container-scanner containers. Network filtering rules must take into account the nodepools on which these components are placed.

Implementation

Identify the labels that distinguish the nodepools.
If the cluster is managed by a cloud provider, labels are already present on the nodes, for example cloud.google.com/gke-nodepool (GKE), eks.amazonaws.com/nodegroup (EKS), or kubernetes.azure.com/agentpool (AKS).
Otherwise, apply a label to the nodes of each nodepool:
```
kubectl label nodes <node-name> nodepool=cyberwatch-app
```
The labels of a node can be checked with:
```
kubectl get nodes --show-labels
```
Specify the nodeSelector field for each component in the values.yml file, according to your chosen distribution.

Apply the configuration:

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

Check the distribution of pods across the nodes:
```
kubectl -n cyberwatch get pods -o wide
```

Applying to an existing instance

Adding nodeSelector fields to an already deployed instance will cause the affected pods to be recreated, resulting in service interruption during the redeployment.

The persistent volumes of stateful components (db, redis, elasticsearch, container-scanner) must be accessible from the nodes of the targeted nodepool. Depending on the storage system, a volume may be attached to a specific zone or node: in this case, targeting an incompatible nodepool will leave the pod in a Pending state. Check the topology constraints of the StorageClass used before moving these components.

Adjusting nodepool capacity

The number of replicas for stateless components is configured with the replicaCount fields or via horizontal autoscaling (HPA). See the HPA documentation for more information.