Bearbeiten

Freigeben über

Überlegungen zu Azure Kubernetes Service (AKS) für mehrinstanzenfähige Mandanten

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) vereinfacht die Bereitstellung eines verwalteten Kubernetes-Clusters in Azure, indem der Betriebsaufwand auf die Azure-Cloudplattform ausgelagert wird. Da AKS ein gehosteter Kubernetes-Dienst ist, verarbeitet Azure wichtige Aufgaben wie Integritätsüberwachung und Wartung sowie die Kontrollebene.

AKS-Cluster können über mehrere Mandanten hinweg in verschiedenen Szenarien und Möglichkeiten gemeinsam genutzt werden. In einigen Fällen können verschiedene Anwendungen im selben Cluster ausgeführt werden. In anderen Fällen können mehrere Instanzen derselben Anwendung im selben freigegebenen Cluster ausgeführt werden, eines für jeden Mandanten. Der Begriff Mehrinstanzenfähigkeit beschreibt häufig alle diese Freigabetypen. Kubernetes verfügt nicht über ein erstklassiges Konzept von Endbenutzern oder Mandanten. Dennoch bietet es mehrere Features, mit denen Sie unterschiedliche Mandantenanforderungen verwalten können.

In diesem Artikel werden einige der Features von AKS beschrieben, die Sie beim Erstellen von Mehrinstanzensystemen verwenden können. Allgemeine Anleitungen und bewährte Methoden für kubernetes Multitenancy finden Sie in der Kubernetes-Dokumentation unter Mandanten-.

Mehrinstanzentypen

Der erste Schritt, um zu bestimmen, wie ein AKS-Cluster für mehrere Mandanten freigegeben wird, besteht darin, die Muster und Tools auszuwerten, die zur Verwendung verfügbar sind. Im Allgemeinen fällt der Mehrinstanzenstand in Kubernetes-Clustern in zwei Hauptkategorien, aber viele Variationen sind immer noch möglich. Die Kubernetes Dokumentation beschreibt zwei häufige Anwendungsfälle für Mehrinstanzenfähigkeit: mehrere Teams und mehrere Kunden.

Mehrere Teams

Eine gemeinsame Form von Mehrinstanzenfähigkeit besteht darin, einen Cluster zwischen mehreren Teams innerhalb einer Organisation zu teilen. Jedes Team kann eine oder mehrere Lösungen bereitstellen, überwachen und betreiben. Diese Workloads müssen häufig miteinander und mit anderen internen oder externen Anwendungen kommunizieren, die sich auf demselben Cluster oder auf anderen Hostingplattformen befinden.

Darüber hinaus müssen diese Workloads mit Diensten kommunizieren, z. B. mit einer relationalen Datenbank, einem NoSQL-Repository oder einem Messagingsystem, die im selben Cluster gehostet werden oder als Plattform als Dienstdienste (PaaS) in Azure ausgeführt werden.

In diesem Szenario haben Mitglieder der Teams häufig direkten Zugriff auf Kubernetes-Ressourcen über Tools wie kubectl. Oder Mitglieder haben indirekten Zugriff über GitOps-Controller, z. B. Flux und Argo CD-oder über andere Arten von Releaseautomatisierungstools.

Weitere Informationen zu diesem Szenario finden Sie unter Mehrere Teams in der Kubernetes-Dokumentation.

Mehrere Kunden

Eine weitere gängige Form von Mehrinstanzenfähigkeit umfasst häufig einen Software as a Service (SaaS)-Anbieter. Oder ein Dienstanbieter führt für seine Kunden mehrere Instanzen einer Workload aus, die als separate Mandanten betrachtet werden. In diesem Szenario haben die Kunden keinen direkten Zugriff auf den AKS-Cluster, aber sie haben nur Zugriff auf ihre Anwendung. Darüber hinaus wissen sie nicht einmal, dass ihre Anwendung auf Kubernetes ausgeführt wird. Die Kostenoptimierung ist häufig ein kritisches Anliegen. Dienstanbieter verwenden Kubernetes-Richtlinien, z. B. Ressourcenkontingente und Netzwerkrichtlinien, um sicherzustellen, dass die Workloads stark voneinander isoliert sind.

Weitere Informationen zu diesem Szenario finden Sie unter Mehrere Kunden in der Kubernetes-Dokumentation.

Isolationsmodelle

Laut der Kubernetes-Dokumentationwird ein Multitenant Kubernetes-Cluster von mehreren Benutzern und Workloads gemeinsam genutzt, die häufig als Mandantenbezeichnet werden. Diese Definition umfasst Kubernetes-Cluster, die von verschiedenen Teams oder Abteilungen innerhalb einer Organisation gemeinsam verwendet werden. Sie enthält auch Cluster, die kundenspezifische Instanzen einer SaaS-Anwendungsfreigabe enthalten.

Cluster multitenancy is an alternative to managing many single-tenant dedicated clusters. Die Operatoren eines Multitenant Kubernetes-Clusters müssen Mandanten voneinander isolieren. Diese Isolation minimiert den Schaden, den ein kompromittierter oder böswilliger Mandant für den Cluster und andere Mandanten ausführen kann.

Wenn mehrere Benutzer oder Teams denselben Cluster mit einer festen Anzahl von Knoten teilen, kann ein Team mehr als seinen fairen Anteil an Ressourcen verwenden. Administratoren können Ressourcenkontingente verwenden, um dieses Problem zu beheben.

Basierend auf der Sicherheitsstufe, die isolation bereitstellt, können Sie zwischen weicher und harter Mehrinstanzenfähigkeit unterscheiden.

  • Soft Multitenancy ist in einem einzigen Unternehmen geeignet, in dem Mandanten unterschiedliche Teams oder Abteilungen sind, die einander vertrauen. In diesem Szenario soll isolation die Workloadintegrität garantieren, Clusterressourcen in verschiedenen internen Benutzergruppen koordinieren und vor möglichen Sicherheitsangriffen schützen.
  • Hard Multitenancy beschreibt Szenarien, in denen heterogene Mandanten nicht einander vertrauen, häufig aus Sicherheits- und Ressourcenfreigabeperspektiven.

Wenn Sie einen mehrinstanzenübergreifenden AKS-Cluster erstellen möchten, sollten Sie die Ebenen der Ressourcenisolation und den Multitenanten berücksichtigen, die Kubernetes bietet, einschließlich:

  • Cluster
  • Namespace
  • Knotenpool oder Knoten
  • Schote
  • Container

Darüber hinaus sollten Sie die Sicherheitsauswirkungen der Freigabe verschiedener Ressourcen für mehrere Mandanten berücksichtigen. Sie können beispielsweise die Anzahl der im Cluster benötigten Computer reduzieren, indem Sie Pods aus verschiedenen Mandanten auf demselben Knoten planen. Andererseits müssen Sie möglicherweise verhindern, dass bestimmte Arbeitslasten zusammengeführt werden. Sie können z. B. nicht vertrauenswürdigen Code außerhalb Ihrer Organisation nicht auf demselben Knoten wie Container ausführen, die vertrauliche Informationen verarbeiten.

Obwohl Kubernetes keine perfekte sichere Isolation zwischen Mandanten garantieren kann, bietet es Features, die für bestimmte Anwendungsfälle ausreichen könnten. Als bewährte Methode sollten Sie jeden Mandanten und seine Kubernetes-Ressourcen in ihre Namespaces unterteilen. Anschließend können Sie Kubernetes rollenbasierte Zugriffssteuerung (RBAC) und Netzwerkrichtlinien verwenden, um die Mandantenisolation zu erzwingen. Das folgende Diagramm zeigt beispielsweise das typische SaaS-Anbietermodell, das mehrere Instanzen derselben Anwendung auf demselben Cluster hostet, eines für jeden Mandanten. Jede Anwendung befindet sich in einem separaten Namespace.

Diagramm, das ein SaaS-Anbietermodell zeigt, das mehrere Instanzen derselben Anwendung auf demselben Cluster hostet.

Es gibt mehrere Möglichkeiten zum Entwerfen und Erstellen von Multitenant-Lösungen mit AKS. Jede dieser Methoden verfügt über einen eigenen Satz von Kompromissen in Bezug auf die Infrastrukturbereitstellung, Netzwerktopologie und Sicherheit. Diese Methoden wirken sich auf den Isolationsgrad, den Implementierungsaufwand, die betriebstechnische Komplexität und die Kosten aus. Sie können die Mandantenisolation in den Steuerelement- und Datenebenen basierend auf Ihren Anforderungen anwenden.

Steuerungsebenenisolation

Wenn Sie auf der Ebene der Steuerungsebene isoliert sind, stellen Sie sicher, dass unterschiedliche Mandanten nicht auf die Ressourcen der anderen Personen zugreifen können, z. B. Pods und Dienste. Außerdem können sie sich nicht auf die Leistung anderer Mandantenanwendungen auswirken. Weitere Informationen finden Sie unter Steuerungsebenenisolation in der Kubernetes-Dokumentation. Die beste Möglichkeit zum Implementieren der Isolation auf Ebene der Steuerungsebene besteht darin, die Arbeitsauslastung jedes Mandanten und seine Kubernetes-Ressourcen in einen separaten Namespace zu trennen.

