Scaling

Topologie de l'application

L'application GitGuardian est constituée de plusieurs ressources Kubernetes. Voici les aspects clés selon le type d'installation :

Installations basées sur KOTS : permettent la configuration des réplicas, des 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, 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 de déploiements/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

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

Recommandations générales

Réaliser 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 pourrez 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 le nombre de scans historiques pouvant être effectués simultanément est élevé. 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 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 durer moins de 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, principalement utilisée 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 du 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 délais d'attente 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 de push et du volume attendu de requêtes API afin de garantir des scans et des interactions efficaces et performants.

Pour éviter la mise à l'échelle manuelle, l'autoscaling peut vous intéresser afin de vous adapter dynamiquement à la charge ; consultez Autoscaling.

Considérations sur le scan des container registries

Configuration des réplicas : par défaut, les réplicas de container registry sont fixés à 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 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 Redis à l'échelle 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. Mettez à l'échelle avec précaution en respectant le nombre minimum de réplicas recommandé.
Coûts de transfert de données : le scan de grands registres 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 réplicas : par défaut, les réplicas de check runs sont fixés à 0, ce qui fait que le traitement des check runs est géré par worker-worker. Si vous observez 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 réplicas : par défaut, les réplicas des scanners Slack sont fixés à 0, ce qui fait que le scan du registre 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 dédiées au registre Slack. Il n'est pas nécessaire de configurer un grand nombre de réplicas, car le scan Slack est limité à un canal à la fois en raison des limites de débit 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 réplicas : 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 réplicas sont fixés à 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 mémoire insuffisante (OOM) sur un dépôt volumineux — la tâche est remise en file d'attente dans premium_repo_scan_retry et réessayé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 plus gros dépôt. Vous pouvez activer ce worker si certains scans VCS échouent de manière répétée avec l'échec « Worker Error ».

Désactivé par défaut (replicas: 0) : ne consomme aucune ressource tant qu'il n'est pas activé. Tant qu'il est désactivé, worker-scanners consomme la file d'attente premium_repo_scan_retry en tant que solution de repli, aucune action n'est donc requise.
Ressources : une requête et une limite de mémoire de 120Gi par défaut — intentionnel, dimensionné pour la récupération OOM de tâches ayant déjà échoué sur des pods standard. Choisissez un nœud correspondant au plus près (par exemple ~128 Go allouables) pour éviter de provisionner un nœud surdimensionné.
Mise à l'échelle à zéro : associez à l'Horizontal Pod Autoscaling (métrique sur premium_repo_scan_retry, seuil 1) afin que le nœud volumineux 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 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 de configuration détaillées, 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 uniquement sont bien plus économiques 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 référence. Pour une mise à l'échelle dynamique lors des 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 de base 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 :

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)
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 nœud. Sur les grands workspaces, cela peut dépasser la limite de stockage éphémère du nœud 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 nœud. Consultez Stockage éphémère pour les analytics in-app.

Small

Composants système de base

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
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 le stockage éphémère global, ajoutez 20 Go à l'espace disque persistant de chacun de vos nœuds de calcul Kubernetes.

