Bearbeiten

Verwenden des Application Gateway-Eingangsdatencontrollers (Application Gateway Ingress Controller, AGIC) mit einer mehrinstanzenfähigen Azure Kubernetes Service-Instanz

Azure Application Gateway
Azure-Schlüsseltresor
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Bastion

In dieser Lösung bietet die Azure Web Application Firewall (WAF) zentralisierten Schutz für Webanwendungen, die auf einem mehrinstanzenfähigen AKS-Cluster (Azure Kubernetes Service) bereitgestellt werden, vor gängigen Exploits und Sicherheitsrisiken. Webanwendungen, die auf Azure Kubernetes Service-Clustern (AKS) ausgeführt und über den Application Gateway-Eingangscontroller (AGIC) bereitgestellt werden, können mithilfe einer WAF-Richtlinie für Azure Application Gateway vor böswilligen Angriffen wie der Einschleusung von SQL-Befehlen und dem Cross-Site Scripting geschützt werden. Die WAF-Richtlinie für Azure Application Gateway ist mit OWASP-Kernregelsätzen vorkonfiguriert und kann auf andere unterstützte OWASP CRS-Versionen geändert werden.

Aufbau

Diagramm dieser Lösung für den Eingangsdatencontroller für Application Gateway.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die ARM-Begleitvorlage stellt ein neues virtuelles Netzwerk mit vier Subnetzen bereit:

  • AksSubnet: Hostet den AKS-Cluster
  • VmSubnet: Hostet eine Jumpbox-VM und private Endpunkte
  • AppGatewaySubnet: Hostet die Application Gateway WAF2-Ebene
  • AzureBastionSubnet: Hostet Azure Bastion

Der AKS-Cluster (Azure Kubernetes Service) verwendet eine benutzerdefinierte verwaltete Identität zum Erstellen zusätzlicher Ressourcen (wie Lastenausgleiche und verwaltete Datenträger) in Azure. Mit der ARM-Vorlage können Sie einen AKS-Cluster mit den folgenden Features bereitstellen:

Der AKS-Cluster besteht aus den folgenden Komponenten:

  • Systemknotenpool, der nur kritische Systempods und -dienste hostet. Die Workerknoten verfügen über einen Taint, der verhindert, dass Anwendungspods in diesem Knotenpool geplant werden.
  • Benutzerknotenpool, der Benutzerworkloads und -artefakte hostet.

Ein virtueller Computer (VM) wird in demselben virtuellen Netzwerk bereitgestellt, das den AKS-Cluster hostet. Wenn Sie Azure Kubernetes Service als privaten Cluster bereitstellen, kann dieser virtuelle Computer von den Systemadministratoren verwendet werden, um den Cluster über das Kubernetes-Befehlszeilentool zu verwalten. Die Startdiagnoseprotokolle des virtuellen Computers werden in einem Azure Storage-Konto gespeichert.

Ein Azure Bastion-Host bietet direkt im Azure-Portal eine sichere und nahtlose SSH-Verbindung mit Ihrer Jumpbox-VM über SSL. Azure Container Registry (ACR) wird verwendet, um Containerimages und -artefakte zu erstellen, zu speichern und zu verwalten (z. B. Helm Charts).

Die Architektur enthält ein Application Gateway, das vom Eingangscontroller verwendet wird. Das Application Gateway wird in einem dedizierten Subnetz bereitgestellt und über eine öffentliche IP-Adresse, die von allen Mandantenworkloads gemeinsam genutzt wird, im öffentlichen Internet verfügbar gemacht. Dem Application Gateway wird auf Stamm- und HTTP-Listenerebene eine Web Access Firewall-Richtlinie (WAF) zugeordnet, um Mandantenworkloads vor böswilligen Angriffen zu schützen. Diese Richtlinie ist im Schutzmodus konfiguriert und verwendet OWASP 3.1, um Eindringlinge und Angriffe zu blockieren, die durch die festgelegten Regeln erkannt werden. Der Angreifer erhält eine Ausnahme vom Typ 403 (nicht autorisierter Zugriff), und die Verbindung wird getrennt. Der Schutzmodus hält diese Angriffe in den WAF-Protokollen fest.

Ein Key Vault wird von Workloads, die auf Azure Kubernetes Service (AKS) ausgeführt werden, als Geheimnisspeicher verwendet, um Schlüssel, Zertifikate und Geheimnisse über eine Clientbibliothek, den Secrets Store CSI-Treiber oder Dapr abzurufen. Mit Azure Private Link können AKS-Workloads über einen privaten Endpunkt im virtuellen Netzwerk auf Azure-PaaS-Dienste wie Key Vault zugreifen.

Die Beispieltopologie enthält die folgenden privaten Endpunkte:

  • einen privaten Endpunkt für das Blob Storage-Konto
  • einen privaten Endpunkt für Azure Container Registry (ACR)
  • einen privaten Endpunkt für Key Vault
  • einen privaten Endpunkt für den API-Server des Kubernetes-Clusters, wenn Sie sich für einen privaten AKS-Cluster entscheiden

Die Architektur umfasst ebenfalls die folgenden privaten DNS-Zonen für die Namensauflösung des vollqualifizierten Domänennamens (FQDN) eines PaaS-Diensts in die private IP-Adresse des zugeordneten privaten Endpunkts:

  • eine private DNS-Zone für die Namensauflösung des privaten Endpunkts in das Azure Blob Storage-Konto
  • eine private DNS-Zone für die Namensauflösung des privaten Endpunkts in Azure Container Registry (ACR)
  • eine private DNS-Zone für die Namensauflösung des privaten Endpunkts in Azure Key Vault
  • eine private DNS-Zone für die Namensauflösung des privaten Endpunkts in die Kubernetes-Server-API, wenn Sie den Cluster als privaten Cluster bereitstellen

Zwischen dem virtuellen Netzwerk, das den AKS-Cluster hostet, und den oben genannten privaten DNS-Zonen besteht eine virtuelle Netzwerkverknüpfung. Ein Log Analytics-Arbeitsbereich wird verwendet, um Diagnoseprotokolle und Metriken aus den folgenden Quellen zu erfassen:

  • Azure Kubernetes Service-Cluster
  • Jumpbox-VM
  • Azure Application Gateway
  • Azure-Schlüsseltresor
  • Azure-Netzwerksicherheitsgruppen