Gemäß der Kubernetes-Dokumentationist ein Namespace eine Abstraktion, die Sie zur Unterstützung der Isolation von Ressourcengruppen innerhalb eines einzelnen Clusters verwenden. Sie können Namespaces verwenden, um Mandantenarbeitslasten zu isolieren, die einen Kubernetes-Cluster gemeinsam nutzen.

  • Namespaces ermöglichen es verschiedenen Mandantenworkloads, in ihrem eigenen virtuellen Arbeitsbereich zu existieren, ohne dass das Risiko besteht, dass sich die Arbeit des anderen beeinträchtigt. Separate Teams innerhalb einer Organisation können Namespaces verwenden, um ihre Projekte voneinander zu isolieren, da sie dieselben Ressourcennamen in verschiedenen Namespaces verwenden können, ohne dass das Risiko besteht, dass Namen überlappen.
  • RBAC-Rollen und Rollenbindungen sind Namespace-bezogene Ressourcen, mit denen Teams Mandantenbenutzer und Prozesse einschränken können, um nur in ihren Namespaces auf Ressourcen und Dienste zuzugreifen. Verschiedene Teams können Rollen definieren, um Listen mit Berechtigungen oder Fähigkeiten unter einem einzigen Namen zu gruppieren. Anschließend weisen sie diese Rollen Benutzerkonten und Dienstkonten zu, um sicherzustellen, dass nur die autorisierten Identitäten Zugriff auf die Ressourcen in einem bestimmten Namespace haben.
  • Ressourcenkontingente für CPU und Arbeitsspeicher sind namespaced-Objekte. Teams können sie verwenden, um sicherzustellen, dass Arbeitslasten, die denselben Cluster gemeinsam nutzen, stark vom Verbrauch von Systemressourcen isoliert sind. Mit dieser Methode kann sichergestellt werden, dass jede Mandantenanwendung, die in einem separaten Namespace ausgeführt wird, über die Ressourcen verfügt, die sie ausführen müssen, und lauten Nachbarproblemenvermeiden, was sich auf andere Mandantenanwendungen auswirken kann, die denselben Cluster gemeinsam nutzen.
  • Netzwerkrichtlinien Namespaceobjekte sind, die Teams übernehmen können, um zu erzwingen, welcher Netzwerkdatenverkehr für eine bestimmte Mandantenanwendung zulässig ist. Sie können Netzwerkrichtlinien verwenden, um unterschiedliche Workloads zu trennen, die denselben Cluster aus einer Netzwerkperspektive gemeinsam nutzen.
  • Teamanwendungen, die in unterschiedlichen Namespaces ausgeführt werden, können verschiedene Dienstkonten verwenden, um auf Ressourcen innerhalb desselben Clusters, externe Anwendungen oder verwaltete Dienste zuzugreifen.
  • Verwenden Sie Namespaces, um die Leistung auf Ebene der Steuerungsebene zu verbessern. Wenn Workloads in einem freigegebenen Cluster in mehreren Namespaces organisiert sind, weist die Kubernetes-API weniger Elemente auf, die beim Ausführen von Vorgängen durchsucht werden müssen. Diese Organisation kann die Latenz von Aufrufen für den API-Server verringern und den Durchsatz der Steuerungsebene erhöhen.

Weitere Informationen zur Isolation auf Namespaceebene finden Sie in der Kubernetes-Dokumentation in den folgenden Ressourcen:

Datenebenenisolation

Datenebenenisolation garantiert, dass Pods und Workloads unterschiedlicher Mandanten ausreichend voneinander isoliert sind. Weitere Informationen finden Sie unter Datenebenenisolation in der Kubernetes-Dokumentation.

Netzwerkisolation

Wenn Sie moderne, mikroservicesbasierte Anwendungen in Kubernetes ausführen, möchten Sie häufig steuern, welche Komponenten miteinander kommunizieren können. Standardmäßig können alle Pods in einem AKS-Cluster Datenverkehr ohne Einschränkungen senden und empfangen, einschließlich anderer Anwendungen, die denselben Cluster nutzen. Um die Sicherheit zu verbessern, können Sie Netzwerkregeln definieren, um den Datenverkehrsfluss zu steuern. Netzwerkrichtlinie ist eine Kubernetes-Spezifikation, die Zugriffsrichtlinien für die Kommunikation zwischen Pods definiert. Sie können Netzwerkrichtlinien verwenden, um die Kommunikation zwischen Mandantenanwendungen zu trennen, die denselben Cluster nutzen.

AKS bietet zwei Möglichkeiten zum Implementieren von Netzwerkrichtlinien:

  • Azure verfügt über seine Implementierung für Netzwerkrichtlinien, die als Azure-Netzwerkrichtlinien bezeichnet werden.
  • Calico-Netzwerkrichtlinien ist eine Open-Source-Netzwerk- und Netzwerksicherheitslösung, die von Tigeragegründet wurde.

Beide Implementierungen verwenden Linux-IPTables, um die angegebenen Richtlinien zu erzwingen. Netzwerkrichtlinien werden in Gruppen zulässiger und unzulässiger IP-Paare übersetzt. Diese Paare werden dann als IPTables-Filterregeln programmiert. Sie können Azure-Netzwerkrichtlinien nur mit AKS-Clustern verwenden, die mit dem Azure CNI-Netzwerk-Plug-In konfiguriert sind. Calico-Netzwerkrichtlinien unterstützen jedoch sowohl Azure CNI- als auch kubenet-. Weitere Informationen finden Sie unter Sicheren Datenverkehr zwischen Pods mithilfe von Netzwerkrichtlinien in Azure Kubernetes Service.

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Netzwerkisolation.

Speicherisolation

Azure bietet eine umfangreiche Sammlung von verwalteten PaaS-Datenrepositorys wie Azure SQL-Datenbank- und Azure Cosmos DB-sowie andere Speicherdienste, die Sie als persistente Volumes für Ihre Workloads verwenden können. Mandantenanwendungen, die auf einem freigegebenen AKS-Cluster ausgeführt werden, können eine Datenbank oder einen Dateispeicherfreigeben, oder sie können ein dediziertes Datenrepository und eine speicherressourceverwenden. Weitere Informationen zu verschiedenen Strategien und Ansätzen zum Verwalten von Daten in einem mehrinstanzenfähigen Szenario finden Sie unter Architekturansätze für Speicherung und Daten in multitenant-Lösungen.

Workloads, die auf AKS ausgeführt werden, können auch persistente Volumes zum Speichern von Daten verwenden. In Azure können Sie persistenten Volumes als Kubernetes-Ressourcen erstellen, die Azure Storage unterstützt. Sie können Datenvolumes manuell erstellen und sie direkt Pods zuweisen, oder Sie können AKS automatisch mit persistenten Volumeansprüchenerstellen lassen. AKS bietet integrierte Speicherklassen zum Erstellen persistenter Volumes, die Azure Disks, Azure Filesund Azure NetApp Files Support. Weitere Informationen finden Sie unter Speicheroptionen für Anwendungen in AKS. Aus Sicherheits- und Resilienzgründen sollten Sie die Verwendung des lokalen Speichers auf Agentknoten über emptyDir- und hostPath-vermeiden.

Wenn AKS integrierte Speicherklassen nicht für einen oder mehrere Mandanten geeignet sind, können Sie benutzerdefinierte Speicherklassen erstellen,, um die Anforderungen verschiedener Mandanten zu erfüllen. Diese Anforderungen umfassen Volumengröße, Speicher-SKU, eine Vereinbarung auf Service-Level (SLA), Sicherungsrichtlinien und das Preisniveau.

Sie können beispielsweise eine benutzerdefinierte Speicherklasse für jeden Mandanten konfigurieren. Sie können es dann verwenden, um Tags auf jedes persistente Volume anzuwenden, das in seinem Namespace erstellt wird, um die Kosten für sie zu belasten. Weitere Informationen finden Sie unter Verwenden von Azure-Tags in AKS.

Weitere Informationen finden Sie unter Speicherisolation in der Kubernetes-Dokumentation.

Knotenisolation

Sie können Mandantenarbeitslasten so konfigurieren, dass sie auf separaten Agentknoten ausgeführt werden, um lauten Nachbarproblemen zu vermeiden und das Risiko der Offenlegung von Informationen zu verringern. In AKS können Sie einen separaten Cluster oder nur einen dedizierten Knotenpool für Mandanten erstellen, die strenge Anforderungen an Isolation, Sicherheit, behördliche Compliance und Leistung aufweisen.

Sie können , Tolerationen, Knotenbeschriftungen, Knotenselektorenund Knotenaffinität verwenden, um die Pods von Mandanten nur auf einen bestimmten Satz von Knoten oder Knotenpools zu beschränken.

