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 la configuration des replicas, du CPU et des requêtes/limites de mémoire pour les principaux deployments/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 telles que le stockage éphémère, les huge pages, etc.
  • La configuration de nodeSelector, tolerations et autres paramètres additionnels.

Pour des informations détaillées sur les noms de deployments/pods, leurs types et leur utilisation, consultez la page Topologie de l'application GitGuardian.

Mise à l'échelle pour GitGuardian : scans historiques, scans en temps réel, API publique et ML Secret Engine

Lors de l'utilisation de GitGuardian pour surveiller des dépôts, il est crucial de mettre à l'échelle les ressources de manière appropriée pour les scans historiques, les scans en temps réel et les requêtes d'API publique. Cela garantit un traitement efficace et rapide quelle que soit la charge. Ces recommandations concernent uniquement les installations sur existing cluster.

Directives générales

Réalisation de vos premiers scans historiques

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 diminuer les replicas 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 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 ajouterez de pods, plus il sera possible d'effectuer de scans historiques 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 fonctionner. 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 être inférieurs à 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 vous assurer que l'API publique peut gérer le trafic attendu, vous devrez peut-être ajuster le nombre de Pods webapp-public_api.

Les pods webapp-internal_api traitent les requêtes internes pour le Dashboard, tandis que les pods webapp-internal_api_long gèrent les opérations plus longues, garantissant des performances fiables et évitant les timeouts lors de 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 pour garantir un scan et des interactions efficaces.

Pour éviter la mise à l'échelle manuelle, l'autoscaling peut vous intéresser afin de 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 scanner workers. Il est recommandé de configurer un nombre de replicas non nul pour des performances de scan dédiées aux container registries.
• Utilisation du cache : Consomme une quantité importante de mémoire Redis et de stockage de base de données (plusieurs Go). Envisagez de mettre à l'échelle Redis ou d'utiliser une instance dédiée.
• Pression sur la base de données : Les pods scanners peuvent solliciter la base de données, en particulier lors des scans initiaux. Mettez à l'échelle avec précaution en respectant les nombres minimaux de replicas recommandés.
• Coûts de transfert de données : Scanner de grands 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 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 pods worker-check-runs dédiés en définissant celeryWorkers.check-runs.replicas pour décharger la file d'attente check_run de worker-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 registry Slack se rabat sur l'utilisation des scanner workers. Il est recommandé de configurer un nombre de replicas non nul pour des performances de scan dédiées au registry Slack. Configurer un grand nombre de replicas est inutile, car le scan Slack est limité à un seul canal à la fois en raison des limites de taux de l'API Slack.

Considérations sur le 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 sur le scan des Package Registries

• Configuration des replicas : scanners-db-less.replicas doit ê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-cache est utilisée pour le scan des JFrog Package Registries. Si commit-cache n'est pas configuré, l'instance Redis principale sera utilisée à la place.

Premium Scan Retry Worker

info

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 de manque de mémoire (OOM) sur un gros dépôt — la tâche est remise en file d'attente sur premium_repo_scan_retry et retentée sur un pod à mémoire supérieure. Cela vous permet de dimensionner vos scanners de base pour le cas courant plutôt que pour votre plus gros 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-scanners consomme la file premium_repo_scan_retry en repli, donc aucune action n'est nécessaire.
• Ressources : par défaut, une requête et une limite mémoire de 120Gi — intentionnel, dimensionné pour la récupération OOM de tâches ayant déjà échoué sur des pods standards. Choisissez un node qui correspond au plus juste (par exemple ~128 Go allouables) pour éviter de provisionner un node surdimensionné.
• Scale to zero : associez avec Horizontal Pod Autoscaling (métrique sur premium_repo_scan_retry, seuil 1) afin que le gros node ne soit provisionné que lorsqu'il y a un scan à retenter.

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 la mise à l'échelle du ML Secret Engine

Le 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 une architecture amd64. Les instances CPU-only 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 l'Horizontal Pod Autoscaling (HPA) pour le worker ml-api-priority.

Analytics

Advanced Analytics nécessite des ressources supplémentaires lorsqu'il est activé. La tâche s'exécute une fois par jour et a la configuration de ressources par défaut suivante :

• Requête mémoire : 8 Go
• Limite 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 /tmp sur le disque local du node. Sur les gros 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 de l'in-app analytics.

Small

Composants principaux du système

Pour jusqu'à 2000 dépôts, gérant jusqu'à 500 push par heure et jusqu'à 1000 requêtes API par heure :