Scans historiques (jusqu'à 5 Go)

Composant	Capacité requise	Nombre
Pods `worker-scanners`	Requête et limite de 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 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 système de base

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
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 le stockage éphémère global, ajoutez 120 Go à l'espace disque persistant de chacun de vos nœuds de calcul Kubernetes.

Scans historiques (jusqu'à 10 Go)

Composant	Capacité requise	Nombre
Pods `worker-scanners`	Requête et limite de 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 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	4

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 système de base

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
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 le stockage éphémère global, ajoutez 160 Go à l'espace disque persistant de chacun de vos nœuds de calcul Kubernetes.

Scans historiques (jusqu'à 15 Go)

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 (plus de 5k canaux). Il vaut mieux isoler ces charges de travail. Sinon, il n'y a pas de problème à partager la même file d'attente et les mêmes workers avec la charge de travail 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 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	6

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 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 ; consultez Autoscaling.

Installation basée sur KOTS

attention

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 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

La modification de ces valeurs n'affecte pas la stratégie de mise à jour progressive.
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 (réplicas fixés à 0)

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

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 à l'aide de 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 le 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.

Recommandation de mise à l'échelle

Pour des performances optimales, envisagez de mettre à l'échelle 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

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 mettant l'accent sur l'exploitation de nœuds « On Demand » avec des disques nvme et l'intégration de Generic Ephemeral Inline Volumes.

Nœuds « On Demand » avec des disques nvme

Dans l'exemple suivant, nous spécifions que les workers scanners utilisent uniquement 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 utile lorsque vous devez composer avec de faibles 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 pour les analytics in-app

La tâche d'analytics in-app 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 nœud. Sur les grands workspaces, cela peut dépasser la limite de stockage éphémère du nœud 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 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 nœud

Utilisez le paramètre nodeSelector dans les values Helm pour planifier les pods de workers sur des nœuds spécifiques, en 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 pod

Le chart Helm de GitGuardian fournit des paramètres d'anti-affinité de pod configurables pour contrôler la manière dont les pods sont répartis 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 sur 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 répartir les pods sur les nœuds mais ne garantit pas une répartition uniforme. Le planificateur 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 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 nœuds individuels (clé de topologie : kubernetes.io/hostname)

Pour activer l'anti-affinité de pod 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 nœud différent, offrant une distribution et une tolérance aux pannes maximales.

Exigences de capacité des nœuds :

Le preset d'anti-affinité hard exige que vous disposiez de suffisamment de nœuds dans votre cluster pour satisfaire le nombre de réplicas souhaité. Si votre cluster ne dispose pas de suffisamment 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 réplicas avec l'anti-affinité stricte 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.

Topologie de l'application​

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

Recommandations générales​

Considérations sur le scan des container registries​

Considérations sur les check runs​

Considérations sur le scan Slack​

Considérations sur le scan des fichiers binaires​

Considérations sur le scan des package registries​

Premium Scan Retry Worker​

Considérations sur la mise à l'échelle du ML Secret Engine​

ClickHouse​

Analytics​

Small​

Composants système de base​

Scans historiques (jusqu'à 5 Go)​

Scans en temps réel (jusqu'à 500 push/h)​

API publique (jusqu'à 1k requêtes/h)​

Dashboard (jusqu'à 200 utilisateurs actifs)​

Machine learning (jusqu'à 500 événements/h)​

Scans historiques et scans en temps réel pour les container registries​

Scans historiques pour Slack​

Scans historiques pour Sharepoint / OneDrive​

Scan des package registries​

Medium​

Composants système de base​

Scans historiques (jusqu'à 10 Go)​

Scans en temps réel (jusqu'à 1k push/h)​

API publique (jusqu'à 25k requêtes/h)​

Dashboard (jusqu'à 500 utilisateurs actifs)​

Machine learning (jusqu'à 1k événements/h)​

Scans historiques et scans en temps réel pour les container registries​

Scans historiques pour Slack​

Scans historiques pour Sharepoint / OneDrive​

Scan des package registries​

Large​

Composants système de base​

Scans historiques (jusqu'à 15 Go)​

Scans en temps réel (jusqu'à 2k push/h)​

API publique (jusqu'à 50k requêtes/h)​

Dashboard (jusqu'à 1k utilisateurs actifs)​

Machine learning (jusqu'à 2k événements/h)​

Scans historiques et scans en temps réel pour les container registries​

Scans historiques pour Slack​

Scans historiques pour Sharepoint / OneDrive​

Scan des package registries​

Configurer les paramètres de mise à l'échelle​

Installation basée sur KOTS​

Installation basée sur Helm​

Réglage supplémentaire du stockage éphémère​

Nœuds « On Demand » avec des disques nvme​

Generic Ephemeral Inline Volumes​

Stockage éphémère pour les analytics in-app​

Planification par affinité de nœud​

Anti-affinité de pod​

Was this page helpful?

Il manque quelque chose ?

Abonnez-vous à notre newsletter

Topologie de l'application

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

Recommandations générales

Considérations sur le scan des container registries

Considérations sur les check runs

Considérations sur le scan Slack

Considérations sur le scan des fichiers binaires

Considérations sur le scan des package registries

Premium Scan Retry Worker

Considérations sur la mise à l'échelle du ML Secret Engine

ClickHouse

Analytics

Small

Composants système de base

Scans historiques (jusqu'à 5 Go)

Scans en temps réel (jusqu'à 500 push/h)

API publique (jusqu'à 1k requêtes/h)

Dashboard (jusqu'à 200 utilisateurs actifs)

Machine learning (jusqu'à 500 événements/h)

Scans historiques et scans en temps réel pour les container registries

Scans historiques pour Slack

Scans historiques pour Sharepoint / OneDrive

Scan des package registries

Medium

Composants système de base

Scans historiques (jusqu'à 10 Go)

Scans en temps réel (jusqu'à 1k push/h)

API publique (jusqu'à 25k requêtes/h)

Dashboard (jusqu'à 500 utilisateurs actifs)

Machine learning (jusqu'à 1k événements/h)

Scans historiques et scans en temps réel pour les container registries

Scans historiques pour Slack

Scans historiques pour Sharepoint / OneDrive

Scan des package registries

Large

Composants système de base

Scans historiques (jusqu'à 15 Go)

Scans en temps réel (jusqu'à 2k push/h)

API publique (jusqu'à 50k requêtes/h)

Dashboard (jusqu'à 1k utilisateurs actifs)

Machine learning (jusqu'à 2k événements/h)

Scans historiques et scans en temps réel pour les container registries

Scans historiques pour Slack

Scans historiques pour Sharepoint / OneDrive

Scan des package registries

Configurer les paramètres de mise à l'échelle

Installation basée sur KOTS

Installation basée sur Helm

Réglage supplémentaire du stockage éphémère

Nœuds « On Demand » avec des disques nvme

Generic Ephemeral Inline Volumes

Stockage éphémère pour les analytics in-app

Planification par affinité de nœud

Anti-affinité de pod