Im Allgemeinen bietet AKS Arbeitsauslastungsisolation auf verschiedenen Ebenen, darunter:

  • Auf Kernelebene durch Ausführen von Mandantenarbeitslasten auf einfachen virtuellen Computern (VMs) auf gemeinsam genutzten Agent-Knoten und mithilfe Pod Sandboxing basierend auf Kata-Containern.
  • Auf physischer Ebene, indem Mandantenanwendungen auf dedizierten Clustern oder Knotenpools gehostet werden.
  • Auf Hardwareebene durch Ausführen von Mandantenarbeitslasten auf dedizierten Azure-Hosts, die garantieren, dass VMs des Agentknotens dedizierte physische Computer ausführen. Die Hardwareisolation stellt sicher, dass keine anderen virtuellen Computer auf den dedizierten Hosts platziert werden, die eine zusätzliche Isolationsebene für Mandantenworkloads bieten.

Sie können diese Techniken kombinieren. Sie können z. B. mandantenspezifische Cluster und Knotenpools in einer Azure Dedicated Host-Gruppe ausführen, um Arbeitsauslastungstrennung und physische Isolation auf Hardwareebene zu erzielen. Sie können auch freigegebene oder mandantenbasierte Knotenpools erstellen, die Federal Information Process Standard (FIPS), vertraulichen virtuellen Computernoder hostbasierte Verschlüsselungunterstützen.

Verwenden Sie die Knotenisolation, um die Kosten einer Gruppe von Knoten oder Knotenpools einfach einem einzelnen Mandanten zuzuordnen und zu berechnen. Es hängt streng mit dem Mandantenmodell zusammen, das von Ihrer Lösung übernommen wird.

Weitere Informationen finden Sie unter Knotenisolation in der Kubernetes-Dokumentation.

Mandantenmodelle

AKS bietet mehr Typen von Knotenisolation und Mandantenmodellen.

Automatisierte Bereitstellungen mit einem Mandanten

In einem automatisierten Einzelmandantenbereitstellungsmodell stellen Sie einen dedizierten Satz von Ressourcen für jeden Mandanten bereit, wie in diesem Beispiel veranschaulicht:

Diagramm, das drei Mandanten mit jeweils separaten Bereitstellungen anzeigt.

Jede Mandantenarbeitsauslastung wird in einem dedizierten AKS-Cluster ausgeführt und greift auf eine unterschiedliche Gruppe von Azure-Ressourcen zu. In der Regel verwenden Sie multitenantische Lösungen, die Sie mithilfe dieses Modells erstellen, umfassend Infrastruktur als Code (IaC). Beispielsweise Bicep-, Azure Resource Manager, Terraform-oder die Azure Resource Manager-REST-APIs helfen, die On-Demand-Bereitstellung mandantendedizierter Ressourcen zu initiieren und zu koordinieren. Sie können diesen Ansatz verwenden, wenn Sie eine völlig separate Infrastruktur für jeden Ihrer Kunden bereitstellen müssen. Berücksichtigen Sie bei der Planung der Bereitstellung das Muster Bereitstellungsstempel.

Vorteile:

  • Ein wichtiger Vorteil dieses Ansatzes ist, dass der API-Server jedes Mandanten-AKS-Clusters getrennt ist. Dieser Ansatz garantiert eine vollständige Isolation zwischen Mandanten von einer Sicherheits-, Netzwerk- und Ressourcenverbrauchsstufe. Ein Angreifer, der die Kontrolle über einen Container erhält, hat nur Zugriff auf die Container und bereitgestellten Volumes, die zu einem einzelnen Mandanten gehören. Ein Vollisolations-Mandantenmodell ist für einige Kunden mit einem hohen Regulatorischen Compliance-Aufwand von entscheidender Bedeutung.
  • Mandanten sind unwahrscheinlich, dass sich die Systemleistung gegenseitig beeinträchtigt wird, sodass Sie lauten Nachbarn-Problemenvermeiden. Diese Berücksichtigung umfasst den Datenverkehr für den API-Server. Der API-Server ist eine freigegebene, kritische Komponente in jedem Kubernetes-Cluster. Benutzerdefinierte Controller, die unregulierten, volumenintensiven Datenverkehr gegen den API-Server generieren, können zu Clusterinstabilität führen. Diese Instabilität führt zu Anforderungsfehlern, Timeouts und API-Wiederholungsstürmen. Verwenden Sie die SLA--Funktion, um die Steuerungsebene eines AKS-Clusters zu skalieren, um den Datenverkehrsbedarf zu erfüllen. Dennoch kann die Bereitstellung eines dedizierten Clusters eine bessere Lösung für diese Kunden mit starken Anforderungen in Bezug auf die Workloadisolation sein.
  • Sie können Updates und Änderungen schrittweise über Mandanten hinweg bereitstellen, wodurch die Wahrscheinlichkeit eines systemweiten Ausfalls reduziert wird. Azure-Kosten können auf einfache Weise an Mandanten zurückgerechnet werden, da jede Ressource von einem einzelnen Mandanten verwendet wird.

Risiken:

  • Die Kosteneffizienz ist niedrig, da jeder Mandant einen dedizierten Satz von Ressourcen verwendet.
  • Die fortlaufende Wartung ist wahrscheinlich zeitaufwändig, da Sie Wartungsaktivitäten über mehrere AKS-Cluster hinweg wiederholen müssen, eines für jeden Mandanten. Erwägen Sie, Ihre betrieblichen Prozesse zu automatisieren und Änderungen schrittweise über Ihre Umgebungen anzuwenden. Andere bereitstellungsübergreifende Vorgänge, z. B. Berichte und Analysen in Ihrem gesamten Besitz, können auch hilfreich sein. Stellen Sie sicher, dass Sie planen, wie Sie Daten in mehreren Bereitstellungen abfragen und bearbeiten.

Vollständig mehrinstanzenfähige Bereitstellungen

Bei einer vollständigen Mehrinstanzenbereitstellung bedient eine einzelne Anwendung die Anforderungen aller Mandanten, und alle Azure-Ressourcen werden gemeinsam genutzt, einschließlich des AKS-Clusters. In diesem Zusammenhang verfügen Sie nur über eine Infrastruktur zum Bereitstellen, Überwachen und Verwalten. Alle Mandanten verwenden die Ressource, wie im folgenden Diagramm dargestellt:

Ein Diagramm, das drei Mandanten zeigt, die alle eine einzelne freigegebene Bereitstellung verwenden.

Vorteile:

  • Dieses Modell ist aufgrund der niedrigeren Kosten für die Bedienung einer Lösung mit gemeinsam genutzten Komponenten attraktiv. Wenn Sie dieses Mandantenmodell verwenden, müssen Sie möglicherweise einen größeren AKS-Cluster bereitstellen und eine höhere SKU für alle freigegebenen Datenrepositorys übernehmen. Diese Änderungen tragen dazu bei, den Datenverkehr aufrechtzuerhalten, den alle Mandantenressourcen wie Datenrepositorys generieren.

Risiken:

  • In diesem Zusammenhang behandelt eine einzelne Anwendung alle Anforderungen der Mandanten. Sie sollten Sicherheitsmaßnahmen entwerfen und implementieren, um zu verhindern, dass Mandanten die Anwendung mit Aufrufen überfluten. Diese Aufrufe können das gesamte System verlangsamen und sich auf alle Mandanten auswirken.
  • Wenn das Datenverkehrsprofil hochgradig variabel ist, sollten Sie die AKS-Cluster-Autoskaler so konfigurieren, dass die Anzahl der Pods und Agentknoten variiert. Die Konfiguration basiert auf der Systemressourcenauslastung, z. B. CPU und Arbeitsspeicher. Alternativ können Sie die Anzahl der Pods und Clusterknoten basierend auf benutzerdefinierten Metriken skalieren und skalieren. Sie können z. B. die Anzahl der ausstehenden Anforderungen oder die Metriken eines externen Messagingsystems verwenden, das Kubernetes-basierte Ereignisgesteuerte Autoscaler (KEDA)verwendet.
  • Stellen Sie sicher, dass Sie die Daten für jeden Mandanten trennen und Schutzmaßnahmen implementieren, um Datenlecks zwischen verschiedenen Mandanten zu vermeiden.
  • Achten Sie darauf, die Azure-Kosten basierend auf ihrer tatsächlichen Nutzung nachzuverfolgen und einzelnen Mandanten zuzuordnen. Nicht-Microsoft-Lösungen wie kubecostkönnen Ihnen helfen, Kosten in verschiedenen Teams und Mandanten zu berechnen und aufzuschlüsseln.
  • Die Wartung kann mit einer einzelnen Bereitstellung einfacher sein, da Sie nur eine Gruppe von Azure-Ressourcen aktualisieren und eine einzelne Anwendung verwalten müssen. Es kann jedoch auch riskanter sein, da sich änderungen an der Infrastruktur oder Anwendungskomponenten auf die gesamte Kundenbasis auswirken können.
  • Sie sollten auch Skalierungseinschränkungen berücksichtigen. Es ist wahrscheinlicher, dass Sie Azure-Ressourcenskalierungsgrenzwerte erreichen, wenn Sie über einen freigegebenen Satz von Ressourcen verfügen. Um ein Ressourcenkontingentlimit zu vermeiden, können Sie Ihre Mandanten über mehrere Azure-Abonnements verteilen.

