Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Il s'agit d'une documentation non publiée pour Admission Controller 1.34-dev.

SUSE Security Admission Controller dans un environnement à grande échelle

Cette section détaille un déploiement réel de SUSE Security Admission Controller dans un environnement exigeant à grande échelle. Elle illustre comment configurer Admission Controller pour une haute disponibilité et des performances, et ce à quoi s’attendre sous une charge importante.

Si vous souhaitez voir plus de conseils sur la façon d’exécuter Admission Controller en production, consultez la documentation sur les Déploiements en production.

Aperçu de l’environnement

L’infrastructure se compose d’environ 20 clusters Kubernetes. Les plus grands de ces clusters se caractérisent par une taille et un volume de ressources significatifs :

  • Noeuds : ~400

  • Namespaces : ~4 000

  • Ressources gérées :

    • Pods : 10 000

    • RoleBindings : 13 000

    • Ingresses : 12 000

    • Déploiements : 8 000

    • Services : 13 000

Admission Controller Configuration

Pour répondre aux exigences de cet environnement, Admission Controller est configuré avec un accent sur l’isolation des charges de travail et la haute disponibilité.

  • Application des stratégies : 22 ClusterAdmissionPolicies sont appliquées à travers les clusters, sans AdmissionPolicies spécifique à un espace de noms.

  • Architecture du serveur de stratégies : Deux déploiements PolicyServer distincts sont utilisés pour isoler les charges de travail :

    • Un PolicyServer est dédié exclusivement aux stratégies contextuelles.

    • Un second PolicyServer gère toutes les autres stratégies, non contextuelles.

  • Évolutivité et ressources :

    • Répliques : Chaque déploiement PolicyServer exécute 15 répliques pour gérer le volume élevé de demandes.

    • Allocation de ressources : Chaque réplique se voit attribuer 300 Mo de mémoire et 4 cœurs d’UC.

Métriques de performance

Cette configuration gère avec succès un taux élevé de demandes d’admission tout en maintenant des performances prévisibles.

  • Débit des demandes d’admission : Les clusters gèrent jusqu’à 300 demandes d’admission par seconde (y compris les validations de webhook et les analyses d’audit).

  • Latence des stratégies :

    • Latence typique : Les stratégies contextuelles prennent généralement environ 500 ms à exécuter.

    • Timeouts : Dans cet environnement à fort débit, les délais d’attente des webhooks sont configurés à 2,5 secondes, tandis que le délai d’attente PolicyServer est fixé à 10 secondes. Bien que la plupart des demandes soient rapides, l’infrastructure est conçue pour gérer des opérations occasionnellement lentes sans compromettre la stabilité du serveur API.

Performance du scanner d’audit

Le scanner d’audit est utilisé pour garantir une conformité continue à travers le grand nombre de ressources.

  • Fréquence : Un audit à l’échelle du cluster est effectué toutes les 4 heures.

  • Configuration : Le travail d’audit est optimisé pour un maximum de parallélisme afin de réduire le temps d’exécution :

--parallel-namespaces: "10"
--parallel-resources: "20"
--parallel-policies: "20"
--page-size: "1000"

  • Durée de l’audit : Même sur le plus grand cluster avec des dizaines de milliers de ressources, un travail d’audit complet se termine en