Composant	Capacité requise	Nombre
Nodes de calcul Kubernetes	4 vCPU 16 Go mémoire 50 Go d'espace disque éphémère, 10 Go d'espace disque persistant	3
PostgreSQL Master	4 vCPU 8 Go mémoire 200 Go d'espace disque	1
Redis	2 vCPU 2 Go mémoire 20 Go d'espace disque	1
Total	18 vCPU 58 Go 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	Requête et limite mémoire : 6 Go	4

Scans en temps réel (jusqu'à 500 push/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 en temps réel pour Container Registries

Composant	Capacité requise	Nombre
Pods worker-container-registries	Requête et limite 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 push par heure et jusqu'à 25000 requêtes API par heure :

Composant	Capacité requise	Nombre
Nodes de calcul Kubernetes	8 vCPU 32 Go mémoire 50 Go d'espace disque éphémère, 10 Go d'espace disque persistant	5
PostgreSQL Master	8 vCPU 32 Go mémoire 250 Go d'espace disque	1
Redis	4 vCPU 8 Go mémoire 40 Go d'espace disque	1
Total	52 vCPU 200 Go 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	Requête et limite mémoire : 11 Go	12

Scans en temps réel (jusqu'à 1k push/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 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 push par heure et jusqu'à 50000 requêtes API par heure :

Composant	Capacité requise	Nombre
Nodes de calcul Kubernetes	8 vCPU 64 Go mémoire 50 Go d'espace disque éphémère, 10 Go d'espace disque persistant	7
PostgreSQL Master	16 vCPU 64 Go mémoire 300 Go d'espace disque	1
Redis	8 vCPU 16 Go mémoire 100 Go d'espace disque	1
Total	80 vCPU 528 Go 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	Requête et limite mémoire : 16 Go	16
Pods worker-scanners-ods	Requête et limite 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 acceptable de partager la même file d'attente et les mêmes workers avec la charge worker-scanners.

Scans en temps réel (jusqu'à 2k push/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 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 mise à l'échelle

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

attention

Assurez-vous de mettre à jour le Kubernetes Application RBAC en ajoutant l'autorisation patch à la ressource servicemonitors.

Naviguez dans Config > Scaling dans la KOTS Admin Console, vous aurez accès aux options de mise à l'échelle des workers.

• Front replicas : Mise à l'échelle des pods nginx.
• API replicas : Mise à l'échelle des pods api.
• Workers replicas : Mise à l'échelle des pods workers (y compris les pods scanners)

info

Modifier ces valeurs n'affecte pas la stratégie de rollout upgrade.
Les workers sont configurés pour être répartis 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 (replicas à 0)

Pour des instructions de configuration détaillées, les exigences des workers et les étapes d'activation, consultez la documentation Non-VCS Sources.

Cette page de mise à l'échelle 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 deployments avec replicas : utilisez webapps.[name].replicas pour les pods web, celeryWorkers.[name].replicas pour les workers async et secretEngine.replicas pour le Machine Learning Secret Engine. Définissez également les requests et limits de ressources selon les 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.

Recommandation de mise à l'échelle

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

info

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 dans les charts Helm. Cette fonctionnalité facilite le provisionnement et la récupération dynamiques du stockage, particulièrement bénéfique lorsqu'il s'agit de petites limites de 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 de l'in-app analytics

La tâche in-app analytics exécute un pipeline Spark qui écrit par défaut les données de shuffle et de spill dans /tmp sur le disque local du node. Sur les gros 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 à /ephemeral et fait pointer l'espace de travail Spark (SPARK_LOCAL_DIRS) vers celui-ci au lieu de /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é des pods

Le chart Helm de GitGuardian fournit des paramètres d'anti-affinité de pods configurables pour contrôler la façon dont les pods sont distribués à travers 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 distribuer les pods sur les nodes mais ne garantit pas une distribution uniforme. Le scheduler essaiera de placer les pods sur différents nodes 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 strictes d'anti-affinité 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 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 node différent, offrant une distribution maximale et une tolérance aux pannes.

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 souhaité de replicas. Si votre cluster ne dispose pas d'assez de nodes pour accueillir tous les pods avec les règles strictes d'anti-affinité, certains pods resteront à l'état « Pending » jusqu'à ce que des nodes supplémentaires soient disponibles. Par exemple, si vous configurez 10 replicas avec une anti-affinité hard mais ne disposez que de 8 nodes disponibles, 2 pods resteront en attente jusqu'à ce que plus de nodes soient ajoutés au cluster.