Horizontal partitionierte Bereitstellungen

Alternativ können Sie die horizontale Partitionierung Ihrer Multitenant Kubernetes-Anwendung in Betracht ziehen. Dieser Ansatz teilt einige Lösungskomponenten für alle Mandanten und stellt dedizierte Ressourcen für einzelne Mandanten bereit. Sie können z. B. eine einzelne Mehrinstanzen-Kubernetes-Anwendung erstellen und dann einzelne Datenbanken erstellen, eine für jeden Mandanten, wie in dieser Abbildung gezeigt:

Ein Diagramm, das drei Mandanten anzeigt. Jede verwendet eine dedizierte Datenbank und eine einzelne, freigegebene Kubernetes-Anwendung.

Vorteile:

  • Horizontal partitionierte Bereitstellungen können Ihnen helfen, lauten Nachbarproblemenzu mindern. Berücksichtigen Sie diesen Ansatz, wenn Sie feststellen, dass die meisten Datenverkehrslasten für Ihre Kubernetes-Anwendung auf bestimmte Komponenten zurückzuführen sind, die Sie separat für jeden Mandanten bereitstellen können. Ihre Datenbanken können z. B. den größten Teil der Auslastung Ihres Systems aufnehmen, da die Abfragelast hoch ist. Wenn ein einzelner Mandant eine große Anzahl von Anforderungen an Ihre Lösung sendet, ist die Leistung einer Datenbank möglicherweise negativ betroffen, aber die Datenbanken und freigegebenen Komponenten anderer Mandanten, wie die Anwendungsebene, bleiben davon unberührt.

Risiken:

  • Bei einer horizontal partitionierten Bereitstellung müssen Sie dennoch die automatisierte Bereitstellung und Verwaltung Ihrer Komponenten berücksichtigen, insbesondere die Komponenten, die ein einzelner Mandant verwendet.
  • Dieses Modell stellt möglicherweise nicht die erforderliche Isolationsebene für Kunden bereit, die Ressourcen aus internen Richtlinien- oder Compliancegründen nicht für andere Mandanten freigeben können.

Vertikal partitionierte Bereitstellungen

Sie können die Vorteile der Einzelmandanten- und Vollinstanzenmodelle nutzen, indem Sie ein Hybridmodell verwenden, das Mandanten vertikal über mehrere AKS-Cluster oder Knotenpools partitioniert. Dieser Ansatz bietet gegenüber den beiden vorherigen Mandantenmodellen die folgenden Vorteile:

  • Sie können eine Kombination aus Einzelmandanten- und Mehrinstanzenbereitstellungen verwenden. So können Sie beispielsweise die meisten Ihrer Kunden einen AKS-Cluster und eine Datenbank in einer mehrinstanzenübergreifenden Infrastruktur gemeinsam nutzen. Sie können auch Einzelmandanteninfrastrukturen für Kunden bereitstellen, die eine höhere Leistung und Isolation erfordern.
  • Sie können Mandanten in mehreren regionalen AKS-Clustern bereitstellen, möglicherweise mit unterschiedlichen Konfigurationen. Diese Technik ist am effektivsten, wenn Sie Mandanten über verschiedene Regionen verteilt haben.

Sie können verschiedene Varianten dieses Mandantenmodells implementieren. Sie können z. B. Ihre Mehrinstanzenlösung mit unterschiedlichen Funktionalitätsebenen zu unterschiedlichen Kosten anbieten. Ihr Preismodell kann mehrere SKUs bereitstellen, die jeweils eine inkrementelle Leistungs- und Isolationsstufe im Hinblick auf ressourcenfreigabe, Leistung, Netzwerk und Datentrennung bieten. Berücksichtigen Sie die folgenden Ebenen:

  • Standardebene: Die Mandantenanforderungen werden von einer einzelnen, mehrinstanzenfähigen Kubernetes-Anwendung bereitgestellt, die für andere Mandanten freigegeben ist. Daten werden in einer oder mehreren Datenbanken gespeichert, die alle Mandanten der Standardebene gemeinsam nutzen.
  • Standardebene: Mandantenanforderungen werden von einer dedizierten Kubernetes-Anwendung bereitgestellt, die in einem separaten Namespace ausgeführt wird, der Isolationsgrenzen hinsichtlich Sicherheit, Netzwerk und Ressourcenverbrauch bereitstellt. Alle Mandantenanwendungen, eine für jeden Mandanten, teilen den gleichen AKS-Cluster und Knotenpool für andere Standardkunden.
  • Premium tier: The tenant application runs in a dedicated node pool or AKS cluster to guarantee a higher SLA, better performance, and a higher degree of isolation. Diese Stufe kann ein flexibles Kostenmodell basierend auf der Anzahl und SKU der Agentknoten bereitstellen, die die Mandantenanwendung hosten. Sie können Pod Sandboxing als alternative Lösung für dedizierte Cluster oder Knotenpools verwenden, um unterschiedliche Mandantenarbeitslasten zu isolieren.

Das folgende Diagramm zeigt ein Szenario, in dem Mandanten A und B auf einem freigegebenen AKS-Cluster ausgeführt werden, während Mandant C auf einem separaten AKS-Cluster ausgeführt wird.

Diagramm mit drei Mandanten. Mandanten A und B teilen einen AKS-Cluster. Der Mandant C verfügt über einen dedizierten AKS-Cluster.

Das folgende Diagramm zeigt ein Szenario, in dem Mandanten A und B auf demselben Knotenpool ausgeführt werden, während Mandant C auf einem dedizierten Knotenpool ausgeführt wird.

Diagramm mit drei Mandanten. Mandanten A und B teilen einen Knotenpool. Der Mandant C verfügt über einen dedizierten Knotenpool.

Dieses Modell kann auch verschiedene SLAs für verschiedene Stufen anbieten. Beispielsweise kann die Basisebene 99,9% Uptime bieten, die Standardstufe kann 99,95% Uptime anbieten, und die Premium-Stufe kann 99,99% Uptime anbieten. Sie können die höhere SLA implementieren, indem Sie Dienste und Features verwenden, die höhere Verfügbarkeitsziele ermöglichen.

Vorteile:

  • Da Sie die Infrastruktur noch gemeinsam nutzen, können Sie dennoch einige der Kostenvorteile erzielen, die gemeinsam genutzte mehrinstanzenfähige Bereitstellungen haben. Sie können Cluster und Knotenpools bereitstellen, die für mehrere Mandantenanwendungen auf basis- und Standardebene gemeinsam genutzt werden, die eine kostengünstigere VM-Größe für Agentknoten verwenden. Dieser Ansatz garantiert eine bessere Dichte und Kosteneinsparungen. Für Premium-Kunden können Sie AKS-Cluster und Knotenpools mit einer höheren VM-Größe und einer maximalen Anzahl von Podreplikaten und Knoten zu einem höheren Preis bereitstellen.
  • Sie können Systemdienste wie CoreDNS, Konnectivityoder Azure Application Gateway Ingress Controllerin einem dedizierten Knotenpool im Systemmodus ausführen. Sie können , Tolerationen, Knotenbeschriftungen, Knotenselektorenund Knoten affinität verwenden, um eine Mandantenanwendung in einem oder mehreren Benutzermodusknotenpools auszuführen.
  • Sie können , Tolerationen, Knotenbeschriftungen, Knotenselektorenund Knotenaffinität verwenden, um gemeinsam genutzte Ressourcen auszuführen. Sie können z. B. einen Eingangscontroller oder ein Messagingsystem in einem dedizierten Knotenpool mit einer bestimmten VM-Größe, Autoskalierungseinstellungen und Verfügbarkeitszonen unterstützen.

Risiken:

  • Sie müssen Ihre Kubernetes-Anwendung so entwerfen, dass sie sowohl mehrinstanzenfähige als auch Einzelmandantenbereitstellungen unterstützt.
  • Wenn Sie beabsichtigen, die Migration zwischen Infrastrukturen zuzulassen, müssen Sie überlegen, wie Sie Kunden aus einer mehrinstanzenfähigen Bereitstellung zu ihrer eigenen Einzelmandantenbereitstellung migrieren.
  • Sie benötigen eine konsistente Strategie und einen einzigen Glasbereich oder einen Standpunkt, um weitere AKS-Cluster zu überwachen und zu verwalten.

Automatische Skalierung

Um mit der Datenverkehrsnachfrage, die Mandantenanwendungen generieren, schritt zu halten, können Sie die Cluster-Autoscaler- aktivieren, um die Agentknoten von AKS zu skalieren. Durch die automatische Skalierung können Systeme unter folgenden Umständen reaktionsfähig bleiben:

  • Die Verkehrsbelastung erhöht sich während bestimmter Arbeitszeiten oder Zeiträume des Jahres.
  • Mandanten- oder freigegebene schwere Lasten werden in einem Cluster bereitgestellt.
  • Agentknoten sind aufgrund von Ausfällen einer Verfügbarkeitszone nicht verfügbar.

