Scaling
Topologie de l'application
L'application GitGuardian se compose de plusieurs ressources Kubernetes. Voici les aspects clés selon le type d'installation :
- Installations basées sur KOTS : Permet de configurer les réplicas, le CPU et les requests/limits de mémoire pour les principaux déploiements/pods.
- Installations basées sur Helm : Offre une personnalisation plus complète, y compris :
- La création de nouvelles classes de workers.
- La personnalisation d'autres types de ressources tels que le stockage éphémère, les huge pages, etc.
- La définition de nodeSelector, tolerations et configurations supplémentaires.
Pour des informations détaillées sur les noms, types et utilisations des déploiements/pods, consultez la page Topologie de l'application GitGuardian.
Scaling pour GitGuardian : scans historiques, scans en temps réel, API publique et ML Secret Engine
Lorsque vous utilisez GitGuardian pour surveiller des dépôts, il est crucial de dimensionner correctement les ressources pour les scans historiques, les scans en temps réel et les requêtes de l'API publique. Cela garantit un traitement efficace et en temps voulu quelle que soit la charge. Ces recommandations concernent uniquement les installations sur existing cluster.
Recommandations générales
Lorsque vous ajoutez un grand nombre de sources, envisagez d'augmenter temporairement le nombre de pods pendant la durée du scan historique initial. Ensuite, vous pouvez réduire les réplicas et les ressources de ces pods.
Lors de la réalisation d'un scan historique sur un dépôt git, GitGuardian clone le dépôt sur le stockage éphémère du pod et parcourt toutes les branches et tous les commits à la recherche de secrets potentiels. Le scan complet est effectué par un seul Pod et peut durer de quelques secondes à plusieurs heures selon la taille du dépôt. Plus vous ajoutez de pods, plus de scans historiques peuvent être effectués simultanément. Lors du dimensionnement de vos nodes, gardez à l'esprit que chaque Pod doit disposer de suffisamment de stockage éphémère et de mémoire pour s'exécuter. Pour améliorer les performances et réduire les temps de scan, il est recommandé d'utiliser des disques SSD pour le stockage éphémère.
Pour les scans en temps réel, ceux-ci sont déclenchés par les événements Push envoyés par le VCS à GitGuardian. Ces scans se terminent généralement en moins d'une seconde et devraient toujours être inférieurs à 3 secondes. Pour gérer les pics de pushes, vous pouvez augmenter le nombre de Pods worker-worker qui traitent les scans en temps réel.
L'API publique, utilisée principalement par ggshield, est déployée sous le pod webapp-public_api. Ce pod est essentiel pour permettre les interactions entre ggshield et GitGuardian. Pour garantir que l'API publique puisse gérer le trafic attendu, vous devrez peut-être ajuster le nombre de Pods webapp-public_api.
Les pods webapp-internal_api gèrent les requêtes internes pour le Dashboard, tandis que les pods webapp-internal_api_long gèrent les opérations de plus longue durée, garantissant des performances fiables et évitant les timeouts pendant les tâches prolongées.
Ajustez le nombre de pods et la capacité des nodes en fonction de la taille et du nombre de dépôts, du volume attendu d'événements push et du volume attendu de requêtes API afin de garantir un scan et des interactions efficaces.
Pour éviter le scaling manuel, l'autoscaling peut vous intéresser afin de s'adapter dynamiquement à la charge, voir Autoscaling.
Considérations relatives au scan des Container Registries
- Configuration des réplicas : Par défaut, les réplicas des container registries sont définis à 0, ce qui fait que le scan des container registries se rabat sur l'utilisation des scanner workers. Il est recommandé de configurer un nombre de réplicas non nul pour des performances de scan des container registries dédiées.
- Utilisation du cache : Consomme une quantité importante de mémoire Redis et de stockage de base de données (plusieurs Go). Envisagez de dimensionner Redis ou d'utiliser une instance dédiée.
- Pression sur la base de données : Les pods scanner peuvent exercer une pression sur la base de données, en particulier lors des scans initiaux. Dimensionnez avec précaution en respectant les nombres minimums de réplicas recommandés.
- Coûts de transfert de données : Le scan de grandes registries peut entraîner des coûts de transfert réseau élevés. Commencez par quelques dépôts pour évaluer les coûts avant de passer à un scan complet.
Considérations relatives aux Check Runs
- Configuration des réplicas : Par défaut, les réplicas des check runs sont définis à 0, ce qui fait que le traitement des check runs est géré par
worker-worker. Si vous rencontrez des volumes élevés de check runs GitHub, vous pouvez activer des podsworker-check-runsdédiés en définissantceleryWorkers.check-runs.replicaspour décharger la filecheck_rundeworker-worker.
Considérations relatives au scan Slack
- Configuration des réplicas : Par défaut, les réplicas des scanners Slack sont définis à 0, ce qui fait que le scan du registry Slack se rabat sur l'utilisation des scanner workers. Il est recommandé de configurer un nombre de réplicas non nul pour des performances de scan du registry Slack dédiées. Configurer un grand nombre de réplicas est inutile, car le scan Slack est restreint à un canal à la fois en raison des limites de débit de l'API Slack.
Considérations relatives au scan des fichiers binaires
Le scan des fichiers binaires n'est actuellement disponible que pour Microsoft Sharepoint Online et Microsoft OneDrive. Lors de la réalisation d'un scan historique sur des sources contenant des fichiers binaires, les fichiers seront téléchargés localement sur le stockage éphémère du pod. Pour améliorer les performances et réduire les temps de scan, il est recommandé d'utiliser des disques SSD pour le stockage éphémère et de provisionner suffisamment de stockage éphémère pour ces pods (100 Go).
Considérations relatives au scan des Package Registries
- Configuration des réplicas :
scanners-db-less.replicasdoit être défini à une valeur supérieure à 0 pour les intégrations JFrog Package Registries, SharePoint et OneDrive. Par défaut, les réplicas sont définis à 0. - Utilisation du cache : L'instance Redis
commit-cacheest utilisée pour le scan des JFrog Package Registries. Sicommit-cachen'est pas configuré, l'instance Redis principale sera utilisée à la place.
Premium Scan Retry Worker
Disponible uniquement pour les installations basées sur Helm.
premium-scanners-retry est un scanner de secours pour les dépôts plus volumineux. Lorsqu'un scan échoue sur un pod worker-scanners standard — généralement une erreur out-of-memory (OOM) sur un dépôt volumineux — la tâche est remise en file dans premium_repo_scan_retry et relancée sur un pod disposant de plus de mémoire. Cela vous permet de dimensionner vos scanners de base pour le cas courant plutôt que pour votre dépôt le plus volumineux. Vous pouvez activer ce worker si certains scans VCS échouent de manière répétée avec une erreur « Worker Error ».
- Désactivé par défaut (
replicas: 0) : ne consomme aucune ressource jusqu'à son activation. Tant qu'il est désactivé,worker-scannersconsomme la filepremium_repo_scan_retryen solution de repli, aucune action n'est donc requise. - Ressources : par défaut une request de mémoire de
120Giet une limit — intentionnel, dimensionné pour la récupération OOM des tâches ayant déjà échoué sur les pods standard. Choisissez un node qui correspond au plus près (par ex. ~128 Go allouables) afin d'éviter de provisionner un node surdimensionné. - Scale to zero : associez à l'Horizontal Pod Autoscaling (métrique sur
premium_repo_scan_retry, seuil1) afin que le node volumineux ne soit provisionné que lorsqu'il y a un scan à relancer.
celeryWorkers:
premium-scanners-retry:
replicas: 1 # 0 disables the dedicated worker (retries fall back to worker-scanners)
resources:
requests:
memory: 120Gi
limits:
memory: 120Gi
Considérations relatives au scaling du ML Secret Engine
Le ML Secret Engine nécessite une allocation de ressources et des considérations de scaling spécifiques. Pour des instructions de configuration détaillées, consultez la documentation Machine Learning.
- Ressources par pod : 3 vCPU et 2,5 GiB de RAM chacun.
- Recommandation d'instance : Utilisez des instances AWS Gen 7 Intel (M7i) avec une architecture amd64. Les instances CPU-only sont bien plus rentables que les instances GPU (g4dn/p3) pour l'analyse ML.
- Scaling : Utilisez les recommandations de dimensionnement ci-dessous (Small/Medium/Large) comme configuration de base. Pour un scaling dynamique pendant les backfills, envisagez de configurer l'Horizontal Pod Autoscaling (HPA) pour le worker
ml-api-priority.
ClickHouse
Certaines fonctionnalités nécessitent ClickHouse, un composant in-cluster facultatif avec ses propres considérations de dimensionnement, distinctes des composants système principaux ci-dessus. Consultez la page dédiée Dimensionnement et durcissement pour les tableaux de dimensionnement et les recommandations matérielles.
Analytics
Advanced Analytics nécessite des ressources supplémentaires lorsqu'il est activé. La tâche s'exécute une fois par jour et possède la configuration de ressources par défaut suivante :
- Request de mémoire : 8 Go
- Limite de mémoire : 12 Go
- Augmentation de l'utilisation de la base de données : 15-20 % (minimum 5-6 Go)
- Stockage éphémère : la tâche exécute un pipeline Spark qui écrit les données de shuffle et de spill dans
/tmpsur le disque local du node. Sur les grands workspaces, cela peut dépasser la limite de stockage éphémère du node et faire échouer la tâche quotidienne. Prévoyez de 5 à 20 Go d'espace de travail selon votre volume de données.
Planifiez la capacité de votre cluster et de votre base de données en conséquence.
À partir de 2026.7.0, vous pouvez déplacer l'espace de travail Spark sur un volume dédié et dimensionné plutôt que sur le disque local du node. Voir Stockage éphémère pour l'analytics in-app.
Small
Composants système principaux
Pour jusqu'à 2000 dépôts, gérant jusqu'à 500 pushes par heure et jusqu'à 1000 requêtes API par heure :
| Composant | Capacité requise | Nombre |
|---|---|---|
| Nodes de calcul Kubernetes | 4 vCPU 16 Go de mémoire 50 Go d'espace disque éphémère, 10 Go d'espace disque persistant | 3 |
| PostgreSQL Master | 4 vCPU 8 Go de mémoire 200 Go d'espace disque | 1 |
| Redis | 2 vCPU 2 Go de mémoire 20 Go d'espace disque | 1 |
| Total | 18 vCPU 58 Go de mémoire 150 Go d'espace disque éphémère, 250 Go d'espace disque persistant | 5 |
Si vous prévoyez d'utiliser le stockage éphémère global, ajoutez 20 Go à l'espace disque persistant sur chacun de vos nodes de calcul Kubernetes.
Scans historiques (jusqu'à 5 Go de taille)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners | Request et limit de mémoire : 6 Go | 4 |
Scans en temps réel (jusqu'à 500 pushes/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-worker | Paramètres de ressources par défaut | 2 |
API publique (jusqu'à 1k requêtes/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods webapp-public_api | Paramètres de ressources par défaut | 2 |
Pods nginx (dashboard et API) | Paramètres de ressources par défaut | 2 |
Dashboard (jusqu'à 200 utilisateurs actifs)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods webapp-internal_api | Paramètres de ressources par défaut | 2 |
Pods webapp-internal_api_long | Paramètres de ressources par défaut | 2 |
Machine learning (jusqu'à 500 événements/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods ml-secret-engine | Paramètres de ressources par défaut | 1 |
Pods worker-ml-api-priority | Paramètres de ressources par défaut | 1 |
Scans historiques et scans en temps réel pour les Container registries
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-container-registries | Request et limit de mémoire : 4 Go | 2 |
Scans historiques pour Slack
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-slack | Paramètres de ressources par défaut | 1 |
Scans historiques pour Sharepoint / OneDrive
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-ods-highdisk | Paramètres de ressources par défaut | 1 |
Pods apacheTika | Paramètres de ressources par défaut | 1 |
Scan des Package Registries
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-db-less | Paramètres de ressources par défaut | 1 |
Medium
Composants système principaux
Pour jusqu'à 10000 dépôts, gérant jusqu'à 1000 pushes par heure et jusqu'à 25000 requêtes API par heure :
| Composant | Capacité requise | Nombre |
|---|---|---|
| Nodes de calcul Kubernetes | 8 vCPU 32 Go de mémoire 50 Go d'espace disque éphémère, 10 Go d'espace disque persistant | 5 |
| PostgreSQL Master | 8 vCPU 32 Go de mémoire 250 Go d'espace disque | 1 |
| Redis | 4 vCPU 8 Go de mémoire 40 Go d'espace disque | 1 |
| Total | 52 vCPU 200 Go de mémoire 250 Go d'espace disque éphémère, 340 Go d'espace disque persistant | 7 |
Si vous prévoyez d'utiliser le stockage éphémère global, ajoutez 120 Go à l'espace disque persistant sur chacun de vos nodes de calcul Kubernetes.
Scans historiques (jusqu'à 10 Go de taille)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners | Request et limit de mémoire : 11 Go | 12 |
Scans en temps réel (jusqu'à 1k pushes/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-worker | Paramètres de ressources par défaut | 4 |
API publique (jusqu'à 25k requêtes/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods webapp-public_api | Paramètres de ressources par défaut | 4 |
Pods nginx (dashboard et API) | Paramètres de ressources par défaut | 2 |
Dashboard (jusqu'à 500 utilisateurs actifs)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods webapp-internal_api | Paramètres de ressources par défaut | 4 |
Pods webapp-internal_api_long | Paramètres de ressources par défaut | 2 |
Machine learning (jusqu'à 1k événements/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods ml-secret-engine | Paramètres de ressources par défaut | 2 |
Pods worker-ml-api-priority | Paramètres de ressources par défaut | 2 |
Scans historiques pour Slack
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-slack | Paramètres de ressources par défaut | 2 |
Scans historiques pour Sharepoint / OneDrive
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-ods-highdisk | Request, limit de mémoire : 4 GiB, 6 GiB | 4 |
Pods apacheTika | Paramètres de ressources par défaut | 2 |
Scan des Package Registries
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-db-less | Paramètres de ressources par défaut | 2 |
Large
Composants système principaux
Pour jusqu'à 40000 dépôts, gérant jusqu'à 2000 pushes par heure et jusqu'à 50000 requêtes API par heure :
| Composant | Capacité requise | Nombre |
|---|---|---|
| Nodes de calcul Kubernetes | 8 vCPU 64 Go de mémoire 50 Go d'espace disque éphémère, 10 Go d'espace disque persistant | 7 |
| PostgreSQL Master | 16 vCPU 64 Go de mémoire 300 Go d'espace disque | 1 |
| Redis | 8 vCPU 16 Go de mémoire 100 Go d'espace disque | 1 |
| Total | 80 vCPU 528 Go de mémoire 350 Go d'espace disque éphémère, 470 Go d'espace disque persistant | 9 |
Si vous prévoyez d'utiliser le stockage éphémère global, ajoutez 160 Go à l'espace disque persistant sur chacun de vos nodes de calcul Kubernetes.
Scans historiques (jusqu'à 15 Go de taille)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners | Request et limit de mémoire : 16 Go | 16 |
Pods worker-scanners-ods | Request et limit de mémoire : 4 Go | 10 |
Définissez des pods worker-scanners-ods spécifiques surtout si vous intégrez de grandes instances Slack ou MS Teams (5k+ canaux). Il est préférable d'isoler ces charges de travail.
Sinon, il est acceptable de partager la même file et les mêmes workers que la charge de travail worker-scanners.
Scans en temps réel (jusqu'à 2k pushes/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-worker | Paramètres de ressources par défaut | 8 |
API publique (jusqu'à 50k requêtes/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods webapp-public_api | Paramètres de ressources par défaut | 6 |
Pods nginx (dashboard et API) | Paramètres de ressources par défaut | 2 |
Dashboard (jusqu'à 1k utilisateurs actifs)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods webapp-internal_api | Paramètres de ressources par défaut | 6 |
Pods webapp-internal_api_long | Paramètres de ressources par défaut | 2 |
Machine learning (jusqu'à 2k événements/h)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods ml-secret-engine | Paramètres de ressources par défaut | 2 |
Pods worker-ml-api-priority | Paramètres de ressources par défaut | 2 |
Scans historiques pour Slack
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-slack | Paramètres de ressources par défaut | 2 |
Scans historiques pour Sharepoint / OneDrive
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-ods-highdisk | Request, limit de mémoire : 4 GiB, 6 GiB | 4 |
Pods apacheTika | Paramètres de ressources par défaut | 2 |
Scan des Package Registries
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners-db-less | Paramètres de ressources par défaut | 4 |
Configurer les paramètres de scaling
Vous pouvez dimensionner votre infrastructure selon les recommandations ci-dessus, mais vous pouvez également utiliser l'autoscaling Kubernetes pour vous adapter dynamiquement à la charge, voir Autoscaling.
Installation basée sur KOTS
Assurez-vous de mettre à jour le RBAC de l'application Kubernetes en ajoutant la permission patch à la ressource servicemonitors.
Naviguez sous Config > Scaling dans la KOTS Admin Console, vous aurez accès aux options de scaling des workers.
- Front replicas : Dimensionne les pods
nginx. - API replicas : Dimensionne les pods
api. - Workers replicas : Dimensionne les pods
workers(y compris les podsscanners)
La modification de ces valeurs n'affecte pas la stratégie de mise à jour par rollout.
Les workers sont configurés pour se répartir sur les nodes s'il y a plusieurs nodes.
Si vous avez configuré votre cluster pour la haute disponibilité, n'utilisez pas moins de 2 workers de chaque type.
Intégration des sources non-VCS :
Pour les intégrations non-VCS (messagerie, documentation, ticketing et container registries), la configuration des workers varie selon le type d'intégration :
- Certaines intégrations peuvent optionnellement utiliser des workers VCS génériques mais bénéficient de workers dédiés
- D'autres nécessitent leurs propres workers spécialisés et ne peuvent pas partager les workers VCS
- Par défaut, tous les workers de sources non-VCS sont désactivés (réplicas définis à 0)
Pour des instructions de configuration détaillées, les exigences des workers et les étapes d'activation, consultez la documentation Sources non-VCS.
Cette page de scaling se concentre sur l'optimisation des performances après l'activation initiale.
Installation basée sur Helm
Personnalisez les applications Helm à l'aide de votre fichier local-values.yaml, soumis avec la commande helm.
Configurez les déploiements avec replicas : use webapps.[name].replicas pour les pods web, celeryWorkers.[name].replicas
pour les workers asynchrones et secretEngine.replicas pour le Machine Learning Secret Engine. En outre, définissez les requests et limits de ressources selon vos besoins.
Exemple
migration:
# Set resources for pre-deploy and post-deploy jobs
resources:
limits:
cpu: 1000m
memory: 500Mi
front:
nginx:
# Set resources for nginx init containers
init:
resources:
limits:
cpu: 1000m
memory: 500Mi
replicas: 2
resources:
limits:
memory: 1Gi
webapps:
public_api:
replicas: 5
resources:
requests:
cpu: 200m
memory: 500Mi
limits:
memory: 4Gi
celeryWorkers:
scanners:
replicas: 8
resources:
requests:
cpu: 200m
memory: 4Gi
limits:
memory: 16Gi
secretEngine:
replicas: 2
Consultez la documentation de référence des values pour plus de détails.
Pour des performances optimales, envisagez de dimensionner les pods suivants à un minimum de 2 réplicas chacun : hook, internal-api-long, public-api, worker-email, worker-long et worker-worker.
Réglage supplémentaire du stockage éphémère
Disponible uniquement pour les installations basées sur Helm.
Dans certains scénarios, l'optimisation des configurations de stockage éphémère devient essentielle pour obtenir de meilleures performances et une meilleure stabilité, en particulier pour les workers scanners. Cette section décrit des configurations supplémentaires pour affiner le stockage éphémère, en se concentrant sur l'utilisation de nodes « On Demand » avec des disques nvme et l'intégration de Generic Ephemeral Inline Volumes.
Nodes « On Demand » avec disques nvme
Dans l'exemple suivant, nous spécifions que les workers scanners n'utilisent que des VM « On Demand » avec des disques nvme et que le
stockage éphémère des pods utilisera ces disques
celeryWorkers:
scanners:
replicas: 8
localStoragePath: /nvme/disk # Used for pods ephemeral storage
nodeSelector: # Must run on "On Demand" nodes with nvme disks
eks.amazonaws.com/capacityType: ON_DEMAND
local-nvme-ready: 'true'
tolerations:
- key: worker-highdisk
operator: Equal
value: 'true'
effect: NoSchedule
resources:
requests:
cpu: 200m
memory: 16Gi
limits:
memory: 16Gi
Generic Ephemeral Inline Volumes
Dans l'exemple suivant, nous exploitons les Generic Ephemeral Inline Volumes de Kubernetes au sein des charts Helm. Cette fonctionnalité facilite le provisionnement dynamique et la récupération du stockage, particulièrement bénéfique lorsqu'on traite de petites limites sur le stockage éphémère. Notez qu'elle est prise en charge à partir de Kubernetes 1.23 (en savoir plus).
celeryWorkers:
scanners:
replicas: 8
resources:
requests:
cpu: 200m
memory: 4Gi
limits:
memory: 16Gi
# -- Worker ephemeral storage
ephemeralStorage:
enabled: true
size: 2Gi
Stockage éphémère pour l'analytics in-app
La tâche analytics in-app exécute un pipeline Spark qui écrit les données de shuffle et de spill dans /tmp sur le disque local du node par défaut. Sur les grands workspaces, cela peut dépasser la limite de stockage éphémère du node et faire échouer la tâche quotidienne.
À partir de 2026.7.0, vous pouvez attacher un Generic Ephemeral Inline Volume dédié au pod analytics. Lorsqu'il est activé, GitGuardian le monte sur /ephemeral et pointe l'espace de travail de Spark (SPARK_LOCAL_DIRS) vers celui-ci plutôt que vers /tmp.
inAppAnalytics:
ephemeralStorage:
enabled: true
size: 20Gi
storageClass: '' # Optional: defaults to the cluster's default StorageClass
Dimensionnez le volume selon votre volume de données. Une plage de 5 à 20 Go est un bon point de départ.
Planification par affinité de node
Utilisez le paramètre nodeSelector dans les values Helm pour planifier les pods worker sur des nodes spécifiques, garantissant qu'ils s'exécutent dans des zones désignées ou répondent à des critères spécifiques (en savoir plus).
celeryWorkers:
long:
nodeSelector:
topology.kubernetes.io/zone: eu-central-1c
scanners:
nodeSelector:
topology.kubernetes.io/zone: eu-central-1c
worker:
nodeSelector:
topology.kubernetes.io/zone: eu-central-1c
Anti-affinité de pods
Le chart Helm de GitGuardian fournit des paramètres d'anti-affinité de pods configurables pour contrôler la répartition des pods sur les nodes de votre cluster Kubernetes. Cette fonctionnalité vous permet d'optimiser la disponibilité et l'utilisation des ressources en garantissant que les pods sont répartis uniformément sur différents nodes et zones de disponibilité.
Configuration par défaut :
Par défaut, le chart applique une configuration podAntiAffinityPreset: soft pour les webApps et les workers. Cette préférence d'anti-affinité soft tente de répartir les pods sur les nodes mais ne garantit pas une répartition uniforme. Le scheduler essaiera de placer les pods sur des nodes différents lorsque cela est possible, mais planifiera tout de même les pods même si la répartition préférée ne peut pas être atteinte.
Configuration durcie :
Pour les environnements nécessitant une répartition uniforme garantie des pods, vous pouvez spécifier podAntiAffinityPreset: hard. Cette configuration applique des règles d'anti-affinité strictes qui garantissent que les pods sont répartis uniformément sur :
- Les zones de disponibilité (clé de topologie :
topology.kubernetes.io/zone) - Les nodes individuels (clé de topologie :
kubernetes.io/hostname)
Pour activer l'anti-affinité de pods stricte pour le composant scanner worker, configurez vos values Helm comme suit :
celeryWorkers:
scanners:
replicas: 10
podAntiAffinityPreset: hard
Cette configuration garantira que chaque pod scanner worker s'exécute sur un node différent, offrant une répartition et une tolérance aux pannes maximales.
Exigences de capacité des nodes :
Le preset d'anti-affinité hard nécessite que vous disposiez de suffisamment de nodes dans votre cluster pour satisfaire le nombre de réplicas souhaité. Si votre cluster ne dispose pas d'assez de nodes pour accueillir tous les pods avec les règles d'anti-affinité strictes, certains pods resteront dans un état « Pending » jusqu'à ce que des nodes supplémentaires deviennent disponibles.
Par exemple, si vous configurez 10 réplicas avec une anti-affinité stricte mais que vous ne disposez que de 8 nodes disponibles, 2 pods resteront en attente jusqu'à ce que davantage de nodes soient ajoutés au cluster.
