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 KOTS : permettent la configuration des réplicas, requêtes/limites CPU et mémoire pour les principaux deployments/pods.
Installations Helm : fournissent une personnalisation plus complète, incluant :
- La création de nouvelles classes de workers.
- La personnalisation d'autres types de ressources comme l'ephemeral storage, huge pages, etc.
- La définition de nodeSelector, tolerations et configurations supplémentaires.

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

Scaling pour GitGuardian : scans historiques, scans temps réel, API publique et ML Secret Engine

Lors de l'utilisation de GitGuardian pour monitorer des dépôts, il est crucial de scaler les ressources de manière appropriée pour les scans historiques, scans temps réel et requêtes d'API publique. Cela garantit un traitement efficace et opportun quelle que soit la charge. Ces recommandations s'appliquent uniquement aux installations sur cluster existant.

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 pouvez diminuer les réplicas et ressources de ces pods.

Lors d'un scan historique sur un dépôt git, GitGuardian clone le dépôt sur l'ephemeral storage du pod et parcourra toutes les branches et commits à la recherche de secrets potentiels. Le scan complet est réalisé 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 de scans historiques pourront être réalisés en parallèle. Lors du dimensionnement de vos nœuds, gardez à l'esprit que chaque pod doit avoir suffisamment d'ephemeral storage et de mémoire pour s'exécuter. Pour améliorer les performances et réduire les durées de scan, il est recommandé d'utiliser des disques SSD pour l'ephemeral storage.

Pour les scans temps réel, ceux-ci sont déclenchés par les événements Push envoyés par le VCS à GitGuardian. Ces scans s'achèvent généralement en moins d'une seconde et devraient toujours être sous 3 secondes. Pour gérer les pics de pushs, vous pourriez vouloir augmenter le nombre de pods worker-worker qui traitent les scans 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 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 gèrent les requêtes internes pour le tableau de bord, 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 pendant les tâches étendues.

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 pour assurer un scan et des interactions efficaces.

Pour éviter le scaling manuel, vous pourriez être intéressé par l'autoscaling pour vous adapter dynamiquement à la charge, voir Autoscaling.

Considérations pour le scan de Container Registry

Configuration des réplicas : par défaut, les réplicas container registry sont à 0, ce qui fait que le scan de container registry se rabat sur les workers de scan. Il est recommandé de configurer cela à un nombre de réplicas non nul pour des performances dédiées de scan de container registry.
Utilisation du cache : consomme de la mémoire Redis et du stockage de base de données significatifs (plusieurs Go). Envisagez de scaler Redis ou d'utiliser une instance dédiée.
Pression sur la base de données : les pods scanner peuvent mettre la base sous pression, surtout pendant les scans initiaux. Scalez avec précaution avec les nombres minimum de réplicas recommandés.
Coûts de transfert de données : scanner de grands registres 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 scaler vers un scan complet.

Considérations pour Check Runs

Configuration des réplicas : par défaut, les réplicas de check runs sont à 0, ce qui fait que le traitement des check runs est géré par worker-worker. Si vous rencontrez de gros volumes 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 queue check_run de worker-worker.

Considérations pour le scan Slack

Configuration des réplicas : par défaut, les réplicas des scanners Slack sont à 0, ce qui fait que le scan de registre Slack se rabat sur les workers de scan. Il est recommandé de configurer cela à un nombre de réplicas non nul pour des performances dédiées de scan de registre Slack. Configurer un grand nombre de réplicas n'est pas nécessaire, car le scan Slack est restreint à un canal à la fois en raison des rate limits de l'API Slack.

Considérations pour le scan de fichiers binaires

Le scan de fichiers binaires n'est actuellement disponible que pour Microsoft Sharepoint Online et Microsoft OneDrive. Lors d'un scan historique sur des sources contenant des fichiers binaires, les fichiers seront téléchargés localement sur l'ephemeral storage du pod. Pour améliorer les performances et réduire les durées de scan, il est recommandé d'utiliser des disques SSD pour l'ephemeral storage et de provisionner suffisamment d'ephemeral storage pour ces pods (100 Go).

Considérations pour le scan de Package Registry

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 à 0.
Utilisation du cache : l'instance Redis commit-cache est utilisée pour le scan JFrog Package Registries. Si commit-cache n'est pas configuré, l'instance Redis principale sera utilisée à la place.

Considérations de scaling du ML Secret Engine

Le ML Secret Engine nécessite une allocation de ressources spécifique et des considérations de scaling. Pour des instructions 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 architecture amd64. Les instances CPU-only sont bien plus économiques 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 le Horizontal Pod Autoscaling (HPA) pour le worker ml-api-priority.