Wenn Sie die automatische Skalierung für einen Knotenpool aktivieren, geben Sie ein Minimum und eine maximale Anzahl von Knoten basierend auf den erwarteten Workloadgrößen an. Durch die Konfiguration einer maximalen Anzahl von Knoten können Sie unabhängig vom namespace, in dem sie ausgeführt werden, genügend Platz für alle Mandanten-Pods im Cluster sicherstellen.

Wenn der Datenverkehr zunimmt, fügt die automatische Clusterkalierung neue Agentknoten hinzu, um zu verhindern, dass Pods aufgrund von Ressourcenengpässen wie CPU und Arbeitsspeicher in einen ausstehenden Zustand gelangen.

Wenn die Last verringert wird, verringert die automatische Skalierung des Clusters die Anzahl der Agentknoten in einem Knotenpool basierend auf den angegebenen Grenzen, wodurch Ihre Betriebskosten reduziert werden.

Sie können pod autocaling verwenden, um Pods automatisch basierend auf Ressourcenanforderungen zu skalieren. HorizontalPodAutoscaler skaliert automatisch die Anzahl der Podreplikate basierend auf der CPU- oder Speicherauslastung oder benutzerdefinierten Metriken. Mithilfe KEDA-können Sie die Skalierung eines beliebigen Containers in Kubernetes basierend auf der Anzahl der Ereignisse von externen Systemen wie Azure Event Hubs oder Azure Service Bussteuern, die von Mandantenanwendungen verwendet werden.

Vertical Pod Autoscaler (VPA) ermöglicht eine effiziente Ressourcenverwaltung für Pods. Durch das Anpassen der CPU und des Arbeitsspeichers, die Pods zugeordnet sind, hilft Ihnen VPA, die Anzahl der Knoten zu reduzieren, die zum Ausführen von Mandantenanwendungen erforderlich sind. Weniger Knoten reduzieren die Gesamtbetriebskosten und helfen Ihnen, lauten Nachbarproblemenzu vermeiden.

Weisen Sie Kapazitätsreservierungsgruppen Knotenpools zu, um eine bessere Ressourcenzuweisung und Isolation für verschiedene Mandanten bereitzustellen.

Instandhaltung

Um das Risiko von Ausfallzeiten zu verringern, die sich auf Mandantenanwendungen während Cluster- oder Knotenpoolupgrades auswirken können, planen Sie AKS geplante Wartung während der Spitzenzeiten. Planen Sie wöchentliche Wartungsfenster, um die Kontrollebene der AKS-Cluster zu aktualisieren, die Mandantenanwendungen und Knotenpools ausführen, um die Auswirkungen auf die Arbeitsauslastung zu minimieren. Sie können ein oder mehrere wöchentliche Wartungsfenster auf Ihrem Cluster planen, indem Sie einen Tag oder einen bestimmten Zeitraum angeben. Alle Wartungsvorgänge treten während der geplanten Fenster auf.

Sicherheit

In den folgenden Abschnitten werden bewährte Sicherheitsmethoden für Multitenant-Lösungen mit AKS beschrieben.

Clusterzugriff

Wenn Sie einen AKS-Cluster zwischen mehreren Teams innerhalb einer Organisation freigeben, müssen Sie das Prinzip der geringsten Rechte implementieren,, um unterschiedliche Mandanten voneinander zu isolieren. Insbesondere müssen Sie sicherstellen, dass Benutzer nur auf ihre Kubernetes-Namespaces und Ressourcen zugreifen können, wenn Sie Tools wie kubectl, Helm, Fluxoder Argo CDverwenden.

Weitere Informationen zur Authentifizierung und Autorisierung mit AKS finden Sie in den folgenden Artikeln:

Workload-Identität

Wenn Sie mehrere Mandantenanwendungen auf einem einzigen AKS-Cluster hosten und jede Anwendung sich in einem separaten Namespace befindet, sollte jede Workload ein anderes Kubernetes-Dienstkonto und Anmeldeinformationen verwenden, um auf die nachgeschalteten Azure-Dienste zuzugreifen. Dienstkonten sind einer der primären Benutzertypen in Kubernetes. Die Kubernetes-API enthält und verwaltet Dienstkonten. Dienstkontoanmeldeinformationen werden als Kubernetes-Geheimschlüssel gespeichert, sodass autorisierte Pods sie für die Kommunikation mit dem API-Server verwenden können. Die meisten API-Anforderungen stellen ein Authentifizierungstoken für ein Dienstkonto oder ein normales Benutzerkonto bereit.

Mandantenarbeitslasten, die Sie in AKS-Clustern bereitstellen, können Microsoft Entra-Anwendungsanmeldeinformationen verwenden, um auf microsoft Entra ID-geschützte Ressourcen zuzugreifen, z. B. Azure Key Vault und Microsoft Graph. Microsoft Entra Workload ID für Kubernetes in die systemeigenen Kubernetes-Funktionen integriert, um mit allen externen Identitätsanbietern zu verbinden.

Pod Sandboxing

AKS enthält einen Mechanismus namens Pod Sandboxing-, der eine Isolationsgrenze zwischen der Containeranwendung und dem gemeinsam genutzten Kernel und Computeressourcen des Containerhosts bereitstellt, z. B. CPU, Arbeitsspeicher und Netzwerk. Pod Sandboxing ergänzt andere Sicherheitsmaßnahmen oder Datenschutzkontrollen, um Mandantenarbeitslasten dabei zu helfen, vertrauliche Informationen zu sichern und behördliche, branchenspezifische oder Governance-Compliance-Anforderungen zu erfüllen, z. B. PCI DSS (Payment Card Industry Data Security Standard), International Organization for Standardization (ISO) 27001 und Health Insurance Portability and Accountability Act (HIPAA).

Durch die Bereitstellung von Anwendungen in separaten Clustern oder Knotenpools können Sie die Mandantenarbeitslasten verschiedener Teams oder Kunden stark isolieren. Die Verwendung mehrerer Cluster und Knotenpools eignet sich möglicherweise für die Isolationsanforderungen vieler Organisationen und SaaS-Lösungen, aber es gibt Szenarien, in denen ein einzelner Cluster mit gemeinsam genutzten VM-Knotenpools effizienter ist. Sie können z. B. einen einzelnen Cluster verwenden, wenn Sie nicht vertrauenswürdige und vertrauenswürdige Pods auf demselben Knoten ausführen oder DaemonSets und privilegierte Container auf demselben Knoten für eine schnellere lokale Kommunikation und funktionale Gruppierung verlagern. Pod Sandboxing- können Sie Mandantenanwendungen auf denselben Clusterknoten stark isolieren, ohne diese Workloads in separaten Cluster- oder Knotenpools ausführen zu müssen. Andere Methoden erfordern, dass Sie Ihren Code neu kompilieren oder andere Kompatibilitätsprobleme verursachen, aber Pod Sandboxing in AKS kann jeden Container ohne Änderungen innerhalb einer erweiterten Sicherheits-VM-Grenze ausführen.

Pod Sandboxing auf AKS basiert auf Kata-Containern, die auf dem Azure Linux-Containerhost für AKS Stack ausgeführt werden, um hardwaregezwingte Isolation bereitzustellen. Kata-Container auf AKS basieren auf einem sicherheitsfesten Azure-Hypervisor. Sie erreicht die Isolation pro Pod über eine geschachtelte, einfache Kata-VM, die Ressourcen von einem übergeordneten VM-Knoten nutzt. In diesem Modell erhält jeder Kata-Pod seinen eigenen Kernel in einer geschachtelten Kata-Gast-VM. Verwenden Sie dieses Modell, um viele Kata-Container in einer einzelnen Gast-VM zu platzieren und weiterhin Container in der übergeordneten VM auszuführen. Dieses Modell bietet eine starke Isolationsgrenze in einem freigegebenen AKS-Cluster.

Weitere Informationen finden Sie unter:

Dedizierter Azure-Host

Azure Dedicated Host ist ein Dienst, der physische Server bereitstellt, die einem einzelnen Azure-Abonnement zugeordnet sind und Hardwareisolation auf physischer Serverebene bereitstellen. Sie können diese dedizierten Hosts innerhalb einer Region, Verfügbarkeitszone und Fehlerdomäne bereitstellen und virtuelle Computer direkt in die bereitgestellten Hosts platzieren.

Es gibt mehrere Vorteile für die Verwendung von Azure Dedicated Host mit AKS, darunter:

  • Die Hardwareisolation stellt sicher, dass keine anderen virtuellen Computer auf den dedizierten Hosts platziert werden, die eine zusätzliche Isolationsebene für Mandantenworkloads bieten. Dedizierte Hosts werden in den gleichen Rechenzentren bereitgestellt und nutzen die gleiche Netzwerk- und zugrunde liegende Speicherinfrastruktur wie andere nicht isolierte Hosts.

  • Azure Dedicated Host bietet Kontrolle über Wartungsereignisse, die die Azure-Plattform initiiert. Sie können ein Wartungsfenster auswählen, um die Auswirkungen auf Dienste zu verringern und die Verfügbarkeit und den Datenschutz von Mandantenarbeitslasten sicherzustellen.

