Bearbeiten

Share via

Überlegungen zur Mehrinstanzenfähigkeit mit Azure Kubernetes Service (AKS)

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) vereinfacht die Bereitstellung eines Managed Kubernetes-Clusters in Azure, indem der Betriebsaufwand auf die Azure Cloud-Plattform ausgelagert wird. Azure führt als gehosteter Kubernetes-Dienst wichtige Aufgaben aus, z. B. Systemüberwachung und Wartung. Die Azure-Plattform verwaltet die AKS-Steuerungsebene, und Sie zahlen nur für die AKS-Knoten, die Ihre Anwendungen ausführen.

AKS-Cluster können über mehrere Mandanten hinweg in unterschiedlichen Szenarien und auf verschiedene Weisen freigegeben 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, eine für jeden Mandanten. Alle diese Arten der Freigabe werden häufig mit dem Sammelbegriff Mehrinstanzenfähigkeit beschrieben. Kubernetes verfügt über kein erstklassiges Konzept für Endbenutzer oder Mandanten. Dennoch bietet es mehrere Features, die Ihnen helfen, unterschiedliche Anforderungen an die Instanzenfähigkeit zu verwalten.

In diesem Artikel werden einige der Features von AKS vorgestellt, die beim Aufbau eines mehrinstanzenfähigen Systems nützlich sind. Allgemeine Anleitungen und bewährte Methoden für Mehrinstanzenfähigkeit von Kubernetes finden Sie in der Kubernetes-Dokumentation.

Arten von Mehrinstanzenfähigkeit

Der erste Schritt zum Ermitteln der Methode zum Freigeben eines AKS-Clusters für mehrere Mandanten besteht darin, die Muster und Tools zu evaluieren, die Ihnen zur Verfügung stehen. Im Allgemeinen fällt Mehrinstanzenfähigkeit von Kubernetes-Clustern in zwei Hauptkategorien, obwohl noch zahlreiche Varianten möglich sind. In der Kubernetes-Dokumentation werden zwei gängige Anwendungsfälle für Mehrinstanzenfähigkeit beschrieben: mehrere Teams und mehrere Kunden.

Mehrere Teams

Eine gängige Form der Mehrinstanzenfähigkeit besteht darin, einen Cluster zwischen mehreren Teams innerhalb einer Organisation freizugeben. 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 wie einer relationalen Datenbank, einem NoSQL-Repository oder einem Messagingsystem kommunizieren, die im selben Cluster gehostet oder als PaaS-Dienste 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 Freigabeautomatisierungstools.

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

Mehrere Kunden

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

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

Isolationsmodelle

Gemäß der Kubernetes-Dokumentation wird ein mehrinstanzenfähiger Kubernetes-Cluster von mehreren Benutzern und Workloads gemeinsam genutzt, die gemeinhin als Mandanten bezeichnet werden. Diese Definition umfasst Kubernetes-Cluster, die verschiedene Teams oder Abteilungen innerhalb einer Organisation gemeinsam nutzen. Sie umfasst ferner Cluster, die von Kundeninstanzen einer SaaS-Anwendung (Software-as-a-Service) gemeinsam genutzt werden.

Mehrinstanzenfähige Cluster sind eine gute Alternative zur Verwaltung vieler dedizierter Cluster mit einzelnen Mandanten. Die Operatoren eines mehrinstanzenfähigen Kubernetes-Clusters müssen Mandanten voneinander isolieren. Diese Isolation minimiert den Schaden, den ein kompromittierter oder böswilliger Mandant dem Cluster und anderen Mandanten zufügen kann.

Wenn mehrere Benutzer oder Teams denselben Cluster mit einer festen Anzahl von Knoten gemeinsam nutzen, besteht die Gefahr, dass ein Team mehr als den ihm zustehenden Ressourcenanteil nutzen könnte. Ressourcenkontingente sind ein Tool, mit dem Administratoren dieses Problem beheben können.

Basierend auf der Sicherheitsstufe, die von der Isolation bereitgestellt wird, können wir zwischen „weicher“ und „harter“ Mehrinstanzenfähigkeit unterscheiden.

  • Weiche Mehrinstanzenfähigkeit eignet sich innerhalb eines einzelnen Unternehmens, in dem Mandanten aus unterschiedlichen Teams oder Abteilungen bestehen, die einander vertrauen. In diesem Szenario soll die Isolation die Integrität von Workloads garantieren, Clusterressourcen über verschiedene internen Benutzergruppen hinweg orchestrieren und vor möglichen Angriffen auf die Sicherheit schützen.
  • Harte Mehrinstanzenfähigkeit wird verwendet, um Szenarien zu beschreiben, in denen sich heterogene Mandanten gegenseitig nicht vertrauen – häufig aufgrund von Sicherheits- und Ressourcenfreigabeerwägungen.

Wenn Sie einen mehrinstanzenfähigen Azure Kubernetes Service-Cluster (AKS) erstellen möchten, sollten Sie die von Kubernetes bereitgestellten Ebenen der Ressourcenisolation und Mehrinstanzenfähigkeit berücksichtigen:

  • Cluster
  • Namespace
  • Knotenpool oder Knoten
  • Pod
  • Container

Zusätzlich sollten Sie die Sicherheitsrisiken berücksichtigen, die sich ergeben, wenn mehrere Mandanten verschiedene Ressourcen gemeinsam nutzen. Durch die Planung von Pods verschiedener Mandanten auf demselben Knoten kann beispielsweise die Anzahl der im Cluster benötigten Computer reduziert werden. Andererseits müssen Sie möglicherweise verhindern, dass bestimmte Workloads am selben Ort angesiedelt werden. So sollten Sie beispielsweise die Ausführung von nicht vertrauenswürdigem Code von außerhalb Ihres Unternehmens nicht auf demselben Knoten zulassen, auf dem auch Container ausgeführt werden, die vertrauliche Informationen verarbeiten.

Kubernetes kann zwar keine absolut sichere Isolation zwischen Mandanten garantieren, verfügt jedoch über Sicherheitsfeatures, die für bestimmte Anwendungsfälle ausreichend sind. Als bewährte Methode empfiehlt es sich, jeden Mandanten und seine Kubernetes-Ressourcen in eigene Namespaces zu untergliedern und so zu trennen. Anschließend können Sie dann rollenbasierte Zugriffssteuerung in Kubernetes (RBAC) und Netzwerkrichtlinien verwenden, um die Mandantenisolation zu erzwingen. Die folgende Abbildung zeigt beispielsweise ein typisches SaaS-Anbietermodell, das mehrere Instanzen derselben Anwendung im selben Cluster hostet, eine für jeden Mandanten. Jede Anwendung befindet sich in einem separaten Namespace.

Diagram that shows a SaaS provider model that hosts multiple instances of the same application on the same cluster.

Es gibt mehrere Möglichkeiten zum Entwerfen und Erstellen mehrinstanzenfähiger Lösungen mit Azure Kubernetes Service (AKS). Jede dieser Methoden verfügt über eine Reihe individueller Kompromisse hinsichtlich Infrastrukturbereitstellung, die Netzwerktopologie und Sicherheit. Diese Methoden wirken sich auf die Isolationsstufe, den Implementierungsaufwand, die Komplexität des Betriebs sowie die Kosten aus. Sie können die Mandantenisolation auf der Steuerungs- und Datenebene gemäß Ihren Anforderungen anwenden.

Isolation auf Steuerungsebene

Wenn Sie die Isolation auf der Steuerungsebene eingerichtet haben, garantieren Sie, dass verschiedene Mandanten nicht gegenseitig auf ihre Ressourcen zugreifen können, z. B. Pods und Dienste. Außerdem können sie nicht gegenseitig die Leistung von Anwendungen anderer Mandanten beeinflussen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Isolation auf Steuerungsebene. Die beste Möglichkeit zum Implementieren der Isolation auf Steuerungsebene besteht darin, die Workload jedes Mandanten und seine Kubernetes-Ressourcen in einen jeweils separaten Namespace zu trennen.