Komponenten

  • Azure Container Registry ist ein verwalteter, privater Docker-Registrierungsdienst, der auf Version 2.0 der Open-Source-Docker-Registrierung basiert. Sie können Azure-Containerregistrierungen mit Ihren vorhandenen Pipelines für die Containerentwicklung und -bereitstellung verwenden, oder Azure Container Registry Tasks nutzen, um Containerimages in Azure zu erstellen. Erstellen Sie bedarfsgesteuerte oder voll automatisierte Builds mit Triggern wie etwa Quellcode-Commits und Basisimage-Aktualisierungen.

  • Azure Kubernetes Services vereinfacht die Bereitstellung eines Managed Kubernetes-Clusters in Azure, indem der betriebliche Aufwand in Azure ausgelagert wird. Azure führt als gehosteter Kubernetes-Dienst wichtige Aufgaben aus, z. B. Systemüberwachung und Wartung. Da die Kubernetes-Mastereinheiten von Azure verwaltet werden, müssen Sie sich nur um die Verwaltung und Wartung der Agent-Knoten kümmern.

  • Mit Azure Key Vault werden Geheimnisse wie API-Schlüssel, Kennwörter, Zertifikate und kryptografische Schlüssel sicher gespeichert und der Zugriff darauf gesteuert. Dank Azure Key Vault können Sie öffentliche und private TLS-/SSL-Zertifikate (Transport Layer Security/Secure Sockets Layer) für die Verwendung mit Azure und Ihren internen verbundenen Ressourcen mühelos bereitstellen und verwalten.

  • Azure Application Gateway Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, mit dem Sie den eingehenden Datenverkehr für mehrere Downstream-Webanwendungen und REST-APIs verwalten können. Herkömmliche Lastenausgleichsmodule sind auf der Transportschicht (OSI-Schicht 4 – TCP und UDP) aktiv und leiten Datenverkehr basierend auf der IP-Quelladresse und dem dazugehörigen Port an eine IP-Zieladresse und an den entsprechenden Port weiter. Beim Application Gateway handelt es sich stattdessen um einen Lastenausgleich auf Anwendungsebene (OSI-Schicht 7). (OSI steht für Open Systems Interconnection, TCP steht für Transmission Control-Protokoll und UDP für User Datagram Protocol.)

  • Web Application Firewall oder WAF ist ein Dienst, der zentralisierten Schutz für Webanwendungen vor verbreiteten Exploits und Sicherheitsrisiken bietet. Die WAF basiert auf den Regeln der OWASP-Kernregelsätze (Open Web Application Security Project). Mit Azure WAF können Sie benutzerdefinierte Regeln erstellen, die jedes Mal wenn eine Anforderung eine Richtlinie durchläuft, neu ausgewertet werden. Diese Regeln haben eine höhere Priorität als die restlichen Regeln in den verwalteten Regelsätzen. Die benutzerdefinierten Regeln enthalten einen Regelnamen, eine Regelpriorität und ein Array von Abgleichsbedingungen. Sind diese Bedingungen erfüllt, erfolgt eine Aktion (Zulassen oder Blockieren).

  • Azure Bastion ist ein vollständig verwalteter PaaS-Dienst (Platform as a Service), den Sie in Ihrem virtuellen Netzwerk bereitstellen können. Azure Bastion bietet über das Remotedesktopprotokoll (RDP) und Secure Shell (SSH) sichere und nahtlose Konnektivität zu den VMs in Ihrem virtuellen Netzwerk, direkt über das Azure-Portal mittels TLS.

  • Azure Virtual Machines bietet bedarfsgesteuerte, skalierbare Computingressourcen, die Ihnen die Flexibilität der Virtualisierung bieten, ohne physische Hardware kaufen und verwalten zu müssen.

  • Azure Virtual Network ist der grundlegende Baustein für private Azure-Netzwerke. Mit Virtual Network können Azure-Ressourcen (wie VMs) sicher untereinander sowie mit dem Internet und mit lokalen Netzwerken kommunizieren. Eine Azure Virtual Network-Instanz ähnelt einem herkömmlichen lokalen Netzwerk, bietet aber die Vorteile der Azure-Infrastruktur wie Skalierbarkeit, Verfügbarkeit und Isolation.

  • Virtuelle Netzwerkschnittstellen ermöglichen virtuellen Azure-Computern die Kommunikation mit dem Internet, mit Azure und lokalen Ressourcen. Sie können mehrere Netzwerkschnittstellenkarten zu einer Azure-VM hinzufügen, sodass untergeordnete VMs über ihre eigenen dedizierten Netzwerkschnittstellengeräte und IP-Adressen verfügen können.

  • Azure Managed Disks bietet Speichervolumes auf Blockebene, die Azure auf Azure-VMs verwaltet. Die verfügbaren Datenträgertypen sind Ultra Disks, SSD Premium (SSDs), SSD Standard und Standardfestplatten-Laufwerke (Hard Disk Drives, HDDs).

  • Azure Blob Storage ist die Objektspeicherlösung von Microsoft für die Cloud. Blob Storage ist für die Speicherung großer Mengen unstrukturierter Daten optimiert. Unstrukturierte Daten sind Daten, die keinem bestimmten Datenmodell und keiner bestimmten Definition entsprechen (also beispielsweise Text- oder Binärdaten).

  • Mit Azure Private Link können Sie über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf Azure-PaaS-Dienste (beispielsweise Azure Blob Storage und Key Vault) sowie auf in Azure gehostete kundeneigene Dienste/Partnerdienste zugreifen.

Alternativen

In dieser Architektur wurde der Application Gateway-Eingangscontroller (AGIC) mithilfe des AGIC-Add-Ons für Azure Kubernetes Service (AKS) installiert. Darüber hinaus können Sie den Application Gateway-Eingangscontroller über ein Helm Chart installieren. Bei einer neuen Einrichtung können Sie mit nur einer Zeile in Azure CLI ein neues Application Gateway und einen neuen AKS-Cluster bereitstellen (mit als Add-On aktiviertem AGIC). Das Add-On ist außerdem ein vollständig verwalteter Dienst, der zusätzliche Vorteile bietet wie automatische Updates und verbesserten Support. Beide Bereitstellungsmethoden für AGIC (Helm- und das AKS-Add-On) werden von Microsoft vollständig unterstützt. Zusätzlich bietet das Add-On als ein erstklassiges Add-On bessere Integrationsmöglichkeiten mit AKS.