Azure Dedicated Host kann SaaS-Anbieter dabei unterstützen, sicherzustellen, dass Mandantenanwendungen behördliche, branchenspezifische und Governance-Complianceanforderungen für die Sicherung vertraulicher Informationen erfüllen. Weitere Informationen finden Sie unter Hinzufügen von Azure Dedicated Host zu einem AKS-Cluster.

Karpenter

Karpenter ist ein Open-Source-Node-Lifecycle-Management-Projekt, das für Kubernetes entwickelt wurde. Das Hinzufügen von Karpenter zu einem Kubernetes-Cluster kann die Effizienz und kosten der Ausführung von Workloads auf diesem Cluster verbessern. Karpenter überwacht pods, die der Kubernetes-Scheduler als nicht geplant markiert. Sie stellt außerdem Knoten, die die Podanforderungen erfüllen können, dynamisch fest und verwaltet sie.

Karpenter bietet eine differenzierte Kontrolle über die Bereitstellung von Knoten und die Workloadplatzierung in einem verwalteten Cluster. Dieses Steuerelement verbessert die Mehrinstanzenfähigkeit, indem die Ressourcenzuordnung optimiert wird, die Isolation zwischen den Anwendungen der einzelnen Mandanten gewährleistet und die Betriebskosten reduziert werden. Wenn Sie eine Mehrinstanzenlösung auf AKS erstellen, bietet Karpenter nützliche Funktionen, mit denen Sie verschiedene Anwendungsanforderungen verwalten können, um verschiedene Mandanten zu unterstützen. Beispielsweise benötigen Sie möglicherweise einige Mandantenanwendungen, um auf GPU-optimierten Knotenpools und anderen für die Ausführung auf speicheroptimierten Knotenpools auszuführen. Wenn Ihre Anwendung eine geringe Latenz für den Speicher erfordert, können Sie mit Karpenter angeben, dass ein Pod einen Knoten erfordert, der in einer bestimmten Verfügbarkeitszone ausgeführt wird, damit Sie Ihren Speicher und die Anwendungsebene verlagern können.

AKS ermöglicht die automatische Bereitstellung von Knoten auf AKS-Clustern über Karpenter. Die meisten Benutzer sollten den Knoten-Autoprovisionsmodus verwenden, um Karpenter als verwaltetes Addon zu aktivieren. Weitere Informationen finden Sie unter node autoprovisioning. Wenn Sie erweiterte Anpassungen benötigen, können Sie sich für den Self-Host Karpenter entscheiden. Weitere Informationen finden Sie im AKS Karpenter-Anbieter.

Vertrauliche virtuelle Computer

Sie können vertraulichen VMs verwenden, um Ihrem AKS-Cluster einen oder mehrere Knotenpools hinzuzufügen, um die strengen Isolations-, Datenschutz- und Sicherheitsanforderungen der Mandanten zu erfüllen. Vertrauliche VMs eine hardwarebasierte vertrauenswürdige Ausführungsumgebungverwenden. AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) vertraulichen VMs den Hypervisor und anderen Hostverwaltungscodezugriff auf VM-Speicher und -Zustand verweigern, wodurch eine Schutzebene und ein eingehender Schutz vor Operatorzugriff hinzugefügt wird. Weitere Informationen finden Sie unter Verwenden vertraulicher VMs in einem AKS-Cluster.

Federal Information Process Standards (FIPS)

FIPS 140-3 ist ein US-Regierungsstandards, der mindestsicherheitsanforderungen für kryptografische Module in Informationstechnologieprodukten und -systemen definiert. Indem Sie FIPS-Compliance für AKS-Knotenpoolsaktivieren, können Sie die Isolation, den Datenschutz und die Sicherheit Ihrer Mandantenworkloads verbessern. FIPS- Compliance stellt sicher, dass validierte kryptografische Module für Verschlüsselung, Hashing und andere sicherheitsbezogene Vorgänge verwendet werden. Mit FIPS-fähigen AKS-Knotenpools können Sie gesetzliche und branchenspezifische Complianceanforderungen erfüllen, indem Sie robuste kryptografische Algorithmen und Mechanismen verwenden. Azure bietet Dokumentation zum Aktivieren von FIPS für AKS-Knotenpools, mit der Sie den Sicherheitsstatus Ihrer mehrinstanzenfähigen AKS-Umgebungen stärken können. Weitere Informationen finden Sie unter Aktivieren von FIPS für AKS-Knotenpools.

Bring your own keys (BYOK) with Azure disks

Azure Storage verschlüsselt alle Daten in einem ruhenden Speicherkonto, einschließlich des Betriebssystems und der Datenträger eines AKS-Clusters. Standardmäßig werden Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Um mehr Kontrolle über Verschlüsselungsschlüssel zu erhalten, können Sie vom Kunden verwaltete Schlüssel bereitstellen, die für die Verschlüsselung im Ruhezustand des Betriebssystems und der Datenträger Ihrer AKS-Cluster verwendet werden können. Weitere Informationen finden Sie unter:

Hostbasierte Verschlüsselung

hostbasierte Verschlüsselung auf AKS stärkt die Mandantenauslastungsisolation, den Datenschutz und die Sicherheit weiter. Wenn Sie die hostbasierte Verschlüsselung aktivieren, verschlüsselt AKS ruhende Daten auf den zugrunde liegenden Hostcomputern, wodurch sichergestellt wird, dass vertrauliche Mandanteninformationen vor unbefugtem Zugriff geschützt sind. Temporäre Datenträger und kurzlebige Betriebssystemdatenträger werden mit plattformverwalteten Schlüsseln verschlüsselt, wenn Sie die End-to-End-Verschlüsselung aktivieren.

In AKS verwenden Betriebssystem- und Datendatenträger standardmäßig serverseitige Verschlüsselung mit plattformverwalteten Schlüsseln. Die Caches für diese Datenträger werden mit plattformverwalteten Schlüsseln verschlüsselt. Sie können ihren eigenen Schlüsselverschlüsselungsschlüssel angeben,, um den Datenschutzschlüssel mithilfe der Umschlagverschlüsselung zu verschlüsseln, auch als Wrappingbezeichnet. Der Cache für das Betriebssystem und Die Datenträger werden auch über die von Ihnen angegebenen BYOK- verschlüsselt.

Die hostbasierte Verschlüsselung fügt eine Sicherheitsebene für Mehrinstanzenumgebungen hinzu. Die Daten jedes Mandanten im Betriebssystem und datenträgercaches werden in Ruhe mit vom Kunden verwalteten oder plattformverwalteten Schlüsseln verschlüsselt, je nach ausgewähltem Datenträgerverschlüsselungstyp. Weitere Informationen finden Sie unter:

Vernetzung

In den folgenden Abschnitten werden bewährte Methoden für Netzwerklösungen mit AKS beschrieben.

Einschränken des Netzwerkzugriffs auf den API-Server

In Kubernetes empfängt der API-Server Anforderungen zum Ausführen von Aktionen im Cluster, z. B. das Erstellen von Ressourcen oder das Skalieren der Anzahl von Knoten. Wenn Sie einen AKS-Cluster für mehrere Teams innerhalb einer Organisation freigeben, schützen Sie den Zugriff auf die Kontrollebene mithilfe einer der folgenden Lösungen.

Private AKS-Cluster

Mithilfe eines privaten AKS-Clusters können Sie sicherstellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und Ihren Knotenpools in Ihrem virtuellen Netzwerk verbleibt. In einem privaten AKS-Cluster verfügt die Steuerungsebene oder der API-Server über eine interne IP-Adresse, auf die nur über einen privaten Azure-Endpunktzugegriffen werden kann, der sich im selben virtuellen Netzwerk des AKS-Clusters befindet. Ebenso kann jeder virtuelle Computer im selben virtuellen Netzwerk privat über den privaten Endpunkt mit der Steuerebene kommunizieren. Weitere Informationen finden Sie unter Erstellen eines privaten AKS-Clusters.

Autorisierte IP-Adressbereiche

Die zweite Option, um die Clustersicherheit zu verbessern und Angriffe zu minimieren, besteht darin, autorisierte IP-Adressbereichezu verwenden. Bei diesem Ansatz wird der Zugriff auf die Kontrollebene eines öffentlichen AKS-Clusters auf eine bekannte Liste von IP-Adressen und klassenlosen Inter-Domain Routingbereichen (CIDR) beschränkt. Wenn Sie autorisierte IP-Adressen verwenden, sind sie weiterhin öffentlich verfügbar, aber der Zugriff ist auf eine Reihe von Bereichen beschränkt. Weitere Informationen finden Sie unter sicheren Zugriff auf den API-Server mithilfe autorisierter IP-Adressbereiche in AKS.