Gemäß der Kubernetes-Dokumentation ist ein Namespace eine Abstraktion, die verwendet wird, um die Isolierung von Ressourcengruppen innerhalb eines einzelnen Clusters zu unterstützen. Namespaces können verwendet werden, um Workloads von Mandanten zu isolieren, die einen Kubernetes-Cluster gemeinsam nutzen:

  • Namespaces ermöglichen, dass unterschiedliche Mandantenworkloads in ihren eigenen virtuellen Arbeitsbereichen existieren, ohne dass das Risiko besteht, die Arbeit des jeweils anderen zu beeinflussen. Gesonderte Teams innerhalb einer Organisation können Namespaces verwenden, um ihre Projekte voneinander zu isolieren, da sie dieselben Ressourcennamen in unterschiedlichen Namespaces verwenden können, ohne dass das Risiko einer Überlappung zwischen den Namen besteht.
  • RBAC-Rollen und Rollenbindungen sind auf einen Namespace beschränkte Ressourcen, mit denen Teams Benutzer und Prozesse von Mandanten so einschränken können, dass sie nur auf Ressourcen und Dienste in ihren eigenen Namespaces zugreifen können. Verschiedene Teams können Rollen definieren, um Listen von 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 auf einen Namespace bezogene Objekte. Teams können sie verwenden, um sicherzustellen, dass Workloads, die denselben Cluster gemeinsam nutzen, streng von einem Systemressourcenverbrauch 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 zur Ausführung benötigt, und dass „Noisy Neighbor“-Probleme (Beeinträchtigung durch andere Mandanten) vermieden werden, die andere Mandantenanwendungen beeinträchtigen könnten, die denselben Cluster verwenden.
  • Netzwerkrichtlinien sind auf einen Namespace bezogene Objekte, die Teams einführen können, um zu erzwingen, welcher Netzwerkdatenverkehr für eine bestimmte Mandantenanwendung zugelassen wird. Sie können Netzwerkrichtlinien verwenden, um unterschiedliche Workloads, die denselben Cluster verwenden, unter Netzwerkaspekten voneinander zu trennen.
  • 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 Steuerungsebene zu verbessern. Wenn Workloads in einem freigegebenen Cluster in mehreren Namespaces organisiert sind, verfügt die Kubernetes-API über weniger Elemente, die beim Ausführen von Vorgängen durchsucht werden müssen. Diese Organisationsweise kann die Wartezeit bei Aufrufen an den API-Server verringern und den Durchsatz auf Steuerungsebene erhöhen.

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

Isolation auf Datenebene

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

Netzwerkisolation

Wenn Sie moderne, auf Microservices basierende Anwendungen in Kubernetes ausführen, können Sie 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 gemeinsam denselben Cluster nutzen. Zur Verbesserung der Sicherheit können Sie Netzwerkregeln definieren, die den Datenverkehrsfluss steuern. Eine 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 gemeinsam denselben Cluster nutzen.

Azure Kubernetes Service (AKS) bietet zwei Möglichkeiten zum Implementieren von Netzwerkrichtlinien:

  1. Azure verfügt über eine eigene Implementierung für Netzwerkrichtlinien, die als Azure-Netzwerkrichtlinien bezeichnet wird.
  2. Calico-Netzwerkrichtlinien sind eine von Tigera gegründete Open-Source-Netzwerk- und -Netzwerkrichtlinienlösung.

Beide Implementierungen verwenden Linux IPTables, um die angegebenen Richtlinien durchzusetzen. Netzwerkrichtlinien werden in Gruppen aus Paaren zulässiger und unzulässiger IP-Adressen übersetzt. Diese Paare werden anschließend als IPTable-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 Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service.

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

Speicherisolation

Azure bietet eine umfangreiche Gruppe verwalteter, PaaS-Datenrepositorys (Platform-as-a-Service), z. B. 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 gemeinsam genutzten AKS-Cluster ausgeführt werden, können eine Datenbank oder einen Dateispeicher gemeinsam nutzen, oder sie können eine dedizierte Datenspeicher- und Speicherressource verwenden. 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 mehrinstanzenfähigen Lösungen.

Workloads, die auf Azure Kubernetes Service (AKS) ausgeführt werden, können auch persistente Volumes zum Speichern von Daten verwenden. In Azure können Sie persistente Volumes als Kubernetes-Ressourcen erstellen, die von Azure Storage unterstützt werden. Sie können Datenvolumes manuell erstellen und sie Pods direkt zuweisen, oder Sie können sie automatisch von AKS mithilfe persistenter Volumeansprüche erstellen lassen. AKS stellt integrierte Speicherklassen bereit, um persistente Volumes zu erstellen, die von Azure-Datenträgern, Azure Files und Azure NetApp Files unterstützt werden. Weitere Informationen finden Sie unter Speicheroptionen für die Anwendung in Azure Kubernetes Service (AKS). Aus Gründen der Sicherheit und Resilienz sollten Sie vermeiden, lokalen Speicher auf Agent-Knoten über emptyDir und hostPath zu verwenden.

Wenn sich die integrierten Speicherklassen von AKS nicht gut für einen oder mehrere Mandanten eignen, können Sie benutzerdefinierte Speicherklassen erstellen, um unterschiedliche Mandantenanforderungen zu erfüllen. Diese Anforderungen umfassen Volumegröße, Speicher-SKU, eine Vereinbarung zum Servicelevel (SLA), Sicherungsrichtlinien und den Tarif.

So können Sie beispielsweise eine benutzerdefinierte Speicherklasse für jeden Mandanten konfigurieren. Diese können Sie dann verwenden, um Tags auf jedes persistente Volume anzuwenden, das im jeweiligen Namespace erstellt wird, um die verbrauchsbasierte Kostenzuteilung wiederum auf diese umzulegen. Weitere Informationen zu diesem Szenario finden Sie unter Verwenden von Azure-Tags in Azure Kubernetes Service (AKS).

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

Knotenisolation

Sie können Workloads von Mandanten so konfigurieren, dass sie auf separaten Agent-Knoten ausgeführt werden, um das „Noisy Neighbor“-Problem (Beeinträchtigung durch andere Mandanten) zu vermeiden sowie das Risiko der Offenlegung von Informationen zu verringern. In AKS können Sie einen separaten Cluster oder lediglich einen dedizierten Knotenpool für Mandanten erstellen, die strenge Anforderungen an Isolation, Sicherheit, Einhaltung gesetzlicher Bestimmungen und Leistung stellen.

Sie können Taints, Toleranzen, Knotenbezeichnungen, Knotenselektoren und Knotenaffinität verwenden, um Mandantenpods so einzuschränken, dass sie nur auf einer bestimmten Gruppe von Knoten oder Knotenpools ausgeführt werden.

Allgemein gesprochen bietet AKS Workloadisolation auf verschiedenen Ebenen:

  • Auf Kernelebene, indem Mandantenworkloads auf einfachen VMs auf freigegebenen Agentknoten ausgeführt werden und Pod Sandboxing basierend auf Kata-Containern eingesetzt wird.
  • Auf physischer Ebene, indem Mandantenanwendungen in dedizierten Clustern oder Knotenpools gehostet werden.
  • Auf Hardwareebene, indem Mandantenworkloads auf dedizierten Azure-Hosts ausgeführt werden, die garantieren, dass Agent-Knoten-VMs dedizierte physische Computer ausführen. Die Hardwareisolation stellt sicher, dass keine anderen VMs auf den dedizierten Hosts platziert werden, was für eine zusätzliche Isolationsebene für Mandantenworkloads sorgt.

