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 : permettent de configurer les replicas, les requêtes/limites de CPU et de mémoire pour les principaux déploiements/pods.
- Installations basées sur Helm : offrent une personnalisation plus complète, incluant :
- 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 configuration de nodeSelector, tolerations et autres paramètres 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
Lors de l'utilisation de GitGuardian pour surveiller les dépôts, il est essentiel de dimensionner les ressources de manière appropriée pour les scans historiques, les scans en temps réel et les requêtes vers l'API publique. Cela garantit un traitement efficace et rapide quelle que soit la charge. Ces recommandations s'appliquent uniquement aux installations sur existing cluster.
Recommandations générales
Lorsque vous ajoutez un grand nombre de sources, envisagez d'augmenter temporairement le nombre de pods le temps du scan historique initial. Par la suite, vous pourrez réduire le nombre de replicas et les ressources de ces pods.
Lors de l'exécution 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 nœuds, 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 des événements Push envoyés par le VCS à GitGuardian. Ces scans se terminent généralement en moins d'une seconde et devraient toujours rester sous 3 secondes. Pour gérer les pics de push, 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 à plus longue durée, garantissant des performances fiables et évitant les timeouts lors de tâches prolongées.
Ajustez le nombre de pods et la capacité des nœuds 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 d'assurer un scan et des interactions efficaces.
Pour éviter une mise à l'échelle manuelle, vous pouvez vous intéresser à l'autoscaling pour vous adapter dynamiquement à la charge, voir Autoscaling.
Considérations sur le scan des Container Registries
- Configuration des replicas : par défaut, les replicas des container registries sont définis à 0, ce qui fait que le scan des container registries se rabat sur l'utilisation des workers de scan. Il est recommandé de configurer cette valeur à un nombre de replicas non nul pour des performances dédiées au scan des container registries.
- Utilisation du cache : consomme une quantité significative de mémoire Redis et de stockage de base de données (plusieurs Go). Envisagez de mettre Redis à l'échelle ou d'utiliser une instance dédiée.
- Pression sur la base de données : les pods scanners peuvent exercer une pression sur la base de données, en particulier lors des scans initiaux. Mettez à l'échelle avec précaution en respectant le nombre minimum de replicas recommandé.
- Coûts de transfert de données : scanner de grands registries peut entraîner des coûts élevés de transfert réseau. Commencez par quelques dépôts pour évaluer les coûts avant de passer à un scan complet.
Considérations sur les Check Runs
- Configuration des replicas : par défaut, les replicas 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.replicasafin de décharger la queuecheck_runduworker-worker.
Considérations sur le scan Slack
- Configuration des replicas : par défaut, les replicas des scanners Slack sont définis à 0, ce qui fait que le scan du registre Slack se rabat sur l'utilisation des workers de scan. Il est recommandé de configurer cette valeur à un nombre de replicas non nul pour des performances dédiées au scan du registre Slack. Configurer un grand nombre de replicas n'est pas nécessaire, car le scan Slack est limité à un canal à la fois en raison des rate limits de l'API Slack.
Considérations sur le scan des fichiers binaires
Le scan des fichiers binaires est actuellement disponible uniquement pour Microsoft Sharepoint Online et Microsoft OneDrive. Lors de l'exécution 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 sur le scan des Package Registries
- Configuration des replicas :
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 replicas 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 gros dépôt — le job est remis dans la queue premium_repo_scan_retry et réessayé sur un pod à mémoire plus élevée. Cela vous permet de dimensionner vos scanners de base pour le cas courant plutôt que pour votre plus grand dépôt. Vous pouvez activer ce worker si certains scans VCS échouent à répétition avec une erreur "Worker Error".
- Désactivé par défaut (
replicas: 0) : ne consomme aucune ressource tant qu'il n'est pas activé. Lorsqu'il est désactivé,worker-scannersconsomme la queuepremium_repo_scan_retryen repli, donc aucune action n'est requise. - Ressources : par défaut, une requête de mémoire et une limite de
120Gi— intentionnel, dimensionné pour la récupération OOM des jobs ayant déjà échoué sur les pods standards. Choisissez un nœud qui correspond au plus près (par exemple, ~128 Go allouables) pour éviter de provisionner un nœud surdimensionné. - Mise à l'échelle à zéro : associez-le à Horizontal Pod Autoscaling (métrique sur
premium_repo_scan_retry, seuil1) afin que le gros nœud ne soit provisionné que lorsqu'il y a un scan à réessayer.
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 sur le scaling de ML Secret Engine
ML Secret Engine nécessite une allocation de ressources et des considérations de mise à l'échelle spécifiques. Pour des instructions détaillées de configuration, consultez la documentation Machine Learning.
- Ressources par pod : 3 vCPU et 2,5 Gio de RAM chacun.
- Recommandation d'instance : utilisez des instances AWS Gen 7 Intel (M7i) avec architecture amd64. Les instances CPU uniquement sont bien plus rentables que les instances GPU (g4dn/p3) pour l'analyse ML.
- Mise à l'échelle : utilisez les recommandations de dimensionnement ci-dessous (Small/Medium/Large) comme configuration de base. Pour une mise à l'échelle dynamique lors des backfills, envisagez de configurer Horizontal Pod Autoscaling (HPA) pour le worker
ml-api-priority.
Analytics (en bêta)
Advanced Analytics requiert des ressources supplémentaires lorsqu'il est activé. Le job s'exécute une fois par jour et possède la configuration de ressources par défaut suivante :
- Requête 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)
Planifiez la capacité de votre cluster et de votre base de données en conséquence.
Small
Composants principaux du système
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 |
|---|---|---|
| Nœuds 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 un stockage éphémère global, ajoutez 20 Go à l'espace disque persistant sur chacun de vos nœuds de calcul Kubernetes.
Scans historiques (jusqu'à 5 Go de taille)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners | Requête et limite 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 | Requête et limite 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 principaux du système
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 |
|---|---|---|
| Nœuds 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 un stockage éphémère global, ajoutez 120 Go à l'espace disque persistant sur chacun de vos nœuds de calcul Kubernetes.
Scans historiques (jusqu'à 10 Go de taille)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners | Requête et limite 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 | Requête, limite de mémoire : 4 Gio, 6 Gio | 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 principaux du système
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 |
|---|---|---|
| Nœuds 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 un stockage éphémère global, ajoutez 160 Go à l'espace disque persistant sur chacun de vos nœuds de calcul Kubernetes.
Scans historiques (jusqu'à 15 Go de taille)
| Composant | Capacité requise | Nombre |
|---|---|---|
Pods worker-scanners | Requête et limite de mémoire : 16 Go | 16 |
Pods worker-scanners-ods | Requête et limite de mémoire : 4 Go | 10 |
Définissez des pods worker-scanners-ods spécifiques en particulier 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 tout à fait acceptable de partager la même queue et les mêmes workers avec 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 | Requête, limite de mémoire : 4 Gio, 6 Gio | 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 Kubernetes Application RBAC en ajoutant la permission patch à la ressource servicemonitors.
Naviguez vers Config > Scaling dans la Console d'administration KOTS, vous aurez accès aux options de scaling des workers.
- Front replicas : met à l'échelle les pods
nginx. - API replicas : met à l'échelle les pods
api. - Workers replicas : met à l'échelle les pods
workers(y compris les podsscanners)
La modification de ces valeurs n'affecte pas la stratégie de déploiement par rollout.
Les workers sont configurés pour se répartir sur les nœuds s'il y a plusieurs nœuds.
Si vous avez configuré votre cluster pour la haute disponibilité, n'utilisez pas moins de 2 workers de chaque type.
Intégration de 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 éventuellement 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 (replicas à 0)
Pour des instructions de configuration détaillées, les exigences de 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 en utilisant votre fichier local-values.yaml, soumis avec la commande helm.
Configurez les déploiements avec replicas : utilisez webapps.[name].replicas pour les pods web, celeryWorkers.[name].replicas
pour les workers asynchrones et secretEngine.replicas pour Machine Learning Secret Engine. De plus, 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 mettre à l'échelle les pods suivants à un minimum de 2 replicas chacun : hook, internal-api-long, public-api, worker-email, worker-long et worker-worker.
Ajustement 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 nœuds "On Demand" avec des disques nvme et l'intégration de Generic Ephemeral Inline Volumes.
Nœuds "On Demand" avec disques nvme
Dans l'exemple suivant, nous spécifions que les workers scanners utilisent uniquement des VMs "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 tirons parti des 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 utile lorsque l'on doit composer avec de faibles limites de stockage éphémère. Notez que cette fonctionnalité 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
Planification par affinité de nœud
Utilisez le paramètre nodeSelector dans les values Helm pour planifier les pods workers sur des nœuds spécifiques, en veillant à ce 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 distribution des pods sur les nœuds 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 entre différents nœuds 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 distribuer les pods entre les nœuds, mais ne garantit pas une distribution uniforme. Le scheduler essaiera de placer les pods sur différents nœuds lorsque cela est possible, mais planifiera tout de même les pods même si la distribution préférée ne peut pas être atteinte.
Configuration renforcée :
Pour les environnements nécessitant une distribution 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 à travers :
- Les zones de disponibilité (clé de topologie :
topology.kubernetes.io/zone) - Les nœuds individuels (clé de topologie :
kubernetes.io/hostname)
Pour activer l'anti-affinité hard 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 nœud différent, offrant une distribution maximale et une tolérance aux pannes.
Exigences de capacité des nœuds :
Le preset d'anti-affinité hard nécessite que vous disposiez de suffisamment de nœuds dans votre cluster pour satisfaire le nombre souhaité de replicas. Si votre cluster ne dispose pas d'assez de nœuds pour accueillir tous les pods avec les règles d'anti-affinité strictes, certains pods resteront à l'état "Pending" jusqu'à ce que des nœuds supplémentaires deviennent disponibles.
Par exemple, si vous configurez 10 replicas avec une anti-affinité hard mais que vous ne disposez que de 8 nœuds disponibles, 2 pods resteront en attente jusqu'à ce que davantage de nœuds soient ajoutés au cluster.