Azure Private Link Service ist eine Infrastrukturkomponente, mit der Anwendungen über einen privaten Azure-Endpunkt eine private Verbindung mit einem Dienst herstellen können,, der in einem virtuellen Netzwerk definiert und mit der Front-End-IP-Konfiguration einer Azure Load Balancer Instanz verbunden ist. Mit Private Linkkönnen Dienstanbieter ihre Dienste sicher für ihre Mandanten bereitstellen, die eine Verbindung zwischen Azure oder lokal herstellen können, ohne dass Datenexfiltrationsrisiken bestehen.

Sie können Integration des Privaten Linkdiensts verwenden, um Mandanten eine private Verbindung mit ihren von AKS gehosteten Workloads auf sichere Weise bereitzustellen, ohne dass öffentliche Endpunkte im öffentlichen Internet verfügbar gemacht werden müssen.

Weitere Informationen dazu, wie Sie private Verknüpfungen für eine von Azure gehostete Mehrinstanzenlösung konfigurieren können, finden Sie unter Multitenancy und private Link.

Umgekehrte Proxys

Ein Reverseproxy- ist ein Lastenausgleichsmodul und ein API-Gateway, das in der Regel vor Mandantenanwendungen zum Sichern, Filtern und Verteilen eingehender Anforderungen verwendet wird. Beliebte Reverseproxys unterstützen Features wie Lastenausgleich, SSL-Beendigung und Layer 7-Routing. Reverseproxys werden in der Regel implementiert, um Sicherheit, Leistung und Zuverlässigkeit zu erhöhen. Beliebte Reverseproxys für Kubernetes umfassen die folgenden Implementierungen:

Wenn Sie einen von AKS gehosteten Reverseproxy verwenden, um eingehende Anforderungen an mehrere Mandantenanwendungen zu sichern und zu verarbeiten, sollten Sie die folgenden Empfehlungen berücksichtigen:

  • Hosten Sie den Reverseproxy in einem dedizierten Knotenpool, der für die Verwendung einer VM-Größe mit hoher Netzwerkbandbreite konfiguriert ist, und beschleunigte Netzwerknetzwerke aktiviert.
  • Konfigurieren Sie den Knotenpool, der Ihren Reverseproxy für die automatische Skalierung hosten soll.
  • Um erhöhte Latenz und Timeouts für Mandantenanwendungen zu vermeiden, definieren Sie eine Richtlinie für die automatische Skalierung, sodass die Anzahl der Eingangscontroller-Pods sofort erweitert und kontraktiert werden kann, um Datenverkehrsschwankungen abzugleichen.
  • Erwägen Sie, den eingehenden Datenverkehr an Mandantenanwendungen in mehreren Instanzen Ihres Eingangscontrollers zu shardieren, um die Skalierbarkeit und Trennungsebene zu erhöhen.

Wenn Sie den Azure Application Gateway Ingress Controller (AGIC)verwenden, sollten Sie die folgenden bewährten Methoden implementieren:

  • Konfigurieren Sie das Anwendungsgateway, das der Eingangscontroller für automatischenverwendet. Wenn die automatische Skalierung aktiviert ist, skalieren die Anwendungsgateway- und Webanwendungsfirewall (WAF) v2 SKUs basierend auf den Anforderungen an den Anwendungsdatenverkehr. Dieser Modus bietet eine bessere Flexibilität für Ihre Anwendung und beseitigt die Notwendigkeit, die Größe oder Anzahl der Instanzen des Anwendungsgateways zu erraten. Dieser Modus hilft Ihnen auch, Kosten zu sparen, da das Gateway nicht für höchst bereitgestellte Kapazität für die erwartete maximale Datenverkehrslast ausgeführt werden muss. Sie müssen eine Mindestinstanzanzahl (und optional maximal) angeben.
  • Erwägen Sie die Bereitstellung mehrerer Instanzen des AGIC-, die jeweils einem separaten Anwendungsgatewayzugeordnet sind, wenn die Anzahl der Mandantenanwendungen die maximale Anzahl von Standorten überschreitet. Unter der Annahme, dass jede Mandantenanwendung in einem dedizierten Namespace ausgeführt wird, verwenden Sie mehrere Namespaceunterstützung, um Mandantenanwendungen über mehrere Instanzen der AGICzu verteilen.

Integration in Azure Front Door

Azure Front Door ist ein globaler Lastenausgleich der Ebene 7 und ein modernes Cloud Content Delivery Network (CDN) von Microsoft, das schnellen, zuverlässigen und sicheren Zugriff zwischen Benutzern und Webanwendungen auf der ganzen Welt bietet. Azure Front Door unterstützt Features wie Anforderungsbeschleunigung, SSL-Beendigung, Antwortzwischenspeicherung, WAF am Edge, URL-basiertes Routing, Umschreiben und Umleitungen, die Sie verwenden können, wenn Sie von AKS gehostete mehrinstanzenfähige Anwendungen für das öffentliche Internet verfügbar machen.

Sie können beispielsweise eine von AKS gehostete mehrinstanzenfähige Anwendung verwenden, um alle Kundenanforderungen zu erfüllen. In diesem Kontext können Sie Azure Front Door verwenden, um mehrere benutzerdefinierte Domänen zu verwalten, eine für jeden Mandanten. Sie können SSL-Verbindungen am Edge beenden und den gesamten Datenverkehr an die von AKS gehostete Mehrinstanzenanwendung weiterleiten, die mit einem einzelnen Hostnamen konfiguriert ist.

Diagramm, das veranschaulicht, wie Azure Front Door und AKS eine Verbindung herstellen.

Sie können Azure Front Door so konfigurieren, dass der Anforderungsursprunghostheader dem Domänennamen der Back-End-Anwendung entspricht. Der ursprüngliche Header, der vom Client gesendet wird, wird über den Header weitergegeben, und der Code der mehrinstanzenfähigen Anwendung kann diese Informationen verwenden, um die eingehende Anforderung dem richtigen Mandantenzu zuordnen.

Azure Web Application Firewall, auf Azure Front Door, bietet zentralisierten Schutz für Webanwendungen. Die Azure Web Application Firewall kann Ihnen dabei helfen, von AKS gehostete Mandantenanwendungen zu schützen, die einen öffentlichen Endpunkt im Internet vor böswilligen Angriffen verfügbar machen.

Sie können Azure Front Door Premium so konfigurieren, dass eine private Verbindung mit einer oder mehreren Mandantenanwendungen hergestellt wird, die auf einem AKS-Cluster ausgeführt werden, über einen internen Lastenausgleichsursprung, indem Sie Private Linkverwenden. Weitere Informationen finden Sie unter Verbinden von Azure Front Door Premium mit einem internen Lastenausgleichsursprung mit privatem Link.

Ausgehende Verbindungen

Wenn von AKS gehostete Anwendungen eine Verbindung mit einer großen Anzahl von Datenbanken oder externen Diensten herstellen, besteht das Risiko einer SNAT-Portausschöpfung (Source Network Address Translation). SNAT-Ports eindeutige Bezeichner generieren, die verwendet werden, um unterschiedliche Flüsse aufrechtzuerhalten, die Anwendungen, die auf demselben Satz von Computeressourcen ausgeführt werden, initiieren. Wenn Sie mehrere Mandantenanwendungen auf einem freigegebenen AKS-Cluster ausführen, können Sie eine hohe Anzahl ausgehender Anrufe tätigen, was zu einer SNAT-Portausschöpfung führen kann. Ein AKS-Cluster kann ausgehende Verbindungen auf drei verschiedene Arten verarbeiten:

  • Azure Load Balancer: Standardmäßig stellt AKS einen Standard-SKU-Lastenausgleich bereit, der für Ausgehende Verbindungen eingerichtet und verwendet werden soll. Das Standardsetup erfüllt jedoch möglicherweise nicht die Anforderungen aller Szenarien, wenn öffentliche IP-Adressen nicht zulässig sind oder zusätzliche Hops für den Ausgang erforderlich sind. Standardmäßig wird das öffentliche Lastenausgleichsmodul mit einer standardmäßigen öffentlichen IP-Adresse erstellt, die die ausgehenden Regeln verwenden. Ausgehende Regeln ermöglichen es Ihnen, SNAT für einen öffentlichen Standardlastenausgleich explizit zu definieren. Mit dieser Konfiguration können Sie die öffentlichen IP-Adressen Ihres Lastenausgleichs verwenden, um ausgehende Internetverbindung für Ihre Back-End-Instanzen bereitzustellen. Um SNAT-Portausschöpfungzu vermeiden, können Sie die ausgehenden Regeln des öffentlichen Lastenausgleichs so konfigurieren, dass mehr öffentliche IP-Adressen verwendet werden. Weitere Informationen finden Sie unter Verwenden der Front-End-IP-Adresse eines Lastenausgleichs für ausgehende Ausgehende Regeln.
  • Azure NAT Gateway: Sie können einen AKS-Cluster so konfigurieren, dass Azure NAT-Gateway verwendet wird, um Datenverkehr von Mandantenanwendungen zu leiten. DAS NAT-Gateway ermöglicht bis zu 64.512 ausgehende UDP- und TCP-Datenverkehrsflüsse pro öffentliche IP-Adresse mit maximal 16 IP-Adressen. Um das Risiko einer SNAT-Portausschöpfung zu vermeiden, wenn Sie ein NAT-Gateway zum Behandeln ausgehender Verbindungen von einem AKS-Cluster verwenden, können Sie dem Gateway weitere öffentliche IP-Adressen oder ein öffentliche IP-Adresspräfix zuordnen. Weitere Informationen finden Sie unter Überlegungen zum Azure NAT-Gateway für mehrinstanzenfähige.
  • benutzerdefinierte Route (USER-Defined Route, UDR): Sie können die Route eines AKS-Clusters anpassen, um benutzerdefinierte Netzwerkszenarien zu unterstützen, z. B. solche, die öffentliche IP-Adressen nicht zulassen und erfordern, dass sich der Cluster hinter einer virtuellen Netzwerkanwendung (Network Virtual Appliance, NVA) befindet. Wenn Sie einen Cluster für benutzerdefiniertes Routingkonfigurieren, konfiguriert AKS keine pfade automatisch. Sie müssen das Ausgangssetup abschließen. Sie leiten z. B. den Datenverkehr über eine Azure Firewallweiter. Sie müssen den AKS-Cluster in einem vorhandenen virtuellen Netzwerk mit einem zuvor konfigurierten Subnetz bereitstellen. Wenn Sie keine standardmäßige Lastenausgleichsarchitektur verwenden, müssen Sie einen expliziten Ausgang einrichten. Daher erfordert diese Architektur explizit das Senden des Datenverkehrs an eine Appliance, z. B. eine Firewall, ein Gateway oder einen Proxy. Oder die Architektur ermöglicht es der Netzwerkadressenübersetzung (NETWORK Address Translation, NAT), von einer öffentlichen IP zu erledigen, die dem Standardmäßigen Lastenausgleichsgerät oder der Appliance zugewiesen ist.