Sie können diese Techniken kombinieren. Beispielsweise können Sie Cluster und Knotenpools pro Mandant in einer Azure Dedicated Host-Gruppe ausführen, um Workloads zu trennen und physische Isolation auf Hardwareebene zu herzustellen. Sie können auch pro Mandant freigegebene oder mandantenspezifische Knotenpools erstellen, die dne FIPS (Federal Information Process Standard), Confidential Virtual Machines (CVM) oder hostbasierte Verschlüsselung unterstützen.

Knotenisolation ermöglicht es Ihnen, die Kosten für eine Gruppe von Knoten oder einen Knotenpool einfach verbrauchsbasiert auf einen einzelnen Mandanten umzulegen. Sie steht in strenger Beziehung zu dem Mandantenmodell, das von Ihrer Lösung verwendet wird.

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

Mandantenmodelle

Azure Kubernetes Service (AKS) bietet mehr Typen von Knotenisolations- und Mandantenmodellen.

Automatisierte Bereitstellungen mit einem Mandanten

In einem automatisierten Bereitstellungsmodell mit nur einem Mandanten stellen Sie einen dedizierten Satz von Ressourcen für jeden Mandanten bereit, wie im folgenden Beispiel veranschaulicht:

Diagram showing three tenants, each with separate deployments.

Jede Workload des Mandanten wird in einem dedizierten AKS-Cluster ausgeführt und greift auf eine bestimmte Gruppe von Azure-Ressourcen zu. In der Regel nutzen mehrinstanzenfähige Lösungen, die mit diesem Modell erstellt werden, in hohem Maße Infrastructure-as-Code (IaC). Beispielsweise helfen Bicep, Azure Resource Manager (ARM), Terraform oder die Azure Resource Manager-REST-APIs dabei, die bedarfsgesteuerte Bereitstellung dedizierter Ressourcen für Mandanten zu initiieren und zu koordinieren. Sie können diesen Ansatz verwenden, wenn Sie jedem Ihrer Kunden eine vollständig gesonderte Infrastruktur bereitstellen müssen. Erwägen Sie bei der Planung Ihrer Bereitstellung die Verwendung des Musters „Bereitstellungsstempel“.

Vorteile:

  • Ein wichtiger Vorteil dieses Ansatzes besteht darin, dass der API-Server jedes Mandanten-AKS-Clusters getrennt ist. Dieser Ansatz garantiert eine mandantenübergreifende vollständige Isolation auf Sicherheits-, Netzwerk- und Ressourcenverbrauchsebene. Ein Angreifer, dem es gelingt, die Kontrolle über einen Container zu übernehmen, hat dann nur Zugriff auf die Container und eingebundenen Volumes, die zu einem einzelnen Mandanten gehören. Ein Mandantenmodell mit vollständiger Isolation ist für einige Kunden mit hohem Aufwand zur Einhaltung gesetzlicher Bestimmungen von kritischer Bedeutung.
  • Es ist unwahrscheinlich, dass Mandanten gegenseitig ihre Systemleistung beeinflussen, was Ihnen erlaubt, das „Noisy Neighbor“-Problem (Beeinträchtigung durch andere Mandanten) zu vermeiden. Diese Erwägung umfasst den Datenverkehr des API-Servers. Der API-Server ist eine gemeinsam genutzte, kritische Komponente in jedem Kubernetes-Cluster. Benutzerdefinierte Controller, die unregulierten Datenverkehr mit hohem Volumen auf dem API-Server generieren, können zur Instabilität des Clusters führen. Diese Instabilität führt zu Anforderungsfehlern, Timeouts und übermäßigen API-Wiederholungsversuchen. Mit der Funktion Uptime SLA (Vereinbarung zum Servicelevel für Uptime) können Sie die Steuerungsebene eines AKS-Clusters aufskalieren, um die Datenverkehrsanforderungen zu erfüllen. Dennoch kann die Bereitstellung eines dedizierten Clusters immer noch eine bessere Lösung für diese Kunden mit hohen Anforderungen an die Workloadisolation darstellen.
  • Updates und Änderungen können mandantenübergreifend progressiv eingeführt werden, wodurch sich die Wahrscheinlichkeit eines systemweiten Ausfalls verringert. Azure-Kosten können problemlos verbrauchsbasiert auf Mandanten umgelegt werden, da jede Ressource von einem einzelnen Mandanten verwendet wird.

Risiken:

  • Die Kosteneffizienz ist niedrig, da jeder Mandant eine dedizierte Gruppe von Ressourcen verwendet.
  • Die laufende Wartung ist wahrscheinlich zeitaufwendig, da sie auf mehreren AKS-Clustern repliziert werden muss – einer für jeden Mandanten. Ziehen Sie in Erwägung, Ihre Betriebsprozesse zu automatisieren und Änderungen progressiv in Ihren Umgebungen anzuwenden. Es wäre außerdem hilfreich, wenn Sie auch andere bereitstellungsübergreifende Vorgänge in Betracht zögen, z. B. die Erstellung von Berichten und Analysen für Ihren gesamten Ressourcen- und Datenbestand. Stellen Sie außerdem sicher, dass Sie planen, wie Sie Daten über mehrere Bereitstellungen hinweg abfragen und bearbeiten.

Vollständig mehrinstanzenfähige Bereitstellungen

In einer vollständig mehrinstanzenfähigen Bereitstellung bedient eine einzelne Anwendung die Anforderungen aller Mandanten, und alle Azure-Ressourcen werden gemeinsam genutzt, einschließlich des AKS-Clusters. In diesem Kontext verfügen Sie nur über einen Infrastruktursatz, den Sie bereitstellen, überwachen und verwalten müssen. Alle Mandanten verwenden die Ressource, wie im folgenden Diagramm dargestellt:

Diagram showing three tenants, all using a single shared deployment.

Vorteile:

  • Dieses Modell ist aufgrund der geringeren Kosten für den Betrieb 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 gemeinsam genutzten Datenrepositorys einführen, um den von den Ressourcen aller Mandanten, z. B. Datenrepositorys, generierten Datenverkehr aufrechtzuerhalten.

Risiken:

  • In diesem Kontext 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önnten das gesamte System verlangsamen und alle Mandanten beeinträchtigen.
  • Wenn das Datenverkehrsprofil in hohem Maße variabel ist, sollten Sie die Autoskalierung des AKS-Clusters so konfigurieren, dass die Anzahl der Pods und Agent-Knoten variiert wird. Verwenden Sie als Basis ihrer Konfiguration die Systemressourcennutzung, z. B. CPU und Arbeitsspeicher. Alternativ können Sie die Anzahl der Pods und Clusterknoten auf Grundlage benutzerdefinierter Metriken auf- und abskalieren. Sie können z. B. die Anzahl der ausstehenden Anforderungen oder die Metriken eines externen Messagingsystems untersuchen, das Kubernetes Event-Driven Autoscaling (KEDA, ereignisgesteuerte Autoskalierung von Kubernetes) verwendet.
  • Stellen Sie sicher, dass Sie die Daten für jeden Mandanten separieren und Schutzmaßnahmen implementieren, um Datenlecks zwischen verschiedenen Mandanten zu vermeiden.
  • Stellen Sie sicher, dass Sie die Azure-Kosten basierend auf ihrer tatsächlichen Nutzung nachverfolgen und einzelnen Mandanten zuordnen. Drittanbieterlösungen wie kubecost können Ihnen helfen, Kosten über verschiedene Teams und Mandanten hinweg zu berechnen und aufzuschlüsseln.
  • Die Wartung kann sich mit einer einzelnen Bereitstellung einfacher gestalten, da Sie nur eine Gruppe von Azure-Ressourcen aktualisieren und eine einzelne Anwendung verwalten müssen. Diese Konstellation ist jedoch auch häufig riskanter, da sich alle Änderungen an der Infrastruktur oder an Anwendungskomponenten auf die gesamte Kundenbasis auswirken können.
  • Sie sollten auch Skalierungseinschränkungen berücksichtigen. Wenn Sie eine gemeinsam genutzte Gruppe von Ressourcen verwenden, ist die Wahrscheinlichkeit höher, dass Sie Skalierungsgrenzwerte für Azure-Ressourcen erreichen. Um zu vermeiden, dass ein Ressourcenkontingentlimit erreicht wird, sollten Sie erwägen, Ihre Mandanten auf mehrere Azure-Abonnements zu verteilen.

