Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Dies ist eine unveröffentlichte Dokumentation für Admission Controller 1.34-dev.

SUSE Security Admission Controller in einer großangelegten Umgebung

Dieser Abschnitt beschreibt eine reale Implementierung von SUSE Security Admission Controller in einer anspruchsvollen, großangelegten Umgebung. Es wird veranschaulicht, wie man Admission Controller für hohe Verfügbarkeit und Leistung konfiguriert und was man unter hoher Last erwarten kann.

Wenn Sie weitere Tipps sehen möchten, wie Sie Admission Controller in der Produktion ausführen können, werfen Sie einen Blick in die Produktionsimplementierungen Dokumentation.

Umgebungsübersicht

Die Infrastruktur besteht aus etwa 20 Kubernetes-Clustern. Die größten dieser Cluster zeichnen sich durch erhebliche Größe und Ressourcenvolumen aus:

  • Knoten: ~400

  • Namespaces: ~4.000

  • Verwaltete Ressourcen:

    • Pods: 10.000

    • RoleBindings: 13.000

    • Ingresses: 12.000

    • Implementierungen: 8.000

    • Services: 13.000

Die Admission Controller-Konfiguration

Um den Anforderungen dieser Umgebung gerecht zu werden, wird Admission Controller mit einem Fokus auf Arbeitslastisolierung und hohe Verfügbarkeit konfiguriert.

  • Richtliniendurchsetzung: 22 ClusterAdmissionPolicies werden in den Clustern durchgesetzt, ohne Namespace-spezifische AdmissionPolicies.

  • PolicyServer Architecture: Zwei separate PolicyServer Implementierungen werden verwendet, um Arbeitslasten zu isolieren:

    • Eine PolicyServer ist ausschließlich für kontextabhängige Richtlinien vorgesehen.

    • Eine zweite PolicyServer behandelt alle anderen, nicht kontextabhängigen Richtlinien.

  • Skalierbarkeit und Ressourcen:

    • Reproduktionen: Jede PolicyServer Implementierung läuft mit 15 Replikaten, um das hohe Anfragevolumen zu bewältigen.

    • Ressourcenzuweisung: Jedes Replikat erhält 300 MB Speicher und 4 CPU-Kerne.

Leistungskennzahlen

Diese Konfiguration verwaltet erfolgreich eine hohe Rate von Zulassungsanfragen und hält dabei eine vorhersehbare Leistung aufrecht.

  • Durchsatz der Zulassungsanfragen: Die Cluster verarbeiten bis zu 300 Zulassungsanfragen pro Sekunde (einschließlich Webhook-Validierungen und Audit-Scans).

  • Richtlinienlatenz:

    • Typische Latenz: Kontextabhängige Richtlinien benötigen in der Regel etwa 500 ms zur Ausführung.

    • Zeitüberschreitungen: In dieser Umgebung mit hoher Durchsatzrate sind die Webhook-Zeitüberschreitungen auf 2,5 Sekunden konfiguriert, während die PolicyServer Zeitüberschreitung auf 10 Sekunden eingestellt ist. Während die meisten Anfragen schnell sind, ist die Infrastruktur so aufgebaut, dass sie gelegentliche langsame Operationen bewältigen kann, ohne die Stabilität des API-Servers zu gefährden.

Leistung des Audit-Scanners

Der Audit-Scanner wird genutzt, um die kontinuierliche Einhaltung über die Vielzahl von Ressourcen sicherzustellen.

  • Häufigkeit: Alle 4 Stunden wird ein clusterweites Audit durchgeführt.

  • Konfiguration: Der Audit-Job ist für maximale Parallelität optimiert, um die Laufzeit zu reduzieren:

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

  • Audit-Dauer: Selbst im größten Cluster mit Zehntausenden von Ressourcen wird ein vollständiger Audit-Job in