Überwachung

Sie können Azure Monitor und Containereinblicke verwenden, um Mandantenanwendungen zu überwachen, die auf einem freigegebenen AKS-Cluster ausgeführt werden, und Kostenaufschlüsselungen für einzelne Namespaces zu berechnen. Verwenden Sie Azure Monitor, um die Integrität und Leistung von AKS zu überwachen. Sie enthält die Sammlung von Protokollen und Metriken, Telemetrieanalyse und Visualisierungen gesammelter Daten, um Trends zu identifizieren und Warnungen zu konfigurieren, die Sie proaktiv über kritische Probleme informieren. Sie können Containereinblicke aktivieren, um diese Überwachung zu erweitern.

Sie können auch Open-Source-Tools wie Prometheus und Grafanaeinführen, die für die Kubernetes-Überwachung weit verbreitet sind. Sie können auch andere Nicht-Microsoft-Tools zur Überwachung und Observability einführen.

Kosten

Cost Governance ist der fortlaufende Prozess der Implementierung von Richtlinien zur Kontrolle der Kosten. Im Kubernetes-Kontext gibt es mehrere Methoden, mit denen Organisationen Kosten steuern und optimieren können. Diese Methoden umfassen die Verwendung systemeigener Kubernetes-Tools zum Verwalten und Steuern der Ressourcennutzung und -nutzung sowie zur proaktiven Überwachung und Optimierung der zugrunde liegenden Infrastruktur. Bei der Berechnung der Kosten pro Mandant sollten Sie die Kosten berücksichtigen, die mit jeder Ressource verbunden sind, die von einer Mandantenanwendung verwendet wird. Der Ansatz, den Sie befolgen, um Gebühren an die Mandanten zurückzurechnen, hängt vom Von Ihnen übernommenen Mandantenmodell ab. In der folgenden Liste werden Mandantenmodelle ausführlicher beschrieben:

  • Vollständig multitenant: Wenn eine einzelne mehrinstanzenfähige Anwendung alle Mandantenanforderungen erfüllt, liegt es in Ihrer Verantwortung, den Ressourcenverbrauch und die Anzahl der Anforderungen nachzuverfolgen, die jeder Mandant generiert. Dann berechnen Sie Ihre Kunden entsprechend.
  • Dedizierter Cluster: Wenn ein Cluster einem einzelnen Mandanten zugeordnet ist, ist es einfach, die Kosten von Azure-Ressourcen wieder an den Kunden zu berechnen. Die Gesamtbetriebskosten hängen von vielen Faktoren ab, einschließlich der Anzahl und Größe von VMs, den Netzwerkkosten für Netzwerkdatenverkehr, öffentlichen IP-Adressen, Lastenausgleichsdiensten und den Speicherdiensten, z. B. verwaltete Datenträger oder Azure-Dateien, die von der Mandantenlösung verwendet werden. Sie können einen AKS-Cluster und seine Ressourcen in der Knotenressourcengruppe markieren, um Kostenaufladungen zu vereinfachen. Weitere Informationen finden Sie unter Hinzufügen von Tags zum Cluster.
  • Dedizierter Knotenpool: Sie können ein Azure-Tag auf einen neuen oder vorhandenen Knotenpool anwenden, der einem einzelnen Mandanten zugeordnet ist. Tags werden auf jeden Knoten innerhalb des Knotenpools angewendet und werden durch Upgrades beibehalten. Tags werden auch auf neue Knoten angewendet, die während der Skalierungsvorgänge einem Knotenpool hinzugefügt werden. Das Hinzufügen eines Tags kann bei Aufgaben wie der Richtliniennachverfolgung oder der Kostenaufladung hilfreich sein. Weitere Informationen finden Sie unter Hinzufügen von Tags zu Knotenpools.
  • Andere Ressourcen: Sie können Tags verwenden, um Kosten dedizierter Ressourcen einem bestimmten Mandanten zuzuordnen. Insbesondere können Sie öffentliche IP-Adressen, Dateien und Datenträger mithilfe eines Kubernetes-Manifests markieren. Auf diese Weise festgelegte Tags verwalten die Kubernetes-Werte, auch wenn Sie sie später mithilfe einer anderen Methode aktualisieren. Wenn öffentliche IP-Adressen, Dateien oder Datenträger über Kubernetes entfernt werden, werden alle Tags entfernt, die Kubernetes festlegt. Tags für Ressourcen, die Kubernetes nicht nachverfolgt, bleiben nicht betroffen. Weitere Informationen finden Sie unter Hinzufügen von Tags mithilfe von Kubernetes.

Sie können Open-Source-Tools wie KubeCostverwenden, um die Kosten eines AKS-Clusters zu überwachen und zu steuern. Sie können die Kostenzuweisung auf eine Bereitstellung, einen Dienst, eine Bezeichnung, einen Pod und einen Namespace festlegen, was Ihnen Flexibilität bei der Kostenaufladung oder dem Anzeigen von Benutzern des Clusters bietet. Weitere Informationen finden Sie unter Cost Governance mit Kubecost.

Weitere Informationen zur Messung, Zuordnung und Optimierung der Kosten für eine mehrinstanzenfähige Anwendung finden Sie unter Architekturansätze für Kostenmanagement und Zuordnung in einer multiinstanzenübergreifenden Lösung. Allgemeine Anleitungen zur Kostenoptimierung finden Sie im Azure Well-Architected Framework-Artikel Übersicht über die Kostenoptimierung.

Governance

Wenn mehrere Mandanten dieselbe Infrastruktur nutzen, können die Verwaltung von Datenschutz, Compliance und behördlichen Anforderungen kompliziert werden. Sie müssen starke Sicherheitsmaßnahmen und Datengovernancerichtlinien implementieren. Freigegebene AKS-Cluster stellen ein höheres Risiko für Datenschutzverletzungen, unbefugten Zugriff und Nichtkompatibilität mit Datenschutzbestimmungen dar. Jeder Mandant verfügt möglicherweise über eindeutige Datengovernanceanforderungen und Compliancerichtlinien, die es schwierig machen, die Sicherheit und den Datenschutz der Daten zu gewährleisten.

Microsoft Defender für Container ist eine cloudeigene Containersicherheitslösung, die Bedrohungserkennungs- und Schutzfunktionen für Kubernetes-Umgebungen bereitstellt. Mithilfe von Defender für Container können Sie Ihren Datengovernance- und Compliancestatus verbessern, wenn Sie mehrere Mandanten in einem Kubernetes-Cluster hosten. Verwenden Sie Defender für Container, um vertrauliche Daten zu schützen, Bedrohungen zu erkennen und darauf zu reagieren, indem Sie containerverhalten und Netzwerkdatenverkehr analysieren und behördliche Anforderungen erfüllen. Es bietet Überwachungsfunktionen, Protokollverwaltung und Berichterstellung, um die Einhaltung von Regulierungsbehörden und Auditoren zu demonstrieren.

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautor:

Andere Mitwirkende: