Konzepte: Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS)

Bei der Beantwortung der Frage "Wie kann ich Kubernetes für mehrere Mandanten konfigurieren?", müssen Architekten zunächst die verfügbaren konzeptionellen Grenzen und Isolationsmodelle verstehen. Multi-Mandantschaft in AKS ist die Praxis, mehrere isolierte Workloads auszuführen, die zu verschiedenen Teams, Anwendungen oder Kunden gehören, auf einem freigegebenen Kubernetes-Cluster. In diesem Artikel werden die Kernkonzepte und Architekturmodelle für mehrinstanzenfähige Azure Kubernetes Service (AKS) erläutert.

Tip

Was sind die drei Mandantenmodelle in AKS? AKS-Mehrinstanzenfähigkeit nutzt ein Isolationsspektrum mit drei gängigen Modellen: Namespace-Isolation, Knotenpool-Isolation und ein Cluster pro Mandant. Die Isolierung auf Namespace-Ebene eignet sich am besten für vertrauenswürdige interne Teams und maximale Kosteneffizienz, die Isolierung von Knotenpools bietet eine stärkere Trennung von Workloads bei moderatem Overhead, und ein Cluster pro Mandant bietet die stärkste Isolation für nicht vertrauenswürdige oder stark regulierte Szenarien.

Schrittweise Implementierungsanweisungen und YAML-Manifeste finden Sie im Begleithandbuch: Bewährte Methoden für mehrinstanzenfähige Mandanten in AKS.

Warum Mehrinstanzenfähigkeit auf AKS?

Mit mehreren Mandanten können mehrere Teams, Anwendungen oder Kunden einen einzelnen Kubernetes-Cluster gemeinsam nutzen. Der Hauptgrundgrund für mehrinstanzenfähige Mandanten auf AKS ist Kosteneffizienz und betrieblicher Maßstab.

Das Ausführen eines dedizierten Clusters für jede Anwendung oder jedes Team führt zu erheblicher Ressourcenfragmentierung, Leerlauf-Rechenkapazität und multipliziertem Steuerungsebenenaufwand. Durch die Konsolidierung von Workloads in Multimandantenclustern maximieren Organisationen die Ressourcenauslastung und verringern die Cloud-Ausgaben. Operationally, Multi-Tenancy reduziert die Flottengröße, was bedeutet, dass Plattformteams weniger Cluster zum Patchen, Aktualisieren, Überwachen und Sichern haben, wodurch die Lebenszyklusverwaltung optimiert wird.

Was ist der Unterschied zwischen weichem und hartem Mandanten?

Kubernetes ist kein mehrinstanzenfähiges System. Um eine Mehrmandantschaft zu erreichen, müssen Sie entweder ein "weiches" oder ein "hartes" Isolationsmodell basierend auf der Vertrauensebene zwischen Mandanten entwerfen.

Der Unterschied zwischen weicher und harter Multi-Tenancy in Kubernetes liegt primär im Vertrauensmodell und den daraus resultierenden Isolationsanforderungen. Weiche Multi-Mandantenfähigkeit geht von vertrauenswürdigen internen Mandanten aus und konzentriert sich darauf, unbeabsichtigte Beeinträchtigungen durch logische Mechanismen wie Namespaces, RBAC und Quoten zu verhindern. Strikte Mandantentrennung setzt voraus, dass zwischen Mandanten wenig oder gar kein Vertrauen besteht, und erfordert stärkere Isolierungsmechanismen, um das Risiko böswilliger Zugriffe, lateraler Bewegungen und der Offenlegung von Daten zu verringern.

Modell	Vertrauensebene	Ziel	Anwendungsfall	Beispielszenarien
Weiche Mehrinstanzenfähigkeit	Hohe Vertrauensstellung zwischen internen Mandanten	Verhindern Sie unbeabsichtigte Beeinträchtigungen, Ressourcenknappheit und Konfigurationskonflikte	Interne Plattformumgebungen, in denen Teams die Infrastruktur teilen	Mehrere Produktteams in einer Organisation teilen einen AKS-Cluster für Entwicklungs-/Test- und interne Dienste
Strikte Multi-Tenancy	Geringes oder kein Vertrauen zwischen Mandanten	Verhindern bösartiger Angriffe, lateraler Bewegungen und Datenexfiltration	Hosting für externe Kunden und regulierte Workloads	SaaS-Anbieter, der kundenspezifische Workloads hostet, bei denen die Mandantenisolation eine Sicherheits- und Complianceanforderung ist