Das AGIC-Add-On (Application Gateway-Eingangscontroller) wird weiterhin als Pod in Ihrem AKS-Cluster bereitgestellt. Es gibt jedoch ein paar Unterschiede zwischen der Helm-Bereitstellungsversion und der Add-On-Version von AGIC. Die folgende Liste bietet eine Übersicht über die Unterschiede zwischen den beiden Versionen:

  • Helm-Bereitstellungswerte können im AKS-Add-On nicht geändert werden:

    • usePrivateIp wird standardmäßig auf false festgelegt. Dies kann mit der use-private-ip-Anmerkung außer Kraft gesetzt werden.
    • shared wird vom Add-On nicht unterstützt.

  • Der mittels Helm bereitgestellte AGIC unterstützt ProhibitedTargets, was bedeutet, dass AGIC das Application Gateway speziell für AKS-Cluster konfigurieren kann, ohne dass sich dies auf andere vorhandene Back-Ends auswirkt.

  • Da das AGIC-Add-On ein verwalteter Dienst ist, wird es automatisch auf die neueste Version des AGIC-Add-Ons aktualisiert, anders als beim mittels Helm bereitgestellten AGIC (hier müssen Sie AGIC manuell aktualisieren).

  • Sie können nur ein AGIC-Add-On pro AKS-Cluster bereitstellen, und jedes AGIC-Add-On kann aktuell nur eine Application Gateway-Instanz als Ziel verwenden. Für Bereitstellungen, für die mehr als ein AGIC-Add-On pro Cluster oder mehrere AGIC-Add-Ons für ein Anwendungsgateway erforderlich sind, können Sie AGIC weiterhin über Helm bereitstellen.

Eine einzelne Instanz des Azure Application Gateway Kubernetes-Eingangscontrollers (AGIC) kann Ereignisse aus mehreren Kubernetes-Namespaces erfassen. Wenn der AKS-Administrator die Verwendung des Application Gateway als Eingang festlegt, verwenden alle Namespaces dieselbe Instanz von Application Gateway. Mit einer einzigen Installation des Eingangscontrollers werden die zugänglichen Namespaces überwacht und die zugeordnete Application Gateway-Instanz konfiguriert. Weitere Informationen finden Sie unter Aktivieren der Unterstützung mehrerer Namespaces in einem AKS-Cluster mit Application Gateway-Eingangscontroller.

Um die Unterstützung mehrerer Namespaces zu aktivieren, müssen die folgenden Schritte ausgeführt werden:

  • Ändern Sie die Datei helm-config.yaml auf eine der folgenden Weisen:

    • Löschen Sie den watchNamespace-Schlüssel vollständig aus der helm-config.yaml-Datei. AGIC wird alle Namespaces überwachen.
    • Legen Sie watchNamespace auf eine leere Zeichenfolge fest. AGIC wird alle Namespaces überwachen.
    • Fügen Sie mehrere durch Kommas getrennte Namespaces hinzu (watchNamespace: default,secondNamespace). AGIC wird ausschließlich diese Namespaces überwachen.

  • Wenden Sie die Änderungen der Helm-Vorlage mit diesem Skript an: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

Nach der Bereitstellung von AGIC mit der Funktion zum Überwachen mehrerer Namespaces wird Folgendes durchgeführt:

  • Auflisten von Eingangsressourcen aus allen zugänglichen Namespaces
  • Filtern nach Eingangsressourcen, die mit kubernetes.io/ingress.class: azure/application-gateway kommentiert sind
  • Erstellen einer kombinierten Application Gateway-Konfiguration
  • Anwenden der Konfiguration auf die zugeordnete Application Gateway-Instanz über ARM

Szenariodetails

Ein mehrinstanzenfähiger Kubernetes-Cluster wird von mehreren Benutzern und Workloads gemeinsam genutzt, die gewöhnlich als „Mandanten“ bezeichnet werden. Diese Definition beinhaltet Kubernetes-Cluster, die von verschiedenen Teams oder Abteilungen innerhalb einer Organisation gemeinsam genutzt werden. Sie umfasst auch 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.

Wenn Sie ein mehrinstanzenfähiges Azure Kubernetes Service-Cluster (AKS) erstellen möchten, sollten Sie die von Kubernetes bereitgestellten Ebenen für die Ressourcenisolation berücksichtigen: Cluster, Namespace, Knoten, Pod und Container. Darüber hinaus sollten Sie die Sicherheitsrisiken berücksichtigen, die sich ergeben, wenn mehrere Mandanten verschiedene Ressourcentypen 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 demselben Ort zugeordnet werden. So sollten Sie nicht vertrauenswürdigen Code von außerhalb Ihres Unternehmens beispielsweise nicht auf demselben Knoten ausführen lassen, auf dem auch Container mit vertraulichen Informationen ausgeführt werden. Azure Policy kann verwendet werden, um die Bereitstellung auf AKS nur über vertrauenswürdige Registrierungen zu beschränken.

Kubernetes kann zwar keine absolut sichere Isolation zwischen den 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. Anschließend können Sie Kubernetes RBAC und Netzwerkrichtlinien verwenden, um die Mandantenisolation zu erzwingen. (RBAC steht für rollenbasierte Zugriffskontrolle.) Die folgende Abbildung zeigt zum Beispiel das typische SaaS-Provider-Modell, bei dem mehrere Instanzen derselben Anwendung auf demselben Cluster gehostet werden, eine für jeden Mandanten. Jede Anwendung befindet sich in einem separaten Namespace. Wenn Mandanten ein höheres Maß an physischer Isolation benötigen oder mehr Leistung garantiert werden soll, können ihre Workloads in einer dedizierten Gruppe von Knoten, in einem dedizierten Pool oder sogar in einem dedizierten Cluster bereitgestellt werden.

Diagramm der Mehrinstanzenfähigkeit

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Application Gateway-Eingangscontroller (Application Gateway Ingress Controller, AGIC) ist eine Kubernetes-Anwendung, die es Kunden von Azure Kubernetes Service (AKS) ermöglicht, einen Azure Application Gateway zu nutzen, um ihre containerisierten Anwendungen im Internet bereitzustellen. AGIC überwacht den Kubernetes-Cluster, auf dem er gehostet wird, und aktualisiert fortlaufend eine Application Gateway-Instanz, sodass die ausgewählten Dienste im Internet bereitgestellt werden. Der Eingangscontroller wird in einem eigenen Pod in der AKS-Instanz des Kunden ausgeführt. AGIC überwacht eine Teilmenge der Kubernetes-Ressourcen auf Änderungen. Der Status des AKS-Clusters wird in eine Application Gateway-spezifische Konfiguration übersetzt und auf Azure Resource Manager (ARM) angewendet. Dieses Architekturbeispiel zeigt bewährte Methoden für die Bereitstellung eines öffentlichen oder privaten AKS-Clusters (Azure Kubernetes Service) mit einem Azure Application Gateway und einem Application Gateway-Eingangscontroller-Add-On.