Horizontal partitionierte Bereitstellungen

Alternativ können Sie die horizontale Partitionierung Ihrer mehrinstanzenfähigen Kubernetes-Anwendung in Betracht ziehen. Dieser Ansatz besteht darin, einige Lösungskomponenten für alle Mandanten freizugeben und dedizierte Ressourcen für einzelne Mandanten bereitzustellen. Beispielsweise können Sie eine einzelne mehrinstanzenfähige Kubernetes-Anwendung erstellen und dann für jeden Mandanten eine einzelne Datenbank bereitstellen, wie in der folgenden Abbildung gezeigt:

Diagram showing three tenants, each using a dedicated database and a single, shared Kubernetes application.

Vorteile:

  • Horizontal partitionierte Bereitstellungen können Ihnen helfen, das „Noisy Neighbor“-Problem (Beeinträchtigung durch andere Mandanten) abzumildern. Berücksichtigen Sie diesen Ansatz, wenn Sie festgestellt haben, dass der Großteil der Datenverkehrslast für Ihre Kubernetes-Anwendung auf bestimmte Komponenten zurückzuführen ist, die Sie separat für jeden Mandanten bereitstellen können. Ihre Datenbanken können z. B. den größten Teil der Systemlast aufnehmen, da die Abfragelast hoch ist. Wenn ein einzelner Mandant eine große Anzahl von Anforderungen an Ihre Lösung sendet, kann sich dies negativ auf die Leistung einer Datenbank auswirken, aber die Datenbanken anderer Mandanten (und freigegebene Komponenten wie die Anwendungsebene) werden davon nicht betroffen.

Risiken:

  • Bei einer horizontal partitionierten Bereitstellung müssen Sie weiterhin die automatisierte Bereitstellung und Verwaltung Ihrer Komponenten berücksichtigen, insbesondere die Komponenten, die von einem einzelnen Mandanten verwendet werden.
  • Dieses Modell stellt möglicherweise nicht die erforderliche Isolationsstufe für diese Kunden bereit, die es sich wegen interner Richtlinien oder aus Gründen der Compliance nicht leisten können, Ressourcen gemeinsam mit anderen Mandanten zu nutzen.

Vertikal partitionierte Bereitstellungen

Sie können die Vorteile der einzelinstanzfähigen und mehrinstanzenfähigen Modelle nutzen, indem Sie ein Hybridmodell verwenden, das Mandanten über mehrere AKS-Cluster oder -Knotenpools hinweg horizontal partitioniert. Dieser Ansatz bietet die folgenden Vorteile gegenüber den vorherigen beiden Mandantenmodellen:

  • Sie können eine Kombination aus Bereitstellungen mit einem Mandanten und mehrinstanzenfähigen Bereitstellungen verwenden. So können Sie beispielsweise dafür sorgen, dass die meisten Ihrer Kunden einen AKS-Cluster und eine Datenbank in einer mehrinstanzenfähigen Infrastruktur gemeinsam nutzen. Dennoch können Sie auch weiterhin Infrastrukturen mit nur einem Mandanten für die Kunden bereitstellen, die höhere Leistung und Isolation erfordern.
  • Sie können Mandanten auf mehreren regionalen AKS-Clustern bereitstellen, potenziell mit unterschiedlichen Konfigurationen. Diese Methode ist am effektivsten, wenn Sie Mandanten haben, die sich auf verschiedene Regionen ausdehnen.

Sie können verschiedene Varianten dieses Mandantenmodells implementieren. Beispielsweise können Sie sich entschließen, Ihre mehrinstanzenfähige Lösung mit unterschiedlichen Funktionalitätsebenen zu unterschiedlichen Kosten anzubieten. Ihr Preismodell könnte mehrere SKUs bereitstellen, die jeweils eine inkrementelle Leistungs- und Isolationsebene hinsichtlich Ressourcenfreigabe, Leistung, Netzwerk und Datentrennung bieten. Betrachten Sie die folgenden Ebenen:

  • Basic-Ebene (grundlegend): Die Anforderungen von Mandanten werden von einer einzelnen, mehrinstanzenfähigen Kubernetes-Anwendung bedient, die gemeinsam mit anderen Mandanten genutzt wird. Daten werden in einer oder mehreren Datenbanken gespeichert, die von allen Mandanten der Basic-Ebene gemeinsam genutzt werden.
  • Standard-Ebene: Die Anforderungen von Mandanten werden von einer dedizierten Kubernetes-Anwendung bedient, die in einem separaten Namespace ausgeführt wird, was Isolationsgrenzen hinsichtlich Sicherheit, Netzwerk und Ressourcenverbrauch bereitstellt. Alle Anwendungen des Mandanten, eine für jeden Mandanten, nutzen denselben AKS-Cluster und -Knotenpool gemeinsam mit anderen Kunden der Standard-Ebene.
  • Premium-Ebene: Die Mandantenanwendung wird in einem dedizierten Knotenpool oder AKS-Cluster ausgeführt, um eine höhere Vereinbarung zum Servicelevel (Service Level Agreement, SLA), bessere Leistung sowie einen stärkeren Isolationsgrad zu gewährleisten. Diese Ebene kann ein flexibles Kostenmodell auf Grundlage der Anzahl und SKU der Agent-Knoten bereitstellen, die zum Hosten der Mandantenanwendung verwendet werden. Sie können Pod Sandboxing als alternative Lösung zur Verwendung dedizierter Cluster oder Knotenpools verwenden, um verschiedene Mandantenworkloads voneinander zu isolieren.

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

Diagram showing three tenants. Tenants A and B share an AKS cluster. Tenant C has a dedicated AKS cluster.

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

Diagram showing three tenants. Tenants A and B share a node pool. Tenant C has a dedicated node pool.

Dieses Modell kann auch unterschiedliche Vereinbarungen zum Servicelevel für verschiedene Ebenen/Tarife bieten. Beispielsweise kann die Basic-Ebene 99,9 % Uptime anbieten, die Standard-Ebene kann 99,95 % Uptime anbieten, und die Premium-Ebene kann 99,99 % anbieten. Die höhere Vereinbarung zum Servicelevel (SLA) könnte mithilfe von Diensten und Features implementiert werden, die höhere Verfügbarkeitsziele ermöglichen.

Vorteile:

  • Da Sie die Infrastruktur weiterhin gemeinsam nutzen, können Sie trotzdem einige der Kostenvorteile erzielen, die sich aus gemeinsam genutzten mehrinstanzenfähigen Bereitstellungen ergeben. Sie können Cluster und Knotenpools bereitstellen, die über mehrere Mandantenanwendungen der Basic- und Standard-Ebene hinweg gemeinsam genutzt werden, die eine kostengünstigere VM-Größe für Agent-Knoten verwenden. Dieser Ansatz garantiert eine bessere Dichte und höhere 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, Konnectivity oder Azure Application Gateway-Eingangsdatencontroller in einem dedizierten Knotenpool im Systemmodus ausführen. Sie können Taints, Toleranzen, Knotenbezeichnungen, Knotenselektoren und Knotenaffinität verwenden, um eine Mandantenanwendung auf einem oder mehreren Knotenpools im Benutzermodus auszuführen.
  • Sie können Taints, Toleranzen, Knotenbezeichnungen, Knotenselektoren und Knotenaffinität verwenden, um gemeinsam genutzte Ressourcen auszuführen. Beispielsweise können Sie über einen Eingangsdatencontroller oder ein Messagingsystem auf einem dedizierten Knotenpool mit einer bestimmten VM-Größe, bestimmten Autoskalierungseinstellungen und einer spezifischen Unterstützung für Verfügbarkeitszonen verfügen.