Das Isolationsspektrum

Mehrinstanzenfähigkeit auf AKS ist keine binäre Wahl; es ist auf einem Spektrum vorhanden. Während Sie sich über das Spektrum bewegen, erhöht sich die Isolation, aber dies führt zu betrieblicher Komplexität und Kosten. Dieses Spektrum bildet die strukturierende Wirbelsäule für das Multimandantenclusterdesign:

• Namespace-Isolation (logisch): Mandanten teilen sich dieselben Knotenpools und dieselbe Control Plane, sind jedoch logisch durch Kubernetes-Namespaces voneinander getrennt. Dies ist die Grundlage von Soft-Multi-Tenancy.
• Knotenpoolisolation (Physische Berechnung):Mandanten teilen die Steuerungsebene, weisen jedoch dedizierte Arbeitsknoten zu. Dies verbessert die Trennung der Workloads und die Abmilderung von Noisy-Neighbor-Effekten, stellt jedoch keine vollständige Mandantenisolierung dar, da Control-Plane- und Cluster-Komponenten weiterhin gemeinsam genutzt werden.
• Cluster pro Tenant (vollständig physisch getrennt): Tenants sind vollständig voneinander isoliert und verfügen jeweils über eine eigene AKS-Kontrollebene und Datenebene. Dies ist die ultimative Form der strikten Mandantentrennung, bei der die gemeinsame Nutzung auf Kubernetes-Ebene effektiv zugunsten der Isolierung auf Azure-Ebene umgangen wird.

AKS-Grundbausteine für Mehrmandantenfähigkeit

AKS bietet eine Reihe nativer und in Azure integrierter Grundbausteine zur Durchsetzung des Isolationsspektrums.

• Microsoft Entra ID: Bietet eine zentrale Identitäts- und Zugriffsverwaltung für die Authentifizierung von Benutzern und automatisierten Systemen für die Kubernetes-API.
• Azure RBAC: Ordnet Microsoft Entra ID Identitäten Kubernetes-Berechtigungen zu, um sicherzustellen, dass Mandanten nur auf ihre autorisierten Ressourcen zugreifen können.
• Verwaltete Namespaces: Bietet logische Abgrenzungen innerhalb des Clusters, um Mandantenressourcen zu gruppieren, Kontingente anzuwenden und den Zugriffsbereich festzulegen.
• Azure Policy / Gatekeeper: Erzwingt zentralisierte Compliance- und Governanceregeln im gesamten Cluster, um zu verhindern, dass Mandanten unsichere oder nicht autorisierte Konfigurationen bereitstellen.
• Azure CNI: Bietet systemeigene virtuelle Netzwerkintegration für AKS-Netzwerke und unterstützt die Segmentierung des Mandantendatenverkehrs mit Netzwerkrichtliniensteuerelementen. Das Pod-IP-Verhalten hängt vom ausgewählten CNI-Modus ab (z. B. Überlagerung oder Pod-Subnetz).
• Azure Container Networking Services (ACNS) Cilium L7: Bietet leistungsstarke, eBPF-basierte Netzwerkrichtlinien und Layer 7-Datenverkehrsfilterung, um den Mandantennetzwerkdatenverkehr streng zu isolieren.
• Workload-Identität: Ermöglicht es einzelnen Pods, sich sicher für externe Azure-Dienste mithilfe der Verbundidentität zu authentifizieren, wodurch gemeinsame geheime Schlüssel zwischen Mandanten eliminiert werden.

Zuordnen von Isolationsebenen über Ebenen hinweg

Um eine sichere Mehrinstanzenarchitektur zu erstellen, müssen Sie die AKS-Grundtypen auf drei verschiedene Ebenen der Clusterumgebung anwenden.

Flugzeug	Description	Angewendete AKS-Grundtypen
Steuerungsebene	Sichern des Zugriffs auf den Kubernetes-API-Server und logische Grenzen.	Microsoft Entra ID, Azure RBAC, verwaltete Namespaces
Datenebene	Absicherung von Netzwerkverkehr, Rechenausführung und Abgrenzungen auf Knotenebene.	Azure CNI, ACNS Cilium L7, Knotenpools
Ressourcenebene	Steuerung von Rechenressourcennutzung, externem Zugriff und Konfigurationskonformität.	Azure Policy, Workload-Identität

Welches Isolationsmodell sollten Sie auswählen?

Verwenden Sie die folgende Matrix, um zu bestimmen, welcher Punkt auf dem Isolationsspektrum ihren Organisationsanforderungen am besten entspricht.

Isolationsmodell	Sicherheitsstufe	Kosteneffizienz	Betriebliche Komplexität	Am besten geeignet für
Namespace pro Mandant	Niedrig bis Mittel (logisch)	Hoch (Maximale Freigabe)	Niedrig (einzelner zu verwaltender Cluster)	Interne Teams, Entwicklungs-/Testumgebungen, weiche Mehrmandantschaft.
Node-pool-per-tenant	Hoch (isolierte Rechenleistung)	Mittel (gemeinsam genutzte Steuerungsebene)	Mittel (Verwalten von Taints/Tolerations)	Interne und externe Workloads, die eine stärkere Computetrennung benötigen, während sie eine Steuerungsebene teilen; nicht ideal für feindliche Zero-Trust-Mandantschaft.
Cluster pro Mandant	Höchste (physisch)	Niedrig (hoher Verwaltungsaufwand)	Hoch (Flottenmanagement erforderlich)	Feindselige Mandanten, externe Unternehmenskunden, Nullvertrauen.

Wann jedes Modell verwendet werden soll

• Verwenden Sie einen Namespace pro Mandant, wenn Mandanten intern oder vertrauenswürdig sind, Kosteneffizienz Priorität hat und logische Isolationsmechanismen ausreichen.
• Verwenden Sie node-pool-per-tenant, wenn Sie eine stärkere Rechenisolierung und geringere Auswirkungen durch „Noisy Neighbors“ benötigen und dabei weiterhin eine AKS-Steuerebene gemeinsam nutzen.
• Verwenden Sie Cluster pro Mandant, wenn Mandanten nicht vertrauenswürdig sind, gesetzliche Grenzen streng sind oder Ihr Risikomodell eine minimale gemeinsame Infrastruktur erfordert.

Nächste Schritte

Nachdem Sie nun die konzeptionellen Modelle und Grundtypen für die Mehrinstanzenfähigkeit verstanden haben, fahren Sie mit dem Implementierungshandbuch fort, um diese Konzepte auf Ihren Cluster anzuwenden.

• Bewährte Methoden für mehrinstanzenfähige Mandanten in AKS

Fazit

• Multimandantschaft in Azure Kubernetes Service (AKS) ist die Praxis, mehrere isolierte Mandantenarbeitslasten in gemeinsam genutzter Kubernetes-Infrastruktur auszuführen, um Kosten zu reduzieren und Vorgänge zu vereinfachen.
• Ein Namespace pro Mandant ist das kosteneffizienteste Modell für vertrauenswürdige interne Workloads, da es die gemeinsame Nutzung der Infrastruktur maximiert und gleichzeitig logische Abgrenzungen anwendet.
• Ein Knotenpool pro Mandant verbessert die Trennung der Rechenressourcen und die Kontrolle über Noisy-Neighbor-Effekte, teilt sich jedoch weiterhin die AKS-Kontrollebene und andere Komponenten auf Cluster-Ebene.
• Cluster pro Mandant bietet die stärkste Mandantenisolation für Szenarien ohne Vertrauen und streng regulierte Szenarien, erfordert jedoch höhere Kosten und mehr Betriebsaufwand.