Eine einzelne Instanz des Azure Application Gateway Kubernetes-Eingangscontrollers (AGIC) kann Ereignisse aus mehreren Namespaces erfassen und mehrere Namespaces überwachen. Wenn der AKS-Administrator die Verwendung von Application Gateway als Eingang festlegt, verwenden alle Namespaces dieselbe Instanz von Application Gateway. Mit einer einzigen Installation des Eingangscontrollers werden die zugänglichen Namespaces überwacht und die zugeordnete Application Gateway-Instanz konfiguriert.

Mögliche Anwendungsfälle

Verwenden Sie den Application Gateway-Eingangscontroller (AGIC), um Workloads mit Internetanbindung verfügbar zu machen und zu schützen, die in einem AKS-Cluster (Azure Kubernetes Service) in einer mehrinstanzenfähigen Umgebung ausgeführt werden.

Überlegungen

Obwohl einige der folgenden Überlegungen nicht vollständig mit der Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS) in Zusammenhang stehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt. Dazu gehören unsere Überlegungen in den Bereichen Sicherheit, Leistung, Verfügbarkeit und Zuverlässigkeit, Speicher, Scheduler, Service Mesh und Überwachung.

Überlegungen zur Mehrinstanzenfähigkeit

  • Entwerfen von AKS-Clustern für die Mehrinstanzenfähigkeit. Kubernetes bietet Features, mit denen Sie Teams und Workloads im selben Cluster logisch isolieren können. Das Ziel sollte sein, die geringste Anzahl von Berechtigungen bereitzustellen, beschränkt auf die Ressourcen, die jedes Team benötigt. Ein Namespace in Kubernetes erstellt eine logische Isolationsgrenze.
  • Trennen Sie Teams und Projekte mithilfe einer logischen Isolation. Versuchen Sie, die Anzahl der physischen AKS-Cluster zu minimieren, die Sie bereitstellen, um Teams oder Anwendungen zu isolieren. Die logische Trennung der Cluster bietet in der Regel eine höhere Poddichte als physisch isolierte Cluster.
  • Verwenden Sie dedizierte Knotenpools oder dedizierte AKS-Cluster, wenn Sie für eine strenge physische Isolation sorgen müssen. Sie können einem Team oder einem Mandanten in einer mehrinstanzenfähigen Umgebung beispielsweise einen Pool von Workerknoten oder einen gesamten Cluster zuweisen.
    • Sie können eine Kombination aus Taints und Toleranzen verwenden, um die Bereitstellung von Pods für einen bestimmten Knotenpool zu steuern. Beachten Sie, dass ein Knoten in AKS nur zum Zeitpunkt der Erstellung des Knotenpools verfälscht werden kann. Alternativ können Bezeichnungen und nodePool-Selektoren verwendet werden, um die Bereitstellung der Workload für bestimmte Knotenpools zu steuern.

Sicherheitsüberlegungen

Obwohl sich die Überlegungen zur Sicherheit nicht vollständig auf die Mehrinstanzenfähigkeit in AKS beziehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt.

Netzwerksicherheit

  • Erstellen Sie einen privaten Endpunkt für jeden PaaS-Dienst, der von AKS-Workloads (z. B. Key Vault, Service Bus oder der Azure SQL-Datenbank) verwendet wird. Dadurch wird der Datenverkehr zwischen den Anwendungen und diesen Diensten nicht über das öffentliche Internet verfügbar gemacht. Weitere Informationen finden Sie unter Was ist Azure Private Link?.
  • Konfigurieren Sie Ihre Kubernetes-Eingangsressource so, dass Workloads über HTTPS verfügbar gemacht werden, und verwenden Sie eine separate Unterdomäne und ein digitales Zertifikat für jeden Mandanten. Der Application Gateway-Eingangscontroller (AGIC) konfiguriert den Azure Application Gateway-Listener automatisch für die SSL-Terminierung (Secure Socket Layer).
  • Konfigurieren Sie Azure Application Gateway so, dass er eine Web Application Firewall-Richtlinie verwendet, um öffentlich zugängliche Workloads (die in AKS ausgeführt werden) vor böswilligen Angriffen zu schützen.
  • Verwenden Sie Azure CNI-Netzwerke in AKS für die Integration in vorhandene virtuelle oder lokale Netzwerke. Dieses Netzwerkmodell ermöglicht zudem eine stärkere Trennung von Ressourcen und Steuerelementen in einer Unternehmensumgebung.
  • Verwenden Sie Netzwerkrichtlinien, um die dienstinterne Kommunikation voneinander zu trennen und zu schützen, indem Sie kontrollieren, welche Komponenten miteinander kommunizieren können. Standardmäßig können alle Pods in einem Kubernetes-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Zur Verbesserung der Sicherheit können Sie Azure-Netzwerkrichtlinien oder Calico-Netzwerkrichtlinien verwenden, um Regeln zu definieren, mit denen der Datenverkehrsfluss zwischen verschiedenen Microservices gesteuert wird. Weitere Informationen finden Sie unter Netzwerkrichtlinie.
  • Machen Sie für Ihre AKS-Knoten keine Remotekonnektivität verfügbar. Erstellen Sie einen Bastionhost oder eine Jumpbox in einem virtuellen Verwaltungsnetzwerk. Verwenden Sie den Bastionhost, um den Datenverkehr sicher in Ihren AKS-Cluster für Remoteverwaltungsaufgaben zu routen.
  • Ziehen Sie die Nutzung eines privaten AKS-Clusters in Ihrer Produktionsumgebung in Erwägung, oder zumindest einen sicheren Zugriff auf den API-Server, indem Sie autorisierte IP-Adressbereiche in Azure Kubernetes Service einsetzen.
  • Azure DDoS Protection, kombiniert mit bewährten Methoden für den Anwendungsentwurf, bietet erweiterte Features zur DDoS-Risikominderung, um besser vor DDoS-Angriffen zu schützen. Sie sollten Azure DDOS Protection in allen virtuellen Umkreisnetzwerken aktivieren.