Risiken:

  • Sie müssen Ihre Kubernetes-Anwendung so entwerfen, dass sie sowohl mehrinstanzenfähige Bereitstellungen als auch Bereitstellungen mit nur einem Mandanten unterstützt.
  • Wenn Sie Migration zwischen Infrastrukturen zulassen möchten, müssen Sie berücksichtigen, wie Sie Kunden aus einer mehrinstanzenfähigen Bereitstellung zu ihrer eigenen Bereitstellung mit nur einem Mandanten migrieren.
  • Sie benötigen eine konsistente Strategie und eine einzelne zentralisierte Oberfläche, um mehr AKS-Cluster zu überwachen und zu verwalten.

Automatische Skalierung

Um mit den Anforderungen des von den Mandantenanwendungen generierten Datenverkehrs Schritt zu halten, können Sie die Autoskalierung des Clusters aktivieren, um die Agent-Knoten Ihres Azure Kubernetes Service (AKS) zu skalieren. Die automatische Skalierung hilft Systemen dabei, unter folgenden Umständen reaktionsfähig zu bleiben:

  • Die Datenverkehrslast wächst während bestimmter Arbeitszeiten oder Zeiträume des Jahres.
  • Mandantenlasten oder gemeinsam genutzte hohe Lasten werden in einem Cluster bereitgestellt.
  • Agent-Knoten werden aufgrund von Zonenausfällen nicht verfügbar.

Wenn Sie die automatische Skalierung für einen Knotenpool aktivieren, geben Sie eine Mindest- und eine Höchstanzahl von Knoten an, basierend auf den erwarteten Workloadgrößen. Durch die Konfiguration einer Höchstanzahl von Knoten können Sie ausreichenden Speicherplatz für alle Mandantenpods im Cluster sicherstellen, unabhängig vom Namespace, in dem sie ausgeführt werden.

Wenn der Datenverkehr anwächst, fügt die automatische Skalierung des Clusters neue Agent-Knoten hinzu, um zu vermeiden, dass Pods in den Zustand „Ausstehend“ wechseln, weil zu wenige Ressourcen hinsichtlich CPU und Arbeitsspeicher vorhanden sind.

Ebenso verringert die automatische Skalierung des Clusters die Anzahl der Agent-Knoten in einem Knotenpool, wenn sich die Last verringert, basierend auf den angegebenen Grenzen, wodurch Ihre Betriebskosten verringert werden.

Sie können automatische Skalierung für Pods verwenden, um Pods automatisch auf Grundlage der Ressourcenanforderungen zu skalieren. Horizontal Pod Autoscaler (HPA, horizontale Pod-Autoskalierung) skaliert automatisch die Anzahl der Podreplikate, basierend auf der CPU-/Arbeitsspeicherauslastung oder benutzerdefinierten Metriken. Mit Kubernetes Event-Driven Autoscaling (KEDA, ereignisgesteuerte Autoskalierung von Kubernetes) können Sie die Skalierung eines beliebigen Containers in Kubernetes steuern, basierend auf der Anzahl der Ereignisse von externen Systemen, z. B. Azure Event Hubs oder Azure Service Bus, die von Mandantenanwendungen verwendet werden.

Wartung

Um das Risiko von Ausfallzeiten zu verringern, die sich während Cluster- oder Knotenpoolupgrades auf Mandantenanwendungen auswirken können, planen Sie die Durchführung geplanter AKS-Wartungen während der Nebenzeiten. Mit der geplanten Wartung können Sie wöchentliche Wartungsfenster planen, um die Steuerungsebene der AKS-Cluster zu aktualisieren, die Mandantenanwendungen und Knotenpools ausführen, wodurch die Auswirkungen auf Workloads minimiert werden. Sie können ein oder mehrere wöchentliche Wartungsfenster für Ihren Cluster planen, indem Sie einen Tagesbereich oder einen Uhrzeitbereich an einem bestimmten Tag angeben. Alle Wartungsvorgänge werden während der geplanten Zeitfenster ausgeführt.

Sicherheit

Clusterzugriff

Wenn Sie einen AKS-Cluster mit mehreren Teams innerhalb einer Organisation gemeinsam nutzen, müssen Sie das Prinzip der geringsten Rechte implementieren, um unterschiedliche Mandanten voneinander zu isolieren. Insbesondere müssen Sie sicherstellen, dass Benutzer nur Zugriff auf ihre Kubernetes-Namespaces und -Ressourcen haben, wenn sie Tools wie kubectl, Helm, Flux, Argo CD oder andere Arten von Tools verwenden.

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

Workload-Identität

Wenn Sie mehrere Mandantenanwendungen in einem einzelnen AKS-Cluster hosten und jede davon sich in einem separaten Namespace befindet, sollte jede Workload ein anderes Kubernetes-Dienstkonto mit eigenen Anmeldeinformationen verwenden, um auf die Downstream-Azure-Dienste zuzugreifen. Dienstkonten sind einer der Hauptbenutzertypen in Kubernetes. Die Kubernetes-API enthält und verwaltet Dienstkonten. Anmeldeinformationen für Dienstkonten werden als Kubernetes-Geheimnisse gespeichert. Dadurch können sie von autorisierten Pods für die Kommunikation mit dem API-Server verwendet werden. Die meisten API-Anforderungen stellen einen Authentifizierungstoken für ein Dienstkonto oder ein normales Benutzerkonto bereit.

Auf AKS-Clustern bereitgestellt Mandantenworkloads können Microsoft Entra ID-Anwendungsanmeldeinformationen verwenden, um auf durch Microsoft Entra ID geschützte Ressourcen zuzugreifen, z. B. Azure Key Vault und Microsoft Graph. Microsoft Entra Workload ID für Kubernetes lässt sich in die nativen Kubernetes-Funktionen integrieren, um einen Verbund mit beliebigen externen Identitätsanbietern zu erstellen.

Pod Sandboxing

AKS enthält einen Mechanismus namens Pod Sandboxing, der eine Isolationsgrenze zwischen der Containeranwendung. dem freigegebenen Kernel und den Computeressourcen des Containerhosts wie CPU, Arbeitsspeicher und Netzwerk bereitstellt. Pod Sandboxing ergänzt andere Sicherheitsmaßnahmen oder Datenschutzkontrollen, um Mandantenworkloads dabei zu unterstützen, vertrauliche Informationen zu schützen und gesetzliche, branchenspezifische oder Governance-Complianceanforderungen zu erfüllen, z. B. Payment Card Industry Data Security Standard (PCI-DSS), 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 Mandantenworkloads verschiedener Teams oder Kunden stark isolieren. Die Verwendung mehrerer Cluster und Knotenpools kann für die Isolationsanforderungen vieler Organisationen und SaaS-Lösungen geeignet sein. Es gibt aber Szenarien, in denen ein einzelner Cluster mit freigegebenen VM-Knotenpools effizienter ist, z. B. wenn Sie nicht vertrauenswürdige und vertrauenswürdige Pods auf demselben Knoten ausführen oder DaemonSets und privilegierte Container für eine schnellere lokale Kommunikation und funktionale Gruppierung auf demselben Knoten zusammenführen. Pod Sandboxing kann Ihnen helfen, Mandantenanwendungen auf denselben Clusterknoten stark voneinander zu isolieren, ohne diese Workloads in separaten Clustern oder Knotenpools ausführen zu müssen. Andere Methoden erfordern, dass Sie Ihren Code neu kompilieren oder können zu Kompatibilitätsproblemen führen. Demgegenüber kann Pod Sandboxing in AKS jeden Container unverändert innerhalb einer erweiterten VM-Sicherheitsgrenze ausführen.