Analytics (en bêta)

Advanced Analytics nécessite des ressources additionnelles lorsqu'activé. Le job s'exécute une fois par jour et a la configuration de ressources par défaut suivante :

Demande mémoire : 8 Go
Limite mémoire : 12 Go
Augmentation de l'usage de base : 15-20 % (minimum 5-6 Go)

Planifiez votre capacité de cluster et de base en conséquence.

Small

Composants système principaux

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

Composant	Capacité requise	Nombre
Nœuds de calcul Kubernetes	4 vCPU 16 Go mémoire 50 Go d'ephemeral storage, 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'ephemeral storage, 250 Go d'espace disque persistant	5

Si vous prévoyez d'utiliser le global ephemeral storage, ajoutez 20 Go à l'espace disque persistant sur chacun de vos nœuds de calcul Kubernetes.

Scans historiques (jusqu'à 5 Go)

Composant	Capacité requise	Nombre
Pods `worker-scanners`	Memory request and limit: 6 GB	4

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

Composant	Capacité requise	Nombre
Pods `worker-worker`	Default resource settings	2

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

Composant	Capacité requise	Nombre
Pods `webapp-public_api`	Default resource settings	2
Pods `nginx` (dashboard et API)	Default resource settings	2

Tableau de bord (jusqu'à 200 utilisateurs actifs)

Composant	Capacité requise	Nombre
Pods `webapp-internal_api`	Default resource settings	2
Pods `webapp-internal_api_long`	Default resource settings	2

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

Composant	Capacité requise	Nombre
Pods `ml-secret-engine`	Default resource settings	1
Pods `worker-ml-api-priority`	Default resource settings	1

Scans historiques et temps réel pour Container Registries

Composant	Capacité requise	Nombre
Pods `worker-container-registries`	Memory request and limit: 4 GB	2

Scans historiques pour Slack

Composant	Capacité requise	Nombre
Pods `worker-scanners-slack`	Default resource settings	1

Scans historiques pour Sharepoint / OneDrive

Composant	Capacité requise	Nombre
Pods `worker-scanners-ods-highdisk`	Default resource settings	1
Pods `apacheTika`	Default resource settings	1

Scan de Package Registry

Composant	Capacité requise	Nombre
Pods `worker-scanners-db-less`	Default resource settings	1

Medium

Composants système principaux

Pour jusqu'à 10000 dépôts, gérant jusqu'à 1000 pushs par heure et jusqu'à 25000 requêtes API par heure :

Composant	Capacité requise	Nombre
Nœuds de calcul Kubernetes	8 vCPU 32 Go mémoire 50 Go d'ephemeral storage, 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'ephemeral storage, 340 Go d'espace disque persistant	7

Si vous prévoyez d'utiliser le global ephemeral storage, ajoutez 120 Go à l'espace disque persistant sur chacun de vos nœuds de calcul Kubernetes.

Scans historiques (jusqu'à 10 Go)

Composant	Capacité requise	Nombre
Pods `worker-scanners`	Memory request and limit: 11 GB	12

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

Composant	Capacité requise	Nombre
Pods `worker-worker`	Default resource settings	4

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

Composant	Capacité requise	Nombre
Pods `webapp-public_api`	Default resource settings	4
Pods `nginx` (dashboard et API)	Default resource settings	2

Tableau de bord (jusqu'à 500 utilisateurs actifs)

Composant	Capacité requise	Nombre
Pods `webapp-internal_api`	Default resource settings	4
Pods `webapp-internal_api_long`	Default resource settings	2

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

Composant	Capacité requise	Nombre
Pods `ml-secret-engine`	Default resource settings	2
Pods `worker-ml-api-priority`	Default resource settings	2

Scans historiques pour Slack

Composant	Capacité requise	Nombre
Pods `worker-scanners-slack`	Default resource settings	2

Scans historiques pour Sharepoint / OneDrive

Composant	Capacité requise	Nombre
Pods `worker-scanners-ods-highdisk`	Memory request, limit: 4GiB, 6GiB	4
Pods `apacheTika`	Default resource settings	2

Scan de Package Registry

Composant	Capacité requise	Nombre
Pods `worker-scanners-db-less`	Default resource settings	2

Large

Composants système principaux

Pour jusqu'à 40000 dépôts, gérant jusqu'à 2000 pushs par heure et jusqu'à 50000 requêtes API par heure :

Composant	Capacité requise	Nombre
Nœuds de calcul Kubernetes	8 vCPU 64 Go mémoire 50 Go d'ephemeral storage, 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'ephemeral storage, 470 Go d'espace disque persistant	9

Si vous prévoyez d'utiliser le global ephemeral storage, ajoutez 160 Go à l'espace disque persistant sur chacun de vos nœuds de calcul Kubernetes.

Scans historiques (jusqu'à 15 Go)

Composant	Capacité requise	Nombre
Pods `worker-scanners`	Memory request and limit: 16 GB	16
Pods `worker-scanners-ods`	Memory request and limit: 4 GB	10

Définissez des pods worker-scanners-ods spécifiques notamment si vous intégrez de larges instances Slack ou MS Teams (5k+ canaux). Il est préférable d'isoler ces workloads. Sinon, il est correct de partager la même queue et workers avec le workload worker-scanners.

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

Composant	Capacité requise	Nombre
Pods `worker-worker`	Default resource settings	8

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

Composant	Capacité requise	Nombre
Pods `webapp-public_api`	Default resource settings	6
Pods `nginx` (dashboard et API)	Default resource settings	2

Tableau de bord (jusqu'à 1k utilisateurs actifs)

Composant	Capacité requise	Nombre
Pods `webapp-internal_api`	Default resource settings	6
Pods `webapp-internal_api_long`	Default resource settings	2

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

Composant	Capacité requise	Nombre
Pods `ml-secret-engine`	Default resource settings	2
Pods `worker-ml-api-priority`	Default resource settings	2

Scans historiques pour Slack

Composant	Capacité requise	Nombre
Pods `worker-scanners-slack`	Default resource settings	2

Scans historiques pour Sharepoint / OneDrive

Composant	Capacité requise	Nombre
Pods `worker-scanners-ods-highdisk`	Memory request, limit: 4GiB, 6GiB	4
Pods `apacheTika`	Default resource settings	2

Scan de Package Registry

Composant	Capacité requise	Nombre
Pods `worker-scanners-db-less`	Default resource settings	4

Configurer les paramètres de scaling

Vous pouvez dimensionner votre infrastructure selon les recommandations ci-dessus mais vous pouvez aussi utiliser l'autoscaling Kubernetes pour vous adapter dynamiquement à la charge, voir Autoscaling.

Installation via KOTS

attention

Assurez-vous de mettre à jour le RBAC application Kubernetes en ajoutant la permission patch à la ressource servicemonitors.

Naviguez sous Config > Scaling dans la console d'administration KOTS, vous aurez accès aux options de scaling des workers.

Front replicas : scale les pods nginx.
API replicas : scale les pods api.
Workers replicas : scale les pods workers (incluant les pods scanners)

info

Modifier ces valeurs n'affecte pas la stratégie de mise à niveau rolling.
Les workers sont configurés pour se répartir sur les nœuds s'il y en a plusieurs. 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 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 à 0)

Pour des instructions de configuration détaillées, prérequis des workers et é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 via Helm

Personnalisez les applications Helm via 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 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

Voir la documentation de référence des values pour plus de détails.

Recommandation de scaling

Pour des performances optimales, envisagez de scaler les pods suivants à un minimum de 2 réplicas chacun : hook, internal-api-long, public-api, worker-email, worker-long et worker-worker.

Tuning supplémentaire de l'ephemeral storage

info

Disponible uniquement pour les installations Helm.

Dans certains scénarios, optimiser les configurations d'ephemeral storage devient essentiel pour atteindre de meilleures performances et stabilité, particulièrement pour les workers scanners. Cette section présente les configurations supplémentaires pour le fine-tuning de l'ephemeral storage, en se concentrant sur l'utilisation de nœuds « On Demand » avec disques nvme et l'intégration des Generic Ephemeral Inline Volumes.

Nœuds « On Demand » avec disques nvme

Dans l'exemple suivant, nous spécifions que les workers scanners n'utilisent que des VM « On Demand » avec disques nvme et que l'ephemeral storage 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 Helm charts. Cette fonctionnalité facilite le provisionnement dynamique et la récupération du stockage, particulièrement bénéfique lorsque l'on traite de petites limites d'ephemeral storage. Notez que c'est supporté à 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

Node Affinity Scheduling

Utilisez le paramètre nodeSelector dans les values Helm pour planifier les pods worker sur des nœuds 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

Pod Anti-Affinity

Le Helm chart de GitGuardian fournit des paramètres configurables d'anti-affinity de pods pour contrôler comment les pods sont distribués sur les nœuds de votre cluster Kubernetes. Cette fonctionnalité vous permet d'optimiser la disponibilité et l'utilisation des ressources en s'assurant 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 workers. Cette préférence d'anti-affinity soft tente de distribuer les pods sur les nœuds mais ne garantit pas une distribution uniforme. Le scheduler essaiera de placer les pods sur différents nœuds quand c'est possible, mais planifiera quand 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 impose des règles strictes d'anti-affinity qui assurent que les pods sont uniformément distribués sur :

Les zones de disponibilité (clé topologie : topology.kubernetes.io/zone)
Les nœuds individuels (clé topologie : kubernetes.io/hostname)

Pour activer le hard pod anti-affinity 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, fournissant une distribution maximale et une tolérance aux pannes.

Prérequis de capacité de nœuds :

Le preset d'anti-affinity hard nécessite que vous ayez suffisamment de nœuds dans votre cluster pour satisfaire le nombre désiré de réplicas. Si votre cluster n'a pas assez de nœuds pour accueillir tous les pods avec les règles strictes d'anti-affinity, certains pods resteront en état « Pending » jusqu'à ce que des nœuds additionnels deviennent disponibles. Par exemple, si vous configurez 10 réplicas avec hard anti-affinity mais n'avez que 8 nœuds disponibles, 2 pods resteront en attente jusqu'à ce que plus de nœuds soient ajoutés au cluster.

Topologie de l'application​

Scaling pour GitGuardian : scans historiques, scans temps réel, API publique et ML Secret Engine​

Recommandations générales​

Considérations pour le scan de Container Registry​

Considérations pour Check Runs​

Considérations pour le scan Slack​

Considérations pour le scan de fichiers binaires​

Considérations pour le scan de Package Registry​

Considérations de scaling du ML Secret Engine​

Analytics (en bêta)​

Small​

Composants système principaux​

Scans historiques (jusqu'à 5 Go)​

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

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

Tableau de bord (jusqu'à 200 utilisateurs actifs)​

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

Scans historiques et temps réel pour Container Registries​

Scans historiques pour Slack​

Scans historiques pour Sharepoint / OneDrive​

Scan de Package Registry​

Medium​

Composants système principaux​

Scans historiques (jusqu'à 10 Go)​

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

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

Tableau de bord (jusqu'à 500 utilisateurs actifs)​

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

Scans historiques pour Slack​

Scans historiques pour Sharepoint / OneDrive​

Scan de Package Registry​

Large​

Composants système principaux​

Scans historiques (jusqu'à 15 Go)​

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

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

Tableau de bord (jusqu'à 1k utilisateurs actifs)​

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

Scans historiques pour Slack​

Scans historiques pour Sharepoint / OneDrive​

Scan de Package Registry​

Configurer les paramètres de scaling​

Installation via KOTS​

Installation via Helm​

Tuning supplémentaire de l'ephemeral storage​

Nœuds « On Demand » avec disques nvme​

Generic Ephemeral Inline Volumes​

Node Affinity Scheduling​

Pod Anti-Affinity​

Was this page helpful?

Il manque quelque chose ?

Voir notre feuille de route

S'abonner sur GitHub

Soumettre une demande

Statut de l’API

Abonnez-vous à notre newsletter

Topologie de l'application

Scaling pour GitGuardian : scans historiques, scans temps réel, API publique et ML Secret Engine

Recommandations générales

Considérations pour le scan de Container Registry

Considérations pour Check Runs

Considérations pour le scan Slack

Considérations pour le scan de fichiers binaires

Considérations pour le scan de Package Registry

Considérations de scaling du ML Secret Engine

Analytics (en bêta)

Small

Composants système principaux

Scans historiques (jusqu'à 5 Go)

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

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

Tableau de bord (jusqu'à 200 utilisateurs actifs)

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

Scans historiques et temps réel pour Container Registries

Scans historiques pour Slack

Scans historiques pour Sharepoint / OneDrive

Scan de Package Registry

Medium

Composants système principaux

Scans historiques (jusqu'à 10 Go)

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

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

Tableau de bord (jusqu'à 500 utilisateurs actifs)

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

Scans historiques pour Slack

Scans historiques pour Sharepoint / OneDrive

Scan de Package Registry

Large

Composants système principaux

Scans historiques (jusqu'à 15 Go)

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

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

Tableau de bord (jusqu'à 1k utilisateurs actifs)

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

Scans historiques pour Slack

Scans historiques pour Sharepoint / OneDrive

Scan de Package Registry

Configurer les paramètres de scaling

Installation via KOTS

Installation via Helm

Tuning supplémentaire de l'ephemeral storage

Nœuds « On Demand » avec disques nvme

Generic Ephemeral Inline Volumes

Node Affinity Scheduling

Pod Anti-Affinity