Authentifizierung und Autorisierung

  • Stellen Sie AKS-Cluster mit Microsoft Entra-Integration bereit. Weitere Informationen finden Sie unter Von AKS verwaltete Microsoft Entra-Integration. Die Verwendung von Microsoft Entra ID zentralisiert die Identitätsverwaltungskomponente. Jede Änderung von Benutzerkonto oder Gruppenstatus wird automatisch im Zugriff auf den AKS-Cluster aktualisiert. Verwenden Sie Rollen oder Clusterrollen und Bindungen, um Benutzer oder Gruppen den minimal erforderlichen Berechtigungen zuzuordnen.
  • Verwenden Sie Kubernetes RBAC zum Definieren der Berechtigungen von Benutzern oder Gruppen für Ressourcen im Cluster. Erstellen Sie Rollen und Bindungen, mit denen Sie die minimal erforderlichen Berechtigungen zuweisen können. Führen Sie die Integration von Kubernetes RBAC mit Microsoft Entra ID durch, sodass jede Änderung von Benutzerstatus oder Gruppenmitgliedschaft automatisch aktualisiert wird, und der Zugriff auf Clusterressourcen aktuell ist.
  • Verwenden Sie Azure RBAC, um die minimal erforderlichen Berechtigungen zu definieren, die Benutzer oder Gruppen für AKS-Ressourcen in einem oder mehreren Abonnements haben. Weitere Informationen finden Sie unter Kubernetes RBAC und Verwenden von Azure RBAC für die Kubernetes-Autorisierung.
  • Ziehen Sie die Verwendung von Microsoft Entra Workload ID in Erwägung, um einzelnen Microservices eine verwaltete Identität für eine Azure-Ressource zuzuweisen, die diese dann für den Zugriff auf verwaltete Ressourcen (z. B. Azure Key Vault, SQL-Datenbank, Service Bus und Cosmos DB) verwenden können. Und das alles, ohne dass Verbindungszeichenfolgen oder Anmeldeinformationen in Kubernetes-Geheimnissen gespeichert und daraus abgerufen werden müssen.
  • Ziehen Sie die Verwendung des Secret Store CSI-Treibers für Azure Key Vault in Erwägung, um auf Geheimnisse wie Anmeldeinformationen und Verbindungszeichenfolgen über Key Vault statt über Kubernetes-Geheimnisse zuzugreifen.
  • Ziehen Sie die Verwendung des Bausteins Dapr Secrets Stores mit dem Azure Key Vault-Speicher mit verwalteten Identitäten in Kubernetes in Erwägung, um Geheimnisse (z. B. Anmeldeinformationen und Verbindungszeichenfolgen) aus Key Vault abzurufen.

Workload und Cluster

  • Eines der wichtigsten Dinge, die Sie tun können, um den Zugriff auf den Kubernetes API-Server zu sichern, ist die Sicherung Ihres Clusters. Integrieren Sie die rollenbasierte Zugriffssteuerung von Kubernetes (Kubernetes RBAC) in Microsoft Entra ID, um den Zugriff auf den API-Server steuern zu können. Mit dieser Steuerung können Sie AKS in der gleichen Weise sichern, wie Sie auch den Zugriff auf Ihre Azure-Abonnements sichern können.
  • Begrenzen Sie den Zugriff auf Aktionen, die von Containern ausgeführt werden können. Verwenden Sie die Pod Security Admission, um eine differenzierte Autorisierung von Poderstellungen und -updates zu ermöglichen. Geben Sie die niedrigste Anzahl an Berechtigungen an, und vermeiden Sie die Verwendung von Stamm- oder Rechteausweitung. Weitere Best Practices finden Sie unter Absichern des Podzugriffs auf Ressourcen.
  • Vermeiden Sie es nach Möglichkeit, Container als Root-Benutzer auszuführen.
  • Verwenden Sie das Kernel-Sicherheitsmodul AppArmor von Linux, um die Aktionen einzuschränken, die Container ausführen können.
  • Aktualisieren Sie Ihre AKS-Cluster regelmäßig auf die neueste Kubernetes-Version, um von neuen Features und Fehlerbehebungen zu profitieren.
  • AKS lädt zwar automatisch Behebungen von Sicherheitsproblemen für jeden einzelnen Linux-Knoten herunter und installiert sie, führt aber keinen automatischen Neustart der Knoten durch, wenn dies notwendig ist. Verwenden Sie kured für die Suche nach ausstehenden Neustarts, für das Absperren und Leeren von Knoten und schlussendlich für die Durchführung Ihrer Updates. Führen Sie für Windows Server-Knoten regelmäßig ein AKS-Upgrade durch, um die Pods sicher abzusperren und zu leeren und um aktualisierte Knoten bereitzustellen.
  • Ziehen Sie die Verwendung von sicheren HTTPS- und gRPC-Transportprotokollen für die gesamte podinterne Kommunikation in Erwägung. Denken Sie darüber hinaus über die Nutzung eines erweiterten Authentifizierungsmechanismus nach, der nicht erfordert, dass Sie Ihre Anmeldeinformationen bei jeder Anforderung in Klartext senden müssen (z. B. OAuth oder JWT). Eine sichere serviceinterne Kommunikation kann mithilfe von Istio, Linkerd oder Consul oder mit Dapr erreicht werden.

Azure Container Registry

  • Überprüfen Sie Ihre Containerimages auf Schwachstellen, und stellen Sie nur Images bereit, die die Validierung bestanden haben. Aktualisieren Sie regelmäßig die Basisimages und die Anwendungsruntime, und stellen Sie die Workloads dann im AKS-Cluster erneut bereit. Ihr CI/CD-Bereitstellungsworkflow sollte einen Prozess zum Überprüfen von Containerimages enthalten. Microsoft Defender for Cloud DevOps-Sicherheit kann verwendet werden, um den Code während des Erstellens/Bereitstellens in Ihren automatisierten Pipelines auf Sicherheitsrisiken zu überprüfen. Alternativ können Tools wie Prisma Cloud oder Aqua verwendet werden, um zu überprüfen, dass nur verifizierte Images bereitgestellt werden können.
  • Verwenden Sie bei der Nutzung von Basisimages für Anwendungsimages die Automatisierung, um neue Images zu erstellen, wenn das Basisimage aktualisiert wird. Da diese Basisimages typischerweise Sicherheitskorrekturen enthalten, aktualisieren Sie alle Downstream-Containerimages der Anwendung. Weitere Informationen zu Basisimageaktualisierungen finden Sie unter Automatisieren von Buildvorgängen für Images nach der Aktualisierung des Basisimages mit Azure Container Registry Tasks.

Überlegungen zur Leistung

Obwohl die Überlegungen zur Leistung nicht vollständig mit der Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS) in Zusammenhang stehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt:

  • Ziehen Sie für Workloads mit geringer Latenz die Bereitstellung eines dedizierten Knotenpools in einer Näherungsplatzierungsgruppe in Erwägung. Wenn Sie Ihre Anwendung in Azure bereitstellen, führt die Verteilung von VM-Instanzen (Virtual Machine, virtueller Computer) auf Regionen oder Verfügbarkeitszonen zu Netzwerkwartezeit, die die Gesamtleistung Ihrer Anwendung beeinträchtigen kann. Eine Näherungsplatzierungsgruppe ist eine logische Gruppierung, die dazu dient, eine geringe physische Entfernung zwischen Azure-Computeressourcen sicherzustellen. Einige Anwendungsfälle (wie Spiele, technische Simulationen und Hochfrequenzhandel (High-Frequency Trading, HFT)) erfordern geringe Wartezeiten und eine schnelle Aufgabenausführung. In solchen HPC-Szenarien (High Performance Computing) empfiehlt sich ggf. der Einsatz von Näherungsplatzierungsgruppen (PPG) für die Knotenpools Ihres Clusters.
  • Verwenden Sie immer kleinere Containerimages, da diese Ihnen dabei helfen, den Erstellvorgang zu beschleunigen. Darüber hinaus sind kleinere Images durch ihre reduzierte Angriffsfläche weniger anfällig für Angriffsvektoren.
  • Verwenden Sie die automatische Kubernetes-Skalierung, um die Anzahl der Workerknoten eines AKS-Clusters bei zunehmendem Datenverkehr dynamisch zu skalieren. Mit der horizontalen automatischen Podskalierung und einer automatischen Clusterskalierung werden Knoten- und Podvolumes in Echtzeit dynamisch angepasst, um den Datenverkehr zu bewältigen und Ausfallzeiten zu vermeiden, die aufgrund von Kapazitätsproblemen entstehen. Weitere Informationen finden Sie unter Verwenden der automatischen Clusterskalierung in Azure Kubernetes Service (AKS).

Überlegungen zu Verfügbarkeit und Zuverlässigkeit

Obwohl die Überlegungen zu Verfügbarkeit und Zuverlässigkeit nicht vollständig mit der Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS) in Zusammenhang stehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt: Berücksichtigen Sie die folgenden Möglichkeiten, um die Verfügbarkeit Ihres AKS-Clusters und Ihrer Workloads zu optimieren.

Container

  • Nutzen Sie Kubernetes-Integritätstests, um zu überprüfen, ob Ihre Container aktiv und fehlerfrei sind:

    • Der Livetest (livenessProbe) gibt an, ob der Container ausgeführt wird. Wenn der Livetest fehlschlägt, wird der Container durch das Kubelet beendet und entsprechend der Neustartrichtlinie neu gestartet.
    • Der Bereitschaftstest (ReadinessProbe) gibt an, ob der Container dazu bereit ist, auf Anforderungen zu reagieren. Wenn der Bereitschaftstest fehlschlägt, entfernt der Endpunktcontroller die IP-Adresse des Pods von den Endpunkten aller Dienste, die mit dem Pod übereinstimmen. Der Standard-Bereitschaftsstatus vor der anfänglichen Verzögerung lautet „Failure“.
    • Der Starttest (startup probe) gibt an, ob die Anwendung im Container gestartet wurde. Wenn ein Starttest durchgeführt wird, werden alle anderen Tests deaktiviert bis dieser erfolgreich ist. Wenn der Starttest fehlschlägt, wird der Container durch das Kubelet beendet und entsprechend der Neustartrichtlinie neu gestartet.

  • Ressourcenkonflikte können sich auf die Verfügbarkeit des Diensts auswirken. Definieren Sie Ressourceneinschränkungen für Container, damit ein einzelner Container die Arbeitsspeicher- und CPU-Ressourcen des Clusters nicht überlasten kann. Sie können die AKS-Diagnose verwenden, um Probleme im Cluster zu ermitteln.

  • Über das Ressourcenlimit können Sie die zulässige Gesamtanzahl von Ressourcen in einem Container einschränken, damit nicht ein Container die anderen beeinträchtigt.

Containerregistrierung

  • Es wird empfohlen, Containerimages in Azure Container Registry zu speichern und die Registrierung anschließend mithilfe der Azure Container Registry-Georeplikation in jede AKS-Region zu replizieren. Die Georeplikation ist ein Azure Container Registry-Feature in Premium-SKUs.
  • Überprüfen Sie Ihre Containerimages auf Schwachstellen, und stellen Sie nur Images bereit, die die Validierung bestanden haben. Aktualisieren Sie regelmäßig die Basisimages und die Anwendungsruntime, und stellen Sie Ihre Workloads dann im AKS-Cluster erneut bereit.
  • Beschränken Sie die Imageregistrierungen, die von Pods und Bereitstellungen verwendet werden können. Lassen Sie nur vertrauenswürdige Registrierungen zu, wobei Sie die verfügbaren Images validieren und steuern.
  • Verwenden Sie bei der Nutzung von Basisimages für Anwendungsimages die Automatisierung, um neue Images zu erstellen, wenn das Basisimage aktualisiert wird. Da diese Basisimages typischerweise Sicherheitskorrekturen enthalten, aktualisieren Sie alle Downstream-Containerimages der Anwendung. Wir empfehlen Ihnen, die Containerimages als Teil der CI/CD-Pipeline auf Sicherheitsrisiken zu überprüfen, bevor Sie die Images in der Containerregistrierung veröffentlichen. Azure Defender für Container kann in CI/CD-Workflows integriert werden.
  • Nutzen Sie ACR Tasks in Azure Container Registry, um das Patchen von Betriebssystemen und Frameworks für Ihre Docker-Container zu automatisieren. ACR Tasks unterstützt das automatisierte Ausführen eines Buildvorgangs, wenn das Basisimage eines Containers aktualisiert wird – beispielsweise, wenn Sie das Betriebssystem oder das Anwendungsframework in einem Ihrer Basisimages patchen.

Intraregionale Resilienz

  • Ziehen Sie die Bereitstellung von Knotenpools Ihres AKS-Clusters in allen Verfügbarkeitszonen innerhalb einer Region in Erwägung, und verwenden Sie vor Ihren Knotenpools einen Azure Load Balancer Standard oder den Azure Application Gateway. Mit dieser Topologie wird die Resilienz bei einem Ausfall eines einzelnen Rechenzentrums verbessert. Auf diese Weise werden Clusterknoten auf mehrere Rechenzentren, d. h. in drei separate Verfügbarkeitszonen innerhalb einer Region, verteilt.
  • Aktivieren Sie die Zonenredundanz in Azure Container Registry für eine intraregionale Resilienz und Hochverfügbarkeit
  • Nutzen Sie Topologie-Verteilungseinschränkungen für Pods, um zu steuern, wie Pods in Ihrem AKS-Cluster auf Fehlerdomänen wie Regionen, Verfügbarkeitszonen und Knoten verteilt werden.
  • Ziehen Sie die Verwendung der Betriebszeit-SLA für AKS-Cluster in Erwägung, die unternehmenskritische Workloads hosten. Eine Betriebszeit-SLA ist ein optionales Feature, das eine finanziell abgesicherte, höhere SLA für einen Cluster ermöglicht. Die Betriebszeit-SLA garantiert eine Verfügbarkeit von 99,95 % des Kubernetes-API-Serverendpunkts für Cluster, die Verfügbarkeitszonen verwenden. Außerdem garantiert sie eine Verfügbarkeit von 99,9 % für Cluster, in denen keine Verfügbarkeitszonen verwendet werden. AKS verwendet Masterknotenreplikate über Update- und Fehlerdomänen hinweg, um sicherzustellen, dass die SLA-Anforderungen erfüllt werden.

Notfallwiederherstellung und Geschäftskontinuität

  • Ziehen Sie die Bereitstellung Ihrer Lösung in mindestens zwei gekoppelten Azure-Regionen innerhalb einer Geografie in Erwägung. Sie sollten ebenfalls einen globalen Lastenausgleich wie Azure Traffic Manager oder Azure Front Door mit einer Aktiv/Aktiv- oder Aktiv/Passiv-Routingmethode nutzen, um die Geschäftskontinuität und Notfallwiederherstellung sicherzustellen.
  • Achten Sie darauf, dass Sie jeden regionalen Failoverprozess in einer QA-Umgebung dokumentieren, regelmäßig testen und Skripts für diese Prozesse erstellen. Auf diese Weise können Sie unvorhersehbare Probleme vermeiden, wenn ein Kerndienst von einem Ausfall in der primären Region betroffen ist.
  • Durch diese Tests sollte ebenfalls überprüft werden, ob der DR-Ansatz in Verbindung mit möglichen manuellen Prozessen und Vorgängen, die für ein Failover erforderlich sind, die RPO-/RTO-Ziele erfüllt.
  • Stellen Sie sicher, dass Sie Failback-Verfahren testen, um herauszufinden, ob diese wie erwartet funktionieren.
  • Speichern Sie Ihre Containerimages in Azure Container Registry (ACR), und erstellen Sie per Georeplikation in jeder AKS-Region eine Instanz der Registry. Weitere Informationen finden Sie unter Georeplikation in Azure Container Registry.
  • Speichern Sie den Dienstzustand nach Möglichkeit nicht im Container. Verwenden Sie stattdessen eine Azure-PaaS-Lösung (Platform as a Service), die die Replikation in mehreren Regionen unterstützt.
  • Wenn Sie Azure Storage verwenden, bereiten Sie die Migration Ihres Speichers von der primären zur Sicherungsregion vor, und testen Sie sie.
  • Erwägen Sie die Bereitstellung der Clusterkonfiguration mithilfe von GitOps. Die Verwendung von GitOps bietet Einheitlichkeit zwischen primären Clustern und Notfallwiederherstellungsclustern sowie eine schnelle Möglichkeit zum Wiederherstellen eines neuen Clusters im Falle eines Clusterausfalls.
  • Erwägen Sie die Sicherung/Wiederherstellung der Clusterkonfiguration mithilfe von Tools wie Azure Kubernetes Service-Backup oder Velero.

Speicheraspekt

Obwohl die Überlegungen zum Speicher nicht vollständig mit der Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS) in Zusammenhang stehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt:

  • Ziehen Sie es in Erwägung, Ihr AKS-Cluster mit kurzlebigen Betriebssystemdatenträgern bereitzustellen, durch die eine geringere Lese-/Schreibwartezeit sowie schnellere Knotenskalierung und Clusterupgrades ermöglicht werden.
  • Zur Auswahl des richtigen Speichers sollten Sie die Anforderungen Ihrer Anwendung verstehen. Verwenden Sie SSD-basierten Hochleistungsspeicher für Produktionsworkloads. Planen Sie mit einem netzwerkbasiertes Speichersystem, z. B. Azure Files, wenn mehrere Pods gleichzeitig auf dieselben Dateien zugreifen müssen. Weitere Informationen finden Sie unter Speicheroptionen für die Anwendung in Azure Kubernetes Service (AKS).
  • Jede Knotengröße unterstützt eine maximale Anzahl von Datenträgern. Unterschiedliche Knotengrößen stellen auch verschiedene Mengen an lokalem Speicher und Netzwerkbandbreite bereit. Planen Sie Ihre Anwendungsanforderungen, um die richtige Größe der Knoten bereitzustellen.
  • Um den Verwaltungsaufwand zu reduzieren und ein Skalieren zu ermöglichen, sollten Sie keine persistenten Volumes statisch erstellen und zuweisen. Verwenden Sie die dynamische Bereitstellung. Definieren Sie in Ihren Speicherklassen die entsprechende Freigaberichtlinie, um die Kosten für nicht benötigten Speicher nach dem Löschen von Pods zu minimieren.

Überlegungen zum Scheduler

Obwohl einige der Überlegungen zum Scheduler nicht vollständig mit der Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS) in Zusammenhang stehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt.

  • Stellen Sie sicher, dass Sie die Best Practices für Clusteroperatoren und Anwendungsentwickler lesen und implementieren, um erfolgreich Anwendungen auf Azure Kubernetes Service (AKS) erstellen und ausführen zu können.
  • Planen Sie Ressourcenkontingente auf Namespaceebene, und wenden Sie diese für alle Namespaces an. Wenn Pods keine Ressourcenanforderungen und -grenzwerte definieren, lehnen Sie die Bereitstellung ab. Überwachen Sie die Ressourcennutzung, und passen Sie Kontingente nach Bedarf an. Wenn mehrere Teams oder Mandanten einen AKS-Cluster mit einer festen Knotenanzahl gemeinsam nutzen, können Ressourcenkontingente eingesetzt werden, um jedem Team oder Mandanten einen angemessenen Ressourcenanteil zuzuweisen.
  • Übernehmen Sie Grenzwerte, um Ressourcenzuordnungen (für Pods oder Container) in einem Namespace hinsichtlich CPU und Arbeitsspeicher einzuschränken.
  • Definieren Sie für Ihre Pods in den YAML-Manifesten oder Helm Charts, die Sie zum Bereitstellen von Anwendungen verwenden, explizit Anforderungen und -grenzwerte hinsichtlich der CPU- und Arbeitsspeicherauslastung der Ressourcen. Wenn Sie die Ressourcenanforderung für Container in einem Pod festlegen, verwendet der Kubernetes-Scheduler diese Informationen, um zu entscheiden, auf welchem Knoten der Pod platziert werden soll. Wenn Sie einen Ressourcengrenzwert (z. B. CPU oder Arbeitsspeicher) für einen Container festlegen, sorgt das Kubelet für die Einhaltung dieser Grenzwerte. Auf diese Weise kann der ausgeführte Container nicht mehr von dieser Ressource nutzen, als durch den Grenzwert festgelegt wurde.
  • Um die Verfügbarkeit von Anwendungen aufrechtzuerhalten, definieren Sie Budgets für die Unterbrechung von Pods (Pod Disruption Budgets, PDBs), um sicherzustellen, dass eine Mindestanzahl von Pods im Cluster verfügbar ist.
  • Prioritätsklassen können genutzt werden, um die Wichtigkeit eines Pods anzugeben. Wenn ein Pod nicht geplant werden kann, versucht der Scheduler, Pods mit niedrigerer Priorität vorzeitig zu entfernen, um die Planung des ausstehenden Pods zu ermöglichen.
  • Verwenden Sie Taints und Toleranzen in Kubernetes, um ressourcenintensive Anwendungen auf bestimmten Knoten zu platzieren und Beeinträchtigungen durch andere Dienste („Noisy Neighbors“) zu vermeiden. Halten Sie Knotenressourcen für Workloads verfügbar, die diese benötigen, und erlauben Sie keine Planung anderer Workloads auf den Knoten.
  • Steuern Sie die Planung von Pods auf Knoten mithilfe von Knotenelektoren, Knotenaffinität oder Pod-interner Affinität. Verwenden Sie podübergreifende Affinitäts- und Antiaffinitätseinstellungen, um besonders aktive („geschwätzige“) Pods demselben Ort zuzuordnen, um Pods auf verschiedenen Knoten zu platzieren, und um zu vermeiden, dass mehrere Instanzen derselben Podart auf demselben Knoten ausgeführt werden.