Pod Sandboxing in AKS basiert auf Kata-Containern, die auf dem Azure Linux-Containerhost für AKS-Stapel ausgeführt werden, um hardwaregestützte Isolation zu bieten. Kata-Container in AKS basieren auf einem sicherheitsgehärteten Azure-Hypervisor. Die Isolation je Pod wird über eine geschachtelte, einfache Kata-VM erreicht, die Ressourcen von einem übergeordneten VM-Knoten verwendet. In diesem Modell erhält jeder Kata-Pod seinen eigenen Kernel in einer geschachtelten Kata-Gast-VM. Mit diesem Modell können Sie viele Kata-Container auf einer einzelnen Gast-VM platzieren, während Sie weiterhin Container auf der übergeordneten VM ausführen. Das Modell bietet eine starke Isolationsgrenze in einem freigegebenen AKS-Cluster.

Weitere Informationen finden Sie unter

Azure Dedicated Host

Azure Dedicated Host ist ein Dienst, der physische Server für ein einzelnes dezidiertes Azure-Abonnement bereitstellt und Hardwareisolation auf der physischen Serverebene bietet. Diese dedizierten Hosts können innerhalb einer Region, Verfügbarkeitszone und Fehlerdomäne bereitgestellt werden, und Sie können VMs direkt in den bereitgestellten Hosts platzieren.

Sie können von mehreren Vorteile profitieren, indem Sie Azure Dedicated Host mit AKS verwenden. Dazu zählen folgende:

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

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

Azure Dedicated Host kann SaaS-Anbietern dabei unterstützen, sicherzustellen, dass Mandantenanwendungen gesetzliche, Branchen- und Governance-Complianceanforderungen zum Schutz vertraulicher Informationen erfüllen. Weitere Informationen finden Sie unter Hinzufügen eines Azure Dedicated Hosts zu einem Azure Kubernetes Service-Cluster (AKS).

Vertrauliche virtuelle Computer

Sie können vertrauliche VMs (Confidential Virtual Machines, CVMs) verwenden, um Ihrem AKS-Cluster einen oder mehrere Knotenpools hinzuzufügen, um strenge Anforderungen der Mandanten an Isolation, Datenschutz und Sicherheit zu erfüllen. CVMs nutzen eine hardwarebasierte vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE). Vertrauenswürdige AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV-SNP)-VMs verweigern dem Hypervisor und anderem Hostverwaltungscode den Zugriff auf VM-Arbeitsspeicher und -Zustand, wodurch eine umfangreiche Schutzebene zum Schutz vor Operatorzugriff hinzugefügt wird. Weitere Informationen finden Sie unter Verwenden von CVMs in einem AKS-Cluster.

Federal Information Processing Standards (FIPS)

Der FIPS 140-3 ist ein Standard für US-Bundesbehörden, der Mindestsicherheitsanforderungen für kryptografische Module in IT-Produkten und -Systemen definiert. Durch Aktivieren der FIPS-Compliance für AKS-Knotenpools können Sie die Isolation, den Datenschutz und die Sicherheit Ihrer Mandantenworkloads verbessern. FIPS-Compliance stellt die Verwendung validierter kryptografischer Module für Verschlüsselung, Hashing und andere sicherheitsbezogene Vorgänge sicher. Mit FIPS-fähigen AKS-Knotenpools können Sie gesetzliche und branchenspezifische Complianceanforderungen erfüllen, indem Sie stabile kryptografische Algorithmen und Mechanismen verwenden. Azure bietet Dokumentation zum Aktivieren von FIPS für AKS-Knotenpools, wodurch Sie den Sicherheitsstatus Ihrer mehrinstanzenfähigen AKS-Umgebungen verbessern können. Weitere Informationen finden Sie unter Aktivieren von FIPS für AKS-Knotenpools.

Bring Your Own Keys (BYOK) mit Azure-Datenträgern

Azure Storage verschlüsselt alle Daten einschließlich der Datenträger für Betriebssystem und Daten eines AKS-Clusters in einem ruhenden Speicherkonto. Standardmäßig werden Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Für zusätzliche Kontrolle über Verschlüsselungsschlüssel können Sie vom Kunden verwaltete Schlüssel zur Verwendung für die Verschlüsselung im Ruhezustand sowohl für die Datenträger des Betriebssystems als auch für die Daten Ihres AKS-Clusters bereitstellen. Weitere Informationen finden Sie unter

Hostbasierte Verschlüsselung

Die hostbasierte Verschlüsselung auf AKS verstärkt die Isolation, den Datenschutz und die Sicherheit der Mandantenworkloads zusätzlich. Wenn Sie die hostbasierte Verschlüsselung aktivieren, verschlüsselt AKS ruhende Daten auf den zugrunde liegenden Hostcomputern, um sicherzustellen, dass vertrauliche Mandanteninformationen vor unbefugtem Zugriff geschützt sind. Temporäre Datenträger und kurzlebige Betriebssystemdatenträger werden im Ruhezustand mit plattformseitig verwalteten Schlüsseln verschlüsselt, wenn Sie die End-to-End-Verschlüsselung aktivieren.

In AKS nutzen die Datenträger für das Betriebssystem und für Daten standardmäßig serverseitige Verschlüsselung mit plattformseitig verwalteten Schlüsseln. Die Caches für diese Datenträger werden im Ruhezustand mit plattformseitig verwalteten Schlüsseln verschlüsselt. Sie können Ihren eigenen Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) angeben, um den Datenschutzschlüssel (Data Protection Key, DEK) zu verschlüsseln, indem Sie Umschlagverschlüsselung (Envelope encryption) verwenden, die auch als Wrapping bezeichnet wird. Der Cache für die Datenträger für das Betriebssystems und die Daten wird auch über den von Ihnen angegebenen BYOK verschlüsselt.

Die hostbasierte Verschlüsselung fügt mehrinstanzenfähigen Umgebungen eine weitere Sicherheitsebene hinzu. Die Daten jedes Mandanten in den Caches der Datenträger für das Betriebssystems und die Daten werden im Ruhezustand entweder mit kunden- oder plattformseitig verwalteten Schlüsseln verschlüsselt. Dies hängt vom ausgewählten Datenträgerverschlüsselungstyp ab. Weitere Informationen finden Sie unter

Netzwerk

Einschränken des Netzwerkzugriff auf den API-Server

In Kubernetes empfängt der API-Server Anforderungen zum Ausführen von Aktionen im Cluster, wie z. B. das Erstellen von Ressourcen oder das Skalieren der Anzahl von Knoten. Wenn Sie einen AKS-Cluster mit mehreren Teams innerhalb einer Organisation gemeinsam nutzen, schützen Sie den Zugriff auf die Steuerungsebene, indem Sie eine der folgenden Lösungen verwenden.

Private AKS-Cluster

Mithilfe eines privaten AKS-Clusters können Sie sicherstellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und Ihren Knotenpools innerhalb Ihres virtuellen Netzwerks verbleibt. In einem privaten AKS-Cluster verfügt die Steuerungsebene oder der API-Server über eine interne IP-Adresse, die nur über einen privaten Azure-Endpunkt zugänglich ist, 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 Steuerungsebene kommunizieren. Weitere Informationen finden Sie unter Erstellen eines privaten Azure Kubernetes Service-Clusters.

Autorisierte IP-Adressen

Die zweite Option, um die Clustersicherheit zu verbessern und Angriffe zu minimieren, besteht darin, autorisierte IP-Adressen zu verwenden. Dieser Ansatz beschränkt den Zugriff auf die Steuerungsebene eines öffentlichen AKS-Clusters auf eine bekannte Liste mit IP-Adressen (Internet Protocol) sowie klassenloses domänenübergreifendes Routing (Classless Inter-Domain Routing, CIDR). Wenn Sie autorisierte IP-Adressen verwenden, sind diese weiterhin öffentlich verfügbar, aber der Zugriff darauf ist auf eine Reihe von IP-Adressbereichen beschränkt. Weitere Informationen finden Sie unter Sicherer Zugriff auf den API-Server mit autorisierten IP-Adressbereichen in Azure Kubernetes Service (AKS).

Der Azure Private Link-Dienst (Private Link Service, PLS) ist eine Infrastrukturkomponente, mit der Anwendungen eine private Verbindung mit einem Dienst über einen privaten Azure-Endpunkt (PE) herstellen können, der in einem virtuellen Netzwerk definiert ist und mit der Front-End-IP-Konfiguration einer Azure Load Balancer (ALB)-Instanz verbunden ist. Mit Azure Private Link können Dienstanbieter ihre Dienste sicher für ihre Mandanten bereitstellen, die aus Azure heraus oder lokal eine Verbindung herstellen können, ohne das Risiko einer Datenexfiltration befürchten zu müssen.

Sie können die Azure Private Link-Dienstintegration verwenden, um Mandanten private Konnektivität mit ihren von AKS gehosteten Workloads auf sichere Weise bereitzustellen, ohne dass ein öffentlicher Endpunkt im öffentlichen Internet verfügbar gemacht werden müsste.

Allgemeine Anleitungen zum Konfigurieren von Private Link für eine von Azure gehostete mehrinstanzenfähige Lösung finden Sie unter Mehrinstanzenfähigkeit und Azure Private Link.

Reverseproxys

Ein Reverseproxy ist ein Lastenausgleichsmodul und ein API-Gateway, das normalerweise vor Mandantenanwendungen verwendet wird, um eingehende Anforderungen zu sichern, zu filtern und zu verteilen. Beliebte Reverseproxys unterstützen Features wie Lastenausgleich, SSL-Terminierung 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 schützen 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 für den der beschleunigte Netzwerkbetrieb aktiviert ist.
  • Konfigurieren Sie den Knotenpool, der Ihren Reverseproxy hostet, für die automatische Skalierung.
  • Um erhöhte Wartezeiten und Timeouts für Mandantenanwendungen zu vermeiden, definieren Sie eine Richtlinie für automatische Skalierung, sodass die Anzahl der Eingangsdatencontroller-Pods sofort erweitert und verkleinert werden kann, um die Datenverkehrsschwankungen auszugleichen.
  • Erwägen Sie das horizontale Partitionieren (Sharding) des an Mandantenanwendungen eingehenden Datenverkehrs über mehrere Instanzen Ihres Eingangsdatencontrollers hinweg, um die Skalierbarkeit und die Trennungsstufe zu erhöhen.

Erwägen Sie bei Verwendung des Azure Application Gateway-Eingangsdatencontrollers (AGIC) die Implementierung der folgenden bewährten Methoden:

  • Konfigurieren Sie das Application Gateway, das vom Eingangsdatencontroller verwendet wird, für die Automatische Skalierung. Bei aktivierter automatischer Skalierung können Application Gateway und WAF v2-SKUs basierend auf den Datenverkehrsanforderungen der Anwendung auf- oder abskaliert werden. Dieser Modus bietet bessere Elastizität für Ihre Anwendung und Größe oder Anzahl der Instanzen von Application Gateway müssen nicht geschätzt werden. Außerdem ermöglicht dieser Modus Kosteneinsparungen, weil das Gateway nicht mit bereitgestellter Spitzenkapazität für die erwartete maximale Datenverkehrslast ausgeführt werden muss. Sie müssen eine Mindestanzahl und optional eine Höchstanzahl von Instanzen angeben.
  • Erwägen Sie die Bereitstellung mehrerer Instanzen des Application Gateway-Eingangsdatencontrollers (AGIC), wobei jede davon einem separaten Application Gateway zugeordnet ist, 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 die Unterstützung für mehrere Namespaces, um Mandantenanwendungen auf mehrere Instanzen des Application Gateway-Eingangsdatencontrollers (AGIC) zu verteilen.

Integration mit Azure Front Door

Azure Front Door ist ein globaler Layer-7-Lastenausgleich sowie das moderne Cloud-CDN (Content Delivery Network) von Microsoft, das schnellen, zuverlässigen und sicheren Zugriff zwischen Benutzern und Webanwendungen weltweit ermöglicht. Azure Front Door unterstützt Features wie Anforderungsbeschleunigung, SSL-Terminierung, Antwortzwischenspeicherung, WAF am Edge, URL-basiertes Routing, Rewrite und Umleitungen, die Sie nutzen können, wenn Sie von AKS gehostete mehrinstanzenfähige Anwendungen öffentlich über das Internet verfügbar machen.

So können Sie beispielsweise eine von AKS gehostete mehrinstanzenfähige Anwendung verwenden, um alle Anforderungen der Kunden zu bedienen. 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 terminieren und den gesamten Datenverkehr an die von AKS gehostete mehrinstanzenfähige Anwendung weiterleiten, die mit einem einzigen Hostnamen konfiguriert ist.

Diagram that demonstrates how Azure Front Door and AKS connect.

Sie können Azure Front Door so konfigurieren, dass der Anforderungsursprungs-Hostheader so geändert wird, dass er dem Domänennamen der Back-End-Anwendung entspricht. Der ursprüngliche, vom Client gesendete Host-Header wird über den X-Forwarded-Host-Header weitergegeben, und der Code der mehrinstanzenfähigen Anwendung kann diese Informationen verwenden, um die eingehende Anforderung dem richtigen Mandanten zuzuordnen.

Azure Web Application Firewall (WAF) in Azure Front Door bietet zentralen Schutz für Webanwendungen. Sie können Azure WAF verwenden, um von AKS gehostete Mandantenanwendungen, die einen öffentlichen Endpunkt im Internet vor verfügbar machen, vor böswilligen Angriffen zu schützen.

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

Ausgehende Verbindungen

Wenn von AKS gehostete Anwendungen eine Verbindung mit einer großen Anzahl von Datenbanken oder externen Diensten herstellen, kann der Cluster dem Risiko einer SNAT-Portauslastung ausgesetzt werden. SNAT-Ports generieren eindeutige Bezeichner, die verwendet werden, um unterschiedliche Datenflüsse aufrechtzuerhalten, die von Anwendungen initiiert werden, die auf derselben Gruppe von Computeressourcen ausgeführt werden. Durch Ausführen mehrerer Mandantenanwendungen auf einem freigegebenen Azure Kubernetes Service-Cluster können Sie eine hohe Anzahl ausgehender Aufrufe generieren, die zu einer SNAT-Portauslastung führen können. Ein AKS-Cluster kann ausgehende Verbindungen auf drei verschiedene Arten behandeln:

  • Azure Public Load Balancer: Standardmäßig stellt AKS einen Load Balancer der Standard-SKU bereit, der für Ausgangsverbindungen eingerichtet und verwendet werden soll. Das Standardsetup erfüllt jedoch möglicherweise nicht alle Anforderungen aller Szenarien, wenn öffentliche IP-Adressen nicht zulässig oder zusätzliche Hops für den ausgehenden Datenverkehr erforderlich sind. Standardmäßig wird der öffentliche Load Balancer mit einer öffentlichen IP-Standardadresse erstellt, die von den Ausgangsregeln verwendet wird. Ausgangsregeln gestatten Ihnen, die Quell-Netzwerkadressenübersetzung (SNAT) für eine öffentliche Load Balancer Standard-Instanz explizit zu definieren. In dieser Konfiguration können Sie die öffentliche IP-Adresse Ihrer Load Balancers-Instanz verwenden, um ausgehende Internetkonnektivität für Ihre Back-End-Instanzen bereitzustellen. Wenn notwendig, können Sie zur Vermeidung der SNAT-Portauslastung die Ausgangsregeln des öffentlichen Lastenausgleichs so konfigurieren, dass zusätzliche öffentliche IP-Adressen verwendet werden. Weitere Informationen finden Sie unter Verwenden der Front-End-IP-Adressen eines Lastenausgleichsmoduls für ausgehende Verbindungen über Ausgangsregeln.
  • Azure NAT Gateway: Sie können einen AKS-Cluster so konfigurieren, dass Azure NAT Gateway verwendet wird, um den von Mandantenanwendungen ausgehenden Datenverkehr weiterzuleiten. NAT Gateway lässt pro öffentlicher IP-Adresse bis zu 64.512 ausgehende UDP- und TCP-Datenverkehrsflüsse sowie maximal 16 IP-Adressen zu. Um das Risiko der SNAT-Portauslastung zu vermeiden, wenn ein NAT Gateway verwendet wird, um ausgehende Verbindungen aus einem AKS-Cluster zu behandeln, können Sie dem Gateway mehr öffentliche IP-Adressen oder ein öffentliches IP-Adressenpräfix zuordnen. Weitere Informationen finden Sie unter Überlegungen zu Azure NAT Gateway für Mehrinstanzenfähigkeit.
  • Benutzerdefinierte Route (User-Defined Route, UDR): Sie können die ausgehende Route eines AKS-Clusters so anpassen, dass verschiedene Netzwerkszenarien unterstützt werden, beispielsweise solche, in denen öffentliche IP-Adressen nicht zugelassen werden und der Cluster hinter einem virtuellen Netzwerkgerät (NVA) platziert werden muss. Wenn Sie einen Cluster für benutzerdefiniertes Routing konfigurieren, konfiguriert AKS nicht automatisch Ausgangspfade. Das ausgehende Setup muss von Ihnen durchgeführt werden. Beispielsweise würden Sie ausgehenden Datenverkehr über eine Azure Firewall weiterleiten. Der AKS-Cluster muss in einem vorhandenen virtuellen Netzwerk mit einem zuvor konfigurierten Subnetz bereitgestellt werden. Wenn Sie keine Load Balancer Standard-Architektur verwenden, müssen Sie expliziten ausgehenden Datenverkehr herstellen. Daher erfordert diese Architektur explizit das Senden von ausgehendem Datenverkehr an eine Appliance, z. B. eine Firewall, ein Gateway oder einen Proxy. Oder die Architektur lässt zu, dass die Netzwerkadressenübersetzung (NAT) durch eine öffentliche IP-Adresse erfolgt, die dem Load Balancer Standard oder der Appliance zugewiesen ist.

Überwachung

Sie können Azure Monitor und Container Insights verwenden, um Mandantenanwendungen zu überwachen, die auf einem freigegebenen AKS-Cluster ausgeführt werden, sowie zur Berechnung von Kostenaufschlüsselungen für einzelne Namespaces. Azure Monitor gestattet Ihnen, die Integrität und Leistung von Azure Kubernetes Service (AKS) zu überwachen. Es umfasst die Sammlung von Protokollen und Metriken, Telemetrieanalysen sowie Visualisierungen von gesammelten Daten, um Trends zu identifizieren und Warnungen so zu konfigurieren, dass sie Sie proaktiv über kritische Probleme informieren. Sie können Container Insights aktivieren, um diese Überwachung zu erweitern.

Sie können außerdem Open-Source-Tools wie Prometheus und Grafana einführen, die weit verbreitet von der Community für die Kubernetes-Überwachung verwendet werden. Oder Sie können auch andere Drittanbietertools zur Überwachung und für Einblicke einführen.

Kosten

Die Kostengovernance ist der fortlaufende Prozess, Richtlinien für die Kostenkontrolle zu implementieren. Im Kubernetes-Kontext gibt es verschiedene Möglichkeiten, um die Kosten zu kontrollieren und zu optimieren. Dazu zählen native Kubernetes-Tools für die Verwaltung und Governance der Ressourcenauslastung und des Ressourcenverbrauchs sowie für die proaktive Überwachung und Optimierung der zugrunde liegenden Infrastruktur. Bei der Berechnung der Kosten pro Mandant sollten Sie die Kosten berücksichtigen, die mit jeder Ressource einhergehen, die von einer Mandantenanwendung verwendet wird. Der Ansatz, den Sie verfolgen, um Gebühren verbrauchsbasiert auf die Mandanten umzulegen, hängt von dem von Ihrer Lösung verwendeten Mandantenmodell ab. Weitere Details werden anhand der folgenden Mandantenmodelle erläutert:

  • Vollständig mehrinstanzenfähig: Wenn eine einzelne, mehrinstanzenfähige Anwendung alle Mandantenanforderungen bedient, liegt es in Ihrer Verantwortung, den Ressourcenverbrauch und die von jedem Mandanten generierte Anzahl der Anforderungen nachzuverfolgen. Anschließend berechnen Sie diese Ihren Kunden entsprechend.
  • Dedizierter Cluster: Wenn ein Cluster dediziert einem einzelnen Mandanten zugeordnet ist, ist es einfach, die Kosten für Azure-Ressourcen verbrauchsbasiert wieder auf den Kunden umzulegen. Die Gesamtkosten hängen von vielen Faktoren ab, wozu die Anzahl und Größe der virtuellen Computer gehören, die Netzwerkkosten aufgrund von Netzwerkdatenverkehr, öffentliche IP-Adressen, Lastenausgleichsmodule, die Speicherdienste wie verwaltete Datenträger oder Azure Files, die von der Mandantenlösung verwendet werden, usw. Sie können einen AKS-Cluster und seine Ressourcen in der Knotenressourcengruppe mit Tags markieren, um Kostenberechnungsvorgänge zu erleichtern. 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 dediziert einem einzelnen Mandanten zugeordnet ist. Auf einen Knotenpool angewendete Tags werden auf jeden Knoten innerhalb des Knotenpools angewendet und bleiben bei Upgrades erhalten. Tags werden auch auf neue Knoten angewendet, die einem Knotenpool im Rahmen von Vorgängen zum horizontalen Skalieren hinzugefügt werden. Das Hinzufügen eines Tags kann Aufgaben wie das Nachverfolgen von Richtlinien oder die Kostenberechnung erleichtern. Weitere Informationen finden Sie unter Hinzufügen von Tags zu Knotenpools.
  • Sonstige Ressourcen: Sie können Tags verwenden, um die Kosten dedizierter Ressourcen einem bestimmten Mandanten zuzuordnen. Insbesondere können Sie öffentliche IP-Adressen, Dateien und Datenträger mithilfe eines Kubernetes-Manifests mit Tags markieren. Auf diese Weise festgelegte Tags behalten die Kubernetes-Werte bei, auch wenn Sie diese später mit einer anderen Methode aktualisieren. Wenn öffentliche IP-Adressen, Dateien oder Datenträger über Kubernetes entfernt werden, werden alle von Kubernetes festgelegten Tags entfernt. Tags für diese Ressourcen, die nicht von Kubernetes nachverfolgt werden, bleiben davon unbeeinflusst. Weitere Informationen finden Sie unter Hinzufügen von Tags mithilfe von Kubernetes.

Sie können Open-Source-Tools wie KubeCost verwenden, um AKS-Clusterkosten zu überwachen und zu steuern. Die Kostenzuordnung kann auf eine Bereitstellung, einen Dienst, eine Bezeichnung, einen Pod und einen Namespace beschränkt werden, wodurch Sie Flexibilität dabei erlangen, wie Sie die verbrauchsbasierte Kostenzuteilung oder das Showback Benutzern des Clusters zuordnen. Weitere Informationen finden Sie unter Kostengovernance mit Kubecost.

Weitere Informationen zur Messung, Zuordnung und Optimierung von Kosten für eine mehrinstanzenfähige Anwendung finden Sie unter Architekturansätze für Kostenverwaltung und -zuordnung in einer mehrinstanzenfähigen Lösung. Allgemeine Anleitungen zur Kostenoptimierung finden Sie im Azure Well-Architected Framework-Artikel Übersicht über die Säule „Kostenoptimierung“

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Nächste Schritte

Weitere Informationen finden Sie unter Ressourcen für Architekten und Entwickler mehrinstanzenfähiger Lösungen.