Überlegungen zum Service Mesh

Obwohl sich die Überlegungen zum Service Mesh nicht vollständig auf die Mehrinstanzenfähigkeit in AKS beziehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt.

  • Ziehen Sie den Einsatz eines Open-Source-Dienstnetzes (wie Istio, Linkerd oder Consul) in Ihrem AKS-Cluster in Erwägung, um den Einblick, die Zuverlässigkeit und die Sicherheit für Ihre Microservices über gegenseitiges TLS zu verbessern. Sie können ebenfalls Strategien für die Aufteilung des Datenverkehrs implementieren (z. B. Blau/Grün-Bereitstellungen und Canary-Bereitstellungen). Bei einem Service Mesh handelt es sich, kurz gesagt, um eine dedizierte Infrastrukturebene, über die die Kommunikation zwischen Diensten sicher, schnell und zuverlässig gestaltet werden kann. Informationen zum AKS-integrierten Istio-Add-On finden Sie unter: Istio Service Mesh AKS-Add-On

  • Ziehen Sie die Einführung von Dapr in Erwägung, um robuste, zustandslose und zustandsbehaftete Microserviceanwendungen zu erstellen. Sie können eine beliebige Programmiersprache und ein beliebiges Entwicklerframework verwenden.

Überlegungen zu DevOps

  • Stellen Sie Ihre Workloads in Azure Kubernetes Service (AKS) über einen Helm Chart in einer CI/CD-Pipeline bereit, indem Sie ein DevOps-System wie GitHub Actions oder Azure DevOps verwenden. Weitere Informationen finden Sie unter Erstellen und Bereitstellen in Azure Kubernetes Service.

  • Führen Sie im Rahmen Ihres Application Lifecycle Managements A/B-Tests und Canary-Bereitstellungen ein, um eine Anwendung ordnungsgemäß zu testen, bevor sie für alle Benutzer verfügbar gemacht wird. Es gibt mehrere Methoden, mit denen Sie den Datenverkehr auf verschiedene Versionen desselben Diensts aufteilen können.

  • Alternativ können Sie die Funktionen zur Verwaltung des Datenverkehrs verwenden, die von einer Dienstnetzimplementierung bereitgestellt werden. Weitere Informationen finden Sie unter:

  • Verwenden Sie Azure Container Registry oder eine andere Containerregistrierung (wie Docker Hub), um die privaten Docker-Images zu speichern, die im Cluster bereitgestellt werden. AKS kann die Authentifizierung mit Azure Container Registry durchführen, indem die eigene Microsoft Entra-Identität verwendet wird.

Aspekte der Überwachung

Obwohl die Überlegungen zu Überwachungsaspekten nicht vollständig mit der Mehrinstanzenfähigkeit in Azure Kubernetes Service (AKS) in Zusammenhang stehen, sind wir der Meinung, dass es sich um grundlegende Anforderungen für die Bereitstellung dieser Lösung handelt:

  • Erwägen Sie Azure-integrierte Überwachungsoptionen, um den Integritätsstatus des AKS-Clusters und der Workloads zu überwachen.
  • Konfigurieren Sie alle PaaS-Dienste (z. B. Azure Container Registry und Key Vault) so, dass sie Diagnoseprotokolle und Metriken für Azure Monitor Log Analytics sammeln.

Kostenoptimierung

Die Kosten dieser Architektur hängen von Konfigurationsaspekten wie den folgenden ab:

  • Dienstebenen
  • Skalierbarkeit, d. h. die Anzahl der Instanzen, die von Diensten dynamisch zugeordnet werden, um einen bestimmten Bedarf zu unterstützen.
  • Automatisierungsskripts
  • Ihrer Notfallwiederherstellungsebene

Nachdem Sie diese Aspekte bewertet haben, wechseln Sie zum Azure Preisrechner, um die Ihnen entstehenden Kosten abzuschätzen. Weitere Optionen für die Preisoptimierung finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Bereitstellen dieses Szenarios

Den Quellcode für dieses Szenario finden Sie auf GitHub. In diesem GitHub Repository finden Sie auch eine Demoanwendung, wie in der folgenden Abbildung dargestellt.

Diagramm der Bereitstellung dieses Eingangsdatencontrollers für Application Gateway mit AKS-Architektur.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Voraussetzungen

Für Onlinebereitstellungen müssen Sie über ein Azure-Konto verfügen. Sollten Sie noch keins haben, können Sie kostenlos eins erstellen, bevor Sie beginnen.

Bereitstellen in Azure

  1. Vergewissern Sie sich, dass Sie auf die Daten zu Ihrem Azure-Abonnement zugreifen können.

  2. Klonen Sie zunächst das GitHub-Repository Workbench:

    git clone https://github.com/Azure-Samples/aks-agic.git

  3. Befolgen Sie die Anweisungen in der Datei README.md.

Beitragende

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

Hauptautoren:

Nächste Schritte

Azure Kubernetes Service

Azure Application Gateway

Azure Application Gateway Ingress Controller (Azure Application Gateway-Eingangscontroller)

Azure Application Gateway-WAF

Architekturleitfaden

Referenzarchitekturen