Basisarchitektur für einen Azure Kubernetes Service (AKS) Cluster

Azure Application Gateway

Azure Container Registry

Azure Firewall

Azure Kubernetes Service (AKS)

Rollenbasierte Zugriffssteuerung in Azure

Dieser Artikel enthält eine empfohlene Basisinfrastrukturarchitektur zum Bereitstellen eines Azure Kubernetes Service (AKS) Clusters. Es folgt unseren Designprinzipien und richtet sich an die bewährten Methoden von AKS architectural aus dem Azure Well-Architected Framework. Der Artikel dient verschiedenen interdisziplinären Teams – wie beispielsweise Netzwerk-, Sicherheits- und Identitätsteams – als Anleitung bei der Bereitstellung dieser universell einsetzbaren Infrastruktur.

Diese Architektur konzentriert sich nicht auf eine Workload. Sie konzentriert sich auf den AKS-Cluster selbst. Bei den hier genannten Informationen handelt es sich um die empfohlene Mindestbaseline für die meisten AKS-Cluster. Es ist in Azure Dienste integriert, die Observability liefern, eine Netzwerktopologie bereitstellen, die multiregionales Wachstum unterstützt und sicheren In-Cluster-Datenverkehr unterstützt.

Ihre Geschäftlichen Anforderungen beeinflussen die Zielarchitektur und können zwischen Anwendungskontexten variieren. Betrachten Sie die Architektur als Ausgangspunkt für die Vorproduktions- und Produktionsphasen.

Tip

In diesem Artikel werden ausführliche Entwurfsüberlegungen für AKS-Cluster behandelt. AKS Automatic implementiert viele Entwurfsentscheidungen, um die Anzahl der Überlegungen zu reduzieren, die Sie bewerten und optimieren müssen, um häufig verwendete Anwendungsfälle zu optimieren. AKS Automatic stellt z. B. einen verwalteten Systemknotenpool bereit und betreibt den Systemknotenpool, sodass die Größen-, Isolations- und Upgradeentscheidungen in diesem Artikel nicht für diese Plattform gelten.

Selbst wenn Ihre Workload in einer automatischen AKS-Umgebung gehostet wird, können Sie die Grundlagen für einen selbstverwalteten AKS-Cluster kennen, um die richtigen Entscheidungen zu treffen, wenn sich Ihre Workload ändert.

Kubernetes ist ein breites Ökosystem, das sich über Azure und Microsoft Technologien erstreckt. Wenn Sie einen AKS-Cluster bereitstellen, sind Sie für viele Entscheidungen zum Entwerfen und Betreiben des Clusters verantwortlich. Der Betrieb eines AKS-Clusters umfasst Closed-Source-Komponenten verschiedener Anbieter, darunter Microsoft, sowie Open-Source-Komponenten aus dem Kubernetes-Ökosystem. Die Landschaft ändert sich häufig, also revidieren Sie regelmäßig Entscheidungen. Wenn Sie Kubernetes einführen, erkennen Sie an, dass Ihre Arbeitsauslastung seine Funktionen benötigt und dass Ihr Workload-Team auf laufender Basis investieren kann.

Sie können eine Implementierung dieser Architektur auf GitHub: AKS-Basisreferenzimplementierung als alternativer Ausgangspunkt verwenden und so konfigurieren, dass sie Ihren Anforderungen entspricht.

Note

Die Referenzarchitektur erfordert Kenntnisse über Kubernetes und die entsprechenden Konzepte. Wenn Sie eine Auffrischung benötigen, lesen Sie die Einführung in Kubernetes und Entwicklung und Bereitstellung von Anwendungen auf Kubernetes Schulungspfade.

Netzwerkkonfiguration

Netzwerktopologie
Planen der IP-Adressen
Anwendungsrouting

Clusterberechnung

Berechnung für den Basiscluster
Container-Image-Referenz
Richtlinienverwaltung

Identitätsverwaltung

Integrate Microsoft Entra ID für den Cluster
Integrieren Sie Microsoft Entra ID für die Arbeitslast

Sicherer Datenfluss

Schützen des Datenflusses im Netzwerk
Hinzufügen einer Geheimnisverwaltung

Geschäftskontinuität

Knoten- und Podskalierbarkeit
Geschäftskontinuitätsentscheidungen
Availability ZonesMehrere Regionen

Operations

Cluster- und Workload-Operationen
Überwachen und Sammeln von Protokollen und Metriken
Kostenverwaltung

Architektur

Das Diagramm zeigt zwei verbundene virtuelle Netzwerke. Das virtuelle Hubnetzwerk enthält Azure Firewall, Azure Bastion und ein Gatewaysubnetz, das mit dem lokalen Netzwerk vor Ort verbunden ist. Das Spoke-virtuelle Netzwerk enthält mehrere Subnetze, den AKS-Cluster und Knotenpools. Das Peering virtueller Netzwerke verbindet die virtuellen Hub- und Spoke-Netzwerke über eine bidirektionale Verbindung. Pfeile zeigen von Key Vault und Container Registry auf das Subnetz für Private Link-Endpunkte. Ein Pfeil zeigt vom Azure Bastion-Subnetz (Verwaltung) zum internen Load Balancer im virtuellen Spoke-Netzwerk. Ein Pfeil zeigt vom lokalen Netzwerk zum lokalen Gateway. Ein bidirektionaler Pfeil mit der Bezeichnung „Virtual Network Peering“ zeigt vom virtuellen Hub-Netzwerk zum Spoke-Netzwerk der Außenstelle. Ein Pfeil verweist vom Internet auf das Azure Application Gateway Subnetz. Ein Pfeil zeigt vom AKS-Cluster zum Abschnitt „Azure Monitor-Arbeitsbereich“, der Metriken und Managed Prometheus umfasst.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Weitere Informationen finden Sie unter Hub-Spoke-Netzwerktopologie in Azure.

Netzwerktopologie

Diese Architektur verwendet eine Hub-and-Spoke-Netzwerktopologie. Stellen Sie den Hub und die Speichen in separaten virtuellen Netzwerken bereit, die über virtual network Peering verbunden sind. Diese Topologie hat mehrere Vorteile:

• Ermöglichen einer getrennten Verwaltung Sie können Governance implementieren und das Prinzip der geringsten Privilegien (PoLP) einhalten. Es unterstützt auch das Konzept einer Azure Landezone mit einer Trennung von Aufgaben.

• Minimieren Sie die direkte Exposition von Azure-Ressourcen zum öffentlichen Internet.

• Stellen Sie regionale Hub-and-Spoke-Topologien bereit. Sie können zukünftig Hub-and-Spoke-Netzwerktopologien erweitern und die Workload-Isolation ermöglichen.

• Verwenden Sie einen web application firewall-Dienst, um den HTTP-Datenverkehrsfluss für alle Webanwendungen zu prüfen.

• Stellen Sie Unterstützung für Workloads bereit, die sich über mehrere Abonnements erstrecken.

• Die Architektur erweiterbar machen Um neue Features oder Workloads zu ermöglichen, können Sie neue Spokes hinzufügen, anstatt die Netzwerktopologie komplett neu zu entwerfen.

• Das Teilen von Ressourcen unterstützen, z. B. eine Firewall und DNS-Zonen (Domain Name System), über Netzwerke hinweg.

• Stimmen Sie diese auf die Azure-Zielzone auf Unternehmensebene ab.

Hub-Virtualnetzwerk

Der Hub virtual network ist der zentrale Punkt der Konnektivität und Observierbarkeit. In dieser Architektur enthält der Hub die folgenden Komponenten:

• Azure Firewall mit globalen Firewallrichtlinien, die Ihre zentralen IT-Teams definieren, um organisationsweite Regeln zu erzwingen

• Azure Bastion, die einen sicheren Tunnel in den privaten Netzwerkperimeter einleite, sodass Sie Clusterverwaltungsvorgänge ausführen können

• Ein Gatewaysubnetz für VPN-Konnektivität

• Azure Monitor für die Netzwerküberwachung

Innerhalb des Netzwerks verfügt die Architektur über drei Subnetze.

Subnetz zum Hosten von Azure Firewall

Azure Firewall ist ein verwalteter Firewalldienst. Die Azure Firewall Instanz sichert ausgehenden Netzwerkdatenverkehr. Ohne diese Sicherheitsebene kommuniziert der Datenverkehr möglicherweise mit einem schädlichen, nicht Microsoft Dienst, der vertrauliche Workloaddaten exfiltrieren könnte. Verwenden Sie Azure Firewall Manager, um mehrere Azure Firewall Instanzen zentral bereitzustellen und zu konfigurieren und Azure Firewall Richtlinien für dieses hub virtual network Architekturtyp zu verwalten.

Subnetz zum Hosten eines Gateways

Dieses Subnetz ist ein Platzhalter für ein VPN-Gateway oder ein Azure ExpressRoute Gateway. Das Gateway bietet Konnektivität zwischen den Routern in Ihrem lokalen Netzwerk und dem virtual network.

Subnetz zum Hosten von Azure Bastion

Dieses Subnetz wird für Azure Bastion verwendet. Sie können Azure Bastion verwenden, um sicher auf Azure Ressourcen zuzugreifen, ohne die Ressourcen für das Internet verfügbar zu machen. Diese Architektur verwendet Azure Bastion, um eine sichere Verbindung mit dem API-Server des AKS-Clusters für Verwaltungsvorgänge herzustellen. Das Subnetz ist nur für Verwaltung und Vorgänge vorgesehen.

Virtuelles Spoke-Netzwerk

Das spoke-virtuelle Netzwerk enthält den AKS-Cluster und andere zugehörige Ressourcen. Der Spoke verfügt über die folgenden Subnetze.

Subnetz zum Hosten von Azure Application Gateway

Azure Application Gateway ist ein Webdatenverkehr-Lastenausgleichsmodul, das auf Layer 7 ausgeführt wird. Die Referenzimplementierung verwendet die Anwendungsgateway-SKU v2, die Azure Web Application Firewall ermöglicht. Web Application Firewall sichert eingehenden Datenverkehr von gängigen Webdatenverkehrangriffen, einschließlich Bots. Die Instanz verfügt über eine öffentliche IP-Konfiguration am Front-End, das die Benutzeranforderungen empfängt. Für das Application Gateway ist von Design her ein dediziertes Subnetz benötigt.

Subnetz für Frontend-IP-Adressen des internen Load Balancers

Dieses Subnetz stellt den IP-Adressraum für die internen Frontend-IP-Adressen des Lastenausgleichs bereit. Application Gateway sendet Datenverkehr an die zugewiesene private IP-Adresse des internen Lastenausgleichsmoduls. Der Lastenausgleich verteilt Datenverkehr an einen beliebigen Knoten im Cluster. kube-proxy auf dem empfangenden Knoten leitet das Paket an den Gateway-Proxy-Pod im System-Nodepool weiter, wodurch möglicherweise ein zusätzlicher Netzwerksprung entsteht. Der Proxy beendet TLS und leitet Anforderungen an Workload-Pods über HTTP weiter. Mithilfe eines dedizierten Subnetzes für diese Front-End-IPs können Sie NSG-Regeln anwenden, die eingehenden Datenverkehr auf das Lastenausgleichsmodul beschränken, ohne dass sich dies auf das Knotensubnetz auswirkt. Weitere Informationen finden Sie unter Verwenden eines internen Lastenausgleichs mit AKS.

Subnetz zum Hosten der Clusterknoten

Diese Architektur verwendet zwei Knotenpools, die separate Knotengruppen sind. Der Systemknotenpool beherbergt Pods, auf denen zentrale Clusterdienste ausgeführt werden, einschließlich des Gateway-Proxy, der den Datenverkehr zur Workload weiterleitet. Der Benutzerknotenpool führt Ihre Workload aus.

Subnet zum Hosten von Azure Private Link Endpunkten

Erstellen Sie Azure Private Link Verbindungen für Azure Container Registry und Azure Key Vault, damit Benutzer über einen private-Endpunkt innerhalb des virtuellen Speichennetzwerks auf diese Dienste zugreifen können. Private Endpunkte erfordern kein dediziertes Subnetz. Sie können auch private Endpunkte im Hub-virtual network platzieren. In der Baselineimplementierung werden die Endpunkte in einem dedizierten Subnetz innerhalb des virtuellen Spoke-Netzwerks bereitgestellt. Dieser Ansatz reduziert den Datenverkehr, der über die Peer-Netzwerkverbindung läuft. Sie behält die Ressourcen, die zum Cluster gehören, in demselben virtual network. Sie können auch präzise Sicherheitsregeln auf Subnetzebene anwenden, indem Sie Netzwerksicherheitsgruppen (NSGs) verwenden.

Weitere Informationen finden Sie unter Private Link Bereitstellungsoptionen.

Subnetz für den AKS-API-Server

Sie können einen AKS-Cluster so konfigurieren, dass die virtuelle Netzwerk-Integration des API-Servers verwendet wird, wodurch der API-Serverendpunkt des Clusters in ein delegiertes Subnetz in Ihrem virtuellen Netzwerk projiziert wird. Diese Konfiguration wird als privater Cluster bezeichnet, da sichergestellt wird, dass der gesamte Datenverkehr zwischen dem API-Server, Knotenpools und verbundenen Clients vollständig in Ihrem privaten Netzwerk verbleibt.

Die gesamte Kommunikation zwischen dem AKS-verwalteten Kubernetes-API-Server und Clients (sowohl clusterinterne als auch externe Clients) ist auf ein vertrauenswürdiges Netzwerk beschränkt.

Mit einem privaten Cluster können Sie NSGs und andere integrierte Netzwerksteuerelemente verwenden, um Ihre Umgebung zu schützen. Diese Konfiguration verbietet jeglichen nicht autorisierten öffentlichen Zugriff zwischen dem Internet und der Umgebung. Weitere Informationen finden Sie unter Create a private AKS cluster.

Planen Sie die IP-Adressen

Das Diagramm zeigt eine einfache AKS Hub-and-Spoke-Netzwerktopologie. Der Hub verfügt über Azure Firewall, Azure Bastion und ein Gateway. Der Spoke verfügt über Subnetze für Application Gateway, Ingress, Knoten, API-Server und private Endpunkte. Pfeile zeigen den eingehenden Datenverkehr aus dem Internet zum Application Gateway und dann zum internen Load Balancer, Gatewayproxy und den Workload-Pods. Ausgehende Pfeile führen vom Cluster zur Azure Firewall. Pfeile von privaten Endpunkten führen zu Azure-Diensten wie Container Registry und Key Vault.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Referenzarchitektur verwendet mehrere Netzwerkansätze, von denen jede einen IP-Adressraum erfordert:

• Ihr Azure virtuelles Netzwerk, das Sie für Ressourcen wie Clusterknoten, den API-Server des Clusters, private Endpunkte für Azure-Dienste und Anwendungsgateway verwenden.

• Der Cluster verwendet Azure Container Networking Interface (CNI) Overlay, das IP-Adressen an Pods von einem separaten Adressraum zu Ihrem virtuellen Azure-Netzwerk zuordnet.

Virtuelles Netzwerk-IP-Adressraum

Der Adressraum Ihres Azure virtuellen Netzwerks sollte groß genug sein, um alle Subnetze zu speichern. Berücksichtigen Sie alle Entitäten, die Datenverkehr empfangen. Kubernetes weist IP-Adressen für die Entitäten aus dem Subnetzadressraum zu. Berücksichtigen Sie die folgenden Punkte, wenn Sie die IP-Adressen Ihres Azure virtuellen Netzwerks planen:

• Upgrades: AKS aktualisiert Knoten regelmäßig, um sicherzustellen, dass die zugrunde liegenden VMs auf dem neuesten Stand in Bezug auf Sicherheitsfunktionen und andere Patches sind. Während eines Upgradevorgangs erstellt AKS einen Knoten, der die Pods temporär hostet, während der Upgradeknoten gesperrt und entladen wird. Dieser temporäre Knoten empfängt eine IP-Adresse aus dem Cluster-Subnetz. Stellen Sie sicher, dass Genügend Adressraum für die temporären Knoten-IP-Adressen vorhanden ist.

  In dieser Architektur sowie während paralleler Updates werden Pods IP-Adressen aus dem Pod-Adressraum des Azure CNI Overlay zugewiesen. Dieser Ansatz reduziert die Gesamtanzahl der IP-Adressen, die von Ihrem Azure virtuellen Netzwerk im Vergleich zu anderen Kubernetes-Netzwerkansätzen verwendet werden.

• Skalierbarkeit: Berücksichtigen Sie die Gesamtanzahl der System- und Benutzerknoten und deren maximale Skalierbarkeitsgrenzwerte. Wenn Sie z. B. um 400 % skalieren möchten, benötigen Sie die vierfache Anzahl an Adressen für alle skalierten Knoten.

  Da diese Architektur Azure CNI Overlay verwendet, wirkt sich die Skalierbarkeit Ihrer Pods nicht auf den Adressraum Ihres virtuellen Netzwerks aus.

• Private Link-Adressen: Berücksichtigen Sie die Adressen, die für die Kommunikation mit anderen Azure-Diensten über Private Link erforderlich sind. Diese Architektur weist zwei Adressen für die Links zur Containerregistrierung und Key Vault auf.

• Private-Cluster-API-Serveradressen: Die Integration des API-Servers in das virtuelle Netzwerk hilft Ihnen, den AKS-API-Server als Endpunkt in Ihrem virtuellen Netzwerk zu projektieren. Für dieses Feature ist eine minimum-Subnetzgröße erforderlich. Stellen Sie daher sicher, dass Sie diese Voraussetzungen während der Netzwerkplanung erfüllen.

• Reservierte IP-Adressen: Azure reserviert bestimmte Adressen für eigene Zwecke. Sie können nicht zugewiesen werden.

Die obige Liste ist nicht vollständig. Wenn Ihr Entwurf andere Ressourcen aufweist, die sich auf die Anzahl der verfügbaren IP-Adressen auswirken, sollten Sie diese Adressen einplanen.

Diese Architektur ist für eine einzelne Workload konzipiert. Trennen Sie in einem AKS-Produktionscluster immer den Systemknotenpool vom Benutzerknotenpool. Wenn Sie mehrere Workloads auf dem Cluster ausführen, sollten Sie die Benutzerknotenpools ggf. voneinander isolieren. Diese Isolation führt zu mehr Subnetzen, die kleiner sind. Die Gateway-Topologie kann auch wachsen, da jede Gateway-Ressource die Bereitstellung eines eigenen Gateway-Proxys und einer eigenen Frontend-IP des Lastenausgleichs bewirkt. Planen Sie den Subnetzadressraum entsprechend.

IP-Adressraum des Pods

Azure CNI Overlay weist Pods IP-Adressen mithilfe eines dedizierten Adressraums zu, der vom Adressraum getrennt ist, den Sie in Ihrem virtuellen Netzwerk verwenden. Verwenden Sie einen IP-Adressraum, der sich nicht mit Ihrem virtuellen Netzwerk oder mit virtuellen Peernetzwerken überlappt. Wenn Sie jedoch mehrere AKS-Cluster erstellen, können Sie sicher den gleichen Pod-Adressraum für jeden Cluster verwenden.

Azure CNI Overlay weist jedem Knoten einen /24-Adressraum für seine Pods zu. Es ist wichtig sicherzustellen, dass der Pod-Adressraum ausreichend groß ist. Lassen Sie so viele /24-Blöcke zu, wie Sie für die Anzahl der Knoten in Ihrem Cluster benötigen. Denken Sie daran, alle temporären Knoten einzuschließen, die während Upgrades oder Scale-Out-Vorgängen erstellt wurden. Wenn Sie z. B. einen /16-Adressraum für Ihren klassenlosen CiDR-Bereich (Inter-Domain Routing) verwenden, kann Ihr Cluster auf maximal 250 Knoten wachsen.

Jeder Knoten unterstützt bis zu 250 Pods, und dieser Grenzwert umfasst alle Pods, die temporär während Upgrades erstellt werden.

Weitere Informationen finden Sie in den Richtlinien zur IP-Adressplanung für Azure CNI Overlay.

Weitere Überlegungen zum IP-Adressraum

Die vollständige Netzwerküberlegung für diese Architektur finden Sie unter AKS-Basisnetzwerktopologie. Weitere Informationen zum Planen der IP-Adressierung für einen AKS-Cluster finden Sie unter Configure Azure CNI-Netzwerk in AKS.

Add-Ons und Previewfunktionen

Kubernetes und AKS entwickeln sich kontinuierlich weiter, mit schnelleren Veröffentlichungszyklen als Software für lokale Umgebungen. Diese Basisarchitektur hängt von bestimmten AKS-Vorschaufeatures und AKS-Add-Ons ab. Berücksichtigen Sie die folgenden Unterschiede zwischen Vorschaufeatures und Add-Ons:

• Das AKS-Team beschreibt Preview-Funktionen als veröffentlicht und in Weiterentwicklung, da viele dieser Funktionen nur wenige Monate in diesem Status verbleiben, bevor sie in die Phase der allgemeinen Verfügbarkeit (AV) übergehen.

• AKS Add-Ons und Erweiterungen bieten zusätzliche, unterstützte Funktionen. AKS verwaltet ihre Installation, Konfiguration und den Lebenszyklus.

Die Basisarchitektur umfasst nicht jede Vorschaufunktion oder Erweiterung. Stattdessen werden nur diejenigen einbezogen, die für einen allgemeinen Cluster von erheblichem Nutzen sind. Wenn diese Funktionen die Vorschauphase verlassen, wird die Basisarchitektur entsprechend überarbeitet. Es gibt einige weitere Vorschaufeatures oder AKS-Add-Ons, die Sie möglicherweise in Vorproduktionsclustern auswerten möchten. Diese Features können Ihre Sicherheit, Verwaltbarkeit oder andere Anforderungen verbessern. Bei Nicht-Microsoft-Add-Ons müssen Sie diese installieren und verwalten, einschließlich der Nachverfolgung verfügbarer Versionen und der Installation von Updates nach dem Upgrade der Kubernetes-Version eines Clusters.

Containerimageverweis

Der Cluster kann die Workload und mehrere andere Images enthalten, z. B. eine selbstverwaltete Gatewayinfrastruktur oder ein Hilfscontainer, der TLS-Zertifikate von Key Vault synchronisiert. Einige dieser Bilder befinden sich möglicherweise in öffentlichen Registern, es empfiehlt sich jedoch, sie in einer dedizierten privaten Registrierung wie Azure Container Registry zu scannen, zu überwachen und zu speichern. Berücksichtigen Sie die folgenden Punkte, wenn Sie die Bilder in Ihren Cluster ziehen:

• Authentifizieren Sie den Cluster, um das Image zu pullen.

• Wenn Sie ein öffentliches Image verwenden, importieren Sie das Image in eine Container-Registry, die mit Ihrem Dienstgüteziel (SLO) übereinstimmt. Andernfalls unterliegt das Image möglicherweise unerwarteten Verfügbarkeitsproblemen. Wenn das Image bei Bedarf nicht verfügbar ist, können Betriebsprobleme auftreten. Beachten Sie die folgenden Vorteile der Verwendung einer privaten Containerregistrierung, z. B. Azure Container Registry, anstelle einer öffentlichen Registrierung:

  • Sie können unautorisierten Zugriff auf Ihre Bilder blockieren.
  • Es liegen keine öffentlichen Abhängigkeiten vor.
  • Sie können auf Protokolle für das Abrufen von Bildern zugreifen, um Aktivitäten und Verbindungsprobleme zu überwachen.
  • Sie können von integrierter Containerüberwachung und Imagekonformität profitieren.

• Ziehen Sie Images aus autorisierten Registries. Sie können diese Einschränkung durch Azure Policy erzwingen. In dieser Referenzimplementierung ruft der Cluster nur Bilder aus der dedizierten Azure Container Registry Instanz ab, die mit dem Cluster bereitgestellt wird.

Konfigurieren Sie die Rechenressourcen für den Basiscluster

In AKS ist jeder Knotenpool in der Regel einem Virtual Machine Scale Set zugeordnet. Knoten sind Virtuelle Maschinen (VMs) in jedem Knotenpool.

Verwenden Sie ggf. eine geringere VM-Größe für den Systemknotenpool, um die Kosten zu minimieren. Diese Referenzimplementierung stellt den Systemknotenpool mit drei D2dv5-Knoten bereit. Diese Größe reicht aus, um die erwartete Last der Systempods zu erfüllen. Der kurzlebige Datenträger des Betriebssystems beträgt 64 GB.

Berücksichtigen Sie beim Planen der Kapazität für einen Benutzerknotenpool die folgenden Empfehlungen:

• Wählen Sie größere Knoten aus, um die maximale Anzahl der auf einem Knoten festgelegten Pods zu unterstützen. Große Knoten minimieren den Fußabdruck von Diensten, die auf allen Knoten ausgeführt werden, z. B. Überwachung und Protokollierung.

• Wählen Sie den entsprechenden VM-Typ aus, wenn Sie spezielle Workload-Anforderungen haben. Möglicherweise benötigen Sie z. B. ein speicheroptimiertes Produkt für einige Workloads oder ein GPU-beschleunigtes Produkt für andere Workloads. Weitere Informationen finden Sie unter Sizes for VMs in Azure.

• Stellen Sie mindestens zwei Knoten bereit, damit die Workload einem Hochverfügbarkeitsmuster mit zwei Replikaten folgen kann. Mit AKS können Sie die Knotenanzahl ändern, ohne den Cluster neu zu erstellen.

• Planen Sie die tatsächlichen Knotengrößen für Ihre Workload basierend auf den Anforderungen, die Ihr Designteam bestimmt. Basierend auf den geschäftlichen Anforderungen verwendet diese Architektur die D4dv5-SKU für die Produktionsworkloads.

• Gehen Sie bei der Kapazitätsplanung für Ihren Cluster davon aus, dass Ihre Workload bis zu 80 % jedes Knotens beansprucht. Die verbleibenden 20 % sind für AKS-Dienste reserviert.

• Legen Sie die maximale Anzahl an Pods für jeden Knoten auf der Grundlage Ihrer Kapazitätsplanung fest. Wenn Sie versuchen, eine Kapazitätsbasislinie festzulegen, beginnen Sie mit dem Wert 30. Passen Sie diesen Wert basierend auf den Anforderungen der Workload, der Knotengröße und den Einschränkungen ihrer IP-Adresse an.

Auswählen eines Betriebssystems

Die meisten AKS-Cluster verwenden für ihre Knotenpools Linux als Betriebssystem. In dieser Referenzimplementierung verwenden wir Azure Linux, eine leicht gehärtete Linux-Verteilung, die für Azure optimiert ist. Sie können eine andere Linux-Verteilung wie Ubuntu auswählen, wenn Sie es bevorzugen oder wenn Azure Linux Ihre Anforderungen nicht erfüllt. Wenn Sie ein anderes Betriebssystem auswählen, stellen Sie sicher, dass der Betriebssystemdatenträger für dieses Image entsprechend angepasst ist. Einige Verteilungen benötigen mehr Speicherplatz als Azure Linux. Möglicherweise müssen Sie die Datenträgergröße erhöhen, um Bereitstellungs- oder Laufzeitprobleme zu vermeiden.

Wenn Ihre Workload aus gemischten Technologien besteht, können Sie verschiedene Betriebssysteme in verschiedenen Knotenpools verwenden. Wenn Sie jedoch keine anderen Betriebssysteme benötigen, empfiehlt es sich, ein einzelnes Betriebssystem für alle Workloadknotenpools zu verwenden, um die Betriebskomplexität zu verringern.

Integrieren von Microsoft Entra ID für den Cluster

Die Sicherung des Zugriffs auf und vom Cluster ist von entscheidender Bedeutung. Verwenden Sie die Perspektive des Clusters, um den Unterschied zwischen eingehendem und ausgehendem Datenverkehr nachzuvollziehen.

• Inside-Out-Zugriff: Berücksichtigen Sie den AKS-Zugriff auf Azure-Komponenten wie die Netzwerkinfrastruktur, die Container Registry und Key Vault. Autorisieren Sie nur die Ressourcen, auf die der Cluster zugreifen darf.

• Outside-In-Zugriff: Gewähren Sie Identitäten Zugriff auf den Kubernetes-Cluster. Autorisieren Sie nur die externen Entitäten, die Zugriff auf den Kubernetes-API-Server und Azure Resource Manager haben.

AKS-Zugriff auf Azure Komponenten

Es gibt zwei Möglichkeiten, den Zugang von AKS zu Azure über Microsoft Entra ID zu verwalten: Dienstprinzipale oder verwaltete Identitäten für Azure-Ressourcen.

Von den beiden Methoden zum Verwalten des AKS-Zugriffs auf Azure empfehlen wir verwaltete Identitäten. Bei Dienstprinzipalen müssen Sie Geheimnisse entweder manuell oder programmgesteuert verwalten und rotieren. Mit verwalteten Identitäten verwaltet Microsoft Entra ID die Authentifizierung und die rechtzeitige Rotation der Geheimnisse für Sie.

Es wird empfohlen, managed-Identitäten in AKS zu aktivieren und zu verwenden, damit der Cluster über Microsoft Entra ID mit externen Azure Ressourcen interagieren kann. Wenn Sie Microsoft Entra ID Integration nicht sofort verwenden, können Sie sie später hinzufügen.

Standardmäßig verwendet der Cluster zwei primäre Identitäten: die Clusteridentität und die Kubelet-Identität. Die AKS-Steuerungsebenenkomponenten verwenden die Clusteridentität zum Verwalten von Clusterressourcen , einschließlich Eingangslastenausgleichsmodulen und von AKS verwalteten öffentlichen IP-Adressen. Die Kubelet-Identität authentifiziert sich bei der Containerregistrierung. Einige Add-Ons unterstützen auch die Authentifizierung mithilfe einer verwalteten Identität.

Sie sollten verwaltete Identitäten verwenden, wenn der Cluster Images aus einer Containerregistrierung pullen muss. Für diesen Vorgang muss der Cluster die Anmeldeinformationen für die Registrierung abrufen. Dies erreichen Sie, indem Sie der vom Kubelet verwalteten Identität des Clusters AcrPull-Zugriff auf Ihre Registrierung gewähren. Wenn Sie keine verwaltete Identität verwenden, speichern Sie diese Informationen möglicherweise in einem Kubernetes-Geheimnis und verwenden imagePullSecrets sie zum Abrufen. Wir empfehlen diesen Ansatz nicht, da es Sicherheitskomplexe einführt, einschließlich der Notwendigkeit, den geheimen Schlüssel im Voraus zu kennen und in der DevOps-Pipeline zu speichern. Zudem entsteht dadurch ein operativer Mehraufwand, da Sie das Secret regelmäßig aktualisieren müssen.

In dieser Architektur greift der Cluster auf Azure-Ressourcen zu, die von Microsoft Entra ID gesichert werden, und führt Vorgänge aus, die verwaltete Identitäten unterstützen. Weisen Sie Azure rollenbasierte Zugriffssteuerung (Azure RBAC) und Berechtigungen den verwalteten Identitäten des Clusters zu, abhängig von den Vorgängen, die der Cluster ausführt. Der Cluster authentifiziert sich bei Microsoft Entra ID und erhält dann basierend auf seinen zugewiesenen Rollen entweder Zugriff oder wird abgelehnt. Hier sind einige Beispiele aus dieser Referenzimplementierung, in denen Azure-integrierte Rollen dem Cluster zugewiesen werden:

• Die Rolle „Network Contributor“ verwaltet die Fähigkeit des Clusters, das virtuelle Spoke-Netzwerk zu steuern. Mit dieser Rollenzuweisung kann die dem AKS-Cluster systemseitig zugewiesene Identität mit dem dedizierten Subnetz für den internen Load Balancer verwendet werden, der dem Gatewayproxy und dem privaten AKS-API-Server vorgeschaltet ist.

• Die Rolle Privates DNS Zone Contributor verwaltet die Fähigkeit des Clusters, die Zone direkt mit dem virtuellen Speichennetzwerk zu verknüpfen, in dem der Cluster gehostet wird. Ein privater Cluster hält DNS-Einträge vom öffentlichen Internet fern, indem er eine private DNS-Zone verwendet. Es ist jedoch weiterhin möglich, einen privaten AKS-Cluster mit einer öffentlichen DNS-Adresse zu erstellen. Es wird empfohlen, dieses Feature explizit zu verbieten, indem Sie enablePrivateClusterPublicFQDN auf false festlegen, um die Offenlegung der privaten IP-Adresse Ihrer Steuerebene zu verhindern. Erwägen Sie die Verwendung von Azure Policy, um die Verwendung privater Cluster ohne öffentliche DNS-Einträge zu erzwingen.

• Die Monitoring Metrics Publisher-Rolle verwaltet die Übertragungsfähigkeit des Clusters von Metriken an Azure Monitor.

• Die Rolle AcrPull verwaltet die Fähigkeit des Clusters, Bilder aus den angegebenen Containerregistrierungsinstanzen abzurufen.

Zwei AKS-Add-Ons stellen zusätzliche verwaltete Identitäten bereit, die Rollenzuweisungen erfordern. Die Identität des Add-ons „Secrets Store CSI Driver“ ruft TLS-Zertifikate aus Key Vault ab. Die Identität des Add-Ons für Anwendungsrouting verwaltet DNS-Einträge und den Gateway-Abgleich.

Gewähren Sie diesen Identitäten Zugriff auf die Ressourcen, mit der sie interagieren:

• Die verwaltete Identität des Secrets Store CSI Driver-Add-Ons benötigt auf Ihrem Key Vault die Rolle Key Vault Certificate User, damit der Treiber TLS-Zertifikate abrufen kann.

• Die verwaltete Identität des Add-Ons für Anwendungsrouting benötigt für Ihren Key Vault die Rollen Key Vault Secrets User und Key Vault Reader sowie für die private DNS-Zone des Ingress die Rolle Privates DNS Zone Contributor, damit der Controller DNS-Einträge verwalten kann, wenn er Gateway-Ressourcen abgleicht.

Note

Alternativ können Sie die verwaltete Identität des CSI-Treiber-Add-ons für den Zugriff auf Key Vault durch Microsoft Entra Workload Identity ersetzen. Mithilfe der Workload-Identität binden Sie eine vom Benutzer zugewiesene verwaltete Identität mithilfe von Verbundanmeldeinformationen an ein Kubernetes ServiceAccount, und verweisen sie in den TLS-Optionen des Gatewaylisteners darauf. Das Anwendungsrouting-Add-On erstellt dann automatisch die SecretProviderClass.

Üblicherweise wählen Sie entweder die verwaltete Identität des Add-Ons oder die Workload-Identität für den Key-Vault-Zugriff über den CSI-Treiber aus. Workload Identity bietet namespaceweite Identitätsisolation und reduziert die manuelle Ressourcenverwaltung zu kosten einer zusätzlichen Identitätshärtung durch Verbundanmeldeinformationen. Weitere Informationen finden Sie unter Konfigurieren von Azure DNS und TLS mit der Gateway-API-Implementierung für Anwendungsrouting.

Clusterzugriff

Microsoft Entra Einbindung vereinfacht auch die Sicherheit für externen Zugriff. Beispielsweise möchten Sie möglicherweise kubectl verwenden. Als Erstes können Sie den Befehl az aks get-credentials ausführen, um die Anmeldeinformationen des Clusters abzurufen. Microsoft Entra ID authentifiziert Ihre Identität gegenüber den Azure-Rollen, die berechtigt sind, Clusteranmeldeinformationen abzurufen. Weitere Informationen finden Sie unter Verfügbare Clusterrollen-Berechtigungen.

AKS unterstützt den Kubernetes-Zugriff über Microsoft Entra ID, indem Microsoft Entra ID als Identitätsanbieter verwendet werden, der mit systemeigenem Kubernetes RBAC integriert ist, oder indem systemeigene Azure RBAC zum Steuern des Clusterzugriffs verwendet wird. In den folgenden Abschnitten werden beide Ansätze beschrieben.

Zuordnen von Kubernetes RBAC zu Microsoft Entra ID

Kubernetes unterstützt RBAC über die folgenden API-Objekte:

• Eine Gruppe von Berechtigungen, die Sie mithilfe eines Role- oder ClusterRole-Objekts für clusterweite Berechtigungen definieren.

• Bindungen, die Benutzern und Gruppen Berechtigungen zuweisen, Aktionen auszuführen. Definieren Sie Bindungen mithilfe eines RoleBinding- oder ClusterRoleBinding-Objekts.

Kubernetes verfügt über einige integrierte Rollen wie Clusteradministrator, Bearbeitung und Ansicht. Binden Sie diese Rollen an Microsoft Entra Benutzer und Gruppen, um das Unternehmensverzeichnis zum Verwalten des Zugriffs zu verwenden. Weitere Informationen finden Sie unter Use Kubernetes RBAC with Microsoft Entra integration.

Achten Sie darauf, dass Sie die Microsoft Entra-Gruppen für den Cluster- und Namespacezugriff in Ihre Microsoft Entra Zugriffsüberprüfungen einschließen.

Verwenden Azure RBAC für Kubernetes-Autorisierung

Es wird empfohlen, Azure RBAC und Azure Rollenzuweisungen zu verwenden, um Autorisierungsprüfungen für den Cluster zu erzwingen. Dieser Autorisierungsansatz ist in Microsoft Entra Authentifizierung integriert. Sie können Rollen in verschiedenen Bereichen zuweisen, z. B. der Verwaltungsgruppe, des Abonnements oder der Ressourcengruppe. Alle Cluster im definierten Bereich erben dann einen konsistenten Satz von Rollenzuweisungen im Hinblick auf die Berechtigungen zum Zugriff auf die Objekte im Kubernetes-Cluster.

Es wird nicht empfohlen, Kubernetes-native RBAC mit ClusterRoleBindings und RoleBindings zu verwenden.

Weitere Informationen finden Sie unter Azure RBAC für Kubernetes-Autorisierung.

Lokale Konten

AKS unterstützt die native Kubernetes Benutzer-Authentifizierung. Wir empfehlen nicht, diese Methode zum Bereitstellen von Benutzerzugriff für Cluster zu verwenden. Diese Methode ist zertifikatbasiert und wird außerhalb Ihres primären Identitätsanbieters ausgeführt, wodurch die zentrale Benutzerzugangskontrolle und Governance erschwert wird. Verwalten Sie immer den Zugriff auf Ihren Cluster mithilfe von Microsoft Entra ID, und konfigurieren Sie Ihren Cluster so, dass der Zugriff auf lokale Konten explizit untersagt wird.

In dieser Referenzimplementierung ist der Zugriff auf lokale Clusterkonten explizit verboten, wenn das System den Cluster bereitstellt.

Integrieren Sie Microsoft Entra ID für die Arbeitslast.

Ähnlich wie bei einer Azure vom System zugewiesenen verwalteten Identität für den gesamten Cluster können Sie verwaltete Identitäten auf Podebene zuweisen. Mithilfe einer Workloadidentität kann eine gehostete Workload über Microsoft Entra ID auf Ressourcen zugreifen. Angenommen, die Arbeitsauslastung speichert Dateien in Azure Storage. Wenn auf diese Dateien zugegriffen werden muss, authentifiziert sich der Pod bei der Ressource als verwaltete Azure-Identität.

In dieser Referenzimplementierung stellt Microsoft Entra Workload ID auf AKS die verwalteten Identitäten für Pods bereit. Dieser Ansatz lässt sich in die kubernetes-nativen Funktionen integrieren, um eine Verbindung mit externen Identitätsanbietern zu erstellen. Weitere Informationen finden Sie unter Workload Identity Federation.

Auswählen eines Netzwerkmodells

AKS stellt Plug-Ins (Container Networking Interface, CNI) in zwei Netzwerkmodellen bereit: Overlay und flach. Beide Modelle unterstützen Netzwerkrichtlinien für die In-Cluster-Datenverkehrskontrolle.

Mit einem Flachnetzwerk-Plug-In, z. B. Azure CNI Pod Subnet, erhält jeder Pod eine IP-Adresse aus dem virtuellen Netzwerk-Subnetz. Ressourcen im selben Netzwerk oder gepeerten Netzwerken können direkt über ihre IP-Adresse ohne NAT (Network Address Translation) auf Pods zugreifen. Verwenden Sie ein flaches Netzwerkmodell, wenn Ihre Workloads direkte Erreichbarkeit der Pods aus dem virtuellen Netzwerk erfordern.

Diese Referenzimplementierung verwendet Azure CNI Overlay, bei dem es sich um ein Overlay-Netzwerk-Plug-In handelt. Es weist virtuelle Netzwerk-IP-Adressen nur Knoten zu und weist Pod-IPs aus einem separaten CIDR-Bereich zu. Da Azure CNI Overlay weit weniger IP-Adressen für virtuelle Netzwerke als flache Modelle verbraucht, empfehlen wir dies für die meisten Bereitstellungen.

Weitere Informationen zu den Modellen finden Sie unter AKS CNI-Netzwerkübersicht und bewährte Methoden für Netzwerkkonnektivität und Sicherheit in AKS.

Weiterleitung von Bewerbungen

Diese Architektur verwendet das Anwendungsrouting-Add-On mit der Kubernetes-Gateway-API. Das Anwendungsrouting-Add-On ist eine AKS-Clusterkonfiguration, die deklariert, dass der Cluster eine verwaltete Gatewayinfrastruktur enthalten soll. Die Gateway-API ist eine Reihe von benutzerdefinierten Kubernetes-Ressourcendefinitionen (CRDs), einschließlich GatewayClass, , Gateway, HTTPRouteund anderen. Die Kubernetes-Community hat die Gateway-API als Nachfolger der vorherigen Ingress-API entworfen. Sie bietet einen standardisierten, rollenorientierten und erweiterbaren Rahmen für das Verkehrsmanagement.

Die Komponenten werden in verschiedenen Lebenszyklusphasen bereitgestellt:

• Cluster-Design. Das Anwendungsteam entscheidet, welcher Gatewaycontroller den Eingehenden Datenverkehr verwaltet und wie der Lebenszyklus dieses Controllers verwaltet wird. Gateway-Controller bündeln in der Regel ihre Data-Plane-Proxys, sodass diese Entscheidung auch bestimmt, welcher Proxy den Verkehrspfad verarbeitet. Diese Architektur ermöglicht verwaltete Gateway-API-CRDs. Es konfiguriert das Add-On für die Verwendung von verwaltetem Istio als Gatewaycontroller, der mit Envoy als Gatewayproxy gekoppelt ist. Obwohl Sie Istio auch als Dienstgitter verwenden können, wird In dieser Architektur Istio nur als Gatewaycontroller verwendet und seine Dienstgitterfunktionen sind nicht aktiviert.

  Wenn das Team eine andere Implementierung erfordert, können sie andere Gateway-API-Controller verwenden, z. B. NGINX-Gateway-Fabric, Envoy-Gateway und Traefik. Diese Controller können eigenständig verwaltet werden, was die Pflege eigener Manifeste, Antiaffinität, Knotenplatzierung, Probes, die Festlegung des RBAC-Geltungsbereichs, Skalierungsrichtlinien, Quell-IP-Einschränkungen und die Verwaltung des Versionslebenszyklus erfordert. Im Gegenzug erhalten Sie die volle Kontrolle über das Proxy-Verhalten, die von Cluster-Upgrades unabhängige Versionsfixierung und eine uneingeschränkte Konfiguration.

• Clusterbereitstellung. In dieser Phase treten keine Entwurfsentscheidungen auf. AKS installiert die Gateway-API-CRDs, Istio-(Gateway-Controller)-Pods im Namespace aks-istio-system und die GatewayClass approuting-istio. Zu diesem Zeitpunkt gibt es keine Data-Plane-Pods für den Gateway-Proxy.

• Initialisierung des Clusters. Das Workloadteam definiert, wie der Gatewayproxy verfügbar gemacht wird (interner oder externer Lastenausgleich), welches Subnetz die Front-End-IP des Lastenausgleichs hostet und in welchem Namespace der Gatewayproxy ausgeführt wird. In dieser Architektur wird der Gateway-Proxy über einen internen Load Balancer exponiert, es gibt ein dediziertes Subnetz für IP-Adressen des Load Balancers, und der Gateway-Proxy wird im a0008Workload-Namespace bereitgestellt.

  Eine Gatewayressource, die auf die approuting-istio GatewayClass verweist, drückt diese Entscheidungen aus. Der Gateway-Controller setzt sie in Envoy-Deployments (Gateway-Proxy), einen LoadBalancer Service, einen HorizontalPodAutoscaler und einen PodDisruptionBudget in demselben Namespace wie die Gateway-Ressource um.

  Wenn eine private DNS-Zone an das Add-On angefügt ist, kann die DNS-Komponente des Add-Ons DNS-A-Einträge für Sie verwalten, wodurch die Notwendigkeit entfernt wird, statische Einträge in Ihren IaC-Vorlagen zu verwalten. Bootstrapping stellt auch die TLS-Zertifikatsynchronisierungsressourcen bereit, die in Access-Clusterschlüsseln beschrieben sind.

Note

Die integrierte DNS-Komponente, die zusammen mit dem Add-on bereitgestellt wird, gleicht DNS-Einträge nicht automatisch ab, wenn Sie Gateway-API-Ressourcen verwenden.

Um die automatische Abstimmung privater DNS-Einträge zu aktivieren, stellen Sie eine benutzerdefinierte ClusterExternalDNS- oder ExternalDNS-Ressource bereit. Die Anwendungsroutingoperatorkomponente stellt dann eine verwaltete externe DNS-Instanz bereit, die Gateway- und HTTPRoute-Ressourcen überwacht und A-Einträge in der angefügten DNS-Zone veröffentlicht. Da das Schreiben in die DNS-Zone RBAC-Berechtigungen erfordert, erfordert diese Integration Microsoft Entra Workload Identity: eine vom Benutzer zugewiesene verwaltete Identität mit DNS-Zonenmitwirkenden in der Zielzone, Verbundidentitätsanmeldeinformationen, die dem OIDC-Aussteller des Clusters vertrauen, und einem dedizierten Kubernetes ServiceAccount. Bewerten Sie die zusätzliche Identitätsinfrastruktur anhand Ihrer Sicherheits- und Betriebsanforderungen.

• Bereitstellung von Workloads. Das Anwendungsteam definiert, welche Hostnamen, Pfade und Back-Ends Datenverkehr empfangen. HTTPRoute-Ressourcen, die an das Gateway gebunden sind, geben diese Routingentscheidungen an. Der Gateway-Controller überträgt das deklarierte Routingverhalten an die Envoy-Pods.
• Fortlaufende Wartung: Das Add-On verknüpft die Version des Istio-Gatewaycontrollers mit Ihrer AKS-Clusterversion, sodass Upgrades zusammen mit Clusterupgrades erfolgen, anstatt eine unabhängige Lebenszyklusverwaltung zu erfordern. Dieses Add-On verwendet Istio ausschließlich für die Gatewayproxyverwaltung. Es aktiviert weder die Sidecar-Injektion noch das vollständige Istio-Service-Mesh, das ein separates Add-on ist.

Note

Wählen Sie die Self-Management-Option aus, wenn Ihre Workload Funktionen erfordert, die das Add-On noch nicht unterstützt, z. B. TLSRoute für SNI-Passthrough, erweiterte Datenverkehrstransformationen über benutzerdefinierte Lua- oder Wasm-Plug-Ins oder wenn compliance ein bestimmtes Proxyprodukt vorgeschrieben. Wählen Sie auch die Option zur Selbstverwaltung, wenn Sie den Proxy unabhängig von Cluster-Upgrades versionieren müssen oder wenn Ihr Cluster bereits das Istio-Service-Mesh-Add-on verwendet, da beide nicht parallel betrieben werden können.

Anwenden von Gateway- und HTTPRoute-Ressourcen

Diese Architektur verwendet das Add-on für Anwendungsrouting mit der Kubernetes-Gateway-API zur Verwaltung des eingehenden Datenverkehrs. In diesem Abschnitt werden die zuvor beschriebenen Phasen des Cluster-Bootstrappings und der Workload-Bereitstellung behandelt. Zu diesem Zeitpunkt läuft der Gateway-Controller bereits und wartet darauf, Gateway-API-Ressourcen abzugleichen.

Die Gateway-API ist ein anbieterneutraler Standard, der TLS-Richtlinie, headerbasiertes Routing und Die Datenverkehrsteilung als systemeigene API-Felder und keine implementierungsspezifischen Anmerkungen zum Ausdruck bringt. Da Ihre Routingkonfiguration nicht von einer bestimmten Proxytechnologie abhängt, können Sie die zugrunde liegende Implementierung später ändern, ohne sie neu zu schreiben. Das Add-On für Anwendungsrouting steuert den Gateway-Controller und den Lebenszyklus des Proxys, sodass Upgrades, Sicherheitspatches, Skalierungskonfigurationen und RBAC-Bereiche nicht mehr verwaltet werden müssen.

Die Gateway-API unterteilt Ingress in zwei Aspekte, die sich unabhängig voneinander ändern:

• Die Gatewayressource deklariert die Netzwerkoberfläche: welche Ports und Protokolle verfügbar gemacht werden sollen, TLS-Zertifikate und das Subnetz für den internen Lastenausgleich. Diese Ressource ändert sich selten und wirkt sich auf alle daran angefügten Routen aus.

• Die HTTPRoute-Ressource deklariert Routinglogik: welche Hosts, Pfade und Header welchen Back-End-Diensten zugeordnet sind. Diese Ressource ändert sich bei jeder Bereitstellung und gilt für einzelne Dienste.

Diese Architektur reduziert das Risiko, dass eine Routingänderung die Netzwerkkonfiguration stört oder umgekehrt, da jede Ressource einen anderen Änderungsrhythmus und Strahlradius aufweist. Außerdem werden mehrere Abhängigkeiten entfernt: Ihre Routingkonfiguration ist nicht an eine bestimmte Proxytechnologie gebunden, die Proxyversion wird mit Ihrer AKS-Clusterversion verschoben, anstatt eine unabhängige Nachverfolgung zu erfordern, und jedes Gateway erhält eine eigene Proxybereitstellung, anstatt einen einzelnen Controller über alle Routen hinweg frei zu nutzen.

Wie zuvor in den Lebenszyklusphasen beschrieben, überführt der Gateway-Controller beim Anwenden einer Gateway-Ressource, die auf die konfigurierte GatewayClass verweist, diese in Deployment-Ressourcen für Gateway-Proxys und unterstützende Ressourcen. Sie steuern die Platzierung von Subnetzen mithilfe von Infrastruktur-Annotationen auf der Gateway-Ressource.

Dieses deklarative Modell entfernt die Notwendigkeit, Helmdiagramme, Containerimages oder Bereitstellungsmanifeste für den Proxy zu verwalten. Sie haben die Absicht über die Gateway-API-Ressourcenkonfiguration ausgedrückt, und der Gatewaycontroller konvergiert den Proxy in Richtung des gewünschten Zustands.

In der Regel stellt ein verwalteter Gateway-Controller den Gateway-Proxy mit produktionsorientierten Standardwerten bereit: Readiness- und Liveness-Prüfungen, RBAC-Berechtigungen, die Skalierung der Replikate (mindestens zwei Replikate, CPU-basierte automatische Skalierung bis auf fünf) sowie ein PodDisruptionBudget, das bei freiwilligen Unterbrechungen sicherstellt, dass mindestens ein Pod verfügbar bleibt.

Grundlegendes zur Add-On-Planungstopologie

AKS-Add-Ons platzieren verwaltete Komponenten auf Knotenpools basierend auf Planungsentscheidungen, die das Anwendungsteam nicht steuert. Bevor Sie die Größe von System- und Benutzerknotenpools anpassen, ermitteln Sie, wo jedes aktivierte Add-On seine Pods plant. Einige Add-Ons tolerieren Systemknotenpool-Taints und werden daher nur auf dem Systempool ausgeführt. Andere zielen auf Benutzerpools ab. Diese Topologie wirkt sich direkt auf die erforderliche Kapazität in jedem Pool aus.

Der verwaltete Envoy-Gateway-Proxy wird systembedingt auf dem Systemknotenpool und nicht auf dem Benutzerknotenpool ausgeführt. Dimensionieren Sie den Systempool unter Berücksichtigung des zusätzlichen Ressourcenbedarfs des Proxys. Wenn diese Standardtopologie die Anforderungen Ihrer Organisation nicht erfüllt, z. B. wenn Sie den Proxy für Benutzerpools aus Kostenisolierung, Netzwerksegmentierung oder Compliance benötigen, wechseln Sie zu einem selbstverwalteten Gatewaycontroller, bei dem Sie eigene Knotenplatzierungsentscheidungen treffen.

Auch mit einem verwalteten Gateway-Controller kann das Anwendungsteam die Pod-Antiaffinität so konfigurieren, dass Proxy-Replikate auf die Knoten verteilt werden. Sie konfigurieren diese Einstellungen über Anpassungseinstellungen für auf die Zulassungsliste gesetzte Gateways. Weitere Informationen finden Sie unter Gatewayressourcenanpassung.

Da der Gatewayproxy im Systemknotenpool ausgeführt wird und die Workload im Benutzerknotenpool ausgeführt wird, behandelt der Planer sie als unabhängige Planungsdomänen. Der Gateway-Proxy und die Workload sind Dienste, die häufig miteinander kommunizieren, da jede eingehende Anfrage durch den Proxy fließt, bevor sie die Workload erreicht. Kein integrierter Mechanismus korreliert die Zonenplatzierung zwischen Pods in verschiedenen Knotenpools. Ohne ausdrückliche Vorgaben kann der Scheduler Workload-Pods in Zonen platzieren, in denen kein Proxy-Replikat vorhanden ist, sodass der Datenverkehr die Grenze einer Verfügbarkeitszone überqueren muss, was die Latenz erhöht und Kosten für zonenübergreifende Datenübertragungen verursacht. Um diesen zonenübergreifenden Datenverkehr zu reduzieren, konfigurieren Sie für Ihre Workload bevorzugte Pod-Affinität, damit sie in derselben Zone wie die Proxy-Replikate platziert wird. Diese gemeinsame Platzierung ist die engste erreichbare, wenn der Proxy und die Workload in separaten Knotenpools ausgeführt werden, da Knotenaffinität poolübergreifend keine Wirkung hat. Beachten Sie, dass die Inter-Pod-Affinität dem Planer zusätzlichen Verarbeitungsaufwand verursacht und den Planungsprozess in großen Clustern möglicherweise verlangsamt.

Berücksichtigen Sie zusätzliche Ressourcenanforderungen in Governance-Richtlinien

AKS-Add-Ons stellen verwaltete Komponenten bereit, deren Ressourcenanforderungen von AKS definiert und gesteuert werden, nicht vom Anwendungsteam. Wenn der Cluster Containerressourcengrenzrichtlinien im Verweigerungsmodus über Azure Policy und OPA Gatekeeper erzwingt, müssen diese Richtlinien alle aktivierten Add-Ons berücksichtigen. Wenn dies nicht der Fall ist, blockiert Gatekeeper stillschweigend die Erstellung der verwalteten Pods, wodurch Plattformfunktionen wie Ingress, Secrets-Synchronisierung oder Observability beeinträchtigt werden, ohne dass ein offensichtlicher Bereitstellungsfehler angezeigt wird.

Betrachten Sie die Ressourcenprofilierung für Erweiterungen als Voraussetzung für die Erstellung von Richtlinien. Bevor Sie Container-CPU-, Arbeitsspeicher-, Volumetyp- oder Sicherheitskontexteinschränkungen definieren, inventarisieren Sie jedes aktivierte Add-On und bestimmen die Anforderungen an die Laufzeitressourcen. Verwenden Sie Lasttests oder kontrollierte Bereitstellungen in einer Vorproduktionsumgebung, um den tatsächlichen Ressourcenverbrauch unter realistischen Verkehrsbedingungen zu erfassen. Legen Sie dann Ihre Richtlinienlimits so fest, dass sowohl die Add-On-Komponenten als auch Ihre Workload-Container berücksichtigt werden. Dieser Ansatz stellt sicher, dass Ihre Governance-Guardrails den Cluster schützen, ohne die plattformverwaltete Infrastruktur zu beeinträchtigen.

Der verwaltete Envoy-Gatewayproxy erfordert beispielsweise bis zu 2 CPU-Kerne und 1 GiB Arbeitsspeicher pro Replikat. Diese Werte sind wahrscheinlich viel größer als die Anforderungen einer kleinen oder geringen Ressourcenauslastung. Legen Sie die Grenzwerte in Ihren Richtlinien so fest, dass der Gateway-Proxy zusammen mit Ihren Anwendungscontainern berücksichtigt wird. Ohne diese Anpassung werden die Gateway-Proxy-Pods von Gatekeeper abgewiesen, und die gesamte Ingress-Pipeline wird nicht erstellt.

Clusterinterne Gateway-TLS-Terminierung und HTTPS-Durchsetzung

Diese Architektur konfiguriert das Gateway mit HTTPS auf Port 443 mithilfe eines von Key Vault synchronisierten TLS-Zertifikats und einen HTTP-Listener am Port 80 für die Umleitung. Infrastrukturanmerkungen auf dem Gateway platzieren das Lastenausgleichsmodul im Eingangssubnetz und machen es intern. Eine an den HTTP-Listener gebundene HTTPRoute zur Umleitung gibt 301 Moved Permanently zurück, um alle HTTP-Anfragen auf HTTPS umzuleiten. Die HttpRoute-Anwendung bindet an den HTTPS-Listener und leitet Datenverkehr an den Workloaddienst über HTTP weiter. Da der Gatewayproxy TLS-Beendigung ausführt, ist die Kommunikation mit den Back-End-Diensten unverschlüsselt.

Schützen des Datenflusses im Netzwerk

In dieser Architektur enthält der Netzwerkfluss die folgenden Arten von Datenverkehr:

• Eingehender Datenverkehr vom Client zur Workload, die im Cluster ausgeführt wird.

• Ausgehender Datenverkehr von einem Pod oder Knoten im Cluster zu einem externen Dienst.

• Pod-zu-Pod-Datenverkehr zwischen Pods. Dieser Datenverkehr umfasst die Kommunikation zwischen dem Gatewayproxy und der Workload. Wenn Ihre Workload mehrere Anwendungen umfasst, die im Cluster bereitgestellt wurden, würde auch die Kommunikation zwischen diesen Anwendungen in diese Kategorie fallen.

• Verwaltungsdatenverkehr zwischen dem Client und dem Kubernetes-API-Server.

Das Diagramm veranschaulicht drei unterschiedliche Datenverkehrsmuster innerhalb der Architektur. Das Hubnetzwerk verfügt über Azure Firewall, Azure Bastion, ein Gateway und Azure Monitor. Das Speichennetz verfügt über den AKS-Cluster mit Application Gateway am Eingang. Grüne Pfeile zeigen eingehenden Datenverkehr vom Internet durch Application Gateway, den internen Load Balancer und den Gateway-Proxy bis zu den Workload-Pods. Orangefarbene Pfeile zeigen den Pod-zu-Pod-Datenverkehr innerhalb des Clusters an. Rote Pfeile zeigen ausgehenden Datenverkehr vom Cluster zu Azure Firewall. Pfeile von privaten Endpunkten weisen auf Container Registry und Key Vault.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Architektur verfügt über mehrere Sicherheitsebenen, um alle Arten von Datenverkehr zu schützen.

Eingehender Datenverkehrsfluss

Die Architektur akzeptiert nur mit TLS verschlüsselte Anforderungen vom Client. TLS v1.2 ist die minimal zulässige Version, die einen eingeschränkten Satz von Verschlüsselungsverfahren umfasst. Die strikte Übereinstimmung der Servernamensanzeige (Server Name Indication, SNI) ist aktiviert. End-to-End-TLS wird über Application Gateway mithilfe von zwei verschiedenen TLS-Zertifikaten eingerichtet, wie im folgenden Diagramm dargestellt.

Das Diagramm zeigt einen End-to-End-TLS-Datenverkehrsfluss von Client zu Workload. Ein Client sendet HTTPS-Datenverkehr an Application Gateway. Ein Pfeil von Key Vault zum Anwendungsgateway zeigt den Zertifikatabruf an. Application Gateway beendet TLS und verschlüsselt dann den Datenverkehr (HTTPS) erneut an den internen Load Balancer. Ein weiterer Pfeil von Key Vault zum Gateway-Proxy zeigt den Zertifikatabruf über den Secrets Store CSI-Treiber. Der interne Lastenausgleich leitet verschlüsselten Datenverkehr an den Gatewayproxy weiter, der TLS beendet. Ein letzter Pfeil zeigt HTTP-Datenverkehr vom Gateway-Proxy zu den Workload-Pods an. Jeder TLS-Endpunkt ist markiert.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Der Client sendet eine HTTPS-Anforderung an den Domänennamen: bicycle.contoso.com. Dieser Name ist einem DNS-A-Eintrag mit der öffentlichen IP-Adresse von Application Gateway zugeordnet. Dieser Datenverkehr wird verschlüsselt, um sicherzustellen, dass er zwischen dem Clientbrowser und dem Gateway nicht überprüft oder geändert werden kann.

2. Application Gateway verfügt über eine integrierte Web Application Firewall und verhandelt den TLS-Handshake für bicycle.contoso.com, sodass nur sichere Chiffren zulässig sind. Application Gateway ist ein TLS-Terminierungspunkt, was wichtig ist, da die Webanwendungs-Firewall des Application Gateways die Klartextanforderungen und -antworten prüfen muss. Key Vault speichert das TLS-Zertifikat. Der Cluster greift auf ihn mit einer vom Benutzer zugewiesenen verwalteten Identität zu, die in Application Gateway integriert wird. Weitere Informationen finden Sie unter TLS-Beendigung mit Key Vault Zertifikaten.

   Application Gateway verarbeitet Webanwendungs-Firewall-Prüfregeln und führt Routingregeln aus, die den Datenverkehr an das konfigurierte Back-End weiterleiten.

3. Wenn der Datenverkehr von Application Gateway zum Back-End wechselt, wird er erneut mit einem anderen TLS-Zertifikat verschlüsselt, bei dem es sich um einen Wildcard für *.aks-ingress.contoso.com handelt, da er an die interne load balancer weiterleitet. Durch diese erneute Verschlüsselung wird sichergestellt, dass kein ungesicherter Datenverkehr in das Clustersubnetz gelangt.

4. Der Gateway-Proxy empfängt den verschlüsselten Datenverkehr über den Load-Balancer. Der Proxy ist ein weiterer TLS-Terminierungspunkt für *.aks-ingress.contoso.com und leitet den Datenverkehr über HTTP an die Workload-Pods weiter. Das TLS-Zertifikat wird in Key Vault gespeichert und im Cluster als Kubernetes Secret synchronisiert, auf den die Gatewayressource verweist. Weitere Informationen finden Sie unter Hinzufügen einer Geheimnisverwaltung.

Sie können End-to-End-TLS-Verkehr an jedem Schritt durch den Workload-Pod implementieren. Messen Sie unbedingt die Leistung, die Latenz und eventuelle betriebliche Auswirkungen, wenn Sie sich entscheiden, den Datenverkehr zwischen Pods zu schützen. Für die meisten Single-Tenant-Cluster ist es bei korrekt konfigurierter RBAC für die Control Plane und ausgereiften Praktiken im Softwareentwicklungslebenszyklus ausreichend, den Datenverkehr bis zum Gateway-Proxy per TLS zu verschlüsseln und mit einer Web Application Firewall abzusichern. Dieser Ansatz minimiert den Aufwand bei der Workloadverwaltung und den Aufwand aufgrund einer schlechten Netzwerkleistung. Ihre Workload- und Complianceanforderungen legen fest, wo Sie TLS-Beendigung ausführen.

Ausgehender Datenverkehrsfluss

In dieser Architektur wird empfohlen, dass der gesamte ausgehende Datenverkehr aus dem Cluster über die Azure Firewall geleitet wird. Sie können auch Ihre eigene ähnliche virtuelle Netzwerk-Appliance verwenden. Es wird nicht empfohlen, andere Ausgangsoptionen wie Azure NAT Gateway oder einen HTTP-Proxy zu verwenden, da sie keine Netzwerkdatenverkehrsprüfung bereitstellen. Für eine Zero-Trust-Kontrolle und die Möglichkeit, den Datenverkehr zu überprüfen, leiten Sie den gesamten ausgehenden Datenverkehr über die Azure Firewall weiter. Implementieren Sie diese Konfiguration mit benutzerdefinierten Routen (UDRs). Der nächste Hop der Route ist die Private-IP-Adresse von Azure Firewall. Azure Firewall entscheidet, ob der Ausgehende Datenverkehr basierend auf den von Ihnen definierten Regeln oder den integrierten Regeln zur Bedrohungserkennung blockiert oder zugelassen werden soll.

Eine Alternative zu Azure Firewall ist das Verwenden der AKS HTTP-Proxy-Funktion. Der gesamte Datenverkehr, der den Cluster verlässt, wird an die IP-Adresse des HTTP-Proxys gesendet, der den Datenverkehr weiterleitet oder verwirft.

Überprüfen Sie bei beiden Methoden die erforderlichen Netzwerkregeln für ausgehenden Datenverkehr für AKS.

Note

Wenn Sie einen öffentlichen Load Balancer als öffentlichen Punkt für den eingehenden und ausgehenden Datenverkehr durch die Azure Firewall mithilfe von UDRs verwenden, könnte ein asymmetrisches Routingszenario auftreten. Diese Architektur verwendet interne Load Balancer in einem dedizierten Ingress-Subnetz hinter dem Application Gateway. Diese Designauswahl verbessert die Sicherheit und beseitigt auch asymmetrische Routingprobleme. Oder Sie können den Datenverkehr vor oder nach Application Gateway durch die Firewall weiterleiten, aber dieser Ansatz ist für die meisten Situationen nicht erforderlich, und es wird nicht empfohlen. Weitere Informationen zum asymmetrischen Routing finden Sie unter Integrate Firewall mit einem Azure Standardlastenausgleich.

Eine Ausnahme des Zero Trust-Steuerelements besteht darin, dass der Cluster mit anderen Azure Ressourcen kommunizieren muss. Beispielsweise muss der Cluster ein aktualisiertes Image aus der Containerregistrierung oder geheimen Schlüssel aus Key Vault abrufen. In diesen Szenarien wird empfohlen, Private Link zu verwenden.

Der Vorteil der Verwendung von Private Link besteht darin, dass bestimmte Subnetze den Dienst direkt erreichen und der Datenverkehr zwischen dem Cluster und den Diensten nicht über das Internet geht. Ein Nachteil ist, dass Private Link zusätzliche Konfiguration benötigt, anstatt den Zieldienst über seinen öffentlichen Endpunkt zu verwenden. Außerdem unterstützen nicht alle Azure Dienste oder Produkte Private Link. In diesen Fällen empfiehlt es sich, einen virtuellen Netzwerkdienstendpunkt im Subnetz zu aktivieren, um auf den Dienst zuzugreifen.

Verwenden Sie für die Containerregistrierung speziell dedizierte Datenendpunkte. Ohne sie werden Downloads von Image-Layern an einen *.blob.core.windows.net-Endpunkt statt an den privaten Endpunkt der Registry umgeleitet, und Ihre Egress-Firewallregeln würden eine gefährliche Blob-Speicher-Wildcard zulassen müssen. Diese Regel würde den ausgehenden Datenverkehr von Knoten zu beliebigen Azure Storage-Konten zulassen. Dedizierte Datenendpunkte ersetzen den Platzhalter durch registrierungsspezifische FQDNs (<registry>.<region>.data.azurecr.io), die über Private Link zu Ihrem privaten Endpunkt aufgelöst werden. Dadurch bleibt der Datenverkehr auf Image-Ebene auf dem privaten Pfad, und Sie können die Regeln für den ausgehenden Datenverkehr auf die Registrierung Ihres Clusters beschränken.

Wenn Private Link oder Dienstendpunkte keine Option sind, können Sie andere Dienste über ihre öffentlichen Endpunkte erreichen und den Zugriff über Azure Firewall Regeln und die in den Zieldienst integrierte Firewall steuern. Die Firewall wendet die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) auf ausgehende Datenströme an, ersetzt die Pod-IP durch eine ihrer angefügten öffentlichen IP-Adressen pro Datenstrom, und die Auswahl erfolgt nicht deterministisch. Fügen Sie den gesamten Satz von angefügten öffentlichen IPs zur IP-Zulassungsliste des Zieldiensts hinzu, oder verwenden Sie ein präfix für öffentliche IP-Adressen , um den Satz als zusammenhängenden Bereich auszudrücken.

Ein Nachteil der Verbindung mit Azure Diensten über öffentliche Endpunkte besteht darin, dass Azure Firewall dann mehr Regeln benötigt, um sicherzustellen, dass nur Datenverkehr von einem bestimmten Subnetz aus zulässig ist. Die Anzahl der angefügten öffentlichen IP-Adressen begrenzt auch den SNAT-Portpool und somit die gleichzeitige Ausgehende Verbindungsgrenze des Clusters. Planen Sie mehrere IP-Adressen auf der Azure Firewall ein, bevor die Port-Kapazität erschöpft ist. Bei Clustern, die eine große Anzahl gleichzeitiger ausgehender Verbindungen öffnen, fügen Sie ein Azure-NAT-Gateway an das AzureFirewallSubnet an, um den SNAT-Port-Pool erheblich zu erweitern und dabei den gesamten ausgehenden Datenverkehr unter der Firewall-Überprüfung zu halten.

Pod-zu-Pod-Datenverkehr

Standardmäßig kann ein Pod Datenverkehr von jedem anderen Pod im Cluster annehmen. Mit NetworkPolicy von Kubernetes wird der Netzwerkdatenverkehr zwischen Pods eingeschränkt. Wenden Sie Richtlinien sorgfältig an, oder Sie haben möglicherweise eine Situation, in der ein kritischer Netzwerkfluss blockiert wird. Nur bestimmte Kommunikationspfade nach Bedarf zulassen, wie den Datenverkehr zwischen dem Gateway-Proxy und der Workload. Da der Gateway-Proxy im selben Namespace wie die Workload ausgeführt wird, sprechen Sie ihn über das Pod-Label an und nicht über den Namespace-Selektor. Weitere Informationen finden Sie unter Network policies.

Aktivieren Sie die Netzwerkrichtlinie, wenn Sie den Cluster einrichten, da Sie ihn später nicht hinzufügen können. Es gibt einige Auswahlmöglichkeiten an Technologien, die NetworkPolicy implementieren. Wir empfehlen Azure Netzwerkrichtlinie, die Azure CNI erfordert. Zu den anderen Möglichkeiten gehört mit der Calico-Netzwerkrichtlinie eine bekannte Open-Source-Option. Verwenden Sie Calico, wenn Sie clusterweite Netzwerkrichtlinien verwalten müssen. Calico wird nicht unter standard-Azure-Support abgedeckt.

Weitere Informationen finden Sie unter Differences between Azure network policy engines.

Verwaltungsdatenverkehr

Im Rahmen der Ausführung des Clusters empfängt der Kubernetes-API-Server Anfragen von Komponenten, die Verwaltungsvorgänge im Cluster durchführen möchten, wie das Erstellen von Ressourcen zum Skalieren des Clusters. Beispiele für diese Ressourcen sind der Build-Agent-Pool in einer DevOps-Pipeline, eine Azure Bastion Instanz im Azure Bastion Subnetz und die Knotenpools selbst. Anstatt diesen Verwaltungsdatenverkehr von allen IP-Adressen zu akzeptieren, empfehlen wir, einen privaten AKS-Cluster einzurichten.

Weitere Informationen finden Sie unter Define API serverautorisierte IP-Bereiche.

Es wird empfohlen, Ihren AKS-Cluster als privaten Cluster bereitzustellen. Der gesamte Steuerebenen- und Knotenpooldatenverkehr verbleibt in Ihrem privaten Netzwerk und wird nicht für das öffentliche Internet verfügbar gemacht. Diese Referenzimplementierung richtet einen privaten Cluster mithilfe von API-Server virtual network Integration ein. In Testumgebungen kann aus Gründen der Benutzerfreundlichkeit eine Lockerung dieser Empfehlung für private Cluster in Betracht gezogen werden. Produktions-AKS-Cluster sollten jedoch stets als private Cluster bereitgestellt werden, um eine sichere Baseline für die Bereitstellung zu gewährleisten.

Privater Datenverkehr zu einem privaten AKS-Cluster kann aus dem Spoke-Virtual-Network, aus Peering-Netzwerken oder von privaten Endpunkten in entfernten Netzwerken stammen. Obwohl die AKS-Knoten natürlich im Speichen leben, benötigen Betreiber, die administrative Aufgaben ausführen, einen dedizierten Netzwerkpfad, um den AKS-API-Server privat zu erreichen. Sie können diese Konnektivität auf folgende Weise einrichten:

• Tunneling: Verwenden Sie Azure Bastion, um einen Tunnel direkt auf den API-Server des Clusters zu öffnen.
• Jump-box: Stellen Sie eine Sprungbox-VM bereit, und verwenden Sie Azure Bastion, um eine Verbindung mit dieser über SSH oder RDP herzustellen. Von dort aus sendet der Operator Anforderungen an den API-Server des Clusters über seine private IP-Adresse.

In der Referenzimplementierung verwenden wir Azure Bastion, um beim Ausführen von Clusterverwaltungsvorgängen zum AKS-API-Server zu tunneln. Im Allgemeinen ist dieser Ansatz einfacher zu verwalten, weniger kostspielig als die Bereitstellung und Verwaltung einer Jump-Box-VM und weniger komplex, um zwischen mehreren Operatoren zu koordinieren. Sie können jedoch eine Sprungbox-VM verwenden, wenn Sie über eine der folgenden Anforderungen verfügen:

• Operatoren verwenden unsichere Geräte. Eine Jump-Box-VM kann eine stärkere Sicherheitshärtung bieten, wenn Ihre Clientgeräte nicht vertrauenswürdig sind.
• Operatoren verbinden sich über instabile Netzwerke. Eine Jump-Box-VM kann eine stabilere Verbindung mit dem Cluster bereitstellen, insbesondere für lange ausgeführte oder Batchverwaltungsvorgänge.
• Operatoren verwenden erweiterte Diagnosetools. Einige Arten von Diagnosetools, z. B. die Paketerfassung, funktionieren möglicherweise nicht gut mit Tunnelingansätzen.

Hinzufügen einer Geheimnisverwaltung

Speichern Sie geheime Schlüssel in einem verwalteten Schlüsselspeicher, z. B. Key Vault. Der Vorteil besteht darin, dass ein verwalteter Schlüsselspeicher die Rotation von Geheimnissen übernimmt. Es bietet eine starke Verschlüsselung und ein Zugangsüberwachungsprotokoll. Außerdem werden Kerngeheimnisse aus der Bereitstellungspipeline herausgehalten. In dieser Architektur ist eine Key Vault Firewall aktiviert und konfiguriert, und Private Link wird verwendet, um eine Verbindung mit Azure Ressourcen herzustellen, z. B. für Key Vault für den Zugriff auf geheime Schlüssel und Zertifikate.

Key Vault ist gut in andere Azure Services integriert. Verwenden Sie die integrierte Funktion dieser Dienste, um auf Geheimnisse zuzugreifen. Weitere Informationen dazu, wie Application Gateway auf TLS-Zertifikate für den Eingangsfluss zugreift, finden Sie im Abschnitt Ingress traffic flow.

Mit dem Azure RBAC-Berechtigungsmodell für Key Vault können Sie die Workloadidentitäten der Rollenzuweisung Geheimnisbenutzer für Schlüsseltresore oder Geheimnisbenutzer für Schlüsseltresore zuweisen und auf die Geheimnisse zugreifen. Weitere Informationen finden Sie unter Access Key Vault mithilfe von Azure RBAC.

Clustergeheimnisse zugreifen

Sie müssen Workload-Identitäten verwenden, um einem Pod den Zugriff auf Geheimnisse aus einem bestimmten Speicher zu ermöglichen. Verwenden Sie zum Vereinfachen des Abrufvorgangs einen Secrets-CSI-Treiber. Wenn der Pod ein Secret benötigt, stellt der Treiber eine Verbindung mit dem angegebenen Speicher her, ruft ein Secret von einem Volume ab und hängt dieses Volume im Cluster ein. Der Pod kann das Geheimnis dann aus dem Dateisystem des Volumes abrufen.

Der CSI-Treiber verfügt über viele Anbieter zur Unterstützung verschiedener verwalteter Speicher. Diese Implementierung verwendet den Key Vault mit dem CSI-Treiber für den Geheimnisspeicher mit dem Ansatz der manuellen TLS-Konfiguration. Eine SecretProviderClass-Ressource definiert, welche Key Vault Zertifikate mit dem Cluster als Kubernetes Secrets synchronisiert werden sollen. Der CSI-Treiber erfordert mindestens einen Pod, der das entsprechende CSI-Volume einhängt, um das synchronisierte Secret zu erstellen und zu pflegen. Wenn Sie alle bereitgestellten Pods löschen, sammelt der Treiber den geheimen Schlüssel, was bedeutet, dass das Gateway sein TLS-Zertifikat verliert. Um dies zu verhindern, stellen Sie einen dedizierten, dauerhaft laufenden Pod bereit, der das CSI-Volume unabhängig vom Lebenszyklus Ihrer Workload-Pods eingehängt hält. Diese Architektur verwendet das Busybox-Containerimage, das einen einfachen Container mit einer Dummy-Aufgabe ausführt. Importieren Sie das Containerimage vor der Clustererstellung in Ihre Azure Container Registry, da Flux es während des Bootstrappings bereitstellt. Aktivieren Sie die geheime Drehung, und legen Sie ein Drehungsabrufintervall (z. B. zwei Minuten) für das CSI-Add-On fest, sodass Zertifikatverlängerungen in Key Vault automatisch verteilt werden. Die Gatewayressource verweist auf den synchronisierten TLS-Geheimschlüssel für die HTTPS-Beendigung. Weitere Informationen finden Sie unter Sichern des Ingress-Datenverkehrs mit der Gateway-API-Implementierung für Anwendungsrouting.

Wie bereits erwähnt, können Sie diese manuelle Konfiguration durch den vom Operator verwalteten TLS-Ansatz ersetzen. Mit diesem Ansatz deklarieren Sie die Key-Vault-Zertifikat-URI und ein Workload-Identity-ServiceAccount direkt am Gateway-Listener. Der Application-Routing-Operator erstellt dann das SecretProviderClass und patcht automatisch den Gateway-Zertifikatsverweis, wodurch es nicht mehr erforderlich ist, diese Ressourcen während des Cluster-Bootstrappings zu definieren, und der dedizierte TLS-Synchronisierungs-Pod entfällt. Beide Ansätze stützen sich auf den Rotationsmechanismus des CSI-Treibers, um Zertifikatserneuerungen aus Key Vault zu übernehmen.

Workloadspeicher

Die in dieser Architektur verwendete Workload ist zustandslos. Wenn Sie den Zustand speichern müssen, wird empfohlen, ihn außerhalb des Clusters beizubehalten. Richtlinien zum Status der Arbeitslast liegen außerhalb des Umfangs dieses Artikels.

Weitere Informationen finden Sie unter Storage Optionen für Anwendungen in AKS.

Richtlinienverwaltung

Eine effektive Möglichkeit zur Verwaltung eines AKS-Clusters ist das Erzwingen von Governance über Richtlinien. Kubernetes implementiert Richtlinien über den Open Policy Agent (OPA) Gatekeeper. Richtlinien für AKS über Azure Policy bereitstellen. Jede Richtlinie wird auf alle Cluster in ihrem Bereich angewendet. OPA Gatekeeper kümmert sich um die Durchsetzung von Richtlinien im Cluster und protokolliert alle Richtlinienüberprüfungen. Die Richtlinienänderungen werden nicht sofort in Ihrem Cluster widergespiegelt. Einige Verzögerungen sind zu erwarten.

Um Ihre AKS-Cluster zu verwalten, können Sie Azure Policy auf verschiedene Arten verwenden:

• Verhindern oder einschränken Sie die Bereitstellung von AKS-Clustern in einer Ressourcengruppe oder einem Abonnement. Wenden Sie Standards für Ihre Organisation an. Beispielsweise Einhalten einer Benennungskonvention oder Angeben eines Tags.

• Sichern Sie Ihren AKS-Cluster über Azure Policy für Kubernetes.

Ein gängiges Beispiel für den sinnvollen Einsatz einer Richtlinie ist die Governance und Validierung von Container-Images. Containerimages können eine Quelle von Sicherheitsrisiken sein, und einige Organisationen erfordern, dass nicht vertrauenswürdige Containerimages mithilfe eines Tools zum Scannen von Containerimages überprüft und dann genehmigt werden, bevor sie in einem Produktionscluster verwendet werden können. Sie können diesen Prozess mithilfe von Azure Policy erzwingen und die Bereitstellung nicht vertrauenswürdiger Containerimages für den Cluster blockieren. Weitere Informationen finden Sie im Quarantine-Muster.

Wenn Sie Richtlinien festlegen, wenden Sie sie basierend auf den Anforderungen der Workload an. Beachten Sie folgende Faktoren:

• Entscheiden Sie, ob eine Sammlung von Richtlinien festgelegt werden soll, die als Initiativen bezeichnet werden, oder wählen Sie einzelne Richtlinien aus. Azure Policy bietet zwei integrierte Initiativen: grundlegende und eingeschränkte. Jede Initiative ist eine Sammlung integrierter Richtlinien, die für einen AKS-Cluster gelten. Es wird empfohlen, eine Initiative sowie andere Richtlinien für den Cluster und die Ressourcen, wie Containerregistrierung, Anwendungsgateway oder Key Vault, die mit dem Cluster interagieren, auszuwählen. Wählen Sie Richtlinien basierend auf den Anforderungen Ihrer Organisation aus.

• Entscheiden Sie, ob Sie die Aktion überwachen oder verweigern möchten. Im Überwachungsmodus ist die Aktion zulässig, aber als nicht konform gekennzeichnet. Verwenden Sie Prozesse, um nicht konforme Zustände in regelmäßigen Abständen zu überprüfen und die erforderlichen Maßnahmen zu ergreifen. Im Verweigerungsmodus wird die Aktion blockiert, da sie gegen die Richtlinie verstößt. Achten Sie darauf, wenn Sie den Modus 'Verweigern' auswählen, da er für die Funktionsfähigkeit des Workloads zu restriktiv sein kann.

• Entscheiden Sie, ob Sie Bereiche in Ihrer Workload haben, die nicht mit dem Entwurf kompatibel sein sollten. Azure Policy können Kubernetes-Namespaces angeben, die von der Richtlinienerzwingung ausgenommen sind. Es wird empfohlen, Richtlinien weiterhin im Überwachungsmodus anzuwenden, damit Sie diese Instanzen kennen.

• Entscheiden Sie, ob Sie über Anforderungen verfügen, die nicht von den integrierten Richtlinien abgedeckt werden. Sie können eine benutzerdefinierte Azure Policy Definition erstellen, die Ihre benutzerdefinierten OPA Gatekeeper-Richtlinien anwendet. Wenden Sie benutzerdefinierte Richtlinien nicht direkt auf den Cluster an. Weitere Informationen finden Sie unter Create and assign custom policy definitions.

• Entscheiden Sie, ob Sie organisationsweite Anforderungen haben. Wenn dies der Fall ist, fügen Sie diese Richtlinien auf der Verwaltungsgruppenebene hinzu. Ihr Cluster muss auch eigene Workload-spezifische Richtlinien zuweisen, auch wenn Ihre Organisation über generische Richtlinien verfügt.

• Entscheiden Sie, ob Sie Azure Richtlinien bestimmten Bereichen zuweisen müssen. Stellen Sie sicher, dass die Produktionsrichtlinien auch für Ihre Vorproduktionsumgebung überprüft werden. Andernfalls könnten Sie bei der Bereitstellung in Ihrer Produktionsumgebung auf unerwartete zusätzliche Einschränkungen stoßen, die Sie in der Vorproduktionsphase nicht berücksichtigt haben.

Diese Referenzimplementierung ermöglicht Azure Policy, wenn der AKS-Cluster erstellt wird. Die restriktive Initiative wird im Überwachungsmodus zugewiesen, um Einblicke in Nichtkompatibilität zu erhalten.

Außerdem werden durch die Implementierung zusätzliche Richtlinien festgelegt, die nicht Teil integrierter Initiativen sind. Diese Richtlinien werden im Verweigerungsmodus festgelegt. Beispielsweise gibt es eine Richtlinie, um sicherzustellen, dass Images nur aus der bereitgestellten Container Registry-Instanz abgerufen werden.

Erstellen Sie ggf. eigene benutzerdefinierte Initiativen. Fassen Sie die Richtlinien, die für Ihre Workload gelten, in einer einzigen Zuweisung zusammen.

Um zu beobachten, wie Azure Policy Funktionen innerhalb Ihres Clusters funktionieren, können Sie auf die Podprotokolle für alle Pods im Namespace gatekeeper-system und die Protokolle für die azure-policy und azure-policy-webhook Pods im namespace kube-system zugreifen.

Skalierbarkeit von Knoten und Pods

Mit zunehmender Nachfrage kann Kubernetes skalieren, indem es durch automatische horizontale Podskalierung weitere Pods zu vorhandenen Knoten hinzufügt. Wenn Kubernetes keine weiteren Pods mehr planen kann, muss die Anzahl der Knoten durch automatische Skalierung des AKS-Clusters erhöht werden. Eine vollständige Skalierungslösung muss sowohl Podreplikate als auch die Anzahl der Knoten im Cluster skalieren können.

Dazu gibt es zwei Ansätze: automatische Skalierung oder manuelle Skalierung.

Sowohl die automatische Skalierung als auch der manuelle Ansatz erfordern, dass Sie Warnungen für die CPU-Auslastung oder benutzerdefinierte Metriken überwachen und festlegen. Für die Podskalierung kann Ihr Anwendungsbediener die Anzahl von Podreplikaten erhöhen oder verringern, indem er ReplicaSet über Kubernetes-APIs anpasst. Bei der Clusterskalierung besteht eine Methode darin, benachrichtigt zu werden, wenn beim Kubernetes-Planer ein Fehler auftritt. Eine andere Möglichkeit besteht darin, ausstehende Pods über einen Zeitraum zu beobachten. Sie können die Knotenanzahl über das Azure CLI oder das Azure Portal anpassen.

Es wird empfohlen, den Autokalierungsansatz zu verwenden, da einige der manuellen Mechanismen in die Autoskalierung integriert sind.

Grundsätzlich sollten Sie Leistungstests mit einer minimalen Anzahl von Pods und Knoten beginnen. Verwenden Sie diese Werte, um die Baselineerwartung festzulegen. Verwenden Sie dann eine Kombination aus Leistungsmetriken und manueller Skalierung, um Engpässe zu ermitteln und die Reaktion der Anwendung auf Skalierung nachzuvollziehen. Legen Sie schließlich mithilfe dieser Daten die Parameter für die automatische Skalierung fest.

Horizontale automatische Podskalierung

Bei der horizontalen automatischen Podskalierung (Horizontal Pod Autoscaler, HPA) handelt es sich um eine Kubernetes-Ressource, die die Anzahl von Pods skaliert.

In der HPA-Ressource wird empfohlen, die mindeste und maximale Replikatanzahl festzulegen. Die Werte schränken die Grenzen für die automatische Skalierung ein.

Die HPA kann anhand der CPU-Auslastung, der Speicherauslastung und benutzerdefinierter Metriken skalieren. Nur die CPU-Auslastung wird nativ bereitgestellt. Die HorizontalPodAutoscaler-Definition gibt Zielwerte für die Metriken an. Die Spezifikation legt beispielsweise die CPU-Zielauslastung fest. Während Pods laufen, überprüft der HPA-Controller die CPU-Auslastung der einzelnen Pods mithilfe der Kubernetes-Metrics-API. Er vergleicht diesen Wert mit der Zielauslastung und berechnet ein Verhältnis. Anschließend ermittelt er anhand dieses Verhältnisses, ob Pods überbelegt oder unterbelegt sind. Er überlässt dem Kubernetes-Planer das Zuweisen neuer Pods zu Knoten oder das Entfernen von Pods von Knoten.

Es kann zu einer Race-Condition kommen, beispielsweise wenn die HPA-Prüfung erfolgt, bevor ein Skalierungsvorgang abgeschlossen ist. Das Ergebnis könnte also eine falsche Verhältnisberechnung sein. Weitere Informationen finden Sie unter Cooldown von Skalierungsereignissen.

Wenn Ihre Workload ereignisgesteuert ist, stellt Kubernetes event-driven autoscaling (KEDA) eine beliebte Open-Source-Option dar. Erwägen Sie KEDA, wenn eine Ereignisquelle, z. B. die Nachrichtenwarteschlange, Ihre Workload steuert, anstatt dass ihre Workload CPU-gebunden oder arbeitsspeichergebunden ist. KEDA unterstützt viele Ereignisquellen oder Skalierer. Verwenden Sie die Liste der Ereignisquellen, die KEDA bei KEDA-Scalern skalieren kann. Die Liste enthält den Azure Monitor Scaler, der eine bequeme Möglichkeit ist, KEDA-Workloads basierend auf Azure Monitor Metriken zu skalieren.

Automatische Clusterskalierung

Die cluster autoscaler ist eine AKS-Add-On-Komponente, die die Anzahl der Knoten in einem Knotenpool skaliert. Fügen Sie sie während der Clusterbereitstellung hinzu. Für jeden Benutzerknotenpool wird eine separate automatische Clusterskalierung benötigt.

Der Kubernetes-Planer löst die automatische Clusterskalierung aus. Wenn der Kubernetes-Scheduler aufgrund von Ressourceneinschränkungen einen Pod nicht planen kann, richtet der Autoscaler automatisch einen neuen Knoten im Knotenpool ein. Umgekehrt überprüft die automatische Clusterskalierung die nicht genutzte Kapazität der Knoten. Wenn der Knoten nicht mit der erwarteten Kapazität läuft, werden die Pods auf einen anderen Knoten verschoben, und der ungenutzte Knoten wird entfernt.

Beim Aktivieren der Autoskalierung legen Sie die maximale und minimale Anzahl von Knoten fest. Die empfohlenen Werte hängen von der Leistungserwartung der Workload, dem gewünschten Wachstum des Clusters und den Auswirkungen auf die Kosten ab. Die Mindestanzahl ist die reservierte Kapazität für diesen Knotenpool. In dieser Referenzimplementierung wird der Mindestwert aufgrund der Einfachheit der Arbeitslast auf zwei festgelegt.

Für den Systemknotenpool beträgt der empfohlene Mindestwert drei.

Entscheidungen zur Geschäftskontinuität

Um die Geschäftskontinuität aufrechtzuerhalten, definieren Sie das SLO für die Infrastruktur und Ihre Anwendung. Weitere Informationen finden Sie unter Recommendations for defining reliability targets. Überprüfen Sie die Bedingungen der Service-Level-Vereinbarung (SLA) für AKS im neuesten Artikel SLA für Onlinedienste.

Clusterknoten

Um das Mindestmaß an Verfügbarkeit für Workloads zu erreichen, benötigen Sie mehrere Knoten in einem Knotenpool. Wenn ein Knoten ausfällt, kann ein anderer Knoten im selben Knotenpool und Cluster die Anwendung weiter ausführen. Aus Zuverlässigkeitsgründen empfehlen wir drei Knoten für den Systemknotenpool. Beginnen Sie für den Benutzerknotenpool mit mindestens zwei Knoten. Wenn Sie eine höhere Verfügbarkeit oder Kapazität benötigen, skalieren Sie, um weitere Knoten hinzuzufügen.

Isolieren Sie Ihre Anwendungen von den Systemdiensten, indem Sie sie in einem separaten Knotenpool, als Benutzerknotenpool bezeichnet, platzieren. Dadurch werden Kubernetes-Dienste auf dedizierten Knoten ausgeführt und konkurrieren nicht mit Ihrer Workload. Wir empfehlen Ihnen, Tags, Labels und Taints zu verwenden, um den Knotenpool zu identifizieren und Ihre Workload zu planen. Stellen Sie sicher, dass Ihr System-Knoten-Pool mit dem Taint CriticalAddonsOnly versehen ist, um zu verhindern, dass Anwendungs-Pods auf Knoten-Pools eingeplant werden.

Regelmäßige Upkeep-Aufgaben auf Ihrem Cluster, z. B. zeitnahe Updates, sind für die Zuverlässigkeit von entscheidender Bedeutung. Außerdem empfehlen wir Ihnen, die Gesundheit der Pods mithilfe von Sonden zu überwachen.

Pod-Verfügbarkeit

• Angabe der Pod-Ressourcenanforderungen: Es wird empfohlen, die Pod-Ressourcenanforderungen in Ihren Bereitstellungen anzugeben. Der Planer kann den Pod dann ordnungsgemäß planen. Die Zuverlässigkeit wird erheblich reduziert, wenn Ihre Pods nicht geplant werden können.

• Pod Disruption Budgets festlegen: Diese Einstellung legt fest, wie viele Repliken in einer Bereitstellung während eines Update- oder Upgrade-Ereignisses ausfallen dürfen. Weitere Informationen finden Sie unter Budgets für die Unterbrechung von Pods.

  Konfigurieren Sie mehrere Replikate in der Bereitstellung, um Störungen wie Hardwarefehler zu bewältigen. Bei geplanten Ereignissen wie Updates und Upgrades kann ein Ausfallbudget dazu beitragen, sicherzustellen, dass die erforderliche Anzahl an Pod-Replikaten vorhanden ist, um die erwartete Anwendungslast zu bewältigen.

• Legen Sie Ressourcenkontingente für die Workload-Namespaces fest: Das Ressourcenkontingent für einen Namespace trägt dazu bei, sicherzustellen, dass Pod-Anforderungen und -Grenzwerte für eine Bereitstellung korrekt festgelegt sind. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten.

  Note

  Wenn Sie Ressourcenkontingente auf Clusterebene festlegen, können Probleme auftreten, wenn Sie externe Workloads bereitstellen, die keine ordnungsgemäßen Anforderungen und Grenzwerte aufweisen. Wenn Sie Kontingente auf Namespaceebene festlegen, wird sichergestellt, dass sie nur für Ihre Workloadkomponenten gelten.

• Festlegen von Pod-Anforderungen und -Grenzwerten: Legen Sie Anforderungen und Grenzwerte fest, damit Kubernetes CPU- und Arbeitsspeicherressourcen effizient den Pods zuordnen kann. Es ermöglicht Ihnen eine höhere Containerdichte auf einem Knoten. Anforderungen und Grenzwerte können zudem die Zuverlässigkeit erhöhen und aufgrund der besseren Hardwarenutzung gleichzeitig die Kosten senken.

  Um die Grenzwerte für eine Workload abzuschätzen, testen und erstellen Sie eine Baseline. Beginnen Sie mit gleichen Werten für Anforderungen und Grenzwerte. Optimieren Sie diese Werte dann schrittweise, bis Sie den Schwellenwert festlegen, der zu Instabilität im Cluster führt.

  Sie können Anforderungen und Grenzwerte in Ihren Bereitstellungsmanifesten angeben. Weitere Informationen finden Sie unter Set pod requests and limits.

Verfügbarkeitszonen

Verwenden Sie availability zones, wenn sie von der Region unterstützt werden, um sich vor einigen Arten von Ausfallen zu schützen. Sowohl die Komponenten der Steuerebene als auch die Knoten in den Knotenpools sind dann zonenredundant, was bedeutet, dass sie über mehrere Zonen verteilt sind. Wenn eine gesamte Zone nicht verfügbar ist, bleibt ein Knoten in einer anderen Zone innerhalb der Region weiterhin verfügbar. Jeder Knotenpool ist einer separaten VM-Skalierungsgruppe zugeordnet, die Knoteninstanzen und Skalierbarkeit verwaltet. Der AKS-Dienst verwaltet Skalierungssatzvorgänge und -konfigurationen. Beachten Sie Folgendes, wenn Sie mehrere Zonen aktivieren:

• Entire infrastructure: Wählen Sie eine Region aus, die Verfügbarkeitszonen unterstützt. Weitere Informationen finden Sie unter Limitations. Um ein SLA für Betriebszeit zu erhalten, müssen Sie die Stufe „Standard“ oder „Premium“ wählen. Die Verfügbarkeits-SLA ist größer, wenn Sie availability zones verwenden.

• Cluster: Sie können die Verfügbarkeitszonen nur beim Erstellen des Knotenpools festlegen. Sie können später nicht mehr geändert werden. Die Knotengrößen sollten in allen Zonen unterstützt werden, damit die gewünschte Verteilung möglich ist. Die zugrunde liegende VM-Skalierungsgruppe stellt die gleiche Hardwarekonfiguration zonenübergreifend bereit.

  Zonenredundanz gilt nicht nur für Knotenpools, sondern auch für die Steuerebene. Die AKS-Steuerungsebene erstreckt sich wie die Knotenpools über die angeforderten Zonen. Wenn Sie keine Unterstützung für Zonen in Ihrem Cluster verwenden, ist es nicht garantiert, dass die Komponenten der Kontrollebene über die Verfügbarkeitszonen verteilt werden.

• Abhängige Ressourcen: Um den Vorteil der Resilienz durch die Verwendung von Verfügbarkeitszonen zu erreichen, müssen alle Dienstabhängigkeiten auch Zonen unterstützen. Wenn ein abhängiger Dienst keine Zonen unterstützt, kann ein Zonenausfall dazu führen, dass bei diesem Dienst ein Fehler auftritt.

  Angenommen, Ihre Arbeitsauslastung verwendet eine Datenbank, die nicht zonensicher ist. Wenn ein Fehler auftritt, wird der AKS-Knoten möglicherweise in eine andere Zone verschoben, die Datenbank wird jedoch nicht mit dem Knoten in diese Zone verschoben, sodass Ihre Arbeitsauslastung unterbrochen wird.

Aus Gründen der Einfachheit in dieser Architektur wird AKS in einer einzelnen Region mit Knotenpools bereitgestellt, die drei availability zones umfassen. Andere Ressourcen der Infrastruktur, z. B. Azure Firewall und Anwendungsgateway, werden auch in derselben Region mit unterstützung mehrerer Zonen bereitgestellt. Die Georeplikation ist für Container Registry aktiviert.

Mehrere Regionen

Wenn Sie availability zones aktivieren, reicht die Abdeckung im unwahrscheinlichen Fall nicht aus, dass eine gesamte Region fehlschlägt. Um eine höhere Verfügbarkeit zu erhalten, führen Sie mehrere AKS-Cluster in unterschiedlichen Regionen aus.

• Bevorzugen Sie gepaarte Regionen, wenn sie verfügbar sind. Ein Vorteil der Verwendung von gekoppelten Regionen ist die Zuverlässigkeit während Plattformupdates. Azure stellt sicher, dass jeweils nur eine Region im Paar aktualisiert wird. Einige Regionen haben keine Paare. Falls Ihre Region nicht gekoppelt ist, können Sie trotzdem eine Lösung mit mehreren Regionen bereitstellen, indem Sie andere Regionen auswählen. Erwägen Sie die Verwendung einer CI/CD-Pipeline (Continuous Integration und Continuous Delivery), die Sie für die Orchestrierung der Wiederherstellung nach einem Regionsausfall konfigurieren. Bestimmte DevOps-Tools wie Flux können die Bereitstellungen mit mehreren Regionen vereinfachen.

• Geben Sie den Standort an, an dem der redundante Dienst über seine sekundäre Instanz verfügt, wenn eine Azure-Ressource Georedundanz unterstützt. Wenn Sie z. B. die Georeplikation für die Containerregistrierung aktivieren, werden automatisch Bilder in die ausgewählten Azure Regionen repliziert. Es bietet zudem fortgesetzten Zugriff auf Bilder, selbst wenn die primäre Region einen Ausfall hat.

• Wählen Sie einen Datenverkehrsrouter aus, der den Datenverkehr abhängig von Ihrer Anforderung über Zonen oder Regionen verteilen kann. Diese Architektur stellt Load Balancer bereit, da sie Nichtwebdatenverkehr über Zonen hinweg verteilen kann. Wenn Sie den Datenverkehr über Regionen hinweg verteilen müssen, sollten Sie Azure Front Door in Betracht ziehen. Weitere Optionen finden Sie unter Choose a load balancer.

Note

Der AKS-Basisplan für das Multiregion-Cluster-Beispielszenario erweitert die Architektur in diesem Artikel, um mehrere Regionen in einer aktiven-aktiven und hochverfügbaren Konfiguration einzuschließen.

Notfallwiederherstellung

Im Idealfall können Sie, wenn ein Fehler in der primären Region auftritt, schnell zu einer Instanz in einer anderen Region wechseln. Möglicherweise erstellen Sie einen Cluster vorab, oder warten Sie, bis er erforderlich ist. Beachten Sie die folgenden Empfehlungen:

• Verwenden Sie mehrere Regionen. Wenn Ihre primäre Region über eine gekoppelte Region verfügt, verwenden Sie dieses Paar. Andernfalls wählen Sie entsprechend Ihren Anforderungen an die Datenresidenz und Latenz Regionen aus.

• Verwenden Sie eine Workload ohne Status, die Sie effizient replizieren können. Wenn Sie den Zustand im Cluster speichern müssen, den wir nicht empfehlen, stellen Sie sicher, dass Sie die Daten häufig in einer anderen Region sichern.

• Integrieren Sie die Wiederherstellungsstrategie, wie zum Beispiel die Replikation in eine andere Region, als Teil der DevOps-Pipeline, um Ihr SLO zu erfüllen.

• Richten Sie jeden Azure Dienst mithilfe von Features ein, die die Notfallwiederherstellung unterstützen. In dieser Architektur ist beispielsweise Container Registry für die Georeplikation aktiviert. Wenn eine Region ausfällt, leitet das zustandsabhängige Failover von ACR Pullvorgänge automatisch über den globalen Endpunkt zu einem fehlerfreien Replikat um, ohne dass Sie die Konfiguration Ihres Clusters ändern müssen.

• Stellen Sie Ihre Infrastruktur als Code bereit, einschließlich Ihres AKS-Clusters sowie aller anderen Komponenten, die Sie benötigen. Falls eine Bereitstellung in einer anderen Region erforderlich ist, können Sie die Skripts oder Vorlagen wiederverwenden, um eine identische Instanz zu erstellen.

Clustersicherung

Für viele Architekturen können Sie einen neuen Cluster einrichten und über gitOps-basiertes Cluster-Bootstrapping zum Betriebszustand zurückkehren, gefolgt von der Anwendungsbereitstellung. Sollten jedoch kritische Ressourcenzustände vorliegen – wie z. B. Konfigurationszuordnungen, Jobs und Geheimnisse, die im Rahmen Ihres Bootstrapping-Prozesses nicht erfasst werden können –, sollten Sie Ihre Wiederherstellungsstrategie überdenken. Es wird empfohlen, zustandslose Workloads in Kubernetes auszuführen. Wenn Ihre Architektur einen datenträgerbasierten Zustand beinhaltet, müssen Sie auch Ihre Wiederherstellungsstrategie für diesen Inhalt berücksichtigen.

Wenn die Clustersicherung Teil Ihrer Wiederherstellungsstrategie sein muss, müssen Sie eine Lösung installieren, die Ihren Geschäftsanforderungen innerhalb des Clusters entspricht. Dieser Agent ist dafür verantwortlich, den Clusterressourcenstatus an ein Ziel Ihrer Wahl zu senden und Azure-Datenträger-basierte, persistente Volume-Snapshots zu koordinieren.

VMware Velero ist ein Beispiel für eine gängige Kubernetes-Sicherungslösung, die Sie direkt installieren und verwalten können. Sie können auch die AKS-Sicherungserweiterung verwenden, um eine verwaltete Velero-Implementierung bereitzustellen. Die AKS-Sicherungserweiterung unterstützt das Sichern von Kubernetes-Ressourcen und persistenten Volumes, wobei Zeitpläne und Sicherungsbereiche als Tresorkonfiguration in Azure Backup externisiert sind.

Die Referenzimplementierung implementiert keine Sicherung, was zusätzliche Azure Ressourcen zum Verwalten, Überwachen, Kaufen und Sichern umfasst. Diese Ressourcen können ein Azure Storage-Konto, einen Azure Backup Tresor und eine Konfiguration sowie das feature trusted access enthalten. Stattdessen ist GitOps in Kombination mit der Absicht, zustandslose Workloads auszuführen, die Lösung für die Wiederherstellung.

Wählen Und validieren Sie eine Backup-Lösung, die Ihrem Geschäftsziel entspricht, einschließlich Ihres definierten Ziels für wiederherstellungspunkt und Wiederherstellungszeit. Definieren Sie Ihren Wiederherstellungsprozess in einem Teamrunbook, und setzen Sie ihn für alle unternehmenskritischen Workloads um.

Wenn Sie zustandsbehaftete Workloads unterstützen und AKS Backup übernehmen müssen, verwenden Sie Azure Policy, um diese Sicherung auf Ihrem Cluster zu erzwingen.If you must support stateful workloads and adopt AKS Backup, use Azure Policy to enforce that backup is configured on your cluster. Azure Monitor macht den Zustand der Sicherungsaufträge über denselben Observability-Stack sichtbar, der in dieser Architektur bereits etabliert ist. Berücksichtigen Sie zusätzlich zu diesen Governance-Vorgaben die folgenden Architekturüberlegungen bei Ihrem Entwurf:

• Umfang der Sicherung. Entscheiden Sie, ob Sie den gesamten Cluster oder bestimmte Namespaces sichern. AKS Backup speichert Daten in einem BLOB-Container und als Datenträger- oder Dateimomentaufnahmen. Definieren Sie diesen Umfang frühzeitig, denn er bestimmt die Größe Ihres Speicherkontos, die Aufbewahrungsrichtlinien und die Granularität der Wiederherstellung für Szenarien wie die operative Wiederherstellung, das Klonen von Umgebungen und Clusterupgrades.
• Vertrauenswürdiger Zugriff. AKS Backup erfordert vertrauenswürdigen Zugriff zwischen dem Sicherungstresor und dem AKS-Cluster, unabhängig davon, ob der Cluster öffentlich, privat oder IP-eingeschränkt ist.
• RBAC-Berechtigungen. Die verwaltete Identität des Backup-Vaults erfordert eine Reihe von Berechtigungen im AKS-Cluster, um Backups zu konfigurieren und auszuführen. Die Sicherungserweiterung erstellt auch eine Benutzeridentität mit Berechtigungen für das Speicherkonto, in dem Sicherungen gespeichert werden.
• Netzwerkausgang. Die Sicherungserweiterung kommuniziert mit Azure Backup Diensten innerhalb des Clusters. Berücksichtigen Sie die erforderlichen ausgehenden Endpunkte in Ihren Azure Firewall- und NSG-Regeln.
• Platzbedarf innerhalb des Clusters. Die Erweiterung stellt Pods auf Ihren Knoten bereit. Planen Sie den zusätzlichen Rechen- und Speicherverbrauch in Ihren Knotenressourcenbudgets ein und beziehen Sie den Erweiterungs-Namespace in Ihre Netzwerkrichtlinienverwaltung ein.

SLA des Kubernetes-API-Servers

Sie können AKS als kostenlosen Dienst verwenden, aber diese Stufe bietet keine finanziell gesicherte SLA. Um eine SLA zu erhalten, müssen Sie die stufe Standard auswählen. Es wird empfohlen, dass alle Produktionscluster die Standardebene verwenden. Reservieren Sie die kostenlose Stufe für Vorproduktionscluster und die Premium-Stufe nur für missionskritische Workloads. Wenn Sie Azure Verfügbarkeitszonen verwenden, ist die SLA des Kubernetes-API-Servers höher. Ihre Knotenpools und anderen Ressourcen werden durch eigene SLAs abgedeckt.

Weitere Informationen zu bestimmten SLAs für jeden Dienst finden Sie unter SLA für Onlinedienste.

Kompromiss

Es gibt einen Kosten-zu-Verfügbarkeit-Kompromiss für die Bereitstellung der Architektur über Zonen und insbesondere Regionen hinweg. Einige Replikationsfeatures, z. B. die Georeplikation in der Containerregistrierung, sind in Premium-SKUs verfügbar, was teurer ist. Bei Bereitstellungen in mehreren Regionen steigen die Kosten auch, da Bandbreitengebühren anfallen, wenn der Datenverkehr über Regionen hinweg übertragen wird.

Erwarten Sie außerdem eine geringe Menge zusätzlicher Netzwerklatenz in der Knotenkommunikation zwischen Zonen und eine größere Latenz bei der Kommunikation zwischen Regionen. Messen Sie die Auswirkung dieser Architekturentscheidung auf Ihre Workload.

Testen mit Simulationen und erzwungenen Failovern

Testen Sie die Zuverlässigkeit Ihrer Lösung durch erzwungene Failovertests mit simulierten Ausfallen. Simulationen können das Beenden eines Knotens, das Herunterfahren aller AKS-Ressourcen in einer bestimmten Zone umfassen, um einen Zonenfehler zu simulieren oder einen externen Abhängigkeitsfehler aufzugeben. Sie können auch Azure Chaos Studio verwenden, um verschiedene Arten von Ausfallen in Azure und auf dem Cluster zu simulieren.

Weitere Informationen finden Sie unter Chaos Studio.

Überwachen und Sammeln von Protokollen und Metriken

Wir empfehlen die Azure Monitor Kubernetes-Überwachungsdienste, um die Leistung von Containerworkloads zu überwachen, da Sie Ereignisse in Echtzeit anzeigen können. Azure Monitor erfasst Protokolle von Containern in laufenden Pods und fasst sie zur Anzeige zusammen. Außerdem sammelt es Informationen von der Metrik-API zur Arbeitsspeicher- und CPU-Auslastung, um die Integrität der ausgeführten Ressourcen und Workloads zu überwachen. Sie können auch Azure Monitor verwenden, um die Leistung während der Skalierung der Pods zu überwachen. Es umfasst Telemetrie, die für die Überwachung, Analyse und Visualisierung der gesammelten Daten von entscheidender Bedeutung ist.

Aktivierung der Log-Erfassung von Pods

Das ContainerLogV2-Protokollschema wurde entwickelt, um Containerprotokolle von Kubernetes-Pods in einem optimierten Ansatz zu erfassen. Protokolleinträge werden in der Tabelle ContainerLogV2 in einem Azure Log Analytics Arbeitsbereich konsolidiert.

In einem AKS-Cluster gibt es zwei primäre Methoden zur Konfiguration der Pod-Protokollerfassung. Mit beiden Ansätzen können Sie Einstellungen anpassen. Sie können Namespaces filtern, Sammlungsintervalle anpassen, bestimmte Features aktivieren oder verbieten (z ContainerLogV2 . B. oder ContainerLogV2-HighScale), und angeben, welche Datenströme erfasst werden sollen.

• Wenn Sie zentrale, wiederverwendbare Überwachungskonfigurationen für mehrere Cluster benötigen oder die Clusterkonfiguration in Azure-nativen Ressourcen externalisiert bevorzugen, verwenden Sie Datensammlungsregeln (DCRs). DCRs sind Azure Ressourcen, die die Azure Resource Manager Steuerebene nativ verwaltet, und Sie können sie in Bicep Dateien einschließen. Die Referenzimplementierung verwendet DCRs.

• Alternativ können Sie die Überwachung mithilfe von ConfigMaps definieren, bei denen es sich um nichtkonfidentiale Kubernetes-YAML-Objekte handelt, die über die Kubernetes-API-Steuerungsebene konfiguriert sind. Der Azure Monitor-Agent, der auf dem Cluster ausgeführt wird, überwacht configMap-Objekte. Es verwendet vordefinierte Einstellungen, um zu bestimmen, welche Daten erfasst werden sollen.

Wenn beide Methoden aktiviert sind, haben ConfigMap-Einstellungen Vorrang vor DCRs. Vermeiden Sie das Mischen von ConfigMap- und DCR-Konfigurationen für die Sammlung von Containerprotokollen, da dies zu schwer zu behebenden Protokollierungsproblemen führen kann.

Warnungen und Prometheus-Metriken

Ausfalle und Fehlfunktionen stellen erhebliche Risiken für Arbeitsauslastungsanwendungen dar. Dies macht es wichtig, Probleme im Zusammenhang mit der Integrität und Leistung Ihrer Infrastruktur proaktiv zu identifizieren. Wenn Sie Ihre Umgebung überwachen und auf Das, was Sie lernen, reagieren, reduzieren Sie Unterbrechungen und verbessern die Zuverlässigkeit Ihrer Lösung. Um potenzielle Fehlerbedingungen in Ihrem Cluster zu antizipieren, aktivieren Sie die empfohlenen Prometheus-Warnungsregeln für Kubernetes.

Die meisten in Pods gehosteten Workloads geben Prometheus-Metriken aus. Azure Monitor kann mit Prometheus integriert werden. Sie können die Anwendungs- und Workloadmetriken anzeigen, die aus Containern, Pods, Knoten und dem Cluster gesammelt werden.

Einige nicht Microsoft Lösungen sind in Kubernetes integriert, z. B. Datadog, Grafana oder New Relic. Wenn Ihre Organisation diese Lösungen bereits verwendet, können Sie diese nutzen.

Protokolle der Azure-Infrastruktur und der Kubernetes-Steuerungsebene

Mit AKS verwaltet Azure einige der wichtigsten Kubernetes-Dienste. Azure implementiert die Protokolle für die AKS-Steuerungsebenenkomponenten als ressourcenprotokolle. Diese Optionen können Ihnen bei der Behandlung von Clusterproblemen helfen und haben eine relativ geringe Protokolldichte. Es wird empfohlen, die folgenden Optionen für die meisten Cluster zu aktivieren:

• ClusterAutoscaler: Gewinnen Sie Überwachbarkeit in den Skalierungsprozessen durch Protokollieren. Weitere Informationen finden Sie unter Cluster-Autoscaler-Protokolle und Status abrufen.

• KubeControllerManager: Erhalten Sie Einblick in die Interaktion zwischen Kubernetes und der Azure-Steuerebene.

• kube-audit-admin: Gewinnen Sie Einblick in die Aktivitäten, die Ihren Cluster ändern. Es ist nicht erforderlich, sowohl kube-audit als auch kube-audit-admin zu aktivieren, da kube-audit eine Obermenge ist, die auch Lesevorgänge (nicht modifizierend) umfasst.

• guard: Erfassen Sie Microsoft Entra ID- und Azure RBAC-Audits.

Es kann hilfreich sein, wenn Sie andere Protokollkategorien wie KubeScheduler oder kube-audit während der frühen Entwicklungsphase des Cluster- oder Workload-Lebenszyklus aktivieren. Die hinzugefügte automatische Clusterskalierung, Pod-Platzierung und -Planung und ähnliche Daten können Ihnen bei der Behebung von Problemen im Zusammenhang mit Cluster- oder Workload-Vorgängen helfen. Wenn Sie jedoch die erweiterten Problembehandlungsprotokolle vollständig speichern, nachdem Ihre Problembehandlungsanforderungen beendet wurden, entstehen möglicherweise unnötige Kosten zum Aufnehmen und Speichern der Daten in Azure Monitor.

Azure Monitor enthält eine Reihe vorhandener Protokollabfragen, mit denen Sie beginnen können, aber Sie können sie auch als Grundlage verwenden, um Ihre eigenen Abfragen zu erstellen. Wenn Ihre Bibliothek wächst, können Sie Protokollabfragen mithilfe eines oder mehrerer Query Packs speichern und wiederverwenden. Ihre benutzerdefinierte Bibliothek von Abfragen bietet eine größere Überwachbarkeit in Bezug auf die Gesundheit und Leistung Ihrer AKS-Cluster. Es unterstützt das Erreichen Ihrer SLOs.

Weitere Informationen zur Überwachung bewährter Methoden für AKS finden Sie unter Monitor AKS mit Azure Monitor.

Netzwerkmetriken

Grundlegende Netzwerkmetriken auf Clusterebene sind über systemeigene platform- und Prometheus-Metriken verfügbar. Sie können AKS node-Netzwerkmetriken weiter verwenden, um Netzwerkmetriken mithilfe von Prometheus-Metriken auf Knotenebene verfügbar zu machen. Die meisten Cluster sollten die Netzwerkbeobachtbarkeit umfassen, um zusätzliche Netzwerkproblembehandlungsfunktionen bereitzustellen und unerwartete Netzwerkauslastungen oder Probleme auf Knotenebene zu erkennen.

Die Referenzimplementierung verwendet Azure Monitor, die auch einige netzwerkbezogene Metriken sammelt. Die Referenzimplementierung verbietet das direkte Sammeln einiger Netzwerkmetriken von Azure Monitor und sammelt stattdessen die Netzwerk-Observierbarkeitsmetriken mithilfe eines Azure Monitor-Arbeitsbereichs mit managed Prometheus.

Für Workloads, die sehr empfindlich auf Paketverluste, Latenzen oder DNS-Druck beim Transmission Control Protocol (TCP) oder User Datagram Protocol (UDP) reagieren, sind die Netzwerkmetriken auf Pod-Ebene wichtig. In AKS können Sie auf diese detaillierten Metriken mithilfe der Funktion Advanced Container Networking Services zugreifen. Für die meisten Workloads ist diese Tiefe an Netzwerktransparenz nicht erforderlich. Sie sollten die erweiterte Netzwerküberwachbarkeit nur aktivieren, wenn Ihre Pods einen hohen Bedarf an einem hochoptimierten Netzwerk haben, das bis auf die Paketebene genau ist.

Kostenoptimierung für die Protokollierung

Die Referenzimplementierung konfiguriert die ContainerLogV2 Tabelle, um den Standardplan als Ausgangspunkt zu verwenden. Microsoft Defender for Containers und die für die Referenzimplementierung erstellten Warnungen fragen diese Tabelle nicht ab, sodass der Basic-Tarif wahrscheinlich kosteneffizient ist, da er die Kosten für das Einbinden von Daten senkt.

Wenn sich Ihre Protokollvolumen- und Abfrageanforderungen weiterentwickeln, wählen Sie den kostengünstigsten Tabellenplan für Ihre Anforderungen aus. Wenn die Lösung schreibintensiv wird, bei der Abfragen häufig Tabellendaten scannen, ist der Standardmäßige Analytics-Plan möglicherweise besser geeignet. Der Analyseplan entfernt Abfragegebühren, was für Szenarien optimiert ist, in denen die Aktivität der Abfragen die Erfassungskosten überwiegt. Wenn Sie Nutzungsmuster überwachen und Tabellenpläne nach Bedarf anpassen, können Sie ein Gleichgewicht zwischen Kosten und Funktionalität für Ihre Überwachungslösung erzielen.

Weitere Informationen finden Sie unter Auswahl eines Tabellenplans basierend auf der Datennutzung in einem Log Analytics-Arbeitsbereich.

Aktivieren der Selbstheilung

Überwachen Sie die Integrität von Pods, indem Sie Live- und Bereitschaftstests festlegen. Wenn Kubernetes einen nicht reagierenden Pod erkennt, startet es den Pod neu. Ein Livetest ermittelt, ob der Pod fehlerfrei ist. Wenn Kubernetes einen nicht reagierenden Pod erkennt, startet es den Pod neu. Ein Bereitschaftstest ermittelt, ob der Pod zum Empfangen von Anforderungen und Datenverkehr bereit ist.

Note

AKS verfügt über eine automatische Knotenreparaturfunktion, die integrierte Self-Healing für Infrastrukturknoten bereitstellt.

Routineupdates für AKS-Cluster

Teil von „Day 2“-Vorgängen für Kubernetes-Cluster besteht darin, routinemäßige Plattform- und Betriebssystemupdates durchzuführen. Es gibt drei Update-Ebenen, die auf jedem AKS-Cluster adressiert werden müssen:

• Die Kubernetes-Version (z. B. Kubernetes 1.32.3 bis 1.32.7 oder Kubernetes 1.32.7 bis 1.33.1), die möglicherweise Änderungen an der Kubernetes-API und veraltete Funktionen mit sich bringt. Versionsänderungen auf dieser Ebene haben Auswirkungen auf den gesamten Cluster.

• Das Image der virtuellen Festplatte (VHD) auf jedem Knoten, das Betriebssystemupdates und AKS-Komponentenupdates kombiniert. Diese Updates werden mit der Kubernetes-Version des Clusters getestet. Versionsänderungen auf dieser Ebene werden auf Knotenpoolebene angewendet und haben keine Auswirkungen auf die Kubernetes-Version.

• Der eigene systemeigene Updateprozess des Betriebssystems, z. B. Windows Update oder apt. Diese Updates werden direkt vom Betriebssystemanbieter bereitgestellt und nicht mit der Kubernetes-Version des Clusters getestet. Versionsänderungen auf dieser Ebene wirken sich auf einen einzelnen Knoten, jedoch nicht auf die Kubernetes-Version aus.

Jede dieser Ebenen wird unabhängig voneinander gesteuert. Sie entscheiden, wie die einzelnen Ebenen für die Cluster Ihrer Workload behandelt werden. Wählen Sie aus, wie oft jeder AKS-Cluster, seine Knotenpools oder seine Knoten aktualisiert werden (die Häufigkeit). Wählen Sie außerdem die Tage oder Uhrzeiten aus, um die Updates anzuwenden (Ihr Wartungsfenster). Wählen Sie aus, ob Updates manuell oder automatisch oder gar nicht installiert werden sollen. Ebenso wie für die Workload, die auf Ihrem Cluster ausgeführt wird, eine sichere Bereitstellungspraxis erforderlich ist, gilt dies auch für die Aktualisierungen Ihrer Cluster.

Eine umfassende Perspektive zum Patchen und Aktualisieren finden Sie in AKS-Patch- und Upgradeleitfaden im AKS Day-2-Betriebshandbuch. Verwenden Sie die folgenden Informationen für grundlegende Empfehlungen in Bezug auf diese Architektur.

Unveränderliche Infrastruktur

Workloads, die AKS-Cluster als unveränderliche Infrastruktur betreiben, aktualisieren ihre Cluster nicht automatisch oder manuell. Legen Sie das node-Imageupgrade auf none und das automatische Upgrade des clusters auf none fest. In dieser Konfiguration sind ausschließlich Sie für alle Upgrades auf allen Ebenen verantwortlich.

Wenn ein gewünschtes Update verfügbar wird, müssen Sie die folgenden Schritte ausführen:

1. Testen Sie das Update in einer Vorproduktionsumgebung, und bewerten Sie die Kompatibilität für einen neuen Cluster.

2. Stellen Sie eine Produktionsreplik-Stempelversion bereit, die die aktualisierte AKS-Version und die VHDs der Knoten-Pools enthält.

3. Wenn der neue Produktionscluster fertig ist, entwässern Sie den alten Cluster und setzen sie schließlich außer Betrieb.

Nur bei einer unveränderlichen Infrastruktur mit regelmäßigen Bereitstellungen neuer Infrastruktur sollte für ein Produktionscluster keine direkte Upgradestrategie angewendet sein. Alle anderen Cluster sollten eine In-Place-Upgrade-Strategie haben.

Direkte Upgrades

Workloads, die keine AKS-Cluster als unveränderliche Infrastruktur betreiben, sollten ihre ausgeführten Cluster regelmäßig aktualisieren, um alle drei Ebenen zu adressieren. Richten Sie den Updateprozess auf die Anforderungen Ihrer Workload aus. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für das Entwerfen Ihres Routineupdateprozesses.

• Planen Sie das Feature planierte Wartung von AKS, sodass Sie Upgrades auf Ihrem Cluster steuern können. Mit dieser Funktion können Sie diese Updates, einen inhärent riskanten Vorgang, zu einem kontrollierten Zeitpunkt ausführen, um die Auswirkungen eines unerwarteten Fehlers zu verringern.

• Konfigurieren Sie Budgets für die Unterbrechung von Pods so, dass Ihre Anwendung während der parallelen Upgrades stabil bleibt. Konfigurieren Sie jedoch die Budgets nicht so aggressiv, dass sie Node-Upgrades blockieren. Denn die meisten Upgrades erfordern für jeden Knoten einen Cordon-und-Drain-Prozess.

• Bestätigen Sie Azure Ressourcenkontingent und Ressourcenverfügbarkeit. Bei direkten Upgrades werden neue Instanzen von Knoten, sogenannte Surge-Knoten, bereitgestellt, bevor alte Knoten entfernt werden. Dies bedeutet, dass Azure Kontingent und IP-Adressraum für die neuen Knoten verfügbar sein müssen. Ein Anstiegswert von 33 % ist ein guter Ausgangspunkt für die meisten Workloads.

• Testen Sie die Kompatibilität mit Tools, z. B. Dienstgitter oder Sicherheits-Agents, die Sie Ihrem Cluster hinzugefügt haben. Testen Sie außerdem Ihre Workloadkomponenten, z. B. Eingangscontroller, Dienstgitter und Ihre Workload-Pods. Führen Sie Tests in einer Vorproduktionsumgebung aus.

Vor-Ort-Upgrades für Knoten

Verwenden Sie den NodeImage Kanal für automatische Upgrades von Betriebssystemimages für Knoten. Dieser Kanal konfiguriert Ihren Cluster so, dass die VHD auf jedem Knoten mit knotenebenen Aktualisierungen aktualisiert wird. Microsoft testet die Updates anhand Ihrer AKS-Version. Bei Windows Knoten erfolgen die Aktualisierungen etwa einmal pro Monat. Bei Linux-Knoten erfolgen die Updates etwa einmal pro Woche.

• Die Upgrades ändern nie Ihre AKS- oder Kubernetes-Version, daher besteht kein Problem hinsichtlich der Kubernetes-API-Kompatibilität.

• Wenn Sie NodeImage als Upgradekanal verwenden, wird Ihr geplantes Wartungsfenster berücksichtigt, das Sie mindestens einmal pro Woche festlegen sollten. Legen Sie es unabhängig davon fest, welches Knotenimagebetriebssystem Sie verwenden, um eine zeitnahe Anwendung von Updates sicherzustellen.

• Zu diesen Updates gehören Sicherheits-, Kompatibilitäts- und Funktionsupdates auf Betriebssystemebene, Betriebssystemkonfigurationseinstellungen und AKS-Komponentenupdates.

• Image-Releases und die darin enthaltenen Versionsnummern werden mithilfe des AKS Release-Trackers nachverfolgt.

Wenn die Sicherheitsanforderungen für Ihren Cluster einen aggressiveren Patching-Rhythmus erfordern und Ihr Cluster die potenziellen Unterbrechungen tolerieren kann, verwenden Sie stattdessen den SecurityPatch-Upgradekanal. Microsoft testet diese Updates ebenfalls. Die Updates werden nur veröffentlicht, wenn Sicherheitsupgrades vorhanden sind, die Microsoft für wichtig genug hält, um vor dem nächsten anstehenden Knoten-Image-Upgrade freizugeben. Wenn Sie den Kanal SecurityPatch verwenden, erhalten Sie auch die Updates wie der Kanal NodeImage. Die SecurityPatch Kanaloption berücksichtigt weiterhin Ihre Wartungsfenster. Achten Sie daher darauf, dass Ihr Wartungsfenster häufiger Lücken (z. B. täglich oder jeden anderen Tag) aufweist, um diese unerwarteten Sicherheitsupdates zu unterstützen.

Die meisten Cluster, bei denen direkte Upgrades durchgeführt werden, sollten die Upgradekanaloptionen für Knotenimages None und Unmanaged vermeiden.

In-situ-Updates des Clusters

Kubernetes ist eine sich schnell entwickelnde Plattform, und regelmäßige Updates bringen wichtige Sicherheitsupdates sowie neue Funktionen mit sich. Es ist wichtig, dass Sie mit Kubernetes-Updates auf dem Laufenden bleiben. Sie sollten innerhalb der zwei neuesten Versionen (N-2) bleiben. Es ist wichtig, auf die neueste Version von Kubernetes zu aktualisieren, da häufig neue Versionen veröffentlicht werden.

Die meisten Cluster sollten in der Lage sein, AKS-Versionsupdates an Ort und Stelle mit ausreichender Vorsicht und Sorgfalt durchzuführen. Das Risiko, ein direktes AKS-Versionsupgrade durchzuführen, kann hauptsächlich durch ausreichende Präproduktionstests, Kontingentüberprüfung und Pod-Unterbrechungsbudgetkonfiguration abgemildert werden. Ein direktes Upgrade kann jedoch unerwartetes Verhalten aufweisen. Wenn direkte Upgrades für Ihre Workload als zu riskant eingestuft werden, empfehlen wir Ihnen, eine Blau-Grün-Bereitstellung von AKS-Clustern zu verwenden, anstatt den verbleibenden Empfehlungen zu folgen.

Wir empfehlen Ihnen, die Funktion automatische Cluster-Aktualisierung zu vermeiden, wenn Sie einen Kubernetes-Cluster zum ersten Mal bereitstellen. Verwenden Sie einen manuellen Ansatz, mit dem Sie eine neue AKS-Clusterversion in Ihren Präproduktionsumgebungen testen können, bevor die Updates auf Ihre Produktionsumgebung stoßen. Dieser Ansatz erreicht auch das größte Maß an Vorhersagbarkeit und Kontrolle. Sie müssen neue Updates für die Kubernetes-Plattform jedoch sorgfältig überwachen und schnell neue Versionen übernehmen, sobald sie veröffentlicht werden. Es ist besser, eine Denkweise zu übernehmen, die das 'auf dem neuesten Stand bleiben' bevorzugt statt einen Langzeitunterstützungs-Ansatz.

Warning

Es wird nicht empfohlen, automatisch einen AKS-Produktionscluster zu patchen oder zu aktualisieren, auch nicht mit Nebenversionsupdates, es sei denn, Sie testen diese Updates zunächst in Ihren niedrigeren Umgebungen. Weitere Informationen finden Sie unter Regelmäßige Aktualisierung auf die neueste Version von Kubernetes und Aktualisieren eines AKS-Clusters.

Sie können Benachrichtigungen empfangen, wenn eine neue AKS-Version für Ihren Cluster verfügbar ist, indem Sie das AKS-System für Azure Event Grid verwenden. Die Referenzimplementierung stellt dieses Ereignisrastersystem bereit, sodass Sie das ereignis Microsoft.ContainerService.NewKubernetesVersionAvailable aus Ihrer Eventstream-Benachrichtigungslösung abonnieren können. Lesen Sie die AKS-Versionshinweise für bestimmte Kompatibilitätsprobleme, Verhaltensänderungen oder veraltete Funktionen.

Möglicherweise erreichen Sie den Konfidenzpunkt mit Kubernetes-Versionen, AKS-Versionen, Ihrem Cluster, seinen Komponenten auf Clusterebene und der Workload, um die Funktion für automatische Upgrades zu entdecken. Für Produktionssysteme ist es selten, über patch hinauszugehen. Wenn Sie Ihre AKS-Version automatisch aktualisieren, überprüfen Sie außerdem die AKS-Versionseinstellung in Ihrer Infrastruktur als Code (IaC), damit die beiden nicht aus dem Gleichgewicht geraten. Konfigurieren Sie Ihr geplantes Wartungsfenster, um die automatische Aktualisierung zu unterstützen.

Sicherheitsüberwachung

Überwachen Sie Ihre Containerinfrastruktur sowohl auf aktive Bedrohungen als auch auf potenzielle Sicherheitsrisiken. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Microsoft Defender für Container identifiziert und korrigiert Defender for Cloud Empfehlungen für Ihre Containerimages.
• Defender für Container überwacht Ihre Container-Images regelmäßig auf Schwachstellen.
• Defender für Container generiert auch realzeit-Sicherheitswarnungen für verdächtige Aktivitäten.
• Security-Konzepte für Anwendungen und Cluster in AKS bieten ausführliche Informationen dazu, wie die Containersicherheit die gesamte End-to-End-Pipeline von der Erstellung bis zu den Anwendungs-Workloads schützt, die in AKS ausgeführt werden.

Cluster- und Workload-Operationen

Überlegungen zu Cluster- und Workloadvorgängen (DevOps) finden Sie in der Säule Entwurfsprinzipien für optimalen Betrieb.

Clusterbootstrapping

Nachdem Sie Ihren Cluster eingerichtet haben, ist es ein Arbeitscluster, aber Möglicherweise haben Sie weitere Schritte to do, bevor Sie Workloads bereitstellen können. Der Prozess der Vorbereitung des Clusters wird als Bootstrapping bezeichnet. Das Bootstrapping besteht häufig aus der Bereitstellung von erforderlichen Images auf Clusterknoten, dem Erstellen von Namespaces und anderen Aufgaben, die die Anforderungen des Anwendungsfalles Ihrer Organisation erfüllen.

Um den Übergang von einem neu eingerichteten Cluster zu einem ordnungsgemäß konfigurierten Cluster zu beschleunigen, müssen Sie Ihren eindeutigen Bootstrapping-Prozess definieren und relevante Ressourcen im Voraus vorbereiten. Wenn Sie beispielsweise ein Dienstgitter wie Linkerd oder Consul Connect verwenden, stellen Sie das Gitter normalerweise bereit, bevor Anwendungsworkloads geplant werden können. Bevor Sie den Cluster einrichten, müssen Sie überprüfen, ob die Images des Service Mesh in einer zuvor erstellten Containerregistrierung vorhanden sind. Diese Überprüfung trägt dazu bei, Bereitstellungsverzögerungen oder Fehler zu verhindern.

Sie können den Bootstrapping-Prozess mit einer der folgenden Methoden konfigurieren:

• GitOps Flux v2 Clustererweiterung
• Pipelines
• Beispielsweise eine Selbstkonfiguration mit Flux oder Argo CD

Note

Alle diese Methoden funktionieren mit jeder Clustertopologie, wir empfehlen jedoch die Clustererweiterung GitOps Flux v2 für Flotten aufgrund der Einheitlichkeit und einfacheren Verwaltung im großen Maßstab. Wenn Sie nur wenige Cluster ausführen, kann GitOps zu komplex sein. Sie können sich stattdessen dafür entscheiden, den Prozess in eine oder mehrere Bereitstellungspipelines zu integrieren, um sicherzustellen, dass Bootstrapping stattfindet. Verwenden Sie die Methode, die am besten zu den Zielen Ihrer Organisation und Ihres Teams passt.

Einer der Hauptvorteile der GitOps Flux v2-Clustererweiterung für AKS besteht darin, dass es praktisch keine Lücke zwischen einem bereitgestellten Cluster und einem Cluster nach dem Bootstrapping gibt. Dadurch wird die Umgebung mit einer soliden Verwaltungsgrundlage für die Zukunft eingerichtet; außerdem wird die Einbindung des Bootstrapping als Ressourcenvorlagen unterstützt, um Ihrer IaC-Strategie gerecht zu werden.

Wenn bootstrapped-Manifeste Werte erfordern, die nur zur Bereitstellungszeit bekannt sind, z. B. eine Containerregistrierungs-URL, einen Key Vault Namen oder eine Identitätsclient-ID, verwenden Sie die variable Ersetzung von Flux in der Kustomisierungskonfiguration. Eine Kustomisierung definiert, welcher Pfad im Git-Repository synchronisiert werden soll und welche Variablensubstitutionen nach dem Build angewendet werden sollen. Sie konfigurieren Kustomisierungen als Teil der Flux-Erweiterungsbereitstellung in Ihrer IaC-Vorlage, in der Sie die Ersetzungsvariablen definieren, sodass Werte aus den bereitgestellten Ressourcen zum Zeitpunkt der Clustererstellung aufgelöst werden. Dieser Ansatz beseitigt Timing-Probleme, die auftreten, wenn eine ConfigMap bereits vor der ersten Reconciliation vorhanden sein muss, und vermeidet, dass Benutzer das Repository eigens forken müssen, nur um umgebungsspezifische Werte anzupassen. Der Flux-Erweiterungs-Agent übersetzt diese IaC-Konfiguration in Kubernetes benutzerdefinierte Ressourcen, die der Flux Kustomize-Controller abgleicht, und wendet die variablen Ersetzungen an, wenn er jeden Pfad verarbeitet.

Wenn Sie die GitOps Flux v2-Clustererweiterung verwenden, ist kubectl nicht für einen Teil des Bootstrapping-Prozesses erforderlich. Sie können den kubectl-basierten Zugriff für Notfallsituationen zur Fehlerbehebung reservieren. Zwischen Vorlagen für Azure Ressourcendefinitionen und dem Bootstrapping von Manifesten über die GitOps-Erweiterung können Sie alle normalen Konfigurationsaktivitäten ausführen, ohne kubectl verwenden zu müssen.

Isolieren der Zuständigkeiten für Workloads

Teilen Sie Workloads nach Teams und Ressourcentypen ein, um jeden Teil einzeln verwalten zu können.

Beginnen Sie mit einer einfachen Workload, die die grundlegenden Komponenten enthält, und bauen Sie darauf auf. Eine erste Aufgabe ist die Konfiguration des Netzwerks. Richten Sie virtuelle Netzwerke für den Hub und die Speichen und auch Subnetze in diesen Netzwerken ein. Beispielsweise verfügt ein Spoke über separate Subnetze für System- und Benutzer-Knoten-Pools, Ingress-Ressourcen und den privaten AKS-API-Server. Stellen Sie ein Subnetz für Azure Firewall im Hub bereit.

Eine weitere Aufgabe besteht darin, die grundlegende Arbeitsauslastung in Microsoft Entra ID zu integrieren.

Verwenden Sie IaC

Wählen Sie nach Möglichkeit eher eine idempotente deklarative Methode als einen imperativen Ansatz aus. Anstatt eine Sequenz von Befehlen zu schreiben, die Konfigurationsoptionen angeben, verwenden Sie eine deklarative Syntax, die die Ressourcen und ihre Eigenschaften beschreibt. Die Referenzimplementierung verwendet Bicep, aber Sie können stattdessen Terraform- oder Azure Resource Manager-Vorlagen (ARM-Vorlagen) verwenden.

Stellen Sie sicher, dass Sie Ressourcen gemäß den geltenden Richtlinien einrichten. Wenn Sie beispielsweise VM-Größen auswählen, halten Sie die Kosteneinschränkungen und Optionen für Verfügbarkeitszonen ein, um den Anforderungen Ihrer Anwendung gerecht zu werden. Sie können auch Azure Policy verwenden, um die Richtlinien Ihrer Organisation für diese Entscheidungen zu erzwingen.

Wenn Sie eine Sequenz von Befehlen schreiben müssen, verwenden Sie die Azure CLI. Diese Befehle decken eine Reihe von Azure-Diensten ab, und Sie können sie durch Skripting automatisieren. Windows und Linux unterstützen die Azure CLI. Eine weitere plattformübergreifende Option ist Azure PowerShell. Ihre Wahl hängt von Ihren bevorzugten Fähigkeiten ab.

Speichern Sie Ihre Skripte und Vorlagendateien in Ihrem Quellcode-Verwaltungssystem, und verwalten Sie dort die Versionen.

CI/CD für Workloads

Pipelines für Workflow und Bereitstellung müssen in der Lage sein, Anwendungen kontinuierlich zu erstellen und bereitzustellen. Updates müssen sicher und schnell bereitgestellt und bei Problemen rückgängig gemacht werden können.

Ihre Bereitstellungsstrategie muss eine zuverlässige und automatisierte Continuous Delivery-Pipeline aufweisen. Stellen Sie Änderungen an Ihren Workload-Container-Images automatisch im Cluster bereit.

In dieser Architektur verwaltet GitHub Actions den Workflow und die Bereitstellung. Weitere beliebte Optionen sind Azure DevOps Services und Jenkins.

Cluster-System CI/CD

Das Diagramm zeigt den CI/CD-Workflow von links nach rechts. Links stellt ein Symbol "Infrastruktur als Code" die deklarative Konfiguration dar, die in der Quellcodeverwaltung gespeichert ist. Ein horizontaler Pfeil mit der Bezeichnung "Deploy" zeigt von "Infrastructure as Code" zu einer zentralen Box mit der Bezeichnung "GitOps". Dieses Feld enthält Azure Pipelines, GitHub Actions und Jenkins Pipelines. Im Feld GitOps zeigt ein Pfeil mit der Bezeichnung "Synchronisieren" auf ein AKS-Symbol.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Anstatt einen imperativen Ansatz wie Kubectl zu verwenden, verwenden Sie Tools, die Cluster- und Repositoryänderungen automatisch synchronisieren. Um den Workflow zu verwalten, z. B. die Veröffentlichung einer neuen Version und Validierung für diese Version vor der Bereitstellung in der Produktion, sollten Sie einen GitOps-Fluss in Betracht ziehen.

Ein wesentlicher Bestandteil des CI/CD-Flows ist das Bootstrapping eines neu bereitgestellten Clusters. Ein GitOps-Ansatz ist nützlich, da er es den Betreibern ermöglicht, den Bootstrapping-Prozess deklarativ als Teil der IaC-Strategie zu definieren und die Konfiguration automatisch im Cluster anzuwenden.

Wenn Sie GitOps verwenden, wird ein Agent im Cluster bereitgestellt, der den Status des Clusters mit der Konfiguration koordiniert, die in Ihrem privaten Git-Repository gespeichert ist. Ein solcher Agent ist Flux, der einen oder mehrere Operatoren im Cluster verwendet, um Bereitstellungen in Kubernetes auszulösen. Flux führt die folgenden Aufgaben aus:

• Überwacht alle konfigurierten Repositorys
• Erkennt neue Konfigurationsänderungen
• Löst Bereitstellungen aus
• Aktualisiert die gewünschte ausgeführte Konfiguration basierend auf diesen Änderungen.

Sie können auch Richtlinien festlegen, die die Bereitstellung der Änderungen steuern.

Das folgende Beispieldiagramm zeigt, wie Sie die Clusterkonfiguration mit GitOps und Flux automatisieren.

Das Diagramm veranschaulicht den GitOps-Workflow mit vier nummerierten Schritten von links nach rechts. Ganz links wird ein Entwicklersymbol mit einem Laptop als Schritt 1 angezeigt, in dem der Benutzer IaC-Änderungen an ein Git-Repository verschiebt. Schritt 2 zeigt das Git-Repository an, das über einen Pfeil mit der Bezeichnung Git Clone --mirror zu einem Flux-Symbol innerhalb der AKS-Clustergrenze verbunden wird. Schritt 3 zeigt einen Pfeil mit der Bezeichnung "kubectl apply", der vom Flux-Icon auf das Kubernetes-API-Serversymbol innerhalb des Clusters verweist. Schritt 4 zeigt einen roten Kreis mit einer diagonalen Linie zwischen dem Entwickler und dem Kubernetes-API-Server mit einer überkreuzten Kubectl-Bezeichnung an.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Ein Entwickler überträgt Änderungen am Quellcode, wie Konfigurations-YAML-Dateien, die in einem Git-Repository gespeichert sind. Die Änderungen werden dann auf einen Git-Server gepusht.

2. Flux wird zusammen mit der Workload in einem Pod ausgeführt. Flux hat schreibgeschützten Zugriff auf das Git-Repository, um sicherzustellen, dass Flux nur die Änderungen anwendet, die von Entwicklern angefordert werden.

3. Flux erkennt Änderungen an der Konfiguration und wendet diese Änderungen mithilfe von kubectl-Befehlen an.

4. Entwickler haben keine direkten access über Kubectl an die Kubernetes-API.

Sie können Verzweigungsrichtlinien auf Ihrem Git-Server haben, damit mehrere Entwickler Änderungen über eine Pullanforderung genehmigen können, bevor die Änderung auf die Produktion angewendet wird.

Während Sie GitOps und Flux manuell konfigurieren können, empfehlen wir die GitOps mit Flux v2 Cluster-Erweiterung für AKS.

Bereitstellungsstrategien für Workloads und Cluster

Stellen Sie alle Änderungen, z. B. Architekturkomponenten, Workload und Clusterkonfiguration, auf mindestens einem AKS-Cluster vor der Produktion bereit. Dieser Prozess simuliert die Änderung und kann Probleme identifizieren, bevor sie in der Produktion bereitgestellt werden.

Führen Sie Tests und Überprüfungen in jeder Phase aus, bevor Sie mit der nächsten Phase fortfahren. Dadurch wird sichergestellt, dass Sie Aktualisierungen streng kontrolliert in die Produktionsumgebung übertragen und Störungen durch unerwartete Bereitstellungsprobleme minimieren können. Die Bereitstellung sollte einem ähnlichen Muster folgen wie die Produktion, indem die gleichen GitHub Actions Pipeline- oder Flux-Operatoren verwendet werden.

Erweiterte Bereitstellungstechniken, wie blaugrüne Bereitstellung, A/B-Tests und Canary-Releases, erfordern zusätzliche Prozesse und potenziell zusätzliches Werkzeug. Flagger ist eine beliebte Open-Source-Lösung zur Lösung erweiterter Bereitstellungsszenarien.

Kostenmanagement

Überprüfen Sie zunächst die Prüfliste für die Kostenoptimierung und die Liste der Empfehlungen, die in Well-Architected Framework für AKS beschrieben sind. Allgemeine Workloadempfehlungen finden Sie in der Prüfliste Entwurfsüberprüfung für Kostenoptimierung.

Sie finden eine Kostenschätzung für die In dieser Basisarchitektur verwendeten Komponenten im Azure Preisrechner. Ändern Sie Ihre Schätzung so, dass sie die für Ihren Anwendungsfall erforderlichen Komponenten enthält. Diese Schätzung umfasst Ressourcen auf Speichenebene, die direkt mit dem Cluster verknüpft sind. Die gemeinsam genutzte Hubinfrastruktur, z. B. Azure Firewall, Hub-VNETs und Azure Privates DNS-Zonen, ist nicht enthalten, da diese Ressourcen in der Regel einem zentralen Plattformteam gehören und von ihm verwaltet werden.

Erwägen Sie die Verwendung von AKS-Kostenanalyse für die granulare Kostenzuordnung der Clusterinfrastruktur durch Kubernetes-spezifische Konstrukte.

Provision

• Verstehen Sie, woher Ihre Kosten kommen. Für die Bereitstellung und Verwaltung von AKS sowie den Betrieb des Kubernetes-Clusters selbst fallen nur minimale Kosten an. Was sich auf die Kosten auswirkt, sind die VM-Instanzen, storage, Protokolldaten und Netzwerkressourcen, die vom Cluster verbraucht werden. Wählen Sie für Systemknotenpools eventuell günstigere VMs aus. Die Serie Ddv5 ist ein typischer VM-Typ für den Systemknotenpool, und die Referenzimplementierung verwendet die Standard_D2d_v5-SKU.

• Verwenden Sie nicht dieselbe Konfiguration für Entwicklungs-/Test- und Produktionsumgebungen. Produktionsworkloads weisen zusätzliche Anforderungen für Hochverfügbarkeit auf und sind in der Regel teurer. Diese Konfiguration ist in der Dev/Test-Umgebung nicht erforderlich.

• Fügen Sie für Produktionsworkloads eine Betriebszeit-SLA hinzu. Bei Clustern für Dev/Test- oder experimentelle Workloads, bei denen keine Verfügbarkeit garantiert werden muss, sind Einsparungen möglich. Beispielsweise könnte Ihr SLO ausreichend sein. Wenn Ihre Workload dies unterstützt, sollten Sie auch dedizierte Spotknotenpools verwenden, die spot VMs ausführen.

  Bei Nichtproduktionsworkloads, die Azure SQL-Datenbank oder Azure App Service als Teil der AKS-Workloadarchitektur enthalten, bewerten Sie, ob Sie berechtigt sind, Azure Dev/Test-Abonnements zu verwenden und Servicerabatte zu erhalten.

• Stellen Sie einen Cluster mit der Mindestanzahl an Knoten bereit und aktivieren Sie die automatische Cluster-Skalierung, um die Überwachung und Größenentscheidungen zu ermöglichen, anstatt mit einem überdimensionierten Cluster zu beginnen, um die Skalierungsanforderungen zu erfüllen.

• Legen Sie Podanforderungen und Grenzwerte fest, damit Kubernetes Knotenressourcen mit höherer Dichte zuordnen kann, damit Sie die volle Kapazität der Knoten verwenden.

• Bedenken Sie, dass die Kosten erhöht werden können, wenn Sie die Diagnose auf dem Cluster aktivieren.

• Entscheiden Sie sich für ein oder drei Jahre Azure Reserved Virtual Machine Instances, um die Knotenkosten zu senken, wenn Ihre Workload über einen langen Zeitraum bestehen muss. Weitere Informationen finden Sie unter Kosten sparen mit Azure Reserved Virtual Machine Instanzen.

• Verwenden Sie beim Erstellen von Knotenpools Tags. Tags helfen beim Erstellen von benutzerdefinierten Berichten, um entstandene Kosten nachzuverfolgen. Mithilfe von Tags können Sie die Gesamtausgaben verfolgen und alle Kosten einer bestimmten Ressource oder einem bestimmten Team zuordnen. Wenn der Cluster von mehreren Teams gemeinsam genutzt wird, erstellen Sie Chargeback-Berichte für jeden Nutzer, um die gemessenen Kosten für gemeinsam genutzte Cloud-Dienste zu ermitteln. Weitere Informationen finden Sie unter Angeben von Taint, Bezeichnung oder Tag für einen Knotenpool.

• Rechnen Sie mit zusätzlichen Bandbreitenkosten, wenn Ihre Workload mehrere Regionen umfasst und Sie Daten zwischen Regionen replizieren. Weitere Informationen finden Sie unter Bandwidth pricing.

• Erstellen Sie Budgets, um die von Ihrem Unternehmen festgelegten Kostenbeschränkungen einzuhalten. Sie können Budgets über Microsoft Cost Management erstellen. Sie können auch Benachrichtigungen erstellen, um Benachrichtigungen zu erhalten, wenn bestimmte Schwellenwerte überschritten werden. Weitere Informationen finden Sie unter Erstellen eines Budgets mit einer Vorlage.

Monitor

Sie können den gesamten Cluster und die Kosten für die Berechnung, Speicher, Bandbreite, Protokolldaten und die Firewall überwachen. Azure bietet die folgenden Optionen zum Überwachen und Analysieren von Kosten:

• Azure Advisor
• Kostenmanagement

Überwachen Sie Ihre Kosten in Echtzeit oder in einem regelmäßigen Zeitplan, damit Sie vor Dem Monatsende Maßnahmen ergreifen können, wenn die Kosten bereits berechnet werden. Überwachen Sie die monatlichen Trends im Laufe der Zeit, um innerhalb des Budgets zu bleiben.

Um datengestützte Entscheidungen zu treffen, bestimmen Sie, welche Ressource auf granularer Ebene die meisten Kosten verursacht. Außerdem sollten Sie die Verbrauchseinheiten verstehen, die die Ressourcennutzung berechnen. Durch die Analyse von Metriken können Sie beispielsweise feststellen, ob die Plattform überdimensioniert ist. Sie können die Nutzungszähler in Azure Monitor Metriken sehen.

Optimize

Folgen Sie den Empfehlungen von Azure Advisor. Erkunden Sie weitere Möglichkeiten zur Optimierung:

• Aktivieren Sie die Autoskalierung für den Cluster, um wenig ausgelastete Knoten im Knotenpool zu erkennen und zu entfernen.

  Important

  Schnelle oder häufige Änderungen an den Einstellungen für die Automatische Skalierung von Clustern, z. B. die Mindest- und maximaler Knotenanzahl für einen Knotenpool, um die Kosten zu steuern, kann zu unbeabsichtigten oder kontraproduktiven Ergebnissen führen. Beispielsweise wird scale-down-unneeded-time auf 10 Minuten eingestellt, und die Mindest- und Höchsteinstellungen der Knoten werden alle 5 Minuten basierend auf den Merkmalen der Arbeitslast geändert, wodurch sich die Anzahl der Knoten niemals verringert. Der Grund dafür ist, dass die Berechnung der nicht benötigten Zeit für jeden Knoten zurückgesetzt wird, wenn die Einstellungen für die Automatische Skalierung des Clusters aktualisiert werden.

• Wählen Sie eine niedrigere SKU für die Knotenpools aus, wenn die Workload dies unterstützt.

• Wenn die Anwendung keine Burst-Skalierung erfordert, sollten Sie eine Anpassung der Clustergröße in Betracht ziehen, indem Sie die Leistungsmetriken im Zeitverlauf analysieren.

• Wenn Ihre Workload dies unterstützt, skalieren Sie Ihre Benutzerknotenpools auf null Knoten, wenn nicht erwartet wird, dass sie ausgeführt werden. Wenn in Ihrem Cluster keine Workloads ausgeführt werden müssen, sollten Sie die AKS-Start-/Stopp-Funktion verwenden, um alle Berechnungen zu beenden, die Ihren Systemknotenpool und die AKS-Steuerungsebene umfassen.

Weitere Informationen finden Sie unter AKS-Preise.

Nächste Schritte

• AKS-Roadmap zu GitHub

Verwandte Ressourcen

• Erweiterte AKS-Microservicearchitektur
• Microservices-Architektur auf AKS
• Use Azure Firewall, um einen AKS-Cluster zu schützen
• GitOps für AKS
• Datenstreaming mithilfe von AKS

Dieser Artikel enthält eine empfohlene Basisinfrastrukturarchitektur zum Bereitstellen eines Azure Kubernetes Service (AKS) Clusters. Es folgt unseren Designprinzipien und richtet sich an die bewährten Methoden von AKS architectural aus dem Azure Well-Architected Framework. Der Artikel dient verschiedenen interdisziplinären Teams – wie beispielsweise Netzwerk-, Sicherheits- und Identitätsteams – als Anleitung bei der Bereitstellung dieser universell einsetzbaren Infrastruktur.

Diese Architektur konzentriert sich nicht auf eine Workload. Sie konzentriert sich auf den AKS-Cluster selbst. Bei den hier genannten Informationen handelt es sich um die empfohlene Mindestbaseline für die meisten AKS-Cluster. Es ist in Azure Dienste integriert, die Observability liefern, eine Netzwerktopologie bereitstellen, die multiregionales Wachstum unterstützt und sicheren In-Cluster-Datenverkehr unterstützt.

Ihre Geschäftlichen Anforderungen beeinflussen die Zielarchitektur und können zwischen Anwendungskontexten variieren. Betrachten Sie die Architektur als Ausgangspunkt für die Vorproduktions- und Produktionsphasen.

Tip

In diesem Artikel werden ausführliche Entwurfsüberlegungen für AKS-Cluster behandelt. AKS Automatic implementiert viele Entwurfsentscheidungen, um die Anzahl der Überlegungen zu reduzieren, die Sie bewerten und optimieren müssen, um häufig verwendete Anwendungsfälle zu optimieren. AKS Automatic stellt z. B. einen verwalteten Systemknotenpool bereit und betreibt den Systemknotenpool, sodass die Größen-, Isolations- und Upgradeentscheidungen in diesem Artikel nicht für diese Plattform gelten.

Selbst wenn Ihre Workload in einer automatischen AKS-Umgebung gehostet wird, können Sie die Grundlagen für einen selbstverwalteten AKS-Cluster kennen, um die richtigen Entscheidungen zu treffen, wenn sich Ihre Workload ändert.

Kubernetes ist ein breites Ökosystem, das sich über Azure und Microsoft Technologien erstreckt. Wenn Sie einen AKS-Cluster bereitstellen, sind Sie für viele Entscheidungen zum Entwerfen und Betreiben des Clusters verantwortlich. Der Betrieb eines AKS-Clusters umfasst Closed-Source-Komponenten verschiedener Anbieter, darunter Microsoft, sowie Open-Source-Komponenten aus dem Kubernetes-Ökosystem. Die Landschaft ändert sich häufig, also revidieren Sie regelmäßig Entscheidungen. Wenn Sie Kubernetes einführen, erkennen Sie an, dass Ihre Arbeitsauslastung seine Funktionen benötigt und dass Ihr Workload-Team auf laufender Basis investieren kann.

Sie können eine Implementierung dieser Architektur auf GitHub: AKS-Basisreferenzimplementierung als alternativer Ausgangspunkt verwenden und so konfigurieren, dass sie Ihren Anforderungen entspricht.

Note

Die Referenzarchitektur erfordert Kenntnisse über Kubernetes und die entsprechenden Konzepte. Wenn Sie eine Auffrischung benötigen, lesen Sie die Einführung in Kubernetes und Entwicklung und Bereitstellung von Anwendungen auf Kubernetes Schulungspfade.

Netzwerkkonfiguration

Netzwerktopologie
Planen der IP-Adressen
Anwendungsrouting

Clusterberechnung

Berechnung für den Basiscluster
Container-Image-Referenz
Richtlinienverwaltung

Identitätsverwaltung

Integrate Microsoft Entra ID für den Cluster
Integrieren Sie Microsoft Entra ID für die Arbeitslast

Sicherer Datenfluss

Schützen des Datenflusses im Netzwerk
Hinzufügen einer Geheimnisverwaltung

Geschäftskontinuität

Knoten- und Podskalierbarkeit
Geschäftskontinuitätsentscheidungen
Availability ZonesMehrere Regionen

Operations

Cluster- und Workload-Operationen
Überwachen und Sammeln von Protokollen und Metriken
Kostenverwaltung

Architektur

Das Diagramm zeigt zwei verbundene virtuelle Netzwerke. Das virtuelle Hubnetzwerk enthält Azure Firewall, Azure Bastion und ein Gatewaysubnetz, das mit dem lokalen Netzwerk vor Ort verbunden ist. Das Spoke-virtuelle Netzwerk enthält mehrere Subnetze, den AKS-Cluster und Knotenpools. Das Peering virtueller Netzwerke verbindet die virtuellen Hub- und Spoke-Netzwerke über eine bidirektionale Verbindung. Pfeile zeigen von Key Vault und Container Registry auf das Subnetz für Private Link-Endpunkte. Ein Pfeil zeigt vom Azure Bastion-Subnetz (Verwaltung) zum internen Load Balancer im virtuellen Spoke-Netzwerk. Ein Pfeil zeigt vom lokalen Netzwerk zum lokalen Gateway. Ein bidirektionaler Pfeil mit der Bezeichnung „Virtual Network Peering“ zeigt vom virtuellen Hub-Netzwerk zum Spoke-Netzwerk der Außenstelle. Ein Pfeil verweist vom Internet auf das Azure Application Gateway Subnetz. Ein Pfeil zeigt vom AKS-Cluster zum Abschnitt „Azure Monitor-Arbeitsbereich“, der Metriken und Managed Prometheus umfasst.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Weitere Informationen finden Sie unter Hub-Spoke-Netzwerktopologie in Azure.

Netzwerktopologie

Diese Architektur verwendet eine Hub-and-Spoke-Netzwerktopologie. Stellen Sie den Hub und die Speichen in separaten virtuellen Netzwerken bereit, die über virtual network Peering verbunden sind. Diese Topologie hat mehrere Vorteile:

• Ermöglichen einer getrennten Verwaltung Sie können Governance implementieren und das Prinzip der geringsten Privilegien (PoLP) einhalten. Es unterstützt auch das Konzept einer Azure Landezone mit einer Trennung von Aufgaben.

• Minimieren Sie die direkte Exposition von Azure-Ressourcen zum öffentlichen Internet.

• Stellen Sie regionale Hub-and-Spoke-Topologien bereit. Sie können zukünftig Hub-and-Spoke-Netzwerktopologien erweitern und die Workload-Isolation ermöglichen.

• Verwenden Sie einen web application firewall-Dienst, um den HTTP-Datenverkehrsfluss für alle Webanwendungen zu prüfen.

• Stellen Sie Unterstützung für Workloads bereit, die sich über mehrere Abonnements erstrecken.

• Die Architektur erweiterbar machen Um neue Features oder Workloads zu ermöglichen, können Sie neue Spokes hinzufügen, anstatt die Netzwerktopologie komplett neu zu entwerfen.

• Das Teilen von Ressourcen unterstützen, z. B. eine Firewall und DNS-Zonen (Domain Name System), über Netzwerke hinweg.

• Stimmen Sie diese auf die Azure-Zielzone auf Unternehmensebene ab.

Hub-Virtualnetzwerk

Der Hub virtual network ist der zentrale Punkt der Konnektivität und Observierbarkeit. In dieser Architektur enthält der Hub die folgenden Komponenten:

• Azure Firewall mit globalen Firewallrichtlinien, die Ihre zentralen IT-Teams definieren, um organisationsweite Regeln zu erzwingen

• Azure Bastion, die einen sicheren Tunnel in den privaten Netzwerkperimeter einleite, sodass Sie Clusterverwaltungsvorgänge ausführen können

• Ein Gatewaysubnetz für VPN-Konnektivität

• Azure Monitor für die Netzwerküberwachung

Innerhalb des Netzwerks verfügt die Architektur über drei Subnetze.

Subnetz zum Hosten von Azure Firewall

Azure Firewall ist ein verwalteter Firewalldienst. Die Azure Firewall Instanz sichert ausgehenden Netzwerkdatenverkehr. Ohne diese Sicherheitsebene kommuniziert der Datenverkehr möglicherweise mit einem schädlichen, nicht Microsoft Dienst, der vertrauliche Workloaddaten exfiltrieren könnte. Verwenden Sie Azure Firewall Manager, um mehrere Azure Firewall Instanzen zentral bereitzustellen und zu konfigurieren und Azure Firewall Richtlinien für dieses hub virtual network Architekturtyp zu verwalten.

Subnetz zum Hosten eines Gateways

Dieses Subnetz ist ein Platzhalter für ein VPN-Gateway oder ein Azure ExpressRoute Gateway. Das Gateway bietet Konnektivität zwischen den Routern in Ihrem lokalen Netzwerk und dem virtual network.

Subnetz zum Hosten von Azure Bastion

Dieses Subnetz wird für Azure Bastion verwendet. Sie können Azure Bastion verwenden, um sicher auf Azure Ressourcen zuzugreifen, ohne die Ressourcen für das Internet verfügbar zu machen. Diese Architektur verwendet Azure Bastion, um eine sichere Verbindung mit dem API-Server des AKS-Clusters für Verwaltungsvorgänge herzustellen. Das Subnetz ist nur für Verwaltung und Vorgänge vorgesehen.

Virtuelles Spoke-Netzwerk

Das spoke-virtuelle Netzwerk enthält den AKS-Cluster und andere zugehörige Ressourcen. Der Spoke verfügt über die folgenden Subnetze.

Subnetz zum Hosten von Azure Application Gateway

Azure Application Gateway ist ein Webdatenverkehr-Lastenausgleichsmodul, das auf Layer 7 ausgeführt wird. Die Referenzimplementierung verwendet die Anwendungsgateway-SKU v2, die Azure Web Application Firewall ermöglicht. Web Application Firewall sichert eingehenden Datenverkehr von gängigen Webdatenverkehrangriffen, einschließlich Bots. Die Instanz verfügt über eine öffentliche IP-Konfiguration am Front-End, das die Benutzeranforderungen empfängt. Für das Application Gateway ist von Design her ein dediziertes Subnetz benötigt.

Subnetz für Frontend-IP-Adressen des internen Load Balancers

Dieses Subnetz stellt den IP-Adressraum für die internen Frontend-IP-Adressen des Lastenausgleichs bereit. Application Gateway sendet Datenverkehr an die zugewiesene private IP-Adresse des internen Lastenausgleichsmoduls. Der Lastenausgleich verteilt Datenverkehr an einen beliebigen Knoten im Cluster. kube-proxy auf dem empfangenden Knoten leitet das Paket an den Gateway-Proxy-Pod im System-Nodepool weiter, wodurch möglicherweise ein zusätzlicher Netzwerksprung entsteht. Der Proxy beendet TLS und leitet Anforderungen an Workload-Pods über HTTP weiter. Mithilfe eines dedizierten Subnetzes für diese Front-End-IPs können Sie NSG-Regeln anwenden, die eingehenden Datenverkehr auf das Lastenausgleichsmodul beschränken, ohne dass sich dies auf das Knotensubnetz auswirkt. Weitere Informationen finden Sie unter Verwenden eines internen Lastenausgleichs mit AKS.

Subnetz zum Hosten der Clusterknoten

Diese Architektur verwendet zwei Knotenpools, die separate Knotengruppen sind. Der Systemknotenpool beherbergt Pods, auf denen zentrale Clusterdienste ausgeführt werden, einschließlich des Gateway-Proxy, der den Datenverkehr zur Workload weiterleitet. Der Benutzerknotenpool führt Ihre Workload aus.

Subnet zum Hosten von Azure Private Link Endpunkten

Erstellen Sie Azure Private Link Verbindungen für Azure Container Registry und Azure Key Vault, damit Benutzer über einen private-Endpunkt innerhalb des virtuellen Speichennetzwerks auf diese Dienste zugreifen können. Private Endpunkte erfordern kein dediziertes Subnetz. Sie können auch private Endpunkte im Hub-virtual network platzieren. In der Baselineimplementierung werden die Endpunkte in einem dedizierten Subnetz innerhalb des virtuellen Spoke-Netzwerks bereitgestellt. Dieser Ansatz reduziert den Datenverkehr, der über die Peer-Netzwerkverbindung läuft. Sie behält die Ressourcen, die zum Cluster gehören, in demselben virtual network. Sie können auch präzise Sicherheitsregeln auf Subnetzebene anwenden, indem Sie Netzwerksicherheitsgruppen (NSGs) verwenden.

Weitere Informationen finden Sie unter Private Link Bereitstellungsoptionen.

Subnetz für den AKS-API-Server

Sie können einen AKS-Cluster so konfigurieren, dass die virtuelle Netzwerk-Integration des API-Servers verwendet wird, wodurch der API-Serverendpunkt des Clusters in ein delegiertes Subnetz in Ihrem virtuellen Netzwerk projiziert wird. Diese Konfiguration wird als privater Cluster bezeichnet, da sichergestellt wird, dass der gesamte Datenverkehr zwischen dem API-Server, Knotenpools und verbundenen Clients vollständig in Ihrem privaten Netzwerk verbleibt.

Die gesamte Kommunikation zwischen dem AKS-verwalteten Kubernetes-API-Server und Clients (sowohl clusterinterne als auch externe Clients) ist auf ein vertrauenswürdiges Netzwerk beschränkt.

Mit einem privaten Cluster können Sie NSGs und andere integrierte Netzwerksteuerelemente verwenden, um Ihre Umgebung zu schützen. Diese Konfiguration verbietet jeglichen nicht autorisierten öffentlichen Zugriff zwischen dem Internet und der Umgebung. Weitere Informationen finden Sie unter Create a private AKS cluster.

Planen Sie die IP-Adressen

Das Diagramm zeigt eine einfache AKS Hub-and-Spoke-Netzwerktopologie. Der Hub verfügt über Azure Firewall, Azure Bastion und ein Gateway. Der Spoke verfügt über Subnetze für Application Gateway, Ingress, Knoten, API-Server und private Endpunkte. Pfeile zeigen den eingehenden Datenverkehr aus dem Internet zum Application Gateway und dann zum internen Load Balancer, Gatewayproxy und den Workload-Pods. Ausgehende Pfeile führen vom Cluster zur Azure Firewall. Pfeile von privaten Endpunkten führen zu Azure-Diensten wie Container Registry und Key Vault.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Referenzarchitektur verwendet mehrere Netzwerkansätze, von denen jede einen IP-Adressraum erfordert:

• Ihr Azure virtuelles Netzwerk, das Sie für Ressourcen wie Clusterknoten, den API-Server des Clusters, private Endpunkte für Azure-Dienste und Anwendungsgateway verwenden.

• Der Cluster verwendet Azure Container Networking Interface (CNI) Overlay, das IP-Adressen an Pods von einem separaten Adressraum zu Ihrem virtuellen Azure-Netzwerk zuordnet.

Virtuelles Netzwerk-IP-Adressraum

Der Adressraum Ihres Azure virtuellen Netzwerks sollte groß genug sein, um alle Subnetze zu speichern. Berücksichtigen Sie alle Entitäten, die Datenverkehr empfangen. Kubernetes weist IP-Adressen für die Entitäten aus dem Subnetzadressraum zu. Berücksichtigen Sie die folgenden Punkte, wenn Sie die IP-Adressen Ihres Azure virtuellen Netzwerks planen:

• Upgrades: AKS aktualisiert Knoten regelmäßig, um sicherzustellen, dass die zugrunde liegenden VMs auf dem neuesten Stand in Bezug auf Sicherheitsfunktionen und andere Patches sind. Während eines Upgradevorgangs erstellt AKS einen Knoten, der die Pods temporär hostet, während der Upgradeknoten gesperrt und entladen wird. Dieser temporäre Knoten empfängt eine IP-Adresse aus dem Cluster-Subnetz. Stellen Sie sicher, dass Genügend Adressraum für die temporären Knoten-IP-Adressen vorhanden ist.

  In dieser Architektur sowie während paralleler Updates werden Pods IP-Adressen aus dem Pod-Adressraum des Azure CNI Overlay zugewiesen. Dieser Ansatz reduziert die Gesamtanzahl der IP-Adressen, die von Ihrem Azure virtuellen Netzwerk im Vergleich zu anderen Kubernetes-Netzwerkansätzen verwendet werden.

• Skalierbarkeit: Berücksichtigen Sie die Gesamtanzahl der System- und Benutzerknoten und deren maximale Skalierbarkeitsgrenzwerte. Wenn Sie z. B. um 400 % skalieren möchten, benötigen Sie die vierfache Anzahl an Adressen für alle skalierten Knoten.

  Da diese Architektur Azure CNI Overlay verwendet, wirkt sich die Skalierbarkeit Ihrer Pods nicht auf den Adressraum Ihres virtuellen Netzwerks aus.

• Private Link-Adressen: Berücksichtigen Sie die Adressen, die für die Kommunikation mit anderen Azure-Diensten über Private Link erforderlich sind. Diese Architektur weist zwei Adressen für die Links zur Containerregistrierung und Key Vault auf.

• Private-Cluster-API-Serveradressen: Die Integration des API-Servers in das virtuelle Netzwerk hilft Ihnen, den AKS-API-Server als Endpunkt in Ihrem virtuellen Netzwerk zu projektieren. Für dieses Feature ist eine minimum-Subnetzgröße erforderlich. Stellen Sie daher sicher, dass Sie diese Voraussetzungen während der Netzwerkplanung erfüllen.

• Reservierte IP-Adressen: Azure reserviert bestimmte Adressen für eigene Zwecke. Sie können nicht zugewiesen werden.

Die obige Liste ist nicht vollständig. Wenn Ihr Entwurf andere Ressourcen aufweist, die sich auf die Anzahl der verfügbaren IP-Adressen auswirken, sollten Sie diese Adressen einplanen.

Diese Architektur ist für eine einzelne Workload konzipiert. Trennen Sie in einem AKS-Produktionscluster immer den Systemknotenpool vom Benutzerknotenpool. Wenn Sie mehrere Workloads auf dem Cluster ausführen, sollten Sie die Benutzerknotenpools ggf. voneinander isolieren. Diese Isolation führt zu mehr Subnetzen, die kleiner sind. Die Gateway-Topologie kann auch wachsen, da jede Gateway-Ressource die Bereitstellung eines eigenen Gateway-Proxys und einer eigenen Frontend-IP des Lastenausgleichs bewirkt. Planen Sie den Subnetzadressraum entsprechend.

IP-Adressraum des Pods

Azure CNI Overlay weist Pods IP-Adressen mithilfe eines dedizierten Adressraums zu, der vom Adressraum getrennt ist, den Sie in Ihrem virtuellen Netzwerk verwenden. Verwenden Sie einen IP-Adressraum, der sich nicht mit Ihrem virtuellen Netzwerk oder mit virtuellen Peernetzwerken überlappt. Wenn Sie jedoch mehrere AKS-Cluster erstellen, können Sie sicher den gleichen Pod-Adressraum für jeden Cluster verwenden.

Azure CNI Overlay weist jedem Knoten einen /24-Adressraum für seine Pods zu. Es ist wichtig sicherzustellen, dass der Pod-Adressraum ausreichend groß ist. Lassen Sie so viele /24-Blöcke zu, wie Sie für die Anzahl der Knoten in Ihrem Cluster benötigen. Denken Sie daran, alle temporären Knoten einzuschließen, die während Upgrades oder Scale-Out-Vorgängen erstellt wurden. Wenn Sie z. B. einen /16-Adressraum für Ihren klassenlosen CiDR-Bereich (Inter-Domain Routing) verwenden, kann Ihr Cluster auf maximal 250 Knoten wachsen.

Jeder Knoten unterstützt bis zu 250 Pods, und dieser Grenzwert umfasst alle Pods, die temporär während Upgrades erstellt werden.

Weitere Informationen finden Sie in den Richtlinien zur IP-Adressplanung für Azure CNI Overlay.

Weitere Überlegungen zum IP-Adressraum

Die vollständige Netzwerküberlegung für diese Architektur finden Sie unter AKS-Basisnetzwerktopologie. Weitere Informationen zum Planen der IP-Adressierung für einen AKS-Cluster finden Sie unter Configure Azure CNI-Netzwerk in AKS.

Add-Ons und Previewfunktionen

Kubernetes und AKS entwickeln sich kontinuierlich weiter, mit schnelleren Veröffentlichungszyklen als Software für lokale Umgebungen. Diese Basisarchitektur hängt von bestimmten AKS-Vorschaufeatures und AKS-Add-Ons ab. Berücksichtigen Sie die folgenden Unterschiede zwischen Vorschaufeatures und Add-Ons:

• Das AKS-Team beschreibt Preview-Funktionen als veröffentlicht und in Weiterentwicklung, da viele dieser Funktionen nur wenige Monate in diesem Status verbleiben, bevor sie in die Phase der allgemeinen Verfügbarkeit (AV) übergehen.

• AKS Add-Ons und Erweiterungen bieten zusätzliche, unterstützte Funktionen. AKS verwaltet ihre Installation, Konfiguration und den Lebenszyklus.

Die Basisarchitektur umfasst nicht jede Vorschaufunktion oder Erweiterung. Stattdessen werden nur diejenigen einbezogen, die für einen allgemeinen Cluster von erheblichem Nutzen sind. Wenn diese Funktionen die Vorschauphase verlassen, wird die Basisarchitektur entsprechend überarbeitet. Es gibt einige weitere Vorschaufeatures oder AKS-Add-Ons, die Sie möglicherweise in Vorproduktionsclustern auswerten möchten. Diese Features können Ihre Sicherheit, Verwaltbarkeit oder andere Anforderungen verbessern. Bei Nicht-Microsoft-Add-Ons müssen Sie diese installieren und verwalten, einschließlich der Nachverfolgung verfügbarer Versionen und der Installation von Updates nach dem Upgrade der Kubernetes-Version eines Clusters.

Containerimageverweis

Der Cluster kann die Workload und mehrere andere Images enthalten, z. B. eine selbstverwaltete Gatewayinfrastruktur oder ein Hilfscontainer, der TLS-Zertifikate von Key Vault synchronisiert. Einige dieser Bilder befinden sich möglicherweise in öffentlichen Registern, es empfiehlt sich jedoch, sie in einer dedizierten privaten Registrierung wie Azure Container Registry zu scannen, zu überwachen und zu speichern. Berücksichtigen Sie die folgenden Punkte, wenn Sie die Bilder in Ihren Cluster ziehen:

• Authentifizieren Sie den Cluster, um das Image zu pullen.

• Wenn Sie ein öffentliches Image verwenden, importieren Sie das Image in eine Container-Registry, die mit Ihrem Dienstgüteziel (SLO) übereinstimmt. Andernfalls unterliegt das Image möglicherweise unerwarteten Verfügbarkeitsproblemen. Wenn das Image bei Bedarf nicht verfügbar ist, können Betriebsprobleme auftreten. Beachten Sie die folgenden Vorteile der Verwendung einer privaten Containerregistrierung, z. B. Azure Container Registry, anstelle einer öffentlichen Registrierung:

  • Sie können unautorisierten Zugriff auf Ihre Bilder blockieren.
  • Es liegen keine öffentlichen Abhängigkeiten vor.
  • Sie können auf Protokolle für das Abrufen von Bildern zugreifen, um Aktivitäten und Verbindungsprobleme zu überwachen.
  • Sie können von integrierter Containerüberwachung und Imagekonformität profitieren.

• Ziehen Sie Images aus autorisierten Registries. Sie können diese Einschränkung durch Azure Policy erzwingen. In dieser Referenzimplementierung ruft der Cluster nur Bilder aus der dedizierten Azure Container Registry Instanz ab, die mit dem Cluster bereitgestellt wird.

Konfigurieren Sie die Rechenressourcen für den Basiscluster

In AKS ist jeder Knotenpool in der Regel einem Virtual Machine Scale Set zugeordnet. Knoten sind Virtuelle Maschinen (VMs) in jedem Knotenpool.

Verwenden Sie ggf. eine geringere VM-Größe für den Systemknotenpool, um die Kosten zu minimieren. Diese Referenzimplementierung stellt den Systemknotenpool mit drei D2dv5-Knoten bereit. Diese Größe reicht aus, um die erwartete Last der Systempods zu erfüllen. Der kurzlebige Datenträger des Betriebssystems beträgt 64 GB.

Berücksichtigen Sie beim Planen der Kapazität für einen Benutzerknotenpool die folgenden Empfehlungen:

• Wählen Sie größere Knoten aus, um die maximale Anzahl der auf einem Knoten festgelegten Pods zu unterstützen. Große Knoten minimieren den Fußabdruck von Diensten, die auf allen Knoten ausgeführt werden, z. B. Überwachung und Protokollierung.

• Wählen Sie den entsprechenden VM-Typ aus, wenn Sie spezielle Workload-Anforderungen haben. Möglicherweise benötigen Sie z. B. ein speicheroptimiertes Produkt für einige Workloads oder ein GPU-beschleunigtes Produkt für andere Workloads. Weitere Informationen finden Sie unter Sizes for VMs in Azure.

• Stellen Sie mindestens zwei Knoten bereit, damit die Workload einem Hochverfügbarkeitsmuster mit zwei Replikaten folgen kann. Mit AKS können Sie die Knotenanzahl ändern, ohne den Cluster neu zu erstellen.

• Planen Sie die tatsächlichen Knotengrößen für Ihre Workload basierend auf den Anforderungen, die Ihr Designteam bestimmt. Basierend auf den geschäftlichen Anforderungen verwendet diese Architektur die D4dv5-SKU für die Produktionsworkloads.

• Gehen Sie bei der Kapazitätsplanung für Ihren Cluster davon aus, dass Ihre Workload bis zu 80 % jedes Knotens beansprucht. Die verbleibenden 20 % sind für AKS-Dienste reserviert.

• Legen Sie die maximale Anzahl an Pods für jeden Knoten auf der Grundlage Ihrer Kapazitätsplanung fest. Wenn Sie versuchen, eine Kapazitätsbasislinie festzulegen, beginnen Sie mit dem Wert 30. Passen Sie diesen Wert basierend auf den Anforderungen der Workload, der Knotengröße und den Einschränkungen ihrer IP-Adresse an.

Auswählen eines Betriebssystems

Die meisten AKS-Cluster verwenden für ihre Knotenpools Linux als Betriebssystem. In dieser Referenzimplementierung verwenden wir Azure Linux, eine leicht gehärtete Linux-Verteilung, die für Azure optimiert ist. Sie können eine andere Linux-Verteilung wie Ubuntu auswählen, wenn Sie es bevorzugen oder wenn Azure Linux Ihre Anforderungen nicht erfüllt. Wenn Sie ein anderes Betriebssystem auswählen, stellen Sie sicher, dass der Betriebssystemdatenträger für dieses Image entsprechend angepasst ist. Einige Verteilungen benötigen mehr Speicherplatz als Azure Linux. Möglicherweise müssen Sie die Datenträgergröße erhöhen, um Bereitstellungs- oder Laufzeitprobleme zu vermeiden.

Wenn Ihre Workload aus gemischten Technologien besteht, können Sie verschiedene Betriebssysteme in verschiedenen Knotenpools verwenden. Wenn Sie jedoch keine anderen Betriebssysteme benötigen, empfiehlt es sich, ein einzelnes Betriebssystem für alle Workloadknotenpools zu verwenden, um die Betriebskomplexität zu verringern.

Integrieren von Microsoft Entra ID für den Cluster

Die Sicherung des Zugriffs auf und vom Cluster ist von entscheidender Bedeutung. Verwenden Sie die Perspektive des Clusters, um den Unterschied zwischen eingehendem und ausgehendem Datenverkehr nachzuvollziehen.

• Inside-Out-Zugriff: Berücksichtigen Sie den AKS-Zugriff auf Azure-Komponenten wie die Netzwerkinfrastruktur, die Container Registry und Key Vault. Autorisieren Sie nur die Ressourcen, auf die der Cluster zugreifen darf.

• Outside-In-Zugriff: Gewähren Sie Identitäten Zugriff auf den Kubernetes-Cluster. Autorisieren Sie nur die externen Entitäten, die Zugriff auf den Kubernetes-API-Server und Azure Resource Manager haben.

AKS-Zugriff auf Azure Komponenten

Es gibt zwei Möglichkeiten, den Zugang von AKS zu Azure über Microsoft Entra ID zu verwalten: Dienstprinzipale oder verwaltete Identitäten für Azure-Ressourcen.

Von den beiden Methoden zum Verwalten des AKS-Zugriffs auf Azure empfehlen wir verwaltete Identitäten. Bei Dienstprinzipalen müssen Sie Geheimnisse entweder manuell oder programmgesteuert verwalten und rotieren. Mit verwalteten Identitäten verwaltet Microsoft Entra ID die Authentifizierung und die rechtzeitige Rotation der Geheimnisse für Sie.

Es wird empfohlen, managed-Identitäten in AKS zu aktivieren und zu verwenden, damit der Cluster über Microsoft Entra ID mit externen Azure Ressourcen interagieren kann. Wenn Sie Microsoft Entra ID Integration nicht sofort verwenden, können Sie sie später hinzufügen.

Standardmäßig verwendet der Cluster zwei primäre Identitäten: die Clusteridentität und die Kubelet-Identität. Die AKS-Steuerungsebenenkomponenten verwenden die Clusteridentität zum Verwalten von Clusterressourcen , einschließlich Eingangslastenausgleichsmodulen und von AKS verwalteten öffentlichen IP-Adressen. Die Kubelet-Identität authentifiziert sich bei der Containerregistrierung. Einige Add-Ons unterstützen auch die Authentifizierung mithilfe einer verwalteten Identität.

Sie sollten verwaltete Identitäten verwenden, wenn der Cluster Images aus einer Containerregistrierung pullen muss. Für diesen Vorgang muss der Cluster die Anmeldeinformationen für die Registrierung abrufen. Dies erreichen Sie, indem Sie der vom Kubelet verwalteten Identität des Clusters AcrPull-Zugriff auf Ihre Registrierung gewähren. Wenn Sie keine verwaltete Identität verwenden, speichern Sie diese Informationen möglicherweise in einem Kubernetes-Geheimnis und verwenden imagePullSecrets sie zum Abrufen. Wir empfehlen diesen Ansatz nicht, da es Sicherheitskomplexe einführt, einschließlich der Notwendigkeit, den geheimen Schlüssel im Voraus zu kennen und in der DevOps-Pipeline zu speichern. Zudem entsteht dadurch ein operativer Mehraufwand, da Sie das Secret regelmäßig aktualisieren müssen.

In dieser Architektur greift der Cluster auf Azure-Ressourcen zu, die von Microsoft Entra ID gesichert werden, und führt Vorgänge aus, die verwaltete Identitäten unterstützen. Weisen Sie Azure rollenbasierte Zugriffssteuerung (Azure RBAC) und Berechtigungen den verwalteten Identitäten des Clusters zu, abhängig von den Vorgängen, die der Cluster ausführt. Der Cluster authentifiziert sich bei Microsoft Entra ID und erhält dann basierend auf seinen zugewiesenen Rollen entweder Zugriff oder wird abgelehnt. Hier sind einige Beispiele aus dieser Referenzimplementierung, in denen Azure-integrierte Rollen dem Cluster zugewiesen werden:

• Die Rolle „Network Contributor“ verwaltet die Fähigkeit des Clusters, das virtuelle Spoke-Netzwerk zu steuern. Mit dieser Rollenzuweisung kann die dem AKS-Cluster systemseitig zugewiesene Identität mit dem dedizierten Subnetz für den internen Load Balancer verwendet werden, der dem Gatewayproxy und dem privaten AKS-API-Server vorgeschaltet ist.

• Die Rolle Privates DNS Zone Contributor verwaltet die Fähigkeit des Clusters, die Zone direkt mit dem virtuellen Speichennetzwerk zu verknüpfen, in dem der Cluster gehostet wird. Ein privater Cluster hält DNS-Einträge vom öffentlichen Internet fern, indem er eine private DNS-Zone verwendet. Es ist jedoch weiterhin möglich, einen privaten AKS-Cluster mit einer öffentlichen DNS-Adresse zu erstellen. Es wird empfohlen, dieses Feature explizit zu verbieten, indem Sie enablePrivateClusterPublicFQDN auf false festlegen, um die Offenlegung der privaten IP-Adresse Ihrer Steuerebene zu verhindern. Erwägen Sie die Verwendung von Azure Policy, um die Verwendung privater Cluster ohne öffentliche DNS-Einträge zu erzwingen.

• Die Monitoring Metrics Publisher-Rolle verwaltet die Übertragungsfähigkeit des Clusters von Metriken an Azure Monitor.

• Die Rolle AcrPull verwaltet die Fähigkeit des Clusters, Bilder aus den angegebenen Containerregistrierungsinstanzen abzurufen.

Zwei AKS-Add-Ons stellen zusätzliche verwaltete Identitäten bereit, die Rollenzuweisungen erfordern. Die Identität des Add-ons „Secrets Store CSI Driver“ ruft TLS-Zertifikate aus Key Vault ab. Die Identität des Add-Ons für Anwendungsrouting verwaltet DNS-Einträge und den Gateway-Abgleich.

Gewähren Sie diesen Identitäten Zugriff auf die Ressourcen, mit der sie interagieren:

• Die verwaltete Identität des Secrets Store CSI Driver-Add-Ons benötigt auf Ihrem Key Vault die Rolle Key Vault Certificate User, damit der Treiber TLS-Zertifikate abrufen kann.

• Die verwaltete Identität des Add-Ons für Anwendungsrouting benötigt für Ihren Key Vault die Rollen Key Vault Secrets User und Key Vault Reader sowie für die private DNS-Zone des Ingress die Rolle Privates DNS Zone Contributor, damit der Controller DNS-Einträge verwalten kann, wenn er Gateway-Ressourcen abgleicht.

Note

Alternativ können Sie die verwaltete Identität des CSI-Treiber-Add-ons für den Zugriff auf Key Vault durch Microsoft Entra Workload Identity ersetzen. Mithilfe der Workload-Identität binden Sie eine vom Benutzer zugewiesene verwaltete Identität mithilfe von Verbundanmeldeinformationen an ein Kubernetes ServiceAccount, und verweisen sie in den TLS-Optionen des Gatewaylisteners darauf. Das Anwendungsrouting-Add-On erstellt dann automatisch die SecretProviderClass.

Üblicherweise wählen Sie entweder die verwaltete Identität des Add-Ons oder die Workload-Identität für den Key-Vault-Zugriff über den CSI-Treiber aus. Workload Identity bietet namespaceweite Identitätsisolation und reduziert die manuelle Ressourcenverwaltung zu kosten einer zusätzlichen Identitätshärtung durch Verbundanmeldeinformationen. Weitere Informationen finden Sie unter Konfigurieren von Azure DNS und TLS mit der Gateway-API-Implementierung für Anwendungsrouting.

Clusterzugriff

Microsoft Entra Einbindung vereinfacht auch die Sicherheit für externen Zugriff. Beispielsweise möchten Sie möglicherweise kubectl verwenden. Als Erstes können Sie den Befehl az aks get-credentials ausführen, um die Anmeldeinformationen des Clusters abzurufen. Microsoft Entra ID authentifiziert Ihre Identität gegenüber den Azure-Rollen, die berechtigt sind, Clusteranmeldeinformationen abzurufen. Weitere Informationen finden Sie unter Verfügbare Clusterrollen-Berechtigungen.

AKS unterstützt den Kubernetes-Zugriff über Microsoft Entra ID, indem Microsoft Entra ID als Identitätsanbieter verwendet werden, der mit systemeigenem Kubernetes RBAC integriert ist, oder indem systemeigene Azure RBAC zum Steuern des Clusterzugriffs verwendet wird. In den folgenden Abschnitten werden beide Ansätze beschrieben.

Zuordnen von Kubernetes RBAC zu Microsoft Entra ID

Kubernetes unterstützt RBAC über die folgenden API-Objekte:

• Eine Gruppe von Berechtigungen, die Sie mithilfe eines Role- oder ClusterRole-Objekts für clusterweite Berechtigungen definieren.

• Bindungen, die Benutzern und Gruppen Berechtigungen zuweisen, Aktionen auszuführen. Definieren Sie Bindungen mithilfe eines RoleBinding- oder ClusterRoleBinding-Objekts.

Kubernetes verfügt über einige integrierte Rollen wie Clusteradministrator, Bearbeitung und Ansicht. Binden Sie diese Rollen an Microsoft Entra Benutzer und Gruppen, um das Unternehmensverzeichnis zum Verwalten des Zugriffs zu verwenden. Weitere Informationen finden Sie unter Use Kubernetes RBAC with Microsoft Entra integration.

Achten Sie darauf, dass Sie die Microsoft Entra-Gruppen für den Cluster- und Namespacezugriff in Ihre Microsoft Entra Zugriffsüberprüfungen einschließen.

Verwenden Azure RBAC für Kubernetes-Autorisierung

Es wird empfohlen, Azure RBAC und Azure Rollenzuweisungen zu verwenden, um Autorisierungsprüfungen für den Cluster zu erzwingen. Dieser Autorisierungsansatz ist in Microsoft Entra Authentifizierung integriert. Sie können Rollen in verschiedenen Bereichen zuweisen, z. B. der Verwaltungsgruppe, des Abonnements oder der Ressourcengruppe. Alle Cluster im definierten Bereich erben dann einen konsistenten Satz von Rollenzuweisungen im Hinblick auf die Berechtigungen zum Zugriff auf die Objekte im Kubernetes-Cluster.

Es wird nicht empfohlen, Kubernetes-native RBAC mit ClusterRoleBindings und RoleBindings zu verwenden.

Weitere Informationen finden Sie unter Azure RBAC für Kubernetes-Autorisierung.

Lokale Konten

AKS unterstützt die native Kubernetes Benutzer-Authentifizierung. Wir empfehlen nicht, diese Methode zum Bereitstellen von Benutzerzugriff für Cluster zu verwenden. Diese Methode ist zertifikatbasiert und wird außerhalb Ihres primären Identitätsanbieters ausgeführt, wodurch die zentrale Benutzerzugangskontrolle und Governance erschwert wird. Verwalten Sie immer den Zugriff auf Ihren Cluster mithilfe von Microsoft Entra ID, und konfigurieren Sie Ihren Cluster so, dass der Zugriff auf lokale Konten explizit untersagt wird.

In dieser Referenzimplementierung ist der Zugriff auf lokale Clusterkonten explizit verboten, wenn das System den Cluster bereitstellt.

Integrieren Sie Microsoft Entra ID für die Arbeitslast.

Ähnlich wie bei einer Azure vom System zugewiesenen verwalteten Identität für den gesamten Cluster können Sie verwaltete Identitäten auf Podebene zuweisen. Mithilfe einer Workloadidentität kann eine gehostete Workload über Microsoft Entra ID auf Ressourcen zugreifen. Angenommen, die Arbeitsauslastung speichert Dateien in Azure Storage. Wenn auf diese Dateien zugegriffen werden muss, authentifiziert sich der Pod bei der Ressource als verwaltete Azure-Identität.

In dieser Referenzimplementierung stellt Microsoft Entra Workload ID auf AKS die verwalteten Identitäten für Pods bereit. Dieser Ansatz lässt sich in die kubernetes-nativen Funktionen integrieren, um eine Verbindung mit externen Identitätsanbietern zu erstellen. Weitere Informationen finden Sie unter Workload Identity Federation.

Auswählen eines Netzwerkmodells

AKS stellt Plug-Ins (Container Networking Interface, CNI) in zwei Netzwerkmodellen bereit: Overlay und flach. Beide Modelle unterstützen Netzwerkrichtlinien für die In-Cluster-Datenverkehrskontrolle.

Mit einem Flachnetzwerk-Plug-In, z. B. Azure CNI Pod Subnet, erhält jeder Pod eine IP-Adresse aus dem virtuellen Netzwerk-Subnetz. Ressourcen im selben Netzwerk oder gepeerten Netzwerken können direkt über ihre IP-Adresse ohne NAT (Network Address Translation) auf Pods zugreifen. Verwenden Sie ein flaches Netzwerkmodell, wenn Ihre Workloads direkte Erreichbarkeit der Pods aus dem virtuellen Netzwerk erfordern.

Diese Referenzimplementierung verwendet Azure CNI Overlay, bei dem es sich um ein Overlay-Netzwerk-Plug-In handelt. Es weist virtuelle Netzwerk-IP-Adressen nur Knoten zu und weist Pod-IPs aus einem separaten CIDR-Bereich zu. Da Azure CNI Overlay weit weniger IP-Adressen für virtuelle Netzwerke als flache Modelle verbraucht, empfehlen wir dies für die meisten Bereitstellungen.

Weitere Informationen zu den Modellen finden Sie unter AKS CNI-Netzwerkübersicht und bewährte Methoden für Netzwerkkonnektivität und Sicherheit in AKS.

Weiterleitung von Bewerbungen

Diese Architektur verwendet das Anwendungsrouting-Add-On mit der Kubernetes-Gateway-API. Das Anwendungsrouting-Add-On ist eine AKS-Clusterkonfiguration, die deklariert, dass der Cluster eine verwaltete Gatewayinfrastruktur enthalten soll. Die Gateway-API ist eine Reihe von benutzerdefinierten Kubernetes-Ressourcendefinitionen (CRDs), einschließlich GatewayClass, , Gateway, HTTPRouteund anderen. Die Kubernetes-Community hat die Gateway-API als Nachfolger der vorherigen Ingress-API entworfen. Sie bietet einen standardisierten, rollenorientierten und erweiterbaren Rahmen für das Verkehrsmanagement.

Die Komponenten werden in verschiedenen Lebenszyklusphasen bereitgestellt:

• Cluster-Design. Das Anwendungsteam entscheidet, welcher Gatewaycontroller den Eingehenden Datenverkehr verwaltet und wie der Lebenszyklus dieses Controllers verwaltet wird. Gateway-Controller bündeln in der Regel ihre Data-Plane-Proxys, sodass diese Entscheidung auch bestimmt, welcher Proxy den Verkehrspfad verarbeitet. Diese Architektur ermöglicht verwaltete Gateway-API-CRDs. Es konfiguriert das Add-On für die Verwendung von verwaltetem Istio als Gatewaycontroller, der mit Envoy als Gatewayproxy gekoppelt ist. Obwohl Sie Istio auch als Dienstgitter verwenden können, wird In dieser Architektur Istio nur als Gatewaycontroller verwendet und seine Dienstgitterfunktionen sind nicht aktiviert.

  Wenn das Team eine andere Implementierung erfordert, können sie andere Gateway-API-Controller verwenden, z. B. NGINX-Gateway-Fabric, Envoy-Gateway und Traefik. Diese Controller können eigenständig verwaltet werden, was die Pflege eigener Manifeste, Antiaffinität, Knotenplatzierung, Probes, die Festlegung des RBAC-Geltungsbereichs, Skalierungsrichtlinien, Quell-IP-Einschränkungen und die Verwaltung des Versionslebenszyklus erfordert. Im Gegenzug erhalten Sie die volle Kontrolle über das Proxy-Verhalten, die von Cluster-Upgrades unabhängige Versionsfixierung und eine uneingeschränkte Konfiguration.

• Clusterbereitstellung. In dieser Phase treten keine Entwurfsentscheidungen auf. AKS installiert die Gateway-API-CRDs, Istio-(Gateway-Controller)-Pods im Namespace aks-istio-system und die GatewayClass approuting-istio. Zu diesem Zeitpunkt gibt es keine Data-Plane-Pods für den Gateway-Proxy.

• Initialisierung des Clusters. Das Workloadteam definiert, wie der Gatewayproxy verfügbar gemacht wird (interner oder externer Lastenausgleich), welches Subnetz die Front-End-IP des Lastenausgleichs hostet und in welchem Namespace der Gatewayproxy ausgeführt wird. In dieser Architektur wird der Gateway-Proxy über einen internen Load Balancer exponiert, es gibt ein dediziertes Subnetz für IP-Adressen des Load Balancers, und der Gateway-Proxy wird im a0008Workload-Namespace bereitgestellt.

  Eine Gatewayressource, die auf die approuting-istio GatewayClass verweist, drückt diese Entscheidungen aus. Der Gateway-Controller setzt sie in Envoy-Deployments (Gateway-Proxy), einen LoadBalancer Service, einen HorizontalPodAutoscaler und einen PodDisruptionBudget in demselben Namespace wie die Gateway-Ressource um.

  Wenn eine private DNS-Zone an das Add-On angefügt ist, kann die DNS-Komponente des Add-Ons DNS-A-Einträge für Sie verwalten, wodurch die Notwendigkeit entfernt wird, statische Einträge in Ihren IaC-Vorlagen zu verwalten. Bootstrapping stellt auch die TLS-Zertifikatsynchronisierungsressourcen bereit, die in Access-Clusterschlüsseln beschrieben sind.

Note

Die integrierte DNS-Komponente, die zusammen mit dem Add-on bereitgestellt wird, gleicht DNS-Einträge nicht automatisch ab, wenn Sie Gateway-API-Ressourcen verwenden.

Um die automatische Abstimmung privater DNS-Einträge zu aktivieren, stellen Sie eine benutzerdefinierte ClusterExternalDNS- oder ExternalDNS-Ressource bereit. Die Anwendungsroutingoperatorkomponente stellt dann eine verwaltete externe DNS-Instanz bereit, die Gateway- und HTTPRoute-Ressourcen überwacht und A-Einträge in der angefügten DNS-Zone veröffentlicht. Da das Schreiben in die DNS-Zone RBAC-Berechtigungen erfordert, erfordert diese Integration Microsoft Entra Workload Identity: eine vom Benutzer zugewiesene verwaltete Identität mit DNS-Zonenmitwirkenden in der Zielzone, Verbundidentitätsanmeldeinformationen, die dem OIDC-Aussteller des Clusters vertrauen, und einem dedizierten Kubernetes ServiceAccount. Bewerten Sie die zusätzliche Identitätsinfrastruktur anhand Ihrer Sicherheits- und Betriebsanforderungen.

• Bereitstellung von Workloads. Das Anwendungsteam definiert, welche Hostnamen, Pfade und Back-Ends Datenverkehr empfangen. HTTPRoute-Ressourcen, die an das Gateway gebunden sind, geben diese Routingentscheidungen an. Der Gateway-Controller überträgt das deklarierte Routingverhalten an die Envoy-Pods.
• Fortlaufende Wartung: Das Add-On verknüpft die Version des Istio-Gatewaycontrollers mit Ihrer AKS-Clusterversion, sodass Upgrades zusammen mit Clusterupgrades erfolgen, anstatt eine unabhängige Lebenszyklusverwaltung zu erfordern. Dieses Add-On verwendet Istio ausschließlich für die Gatewayproxyverwaltung. Es aktiviert weder die Sidecar-Injektion noch das vollständige Istio-Service-Mesh, das ein separates Add-on ist.

Note

Wählen Sie die Self-Management-Option aus, wenn Ihre Workload Funktionen erfordert, die das Add-On noch nicht unterstützt, z. B. TLSRoute für SNI-Passthrough, erweiterte Datenverkehrstransformationen über benutzerdefinierte Lua- oder Wasm-Plug-Ins oder wenn compliance ein bestimmtes Proxyprodukt vorgeschrieben. Wählen Sie auch die Option zur Selbstverwaltung, wenn Sie den Proxy unabhängig von Cluster-Upgrades versionieren müssen oder wenn Ihr Cluster bereits das Istio-Service-Mesh-Add-on verwendet, da beide nicht parallel betrieben werden können.

Anwenden von Gateway- und HTTPRoute-Ressourcen

Diese Architektur verwendet das Add-on für Anwendungsrouting mit der Kubernetes-Gateway-API zur Verwaltung des eingehenden Datenverkehrs. In diesem Abschnitt werden die zuvor beschriebenen Phasen des Cluster-Bootstrappings und der Workload-Bereitstellung behandelt. Zu diesem Zeitpunkt läuft der Gateway-Controller bereits und wartet darauf, Gateway-API-Ressourcen abzugleichen.

Die Gateway-API ist ein anbieterneutraler Standard, der TLS-Richtlinie, headerbasiertes Routing und Die Datenverkehrsteilung als systemeigene API-Felder und keine implementierungsspezifischen Anmerkungen zum Ausdruck bringt. Da Ihre Routingkonfiguration nicht von einer bestimmten Proxytechnologie abhängt, können Sie die zugrunde liegende Implementierung später ändern, ohne sie neu zu schreiben. Das Add-On für Anwendungsrouting steuert den Gateway-Controller und den Lebenszyklus des Proxys, sodass Upgrades, Sicherheitspatches, Skalierungskonfigurationen und RBAC-Bereiche nicht mehr verwaltet werden müssen.

Die Gateway-API unterteilt Ingress in zwei Aspekte, die sich unabhängig voneinander ändern:

• Die Gatewayressource deklariert die Netzwerkoberfläche: welche Ports und Protokolle verfügbar gemacht werden sollen, TLS-Zertifikate und das Subnetz für den internen Lastenausgleich. Diese Ressource ändert sich selten und wirkt sich auf alle daran angefügten Routen aus.

• Die HTTPRoute-Ressource deklariert Routinglogik: welche Hosts, Pfade und Header welchen Back-End-Diensten zugeordnet sind. Diese Ressource ändert sich bei jeder Bereitstellung und gilt für einzelne Dienste.

Diese Architektur reduziert das Risiko, dass eine Routingänderung die Netzwerkkonfiguration stört oder umgekehrt, da jede Ressource einen anderen Änderungsrhythmus und Strahlradius aufweist. Außerdem werden mehrere Abhängigkeiten entfernt: Ihre Routingkonfiguration ist nicht an eine bestimmte Proxytechnologie gebunden, die Proxyversion wird mit Ihrer AKS-Clusterversion verschoben, anstatt eine unabhängige Nachverfolgung zu erfordern, und jedes Gateway erhält eine eigene Proxybereitstellung, anstatt einen einzelnen Controller über alle Routen hinweg frei zu nutzen.

Wie zuvor in den Lebenszyklusphasen beschrieben, überführt der Gateway-Controller beim Anwenden einer Gateway-Ressource, die auf die konfigurierte GatewayClass verweist, diese in Deployment-Ressourcen für Gateway-Proxys und unterstützende Ressourcen. Sie steuern die Platzierung von Subnetzen mithilfe von Infrastruktur-Annotationen auf der Gateway-Ressource.

Dieses deklarative Modell entfernt die Notwendigkeit, Helmdiagramme, Containerimages oder Bereitstellungsmanifeste für den Proxy zu verwalten. Sie haben die Absicht über die Gateway-API-Ressourcenkonfiguration ausgedrückt, und der Gatewaycontroller konvergiert den Proxy in Richtung des gewünschten Zustands.

In der Regel stellt ein verwalteter Gateway-Controller den Gateway-Proxy mit produktionsorientierten Standardwerten bereit: Readiness- und Liveness-Prüfungen, RBAC-Berechtigungen, die Skalierung der Replikate (mindestens zwei Replikate, CPU-basierte automatische Skalierung bis auf fünf) sowie ein PodDisruptionBudget, das bei freiwilligen Unterbrechungen sicherstellt, dass mindestens ein Pod verfügbar bleibt.

Grundlegendes zur Add-On-Planungstopologie

AKS-Add-Ons platzieren verwaltete Komponenten auf Knotenpools basierend auf Planungsentscheidungen, die das Anwendungsteam nicht steuert. Bevor Sie die Größe von System- und Benutzerknotenpools anpassen, ermitteln Sie, wo jedes aktivierte Add-On seine Pods plant. Einige Add-Ons tolerieren Systemknotenpool-Taints und werden daher nur auf dem Systempool ausgeführt. Andere zielen auf Benutzerpools ab. Diese Topologie wirkt sich direkt auf die erforderliche Kapazität in jedem Pool aus.

Der verwaltete Envoy-Gateway-Proxy wird systembedingt auf dem Systemknotenpool und nicht auf dem Benutzerknotenpool ausgeführt. Dimensionieren Sie den Systempool unter Berücksichtigung des zusätzlichen Ressourcenbedarfs des Proxys. Wenn diese Standardtopologie die Anforderungen Ihrer Organisation nicht erfüllt, z. B. wenn Sie den Proxy für Benutzerpools aus Kostenisolierung, Netzwerksegmentierung oder Compliance benötigen, wechseln Sie zu einem selbstverwalteten Gatewaycontroller, bei dem Sie eigene Knotenplatzierungsentscheidungen treffen.

Auch mit einem verwalteten Gateway-Controller kann das Anwendungsteam die Pod-Antiaffinität so konfigurieren, dass Proxy-Replikate auf die Knoten verteilt werden. Sie konfigurieren diese Einstellungen über Anpassungseinstellungen für auf die Zulassungsliste gesetzte Gateways. Weitere Informationen finden Sie unter Gatewayressourcenanpassung.

Da der Gatewayproxy im Systemknotenpool ausgeführt wird und die Workload im Benutzerknotenpool ausgeführt wird, behandelt der Planer sie als unabhängige Planungsdomänen. Der Gateway-Proxy und die Workload sind Dienste, die häufig miteinander kommunizieren, da jede eingehende Anfrage durch den Proxy fließt, bevor sie die Workload erreicht. Kein integrierter Mechanismus korreliert die Zonenplatzierung zwischen Pods in verschiedenen Knotenpools. Ohne ausdrückliche Vorgaben kann der Scheduler Workload-Pods in Zonen platzieren, in denen kein Proxy-Replikat vorhanden ist, sodass der Datenverkehr die Grenze einer Verfügbarkeitszone überqueren muss, was die Latenz erhöht und Kosten für zonenübergreifende Datenübertragungen verursacht. Um diesen zonenübergreifenden Datenverkehr zu reduzieren, konfigurieren Sie für Ihre Workload bevorzugte Pod-Affinität, damit sie in derselben Zone wie die Proxy-Replikate platziert wird. Diese gemeinsame Platzierung ist die engste erreichbare, wenn der Proxy und die Workload in separaten Knotenpools ausgeführt werden, da Knotenaffinität poolübergreifend keine Wirkung hat. Beachten Sie, dass die Inter-Pod-Affinität dem Planer zusätzlichen Verarbeitungsaufwand verursacht und den Planungsprozess in großen Clustern möglicherweise verlangsamt.

Berücksichtigen Sie zusätzliche Ressourcenanforderungen in Governance-Richtlinien

AKS-Add-Ons stellen verwaltete Komponenten bereit, deren Ressourcenanforderungen von AKS definiert und gesteuert werden, nicht vom Anwendungsteam. Wenn der Cluster Containerressourcengrenzrichtlinien im Verweigerungsmodus über Azure Policy und OPA Gatekeeper erzwingt, müssen diese Richtlinien alle aktivierten Add-Ons berücksichtigen. Wenn dies nicht der Fall ist, blockiert Gatekeeper stillschweigend die Erstellung der verwalteten Pods, wodurch Plattformfunktionen wie Ingress, Secrets-Synchronisierung oder Observability beeinträchtigt werden, ohne dass ein offensichtlicher Bereitstellungsfehler angezeigt wird.

Betrachten Sie die Ressourcenprofilierung für Erweiterungen als Voraussetzung für die Erstellung von Richtlinien. Bevor Sie Container-CPU-, Arbeitsspeicher-, Volumetyp- oder Sicherheitskontexteinschränkungen definieren, inventarisieren Sie jedes aktivierte Add-On und bestimmen die Anforderungen an die Laufzeitressourcen. Verwenden Sie Lasttests oder kontrollierte Bereitstellungen in einer Vorproduktionsumgebung, um den tatsächlichen Ressourcenverbrauch unter realistischen Verkehrsbedingungen zu erfassen. Legen Sie dann Ihre Richtlinienlimits so fest, dass sowohl die Add-On-Komponenten als auch Ihre Workload-Container berücksichtigt werden. Dieser Ansatz stellt sicher, dass Ihre Governance-Guardrails den Cluster schützen, ohne die plattformverwaltete Infrastruktur zu beeinträchtigen.

Der verwaltete Envoy-Gatewayproxy erfordert beispielsweise bis zu 2 CPU-Kerne und 1 GiB Arbeitsspeicher pro Replikat. Diese Werte sind wahrscheinlich viel größer als die Anforderungen einer kleinen oder geringen Ressourcenauslastung. Legen Sie die Grenzwerte in Ihren Richtlinien so fest, dass der Gateway-Proxy zusammen mit Ihren Anwendungscontainern berücksichtigt wird. Ohne diese Anpassung werden die Gateway-Proxy-Pods von Gatekeeper abgewiesen, und die gesamte Ingress-Pipeline wird nicht erstellt.

Clusterinterne Gateway-TLS-Terminierung und HTTPS-Durchsetzung

Diese Architektur konfiguriert das Gateway mit HTTPS auf Port 443 mithilfe eines von Key Vault synchronisierten TLS-Zertifikats und einen HTTP-Listener am Port 80 für die Umleitung. Infrastrukturanmerkungen auf dem Gateway platzieren das Lastenausgleichsmodul im Eingangssubnetz und machen es intern. Eine an den HTTP-Listener gebundene HTTPRoute zur Umleitung gibt 301 Moved Permanently zurück, um alle HTTP-Anfragen auf HTTPS umzuleiten. Die HttpRoute-Anwendung bindet an den HTTPS-Listener und leitet Datenverkehr an den Workloaddienst über HTTP weiter. Da der Gatewayproxy TLS-Beendigung ausführt, ist die Kommunikation mit den Back-End-Diensten unverschlüsselt.

Schützen des Datenflusses im Netzwerk

In dieser Architektur enthält der Netzwerkfluss die folgenden Arten von Datenverkehr:

• Eingehender Datenverkehr vom Client zur Workload, die im Cluster ausgeführt wird.

• Ausgehender Datenverkehr von einem Pod oder Knoten im Cluster zu einem externen Dienst.

• Pod-zu-Pod-Datenverkehr zwischen Pods. Dieser Datenverkehr umfasst die Kommunikation zwischen dem Gatewayproxy und der Workload. Wenn Ihre Workload mehrere Anwendungen umfasst, die im Cluster bereitgestellt wurden, würde auch die Kommunikation zwischen diesen Anwendungen in diese Kategorie fallen.

• Verwaltungsdatenverkehr zwischen dem Client und dem Kubernetes-API-Server.

Das Diagramm veranschaulicht drei unterschiedliche Datenverkehrsmuster innerhalb der Architektur. Das Hubnetzwerk verfügt über Azure Firewall, Azure Bastion, ein Gateway und Azure Monitor. Das Speichennetz verfügt über den AKS-Cluster mit Application Gateway am Eingang. Grüne Pfeile zeigen eingehenden Datenverkehr vom Internet durch Application Gateway, den internen Load Balancer und den Gateway-Proxy bis zu den Workload-Pods. Orangefarbene Pfeile zeigen den Pod-zu-Pod-Datenverkehr innerhalb des Clusters an. Rote Pfeile zeigen ausgehenden Datenverkehr vom Cluster zu Azure Firewall. Pfeile von privaten Endpunkten weisen auf Container Registry und Key Vault.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Architektur verfügt über mehrere Sicherheitsebenen, um alle Arten von Datenverkehr zu schützen.

Eingehender Datenverkehrsfluss

Die Architektur akzeptiert nur mit TLS verschlüsselte Anforderungen vom Client. TLS v1.2 ist die minimal zulässige Version, die einen eingeschränkten Satz von Verschlüsselungsverfahren umfasst. Die strikte Übereinstimmung der Servernamensanzeige (Server Name Indication, SNI) ist aktiviert. End-to-End-TLS wird über Application Gateway mithilfe von zwei verschiedenen TLS-Zertifikaten eingerichtet, wie im folgenden Diagramm dargestellt.

Das Diagramm zeigt einen End-to-End-TLS-Datenverkehrsfluss von Client zu Workload. Ein Client sendet HTTPS-Datenverkehr an Application Gateway. Ein Pfeil von Key Vault zum Anwendungsgateway zeigt den Zertifikatabruf an. Application Gateway beendet TLS und verschlüsselt dann den Datenverkehr (HTTPS) erneut an den internen Load Balancer. Ein weiterer Pfeil von Key Vault zum Gateway-Proxy zeigt den Zertifikatabruf über den Secrets Store CSI-Treiber. Der interne Lastenausgleich leitet verschlüsselten Datenverkehr an den Gatewayproxy weiter, der TLS beendet. Ein letzter Pfeil zeigt HTTP-Datenverkehr vom Gateway-Proxy zu den Workload-Pods an. Jeder TLS-Endpunkt ist markiert.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Der Client sendet eine HTTPS-Anforderung an den Domänennamen: bicycle.contoso.com. Dieser Name ist einem DNS-A-Eintrag mit der öffentlichen IP-Adresse von Application Gateway zugeordnet. Dieser Datenverkehr wird verschlüsselt, um sicherzustellen, dass er zwischen dem Clientbrowser und dem Gateway nicht überprüft oder geändert werden kann.

2. Application Gateway verfügt über eine integrierte Web Application Firewall und verhandelt den TLS-Handshake für bicycle.contoso.com, sodass nur sichere Chiffren zulässig sind. Application Gateway ist ein TLS-Terminierungspunkt, was wichtig ist, da die Webanwendungs-Firewall des Application Gateways die Klartextanforderungen und -antworten prüfen muss. Key Vault speichert das TLS-Zertifikat. Der Cluster greift auf ihn mit einer vom Benutzer zugewiesenen verwalteten Identität zu, die in Application Gateway integriert wird. Weitere Informationen finden Sie unter TLS-Beendigung mit Key Vault Zertifikaten.

   Application Gateway verarbeitet Webanwendungs-Firewall-Prüfregeln und führt Routingregeln aus, die den Datenverkehr an das konfigurierte Back-End weiterleiten.

3. Wenn der Datenverkehr von Application Gateway zum Back-End wechselt, wird er erneut mit einem anderen TLS-Zertifikat verschlüsselt, bei dem es sich um einen Wildcard für *.aks-ingress.contoso.com handelt, da er an die interne load balancer weiterleitet. Durch diese erneute Verschlüsselung wird sichergestellt, dass kein ungesicherter Datenverkehr in das Clustersubnetz gelangt.

4. Der Gateway-Proxy empfängt den verschlüsselten Datenverkehr über den Load-Balancer. Der Proxy ist ein weiterer TLS-Terminierungspunkt für *.aks-ingress.contoso.com und leitet den Datenverkehr über HTTP an die Workload-Pods weiter. Das TLS-Zertifikat wird in Key Vault gespeichert und im Cluster als Kubernetes Secret synchronisiert, auf den die Gatewayressource verweist. Weitere Informationen finden Sie unter Hinzufügen einer Geheimnisverwaltung.

Sie können End-to-End-TLS-Verkehr an jedem Schritt durch den Workload-Pod implementieren. Messen Sie unbedingt die Leistung, die Latenz und eventuelle betriebliche Auswirkungen, wenn Sie sich entscheiden, den Datenverkehr zwischen Pods zu schützen. Für die meisten Single-Tenant-Cluster ist es bei korrekt konfigurierter RBAC für die Control Plane und ausgereiften Praktiken im Softwareentwicklungslebenszyklus ausreichend, den Datenverkehr bis zum Gateway-Proxy per TLS zu verschlüsseln und mit einer Web Application Firewall abzusichern. Dieser Ansatz minimiert den Aufwand bei der Workloadverwaltung und den Aufwand aufgrund einer schlechten Netzwerkleistung. Ihre Workload- und Complianceanforderungen legen fest, wo Sie TLS-Beendigung ausführen.

Ausgehender Datenverkehrsfluss

In dieser Architektur wird empfohlen, dass der gesamte ausgehende Datenverkehr aus dem Cluster über die Azure Firewall geleitet wird. Sie können auch Ihre eigene ähnliche virtuelle Netzwerk-Appliance verwenden. Es wird nicht empfohlen, andere Ausgangsoptionen wie Azure NAT Gateway oder einen HTTP-Proxy zu verwenden, da sie keine Netzwerkdatenverkehrsprüfung bereitstellen. Für eine Zero-Trust-Kontrolle und die Möglichkeit, den Datenverkehr zu überprüfen, leiten Sie den gesamten ausgehenden Datenverkehr über die Azure Firewall weiter. Implementieren Sie diese Konfiguration mit benutzerdefinierten Routen (UDRs). Der nächste Hop der Route ist die Private-IP-Adresse von Azure Firewall. Azure Firewall entscheidet, ob der Ausgehende Datenverkehr basierend auf den von Ihnen definierten Regeln oder den integrierten Regeln zur Bedrohungserkennung blockiert oder zugelassen werden soll.

Eine Alternative zu Azure Firewall ist das Verwenden der AKS HTTP-Proxy-Funktion. Der gesamte Datenverkehr, der den Cluster verlässt, wird an die IP-Adresse des HTTP-Proxys gesendet, der den Datenverkehr weiterleitet oder verwirft.

Überprüfen Sie bei beiden Methoden die erforderlichen Netzwerkregeln für ausgehenden Datenverkehr für AKS.

Note

Wenn Sie einen öffentlichen Load Balancer als öffentlichen Punkt für den eingehenden und ausgehenden Datenverkehr durch die Azure Firewall mithilfe von UDRs verwenden, könnte ein asymmetrisches Routingszenario auftreten. Diese Architektur verwendet interne Load Balancer in einem dedizierten Ingress-Subnetz hinter dem Application Gateway. Diese Designauswahl verbessert die Sicherheit und beseitigt auch asymmetrische Routingprobleme. Oder Sie können den Datenverkehr vor oder nach Application Gateway durch die Firewall weiterleiten, aber dieser Ansatz ist für die meisten Situationen nicht erforderlich, und es wird nicht empfohlen. Weitere Informationen zum asymmetrischen Routing finden Sie unter Integrate Firewall mit einem Azure Standardlastenausgleich.

Eine Ausnahme des Zero Trust-Steuerelements besteht darin, dass der Cluster mit anderen Azure Ressourcen kommunizieren muss. Beispielsweise muss der Cluster ein aktualisiertes Image aus der Containerregistrierung oder geheimen Schlüssel aus Key Vault abrufen. In diesen Szenarien wird empfohlen, Private Link zu verwenden.

Der Vorteil der Verwendung von Private Link besteht darin, dass bestimmte Subnetze den Dienst direkt erreichen und der Datenverkehr zwischen dem Cluster und den Diensten nicht über das Internet geht. Ein Nachteil ist, dass Private Link zusätzliche Konfiguration benötigt, anstatt den Zieldienst über seinen öffentlichen Endpunkt zu verwenden. Außerdem unterstützen nicht alle Azure Dienste oder Produkte Private Link. In diesen Fällen empfiehlt es sich, einen virtuellen Netzwerkdienstendpunkt im Subnetz zu aktivieren, um auf den Dienst zuzugreifen.

Verwenden Sie für die Containerregistrierung speziell dedizierte Datenendpunkte. Ohne sie werden Downloads von Image-Layern an einen *.blob.core.windows.net-Endpunkt statt an den privaten Endpunkt der Registry umgeleitet, und Ihre Egress-Firewallregeln würden eine gefährliche Blob-Speicher-Wildcard zulassen müssen. Diese Regel würde den ausgehenden Datenverkehr von Knoten zu beliebigen Azure Storage-Konten zulassen. Dedizierte Datenendpunkte ersetzen den Platzhalter durch registrierungsspezifische FQDNs (<registry>.<region>.data.azurecr.io), die über Private Link zu Ihrem privaten Endpunkt aufgelöst werden. Dadurch bleibt der Datenverkehr auf Image-Ebene auf dem privaten Pfad, und Sie können die Regeln für den ausgehenden Datenverkehr auf die Registrierung Ihres Clusters beschränken.

Wenn Private Link oder Dienstendpunkte keine Option sind, können Sie andere Dienste über ihre öffentlichen Endpunkte erreichen und den Zugriff über Azure Firewall Regeln und die in den Zieldienst integrierte Firewall steuern. Die Firewall wendet die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) auf ausgehende Datenströme an, ersetzt die Pod-IP durch eine ihrer angefügten öffentlichen IP-Adressen pro Datenstrom, und die Auswahl erfolgt nicht deterministisch. Fügen Sie den gesamten Satz von angefügten öffentlichen IPs zur IP-Zulassungsliste des Zieldiensts hinzu, oder verwenden Sie ein präfix für öffentliche IP-Adressen , um den Satz als zusammenhängenden Bereich auszudrücken.

Ein Nachteil der Verbindung mit Azure Diensten über öffentliche Endpunkte besteht darin, dass Azure Firewall dann mehr Regeln benötigt, um sicherzustellen, dass nur Datenverkehr von einem bestimmten Subnetz aus zulässig ist. Die Anzahl der angefügten öffentlichen IP-Adressen begrenzt auch den SNAT-Portpool und somit die gleichzeitige Ausgehende Verbindungsgrenze des Clusters. Planen Sie mehrere IP-Adressen auf der Azure Firewall ein, bevor die Port-Kapazität erschöpft ist. Bei Clustern, die eine große Anzahl gleichzeitiger ausgehender Verbindungen öffnen, fügen Sie ein Azure-NAT-Gateway an das AzureFirewallSubnet an, um den SNAT-Port-Pool erheblich zu erweitern und dabei den gesamten ausgehenden Datenverkehr unter der Firewall-Überprüfung zu halten.

Pod-zu-Pod-Datenverkehr

Standardmäßig kann ein Pod Datenverkehr von jedem anderen Pod im Cluster annehmen. Mit NetworkPolicy von Kubernetes wird der Netzwerkdatenverkehr zwischen Pods eingeschränkt. Wenden Sie Richtlinien sorgfältig an, oder Sie haben möglicherweise eine Situation, in der ein kritischer Netzwerkfluss blockiert wird. Nur bestimmte Kommunikationspfade nach Bedarf zulassen, wie den Datenverkehr zwischen dem Gateway-Proxy und der Workload. Da der Gateway-Proxy im selben Namespace wie die Workload ausgeführt wird, sprechen Sie ihn über das Pod-Label an und nicht über den Namespace-Selektor. Weitere Informationen finden Sie unter Network policies.

Aktivieren Sie die Netzwerkrichtlinie, wenn Sie den Cluster einrichten, da Sie ihn später nicht hinzufügen können. Es gibt einige Auswahlmöglichkeiten an Technologien, die NetworkPolicy implementieren. Wir empfehlen Azure Netzwerkrichtlinie, die Azure CNI erfordert. Zu den anderen Möglichkeiten gehört mit der Calico-Netzwerkrichtlinie eine bekannte Open-Source-Option. Verwenden Sie Calico, wenn Sie clusterweite Netzwerkrichtlinien verwalten müssen. Calico wird nicht unter standard-Azure-Support abgedeckt.

Weitere Informationen finden Sie unter Differences between Azure network policy engines.

Verwaltungsdatenverkehr

Im Rahmen der Ausführung des Clusters empfängt der Kubernetes-API-Server Anfragen von Komponenten, die Verwaltungsvorgänge im Cluster durchführen möchten, wie das Erstellen von Ressourcen zum Skalieren des Clusters. Beispiele für diese Ressourcen sind der Build-Agent-Pool in einer DevOps-Pipeline, eine Azure Bastion Instanz im Azure Bastion Subnetz und die Knotenpools selbst. Anstatt diesen Verwaltungsdatenverkehr von allen IP-Adressen zu akzeptieren, empfehlen wir, einen privaten AKS-Cluster einzurichten.

Weitere Informationen finden Sie unter Define API serverautorisierte IP-Bereiche.

Es wird empfohlen, Ihren AKS-Cluster als privaten Cluster bereitzustellen. Der gesamte Steuerebenen- und Knotenpooldatenverkehr verbleibt in Ihrem privaten Netzwerk und wird nicht für das öffentliche Internet verfügbar gemacht. Diese Referenzimplementierung richtet einen privaten Cluster mithilfe von API-Server virtual network Integration ein. In Testumgebungen kann aus Gründen der Benutzerfreundlichkeit eine Lockerung dieser Empfehlung für private Cluster in Betracht gezogen werden. Produktions-AKS-Cluster sollten jedoch stets als private Cluster bereitgestellt werden, um eine sichere Baseline für die Bereitstellung zu gewährleisten.

Privater Datenverkehr zu einem privaten AKS-Cluster kann aus dem Spoke-Virtual-Network, aus Peering-Netzwerken oder von privaten Endpunkten in entfernten Netzwerken stammen. Obwohl die AKS-Knoten natürlich im Speichen leben, benötigen Betreiber, die administrative Aufgaben ausführen, einen dedizierten Netzwerkpfad, um den AKS-API-Server privat zu erreichen. Sie können diese Konnektivität auf folgende Weise einrichten:

• Tunneling: Verwenden Sie Azure Bastion, um einen Tunnel direkt auf den API-Server des Clusters zu öffnen.
• Jump-box: Stellen Sie eine Sprungbox-VM bereit, und verwenden Sie Azure Bastion, um eine Verbindung mit dieser über SSH oder RDP herzustellen. Von dort aus sendet der Operator Anforderungen an den API-Server des Clusters über seine private IP-Adresse.

In der Referenzimplementierung verwenden wir Azure Bastion, um beim Ausführen von Clusterverwaltungsvorgängen zum AKS-API-Server zu tunneln. Im Allgemeinen ist dieser Ansatz einfacher zu verwalten, weniger kostspielig als die Bereitstellung und Verwaltung einer Jump-Box-VM und weniger komplex, um zwischen mehreren Operatoren zu koordinieren. Sie können jedoch eine Sprungbox-VM verwenden, wenn Sie über eine der folgenden Anforderungen verfügen:

• Operatoren verwenden unsichere Geräte. Eine Jump-Box-VM kann eine stärkere Sicherheitshärtung bieten, wenn Ihre Clientgeräte nicht vertrauenswürdig sind.
• Operatoren verbinden sich über instabile Netzwerke. Eine Jump-Box-VM kann eine stabilere Verbindung mit dem Cluster bereitstellen, insbesondere für lange ausgeführte oder Batchverwaltungsvorgänge.
• Operatoren verwenden erweiterte Diagnosetools. Einige Arten von Diagnosetools, z. B. die Paketerfassung, funktionieren möglicherweise nicht gut mit Tunnelingansätzen.

Hinzufügen einer Geheimnisverwaltung

Speichern Sie geheime Schlüssel in einem verwalteten Schlüsselspeicher, z. B. Key Vault. Der Vorteil besteht darin, dass ein verwalteter Schlüsselspeicher die Rotation von Geheimnissen übernimmt. Es bietet eine starke Verschlüsselung und ein Zugangsüberwachungsprotokoll. Außerdem werden Kerngeheimnisse aus der Bereitstellungspipeline herausgehalten. In dieser Architektur ist eine Key Vault Firewall aktiviert und konfiguriert, und Private Link wird verwendet, um eine Verbindung mit Azure Ressourcen herzustellen, z. B. für Key Vault für den Zugriff auf geheime Schlüssel und Zertifikate.

Key Vault ist gut in andere Azure Services integriert. Verwenden Sie die integrierte Funktion dieser Dienste, um auf Geheimnisse zuzugreifen. Weitere Informationen dazu, wie Application Gateway auf TLS-Zertifikate für den Eingangsfluss zugreift, finden Sie im Abschnitt Ingress traffic flow.

Mit dem Azure RBAC-Berechtigungsmodell für Key Vault können Sie die Workloadidentitäten der Rollenzuweisung Geheimnisbenutzer für Schlüsseltresore oder Geheimnisbenutzer für Schlüsseltresore zuweisen und auf die Geheimnisse zugreifen. Weitere Informationen finden Sie unter Access Key Vault mithilfe von Azure RBAC.

Clustergeheimnisse zugreifen

Sie müssen Workload-Identitäten verwenden, um einem Pod den Zugriff auf Geheimnisse aus einem bestimmten Speicher zu ermöglichen. Verwenden Sie zum Vereinfachen des Abrufvorgangs einen Secrets-CSI-Treiber. Wenn der Pod ein Secret benötigt, stellt der Treiber eine Verbindung mit dem angegebenen Speicher her, ruft ein Secret von einem Volume ab und hängt dieses Volume im Cluster ein. Der Pod kann das Geheimnis dann aus dem Dateisystem des Volumes abrufen.

Der CSI-Treiber verfügt über viele Anbieter zur Unterstützung verschiedener verwalteter Speicher. Diese Implementierung verwendet den Key Vault mit dem CSI-Treiber für den Geheimnisspeicher mit dem Ansatz der manuellen TLS-Konfiguration. Eine SecretProviderClass-Ressource definiert, welche Key Vault Zertifikate mit dem Cluster als Kubernetes Secrets synchronisiert werden sollen. Der CSI-Treiber erfordert mindestens einen Pod, der das entsprechende CSI-Volume einhängt, um das synchronisierte Secret zu erstellen und zu pflegen. Wenn Sie alle bereitgestellten Pods löschen, sammelt der Treiber den geheimen Schlüssel, was bedeutet, dass das Gateway sein TLS-Zertifikat verliert. Um dies zu verhindern, stellen Sie einen dedizierten, dauerhaft laufenden Pod bereit, der das CSI-Volume unabhängig vom Lebenszyklus Ihrer Workload-Pods eingehängt hält. Diese Architektur verwendet das Busybox-Containerimage, das einen einfachen Container mit einer Dummy-Aufgabe ausführt. Importieren Sie das Containerimage vor der Clustererstellung in Ihre Azure Container Registry, da Flux es während des Bootstrappings bereitstellt. Aktivieren Sie die geheime Drehung, und legen Sie ein Drehungsabrufintervall (z. B. zwei Minuten) für das CSI-Add-On fest, sodass Zertifikatverlängerungen in Key Vault automatisch verteilt werden. Die Gatewayressource verweist auf den synchronisierten TLS-Geheimschlüssel für die HTTPS-Beendigung. Weitere Informationen finden Sie unter Sichern des Ingress-Datenverkehrs mit der Gateway-API-Implementierung für Anwendungsrouting.

Wie bereits erwähnt, können Sie diese manuelle Konfiguration durch den vom Operator verwalteten TLS-Ansatz ersetzen. Mit diesem Ansatz deklarieren Sie die Key-Vault-Zertifikat-URI und ein Workload-Identity-ServiceAccount direkt am Gateway-Listener. Der Application-Routing-Operator erstellt dann das SecretProviderClass und patcht automatisch den Gateway-Zertifikatsverweis, wodurch es nicht mehr erforderlich ist, diese Ressourcen während des Cluster-Bootstrappings zu definieren, und der dedizierte TLS-Synchronisierungs-Pod entfällt. Beide Ansätze stützen sich auf den Rotationsmechanismus des CSI-Treibers, um Zertifikatserneuerungen aus Key Vault zu übernehmen.

Workloadspeicher

Die in dieser Architektur verwendete Workload ist zustandslos. Wenn Sie den Zustand speichern müssen, wird empfohlen, ihn außerhalb des Clusters beizubehalten. Richtlinien zum Status der Arbeitslast liegen außerhalb des Umfangs dieses Artikels.

Weitere Informationen finden Sie unter Storage Optionen für Anwendungen in AKS.

Richtlinienverwaltung

Eine effektive Möglichkeit zur Verwaltung eines AKS-Clusters ist das Erzwingen von Governance über Richtlinien. Kubernetes implementiert Richtlinien über den Open Policy Agent (OPA) Gatekeeper. Richtlinien für AKS über Azure Policy bereitstellen. Jede Richtlinie wird auf alle Cluster in ihrem Bereich angewendet. OPA Gatekeeper kümmert sich um die Durchsetzung von Richtlinien im Cluster und protokolliert alle Richtlinienüberprüfungen. Die Richtlinienänderungen werden nicht sofort in Ihrem Cluster widergespiegelt. Einige Verzögerungen sind zu erwarten.

Um Ihre AKS-Cluster zu verwalten, können Sie Azure Policy auf verschiedene Arten verwenden:

• Verhindern oder einschränken Sie die Bereitstellung von AKS-Clustern in einer Ressourcengruppe oder einem Abonnement. Wenden Sie Standards für Ihre Organisation an. Beispielsweise Einhalten einer Benennungskonvention oder Angeben eines Tags.

• Sichern Sie Ihren AKS-Cluster über Azure Policy für Kubernetes.

Ein gängiges Beispiel für den sinnvollen Einsatz einer Richtlinie ist die Governance und Validierung von Container-Images. Containerimages können eine Quelle von Sicherheitsrisiken sein, und einige Organisationen erfordern, dass nicht vertrauenswürdige Containerimages mithilfe eines Tools zum Scannen von Containerimages überprüft und dann genehmigt werden, bevor sie in einem Produktionscluster verwendet werden können. Sie können diesen Prozess mithilfe von Azure Policy erzwingen und die Bereitstellung nicht vertrauenswürdiger Containerimages für den Cluster blockieren. Weitere Informationen finden Sie im Quarantine-Muster.

Wenn Sie Richtlinien festlegen, wenden Sie sie basierend auf den Anforderungen der Workload an. Beachten Sie folgende Faktoren:

• Entscheiden Sie, ob eine Sammlung von Richtlinien festgelegt werden soll, die als Initiativen bezeichnet werden, oder wählen Sie einzelne Richtlinien aus. Azure Policy bietet zwei integrierte Initiativen: grundlegende und eingeschränkte. Jede Initiative ist eine Sammlung integrierter Richtlinien, die für einen AKS-Cluster gelten. Es wird empfohlen, eine Initiative sowie andere Richtlinien für den Cluster und die Ressourcen, wie Containerregistrierung, Anwendungsgateway oder Key Vault, die mit dem Cluster interagieren, auszuwählen. Wählen Sie Richtlinien basierend auf den Anforderungen Ihrer Organisation aus.

• Entscheiden Sie, ob Sie die Aktion überwachen oder verweigern möchten. Im Überwachungsmodus ist die Aktion zulässig, aber als nicht konform gekennzeichnet. Verwenden Sie Prozesse, um nicht konforme Zustände in regelmäßigen Abständen zu überprüfen und die erforderlichen Maßnahmen zu ergreifen. Im Verweigerungsmodus wird die Aktion blockiert, da sie gegen die Richtlinie verstößt. Achten Sie darauf, wenn Sie den Modus 'Verweigern' auswählen, da er für die Funktionsfähigkeit des Workloads zu restriktiv sein kann.

• Entscheiden Sie, ob Sie Bereiche in Ihrer Workload haben, die nicht mit dem Entwurf kompatibel sein sollten. Azure Policy können Kubernetes-Namespaces angeben, die von der Richtlinienerzwingung ausgenommen sind. Es wird empfohlen, Richtlinien weiterhin im Überwachungsmodus anzuwenden, damit Sie diese Instanzen kennen.

• Entscheiden Sie, ob Sie über Anforderungen verfügen, die nicht von den integrierten Richtlinien abgedeckt werden. Sie können eine benutzerdefinierte Azure Policy Definition erstellen, die Ihre benutzerdefinierten OPA Gatekeeper-Richtlinien anwendet. Wenden Sie benutzerdefinierte Richtlinien nicht direkt auf den Cluster an. Weitere Informationen finden Sie unter Create and assign custom policy definitions.

• Entscheiden Sie, ob Sie organisationsweite Anforderungen haben. Wenn dies der Fall ist, fügen Sie diese Richtlinien auf der Verwaltungsgruppenebene hinzu. Ihr Cluster muss auch eigene Workload-spezifische Richtlinien zuweisen, auch wenn Ihre Organisation über generische Richtlinien verfügt.

• Entscheiden Sie, ob Sie Azure Richtlinien bestimmten Bereichen zuweisen müssen. Stellen Sie sicher, dass die Produktionsrichtlinien auch für Ihre Vorproduktionsumgebung überprüft werden. Andernfalls könnten Sie bei der Bereitstellung in Ihrer Produktionsumgebung auf unerwartete zusätzliche Einschränkungen stoßen, die Sie in der Vorproduktionsphase nicht berücksichtigt haben.

Diese Referenzimplementierung ermöglicht Azure Policy, wenn der AKS-Cluster erstellt wird. Die restriktive Initiative wird im Überwachungsmodus zugewiesen, um Einblicke in Nichtkompatibilität zu erhalten.

Außerdem werden durch die Implementierung zusätzliche Richtlinien festgelegt, die nicht Teil integrierter Initiativen sind. Diese Richtlinien werden im Verweigerungsmodus festgelegt. Beispielsweise gibt es eine Richtlinie, um sicherzustellen, dass Images nur aus der bereitgestellten Container Registry-Instanz abgerufen werden.

Erstellen Sie ggf. eigene benutzerdefinierte Initiativen. Fassen Sie die Richtlinien, die für Ihre Workload gelten, in einer einzigen Zuweisung zusammen.

Um zu beobachten, wie Azure Policy Funktionen innerhalb Ihres Clusters funktionieren, können Sie auf die Podprotokolle für alle Pods im Namespace gatekeeper-system und die Protokolle für die azure-policy und azure-policy-webhook Pods im namespace kube-system zugreifen.

Skalierbarkeit von Knoten und Pods

Mit zunehmender Nachfrage kann Kubernetes skalieren, indem es durch automatische horizontale Podskalierung weitere Pods zu vorhandenen Knoten hinzufügt. Wenn Kubernetes keine weiteren Pods mehr planen kann, muss die Anzahl der Knoten durch automatische Skalierung des AKS-Clusters erhöht werden. Eine vollständige Skalierungslösung muss sowohl Podreplikate als auch die Anzahl der Knoten im Cluster skalieren können.

Dazu gibt es zwei Ansätze: automatische Skalierung oder manuelle Skalierung.

Sowohl die automatische Skalierung als auch der manuelle Ansatz erfordern, dass Sie Warnungen für die CPU-Auslastung oder benutzerdefinierte Metriken überwachen und festlegen. Für die Podskalierung kann Ihr Anwendungsbediener die Anzahl von Podreplikaten erhöhen oder verringern, indem er ReplicaSet über Kubernetes-APIs anpasst. Bei der Clusterskalierung besteht eine Methode darin, benachrichtigt zu werden, wenn beim Kubernetes-Planer ein Fehler auftritt. Eine andere Möglichkeit besteht darin, ausstehende Pods über einen Zeitraum zu beobachten. Sie können die Knotenanzahl über das Azure CLI oder das Azure Portal anpassen.

Es wird empfohlen, den Autokalierungsansatz zu verwenden, da einige der manuellen Mechanismen in die Autoskalierung integriert sind.

Grundsätzlich sollten Sie Leistungstests mit einer minimalen Anzahl von Pods und Knoten beginnen. Verwenden Sie diese Werte, um die Baselineerwartung festzulegen. Verwenden Sie dann eine Kombination aus Leistungsmetriken und manueller Skalierung, um Engpässe zu ermitteln und die Reaktion der Anwendung auf Skalierung nachzuvollziehen. Legen Sie schließlich mithilfe dieser Daten die Parameter für die automatische Skalierung fest.

Horizontale automatische Podskalierung

Bei der horizontalen automatischen Podskalierung (Horizontal Pod Autoscaler, HPA) handelt es sich um eine Kubernetes-Ressource, die die Anzahl von Pods skaliert.

In der HPA-Ressource wird empfohlen, die mindeste und maximale Replikatanzahl festzulegen. Die Werte schränken die Grenzen für die automatische Skalierung ein.

Die HPA kann anhand der CPU-Auslastung, der Speicherauslastung und benutzerdefinierter Metriken skalieren. Nur die CPU-Auslastung wird nativ bereitgestellt. Die HorizontalPodAutoscaler-Definition gibt Zielwerte für die Metriken an. Die Spezifikation legt beispielsweise die CPU-Zielauslastung fest. Während Pods laufen, überprüft der HPA-Controller die CPU-Auslastung der einzelnen Pods mithilfe der Kubernetes-Metrics-API. Er vergleicht diesen Wert mit der Zielauslastung und berechnet ein Verhältnis. Anschließend ermittelt er anhand dieses Verhältnisses, ob Pods überbelegt oder unterbelegt sind. Er überlässt dem Kubernetes-Planer das Zuweisen neuer Pods zu Knoten oder das Entfernen von Pods von Knoten.

Es kann zu einer Race-Condition kommen, beispielsweise wenn die HPA-Prüfung erfolgt, bevor ein Skalierungsvorgang abgeschlossen ist. Das Ergebnis könnte also eine falsche Verhältnisberechnung sein. Weitere Informationen finden Sie unter Cooldown von Skalierungsereignissen.

Wenn Ihre Workload ereignisgesteuert ist, stellt Kubernetes event-driven autoscaling (KEDA) eine beliebte Open-Source-Option dar. Erwägen Sie KEDA, wenn eine Ereignisquelle, z. B. die Nachrichtenwarteschlange, Ihre Workload steuert, anstatt dass ihre Workload CPU-gebunden oder arbeitsspeichergebunden ist. KEDA unterstützt viele Ereignisquellen oder Skalierer. Verwenden Sie die Liste der Ereignisquellen, die KEDA bei KEDA-Scalern skalieren kann. Die Liste enthält den Azure Monitor Scaler, der eine bequeme Möglichkeit ist, KEDA-Workloads basierend auf Azure Monitor Metriken zu skalieren.

Automatische Clusterskalierung

Die cluster autoscaler ist eine AKS-Add-On-Komponente, die die Anzahl der Knoten in einem Knotenpool skaliert. Fügen Sie sie während der Clusterbereitstellung hinzu. Für jeden Benutzerknotenpool wird eine separate automatische Clusterskalierung benötigt.

Der Kubernetes-Planer löst die automatische Clusterskalierung aus. Wenn der Kubernetes-Scheduler aufgrund von Ressourceneinschränkungen einen Pod nicht planen kann, richtet der Autoscaler automatisch einen neuen Knoten im Knotenpool ein. Umgekehrt überprüft die automatische Clusterskalierung die nicht genutzte Kapazität der Knoten. Wenn der Knoten nicht mit der erwarteten Kapazität läuft, werden die Pods auf einen anderen Knoten verschoben, und der ungenutzte Knoten wird entfernt.

Beim Aktivieren der Autoskalierung legen Sie die maximale und minimale Anzahl von Knoten fest. Die empfohlenen Werte hängen von der Leistungserwartung der Workload, dem gewünschten Wachstum des Clusters und den Auswirkungen auf die Kosten ab. Die Mindestanzahl ist die reservierte Kapazität für diesen Knotenpool. In dieser Referenzimplementierung wird der Mindestwert aufgrund der Einfachheit der Arbeitslast auf zwei festgelegt.

Für den Systemknotenpool beträgt der empfohlene Mindestwert drei.

Entscheidungen zur Geschäftskontinuität

Um die Geschäftskontinuität aufrechtzuerhalten, definieren Sie das SLO für die Infrastruktur und Ihre Anwendung. Weitere Informationen finden Sie unter Recommendations for defining reliability targets. Überprüfen Sie die Bedingungen der Service-Level-Vereinbarung (SLA) für AKS im neuesten Artikel SLA für Onlinedienste.

Clusterknoten

Um das Mindestmaß an Verfügbarkeit für Workloads zu erreichen, benötigen Sie mehrere Knoten in einem Knotenpool. Wenn ein Knoten ausfällt, kann ein anderer Knoten im selben Knotenpool und Cluster die Anwendung weiter ausführen. Aus Zuverlässigkeitsgründen empfehlen wir drei Knoten für den Systemknotenpool. Beginnen Sie für den Benutzerknotenpool mit mindestens zwei Knoten. Wenn Sie eine höhere Verfügbarkeit oder Kapazität benötigen, skalieren Sie, um weitere Knoten hinzuzufügen.

Isolieren Sie Ihre Anwendungen von den Systemdiensten, indem Sie sie in einem separaten Knotenpool, als Benutzerknotenpool bezeichnet, platzieren. Dadurch werden Kubernetes-Dienste auf dedizierten Knoten ausgeführt und konkurrieren nicht mit Ihrer Workload. Wir empfehlen Ihnen, Tags, Labels und Taints zu verwenden, um den Knotenpool zu identifizieren und Ihre Workload zu planen. Stellen Sie sicher, dass Ihr System-Knoten-Pool mit dem Taint CriticalAddonsOnly versehen ist, um zu verhindern, dass Anwendungs-Pods auf Knoten-Pools eingeplant werden.

Regelmäßige Upkeep-Aufgaben auf Ihrem Cluster, z. B. zeitnahe Updates, sind für die Zuverlässigkeit von entscheidender Bedeutung. Außerdem empfehlen wir Ihnen, die Gesundheit der Pods mithilfe von Sonden zu überwachen.

Pod-Verfügbarkeit

• Angabe der Pod-Ressourcenanforderungen: Es wird empfohlen, die Pod-Ressourcenanforderungen in Ihren Bereitstellungen anzugeben. Der Planer kann den Pod dann ordnungsgemäß planen. Die Zuverlässigkeit wird erheblich reduziert, wenn Ihre Pods nicht geplant werden können.

• Pod Disruption Budgets festlegen: Diese Einstellung legt fest, wie viele Repliken in einer Bereitstellung während eines Update- oder Upgrade-Ereignisses ausfallen dürfen. Weitere Informationen finden Sie unter Budgets für die Unterbrechung von Pods.

  Konfigurieren Sie mehrere Replikate in der Bereitstellung, um Störungen wie Hardwarefehler zu bewältigen. Bei geplanten Ereignissen wie Updates und Upgrades kann ein Ausfallbudget dazu beitragen, sicherzustellen, dass die erforderliche Anzahl an Pod-Replikaten vorhanden ist, um die erwartete Anwendungslast zu bewältigen.

• Legen Sie Ressourcenkontingente für die Workload-Namespaces fest: Das Ressourcenkontingent für einen Namespace trägt dazu bei, sicherzustellen, dass Pod-Anforderungen und -Grenzwerte für eine Bereitstellung korrekt festgelegt sind. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten.

  Note

  Wenn Sie Ressourcenkontingente auf Clusterebene festlegen, können Probleme auftreten, wenn Sie externe Workloads bereitstellen, die keine ordnungsgemäßen Anforderungen und Grenzwerte aufweisen. Wenn Sie Kontingente auf Namespaceebene festlegen, wird sichergestellt, dass sie nur für Ihre Workloadkomponenten gelten.

• Festlegen von Pod-Anforderungen und -Grenzwerten: Legen Sie Anforderungen und Grenzwerte fest, damit Kubernetes CPU- und Arbeitsspeicherressourcen effizient den Pods zuordnen kann. Es ermöglicht Ihnen eine höhere Containerdichte auf einem Knoten. Anforderungen und Grenzwerte können zudem die Zuverlässigkeit erhöhen und aufgrund der besseren Hardwarenutzung gleichzeitig die Kosten senken.

  Um die Grenzwerte für eine Workload abzuschätzen, testen und erstellen Sie eine Baseline. Beginnen Sie mit gleichen Werten für Anforderungen und Grenzwerte. Optimieren Sie diese Werte dann schrittweise, bis Sie den Schwellenwert festlegen, der zu Instabilität im Cluster führt.

  Sie können Anforderungen und Grenzwerte in Ihren Bereitstellungsmanifesten angeben. Weitere Informationen finden Sie unter Set pod requests and limits.

Verfügbarkeitszonen

Verwenden Sie availability zones, wenn sie von der Region unterstützt werden, um sich vor einigen Arten von Ausfallen zu schützen. Sowohl die Komponenten der Steuerebene als auch die Knoten in den Knotenpools sind dann zonenredundant, was bedeutet, dass sie über mehrere Zonen verteilt sind. Wenn eine gesamte Zone nicht verfügbar ist, bleibt ein Knoten in einer anderen Zone innerhalb der Region weiterhin verfügbar. Jeder Knotenpool ist einer separaten VM-Skalierungsgruppe zugeordnet, die Knoteninstanzen und Skalierbarkeit verwaltet. Der AKS-Dienst verwaltet Skalierungssatzvorgänge und -konfigurationen. Beachten Sie Folgendes, wenn Sie mehrere Zonen aktivieren:

• Entire infrastructure: Wählen Sie eine Region aus, die Verfügbarkeitszonen unterstützt. Weitere Informationen finden Sie unter Limitations. Um ein SLA für Betriebszeit zu erhalten, müssen Sie die Stufe „Standard“ oder „Premium“ wählen. Die Verfügbarkeits-SLA ist größer, wenn Sie availability zones verwenden.

• Cluster: Sie können die Verfügbarkeitszonen nur beim Erstellen des Knotenpools festlegen. Sie können später nicht mehr geändert werden. Die Knotengrößen sollten in allen Zonen unterstützt werden, damit die gewünschte Verteilung möglich ist. Die zugrunde liegende VM-Skalierungsgruppe stellt die gleiche Hardwarekonfiguration zonenübergreifend bereit.

  Zonenredundanz gilt nicht nur für Knotenpools, sondern auch für die Steuerebene. Die AKS-Steuerungsebene erstreckt sich wie die Knotenpools über die angeforderten Zonen. Wenn Sie keine Unterstützung für Zonen in Ihrem Cluster verwenden, ist es nicht garantiert, dass die Komponenten der Kontrollebene über die Verfügbarkeitszonen verteilt werden.

• Abhängige Ressourcen: Um den Vorteil der Resilienz durch die Verwendung von Verfügbarkeitszonen zu erreichen, müssen alle Dienstabhängigkeiten auch Zonen unterstützen. Wenn ein abhängiger Dienst keine Zonen unterstützt, kann ein Zonenausfall dazu führen, dass bei diesem Dienst ein Fehler auftritt.

  Angenommen, Ihre Arbeitsauslastung verwendet eine Datenbank, die nicht zonensicher ist. Wenn ein Fehler auftritt, wird der AKS-Knoten möglicherweise in eine andere Zone verschoben, die Datenbank wird jedoch nicht mit dem Knoten in diese Zone verschoben, sodass Ihre Arbeitsauslastung unterbrochen wird.

Aus Gründen der Einfachheit in dieser Architektur wird AKS in einer einzelnen Region mit Knotenpools bereitgestellt, die drei availability zones umfassen. Andere Ressourcen der Infrastruktur, z. B. Azure Firewall und Anwendungsgateway, werden auch in derselben Region mit unterstützung mehrerer Zonen bereitgestellt. Die Georeplikation ist für Container Registry aktiviert.

Mehrere Regionen

Wenn Sie availability zones aktivieren, reicht die Abdeckung im unwahrscheinlichen Fall nicht aus, dass eine gesamte Region fehlschlägt. Um eine höhere Verfügbarkeit zu erhalten, führen Sie mehrere AKS-Cluster in unterschiedlichen Regionen aus.

• Bevorzugen Sie gepaarte Regionen, wenn sie verfügbar sind. Ein Vorteil der Verwendung von gekoppelten Regionen ist die Zuverlässigkeit während Plattformupdates. Azure stellt sicher, dass jeweils nur eine Region im Paar aktualisiert wird. Einige Regionen haben keine Paare. Falls Ihre Region nicht gekoppelt ist, können Sie trotzdem eine Lösung mit mehreren Regionen bereitstellen, indem Sie andere Regionen auswählen. Erwägen Sie die Verwendung einer CI/CD-Pipeline (Continuous Integration und Continuous Delivery), die Sie für die Orchestrierung der Wiederherstellung nach einem Regionsausfall konfigurieren. Bestimmte DevOps-Tools wie Flux können die Bereitstellungen mit mehreren Regionen vereinfachen.

• Geben Sie den Standort an, an dem der redundante Dienst über seine sekundäre Instanz verfügt, wenn eine Azure-Ressource Georedundanz unterstützt. Wenn Sie z. B. die Georeplikation für die Containerregistrierung aktivieren, werden automatisch Bilder in die ausgewählten Azure Regionen repliziert. Es bietet zudem fortgesetzten Zugriff auf Bilder, selbst wenn die primäre Region einen Ausfall hat.

• Wählen Sie einen Datenverkehrsrouter aus, der den Datenverkehr abhängig von Ihrer Anforderung über Zonen oder Regionen verteilen kann. Diese Architektur stellt Load Balancer bereit, da sie Nichtwebdatenverkehr über Zonen hinweg verteilen kann. Wenn Sie den Datenverkehr über Regionen hinweg verteilen müssen, sollten Sie Azure Front Door in Betracht ziehen. Weitere Optionen finden Sie unter Choose a load balancer.

Note

Der AKS-Basisplan für das Multiregion-Cluster-Beispielszenario erweitert die Architektur in diesem Artikel, um mehrere Regionen in einer aktiven-aktiven und hochverfügbaren Konfiguration einzuschließen.

Notfallwiederherstellung

Im Idealfall können Sie, wenn ein Fehler in der primären Region auftritt, schnell zu einer Instanz in einer anderen Region wechseln. Möglicherweise erstellen Sie einen Cluster vorab, oder warten Sie, bis er erforderlich ist. Beachten Sie die folgenden Empfehlungen:

• Verwenden Sie mehrere Regionen. Wenn Ihre primäre Region über eine gekoppelte Region verfügt, verwenden Sie dieses Paar. Andernfalls wählen Sie entsprechend Ihren Anforderungen an die Datenresidenz und Latenz Regionen aus.

• Verwenden Sie eine Workload ohne Status, die Sie effizient replizieren können. Wenn Sie den Zustand im Cluster speichern müssen, den wir nicht empfehlen, stellen Sie sicher, dass Sie die Daten häufig in einer anderen Region sichern.

• Integrieren Sie die Wiederherstellungsstrategie, wie zum Beispiel die Replikation in eine andere Region, als Teil der DevOps-Pipeline, um Ihr SLO zu erfüllen.

• Richten Sie jeden Azure Dienst mithilfe von Features ein, die die Notfallwiederherstellung unterstützen. In dieser Architektur ist beispielsweise Container Registry für die Georeplikation aktiviert. Wenn eine Region ausfällt, leitet das zustandsabhängige Failover von ACR Pullvorgänge automatisch über den globalen Endpunkt zu einem fehlerfreien Replikat um, ohne dass Sie die Konfiguration Ihres Clusters ändern müssen.

• Stellen Sie Ihre Infrastruktur als Code bereit, einschließlich Ihres AKS-Clusters sowie aller anderen Komponenten, die Sie benötigen. Falls eine Bereitstellung in einer anderen Region erforderlich ist, können Sie die Skripts oder Vorlagen wiederverwenden, um eine identische Instanz zu erstellen.

Clustersicherung

Für viele Architekturen können Sie einen neuen Cluster einrichten und über gitOps-basiertes Cluster-Bootstrapping zum Betriebszustand zurückkehren, gefolgt von der Anwendungsbereitstellung. Sollten jedoch kritische Ressourcenzustände vorliegen – wie z. B. Konfigurationszuordnungen, Jobs und Geheimnisse, die im Rahmen Ihres Bootstrapping-Prozesses nicht erfasst werden können –, sollten Sie Ihre Wiederherstellungsstrategie überdenken. Es wird empfohlen, zustandslose Workloads in Kubernetes auszuführen. Wenn Ihre Architektur einen datenträgerbasierten Zustand beinhaltet, müssen Sie auch Ihre Wiederherstellungsstrategie für diesen Inhalt berücksichtigen.

Wenn die Clustersicherung Teil Ihrer Wiederherstellungsstrategie sein muss, müssen Sie eine Lösung installieren, die Ihren Geschäftsanforderungen innerhalb des Clusters entspricht. Dieser Agent ist dafür verantwortlich, den Clusterressourcenstatus an ein Ziel Ihrer Wahl zu senden und Azure-Datenträger-basierte, persistente Volume-Snapshots zu koordinieren.

VMware Velero ist ein Beispiel für eine gängige Kubernetes-Sicherungslösung, die Sie direkt installieren und verwalten können. Sie können auch die AKS-Sicherungserweiterung verwenden, um eine verwaltete Velero-Implementierung bereitzustellen. Die AKS-Sicherungserweiterung unterstützt das Sichern von Kubernetes-Ressourcen und persistenten Volumes, wobei Zeitpläne und Sicherungsbereiche als Tresorkonfiguration in Azure Backup externisiert sind.

Die Referenzimplementierung implementiert keine Sicherung, was zusätzliche Azure Ressourcen zum Verwalten, Überwachen, Kaufen und Sichern umfasst. Diese Ressourcen können ein Azure Storage-Konto, einen Azure Backup Tresor und eine Konfiguration sowie das feature trusted access enthalten. Stattdessen ist GitOps in Kombination mit der Absicht, zustandslose Workloads auszuführen, die Lösung für die Wiederherstellung.

Wählen Und validieren Sie eine Backup-Lösung, die Ihrem Geschäftsziel entspricht, einschließlich Ihres definierten Ziels für wiederherstellungspunkt und Wiederherstellungszeit. Definieren Sie Ihren Wiederherstellungsprozess in einem Teamrunbook, und setzen Sie ihn für alle unternehmenskritischen Workloads um.

Wenn Sie zustandsbehaftete Workloads unterstützen und AKS Backup übernehmen müssen, verwenden Sie Azure Policy, um diese Sicherung auf Ihrem Cluster zu erzwingen.If you must support stateful workloads and adopt AKS Backup, use Azure Policy to enforce that backup is configured on your cluster. Azure Monitor macht den Zustand der Sicherungsaufträge über denselben Observability-Stack sichtbar, der in dieser Architektur bereits etabliert ist. Berücksichtigen Sie zusätzlich zu diesen Governance-Vorgaben die folgenden Architekturüberlegungen bei Ihrem Entwurf:

• Umfang der Sicherung. Entscheiden Sie, ob Sie den gesamten Cluster oder bestimmte Namespaces sichern. AKS Backup speichert Daten in einem BLOB-Container und als Datenträger- oder Dateimomentaufnahmen. Definieren Sie diesen Umfang frühzeitig, denn er bestimmt die Größe Ihres Speicherkontos, die Aufbewahrungsrichtlinien und die Granularität der Wiederherstellung für Szenarien wie die operative Wiederherstellung, das Klonen von Umgebungen und Clusterupgrades.
• Vertrauenswürdiger Zugriff. AKS Backup erfordert vertrauenswürdigen Zugriff zwischen dem Sicherungstresor und dem AKS-Cluster, unabhängig davon, ob der Cluster öffentlich, privat oder IP-eingeschränkt ist.
• RBAC-Berechtigungen. Die verwaltete Identität des Backup-Vaults erfordert eine Reihe von Berechtigungen im AKS-Cluster, um Backups zu konfigurieren und auszuführen. Die Sicherungserweiterung erstellt auch eine Benutzeridentität mit Berechtigungen für das Speicherkonto, in dem Sicherungen gespeichert werden.
• Netzwerkausgang. Die Sicherungserweiterung kommuniziert mit Azure Backup Diensten innerhalb des Clusters. Berücksichtigen Sie die erforderlichen ausgehenden Endpunkte in Ihren Azure Firewall- und NSG-Regeln.
• Platzbedarf innerhalb des Clusters. Die Erweiterung stellt Pods auf Ihren Knoten bereit. Planen Sie den zusätzlichen Rechen- und Speicherverbrauch in Ihren Knotenressourcenbudgets ein und beziehen Sie den Erweiterungs-Namespace in Ihre Netzwerkrichtlinienverwaltung ein.

SLA des Kubernetes-API-Servers

Sie können AKS als kostenlosen Dienst verwenden, aber diese Stufe bietet keine finanziell gesicherte SLA. Um eine SLA zu erhalten, müssen Sie die stufe Standard auswählen. Es wird empfohlen, dass alle Produktionscluster die Standardebene verwenden. Reservieren Sie die kostenlose Stufe für Vorproduktionscluster und die Premium-Stufe nur für missionskritische Workloads. Wenn Sie Azure Verfügbarkeitszonen verwenden, ist die SLA des Kubernetes-API-Servers höher. Ihre Knotenpools und anderen Ressourcen werden durch eigene SLAs abgedeckt.

Weitere Informationen zu bestimmten SLAs für jeden Dienst finden Sie unter SLA für Onlinedienste.

Kompromiss

Es gibt einen Kosten-zu-Verfügbarkeit-Kompromiss für die Bereitstellung der Architektur über Zonen und insbesondere Regionen hinweg. Einige Replikationsfeatures, z. B. die Georeplikation in der Containerregistrierung, sind in Premium-SKUs verfügbar, was teurer ist. Bei Bereitstellungen in mehreren Regionen steigen die Kosten auch, da Bandbreitengebühren anfallen, wenn der Datenverkehr über Regionen hinweg übertragen wird.

Erwarten Sie außerdem eine geringe Menge zusätzlicher Netzwerklatenz in der Knotenkommunikation zwischen Zonen und eine größere Latenz bei der Kommunikation zwischen Regionen. Messen Sie die Auswirkung dieser Architekturentscheidung auf Ihre Workload.

Testen mit Simulationen und erzwungenen Failovern

Testen Sie die Zuverlässigkeit Ihrer Lösung durch erzwungene Failovertests mit simulierten Ausfallen. Simulationen können das Beenden eines Knotens, das Herunterfahren aller AKS-Ressourcen in einer bestimmten Zone umfassen, um einen Zonenfehler zu simulieren oder einen externen Abhängigkeitsfehler aufzugeben. Sie können auch Azure Chaos Studio verwenden, um verschiedene Arten von Ausfallen in Azure und auf dem Cluster zu simulieren.

Weitere Informationen finden Sie unter Chaos Studio.

Überwachen und Sammeln von Protokollen und Metriken

Wir empfehlen die Azure Monitor Kubernetes-Überwachungsdienste, um die Leistung von Containerworkloads zu überwachen, da Sie Ereignisse in Echtzeit anzeigen können. Azure Monitor erfasst Protokolle von Containern in laufenden Pods und fasst sie zur Anzeige zusammen. Außerdem sammelt es Informationen von der Metrik-API zur Arbeitsspeicher- und CPU-Auslastung, um die Integrität der ausgeführten Ressourcen und Workloads zu überwachen. Sie können auch Azure Monitor verwenden, um die Leistung während der Skalierung der Pods zu überwachen. Es umfasst Telemetrie, die für die Überwachung, Analyse und Visualisierung der gesammelten Daten von entscheidender Bedeutung ist.

Aktivierung der Log-Erfassung von Pods

Das ContainerLogV2-Protokollschema wurde entwickelt, um Containerprotokolle von Kubernetes-Pods in einem optimierten Ansatz zu erfassen. Protokolleinträge werden in der Tabelle ContainerLogV2 in einem Azure Log Analytics Arbeitsbereich konsolidiert.

In einem AKS-Cluster gibt es zwei primäre Methoden zur Konfiguration der Pod-Protokollerfassung. Mit beiden Ansätzen können Sie Einstellungen anpassen. Sie können Namespaces filtern, Sammlungsintervalle anpassen, bestimmte Features aktivieren oder verbieten (z ContainerLogV2 . B. oder ContainerLogV2-HighScale), und angeben, welche Datenströme erfasst werden sollen.

• Wenn Sie zentrale, wiederverwendbare Überwachungskonfigurationen für mehrere Cluster benötigen oder die Clusterkonfiguration in Azure-nativen Ressourcen externalisiert bevorzugen, verwenden Sie Datensammlungsregeln (DCRs). DCRs sind Azure Ressourcen, die die Azure Resource Manager Steuerebene nativ verwaltet, und Sie können sie in Bicep Dateien einschließen. Die Referenzimplementierung verwendet DCRs.

• Alternativ können Sie die Überwachung mithilfe von ConfigMaps definieren, bei denen es sich um nichtkonfidentiale Kubernetes-YAML-Objekte handelt, die über die Kubernetes-API-Steuerungsebene konfiguriert sind. Der Azure Monitor-Agent, der auf dem Cluster ausgeführt wird, überwacht configMap-Objekte. Es verwendet vordefinierte Einstellungen, um zu bestimmen, welche Daten erfasst werden sollen.

Wenn beide Methoden aktiviert sind, haben ConfigMap-Einstellungen Vorrang vor DCRs. Vermeiden Sie das Mischen von ConfigMap- und DCR-Konfigurationen für die Sammlung von Containerprotokollen, da dies zu schwer zu behebenden Protokollierungsproblemen führen kann.

Warnungen und Prometheus-Metriken

Ausfalle und Fehlfunktionen stellen erhebliche Risiken für Arbeitsauslastungsanwendungen dar. Dies macht es wichtig, Probleme im Zusammenhang mit der Integrität und Leistung Ihrer Infrastruktur proaktiv zu identifizieren. Wenn Sie Ihre Umgebung überwachen und auf Das, was Sie lernen, reagieren, reduzieren Sie Unterbrechungen und verbessern die Zuverlässigkeit Ihrer Lösung. Um potenzielle Fehlerbedingungen in Ihrem Cluster zu antizipieren, aktivieren Sie die empfohlenen Prometheus-Warnungsregeln für Kubernetes.

Die meisten in Pods gehosteten Workloads geben Prometheus-Metriken aus. Azure Monitor kann mit Prometheus integriert werden. Sie können die Anwendungs- und Workloadmetriken anzeigen, die aus Containern, Pods, Knoten und dem Cluster gesammelt werden.

Einige nicht Microsoft Lösungen sind in Kubernetes integriert, z. B. Datadog, Grafana oder New Relic. Wenn Ihre Organisation diese Lösungen bereits verwendet, können Sie diese nutzen.

Protokolle der Azure-Infrastruktur und der Kubernetes-Steuerungsebene

Mit AKS verwaltet Azure einige der wichtigsten Kubernetes-Dienste. Azure implementiert die Protokolle für die AKS-Steuerungsebenenkomponenten als ressourcenprotokolle. Diese Optionen können Ihnen bei der Behandlung von Clusterproblemen helfen und haben eine relativ geringe Protokolldichte. Es wird empfohlen, die folgenden Optionen für die meisten Cluster zu aktivieren:

• ClusterAutoscaler: Gewinnen Sie Überwachbarkeit in den Skalierungsprozessen durch Protokollieren. Weitere Informationen finden Sie unter Cluster-Autoscaler-Protokolle und Status abrufen.

• KubeControllerManager: Erhalten Sie Einblick in die Interaktion zwischen Kubernetes und der Azure-Steuerebene.

• kube-audit-admin: Gewinnen Sie Einblick in die Aktivitäten, die Ihren Cluster ändern. Es ist nicht erforderlich, sowohl kube-audit als auch kube-audit-admin zu aktivieren, da kube-audit eine Obermenge ist, die auch Lesevorgänge (nicht modifizierend) umfasst.

• guard: Erfassen Sie Microsoft Entra ID- und Azure RBAC-Audits.

Es kann hilfreich sein, wenn Sie andere Protokollkategorien wie KubeScheduler oder kube-audit während der frühen Entwicklungsphase des Cluster- oder Workload-Lebenszyklus aktivieren. Die hinzugefügte automatische Clusterskalierung, Pod-Platzierung und -Planung und ähnliche Daten können Ihnen bei der Behebung von Problemen im Zusammenhang mit Cluster- oder Workload-Vorgängen helfen. Wenn Sie jedoch die erweiterten Problembehandlungsprotokolle vollständig speichern, nachdem Ihre Problembehandlungsanforderungen beendet wurden, entstehen möglicherweise unnötige Kosten zum Aufnehmen und Speichern der Daten in Azure Monitor.

Azure Monitor enthält eine Reihe vorhandener Protokollabfragen, mit denen Sie beginnen können, aber Sie können sie auch als Grundlage verwenden, um Ihre eigenen Abfragen zu erstellen. Wenn Ihre Bibliothek wächst, können Sie Protokollabfragen mithilfe eines oder mehrerer Query Packs speichern und wiederverwenden. Ihre benutzerdefinierte Bibliothek von Abfragen bietet eine größere Überwachbarkeit in Bezug auf die Gesundheit und Leistung Ihrer AKS-Cluster. Es unterstützt das Erreichen Ihrer SLOs.

Weitere Informationen zur Überwachung bewährter Methoden für AKS finden Sie unter Monitor AKS mit Azure Monitor.

Netzwerkmetriken

Grundlegende Netzwerkmetriken auf Clusterebene sind über systemeigene platform- und Prometheus-Metriken verfügbar. Sie können AKS node-Netzwerkmetriken weiter verwenden, um Netzwerkmetriken mithilfe von Prometheus-Metriken auf Knotenebene verfügbar zu machen. Die meisten Cluster sollten die Netzwerkbeobachtbarkeit umfassen, um zusätzliche Netzwerkproblembehandlungsfunktionen bereitzustellen und unerwartete Netzwerkauslastungen oder Probleme auf Knotenebene zu erkennen.

Die Referenzimplementierung verwendet Azure Monitor, die auch einige netzwerkbezogene Metriken sammelt. Die Referenzimplementierung verbietet das direkte Sammeln einiger Netzwerkmetriken von Azure Monitor und sammelt stattdessen die Netzwerk-Observierbarkeitsmetriken mithilfe eines Azure Monitor-Arbeitsbereichs mit managed Prometheus.

Für Workloads, die sehr empfindlich auf Paketverluste, Latenzen oder DNS-Druck beim Transmission Control Protocol (TCP) oder User Datagram Protocol (UDP) reagieren, sind die Netzwerkmetriken auf Pod-Ebene wichtig. In AKS können Sie auf diese detaillierten Metriken mithilfe der Funktion Advanced Container Networking Services zugreifen. Für die meisten Workloads ist diese Tiefe an Netzwerktransparenz nicht erforderlich. Sie sollten die erweiterte Netzwerküberwachbarkeit nur aktivieren, wenn Ihre Pods einen hohen Bedarf an einem hochoptimierten Netzwerk haben, das bis auf die Paketebene genau ist.

Kostenoptimierung für die Protokollierung

Die Referenzimplementierung konfiguriert die ContainerLogV2 Tabelle, um den Standardplan als Ausgangspunkt zu verwenden. Microsoft Defender for Containers und die für die Referenzimplementierung erstellten Warnungen fragen diese Tabelle nicht ab, sodass der Basic-Tarif wahrscheinlich kosteneffizient ist, da er die Kosten für das Einbinden von Daten senkt.

Wenn sich Ihre Protokollvolumen- und Abfrageanforderungen weiterentwickeln, wählen Sie den kostengünstigsten Tabellenplan für Ihre Anforderungen aus. Wenn die Lösung schreibintensiv wird, bei der Abfragen häufig Tabellendaten scannen, ist der Standardmäßige Analytics-Plan möglicherweise besser geeignet. Der Analyseplan entfernt Abfragegebühren, was für Szenarien optimiert ist, in denen die Aktivität der Abfragen die Erfassungskosten überwiegt. Wenn Sie Nutzungsmuster überwachen und Tabellenpläne nach Bedarf anpassen, können Sie ein Gleichgewicht zwischen Kosten und Funktionalität für Ihre Überwachungslösung erzielen.

Weitere Informationen finden Sie unter Auswahl eines Tabellenplans basierend auf der Datennutzung in einem Log Analytics-Arbeitsbereich.

Aktivieren der Selbstheilung

Überwachen Sie die Integrität von Pods, indem Sie Live- und Bereitschaftstests festlegen. Wenn Kubernetes einen nicht reagierenden Pod erkennt, startet es den Pod neu. Ein Livetest ermittelt, ob der Pod fehlerfrei ist. Wenn Kubernetes einen nicht reagierenden Pod erkennt, startet es den Pod neu. Ein Bereitschaftstest ermittelt, ob der Pod zum Empfangen von Anforderungen und Datenverkehr bereit ist.

Note

AKS verfügt über eine automatische Knotenreparaturfunktion, die integrierte Self-Healing für Infrastrukturknoten bereitstellt.

Routineupdates für AKS-Cluster

Teil von „Day 2“-Vorgängen für Kubernetes-Cluster besteht darin, routinemäßige Plattform- und Betriebssystemupdates durchzuführen. Es gibt drei Update-Ebenen, die auf jedem AKS-Cluster adressiert werden müssen:

• Die Kubernetes-Version (z. B. Kubernetes 1.32.3 bis 1.32.7 oder Kubernetes 1.32.7 bis 1.33.1), die möglicherweise Änderungen an der Kubernetes-API und veraltete Funktionen mit sich bringt. Versionsänderungen auf dieser Ebene haben Auswirkungen auf den gesamten Cluster.

• Das Image der virtuellen Festplatte (VHD) auf jedem Knoten, das Betriebssystemupdates und AKS-Komponentenupdates kombiniert. Diese Updates werden mit der Kubernetes-Version des Clusters getestet. Versionsänderungen auf dieser Ebene werden auf Knotenpoolebene angewendet und haben keine Auswirkungen auf die Kubernetes-Version.

• Der eigene systemeigene Updateprozess des Betriebssystems, z. B. Windows Update oder apt. Diese Updates werden direkt vom Betriebssystemanbieter bereitgestellt und nicht mit der Kubernetes-Version des Clusters getestet. Versionsänderungen auf dieser Ebene wirken sich auf einen einzelnen Knoten, jedoch nicht auf die Kubernetes-Version aus.

Jede dieser Ebenen wird unabhängig voneinander gesteuert. Sie entscheiden, wie die einzelnen Ebenen für die Cluster Ihrer Workload behandelt werden. Wählen Sie aus, wie oft jeder AKS-Cluster, seine Knotenpools oder seine Knoten aktualisiert werden (die Häufigkeit). Wählen Sie außerdem die Tage oder Uhrzeiten aus, um die Updates anzuwenden (Ihr Wartungsfenster). Wählen Sie aus, ob Updates manuell oder automatisch oder gar nicht installiert werden sollen. Ebenso wie für die Workload, die auf Ihrem Cluster ausgeführt wird, eine sichere Bereitstellungspraxis erforderlich ist, gilt dies auch für die Aktualisierungen Ihrer Cluster.

Eine umfassende Perspektive zum Patchen und Aktualisieren finden Sie in AKS-Patch- und Upgradeleitfaden im AKS Day-2-Betriebshandbuch. Verwenden Sie die folgenden Informationen für grundlegende Empfehlungen in Bezug auf diese Architektur.

Unveränderliche Infrastruktur

Workloads, die AKS-Cluster als unveränderliche Infrastruktur betreiben, aktualisieren ihre Cluster nicht automatisch oder manuell. Legen Sie das node-Imageupgrade auf none und das automatische Upgrade des clusters auf none fest. In dieser Konfiguration sind ausschließlich Sie für alle Upgrades auf allen Ebenen verantwortlich.

Wenn ein gewünschtes Update verfügbar wird, müssen Sie die folgenden Schritte ausführen:

1. Testen Sie das Update in einer Vorproduktionsumgebung, und bewerten Sie die Kompatibilität für einen neuen Cluster.

2. Stellen Sie eine Produktionsreplik-Stempelversion bereit, die die aktualisierte AKS-Version und die VHDs der Knoten-Pools enthält.

3. Wenn der neue Produktionscluster fertig ist, entwässern Sie den alten Cluster und setzen sie schließlich außer Betrieb.

Nur bei einer unveränderlichen Infrastruktur mit regelmäßigen Bereitstellungen neuer Infrastruktur sollte für ein Produktionscluster keine direkte Upgradestrategie angewendet sein. Alle anderen Cluster sollten eine In-Place-Upgrade-Strategie haben.

Direkte Upgrades

Workloads, die keine AKS-Cluster als unveränderliche Infrastruktur betreiben, sollten ihre ausgeführten Cluster regelmäßig aktualisieren, um alle drei Ebenen zu adressieren. Richten Sie den Updateprozess auf die Anforderungen Ihrer Workload aus. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für das Entwerfen Ihres Routineupdateprozesses.

• Planen Sie das Feature planierte Wartung von AKS, sodass Sie Upgrades auf Ihrem Cluster steuern können. Mit dieser Funktion können Sie diese Updates, einen inhärent riskanten Vorgang, zu einem kontrollierten Zeitpunkt ausführen, um die Auswirkungen eines unerwarteten Fehlers zu verringern.

• Konfigurieren Sie Budgets für die Unterbrechung von Pods so, dass Ihre Anwendung während der parallelen Upgrades stabil bleibt. Konfigurieren Sie jedoch die Budgets nicht so aggressiv, dass sie Node-Upgrades blockieren. Denn die meisten Upgrades erfordern für jeden Knoten einen Cordon-und-Drain-Prozess.

• Bestätigen Sie Azure Ressourcenkontingent und Ressourcenverfügbarkeit. Bei direkten Upgrades werden neue Instanzen von Knoten, sogenannte Surge-Knoten, bereitgestellt, bevor alte Knoten entfernt werden. Dies bedeutet, dass Azure Kontingent und IP-Adressraum für die neuen Knoten verfügbar sein müssen. Ein Anstiegswert von 33 % ist ein guter Ausgangspunkt für die meisten Workloads.

• Testen Sie die Kompatibilität mit Tools, z. B. Dienstgitter oder Sicherheits-Agents, die Sie Ihrem Cluster hinzugefügt haben. Testen Sie außerdem Ihre Workloadkomponenten, z. B. Eingangscontroller, Dienstgitter und Ihre Workload-Pods. Führen Sie Tests in einer Vorproduktionsumgebung aus.

Vor-Ort-Upgrades für Knoten

Verwenden Sie den NodeImage Kanal für automatische Upgrades von Betriebssystemimages für Knoten. Dieser Kanal konfiguriert Ihren Cluster so, dass die VHD auf jedem Knoten mit knotenebenen Aktualisierungen aktualisiert wird. Microsoft testet die Updates anhand Ihrer AKS-Version. Bei Windows Knoten erfolgen die Aktualisierungen etwa einmal pro Monat. Bei Linux-Knoten erfolgen die Updates etwa einmal pro Woche.

• Die Upgrades ändern nie Ihre AKS- oder Kubernetes-Version, daher besteht kein Problem hinsichtlich der Kubernetes-API-Kompatibilität.

• Wenn Sie NodeImage als Upgradekanal verwenden, wird Ihr geplantes Wartungsfenster berücksichtigt, das Sie mindestens einmal pro Woche festlegen sollten. Legen Sie es unabhängig davon fest, welches Knotenimagebetriebssystem Sie verwenden, um eine zeitnahe Anwendung von Updates sicherzustellen.

• Zu diesen Updates gehören Sicherheits-, Kompatibilitäts- und Funktionsupdates auf Betriebssystemebene, Betriebssystemkonfigurationseinstellungen und AKS-Komponentenupdates.

• Image-Releases und die darin enthaltenen Versionsnummern werden mithilfe des AKS Release-Trackers nachverfolgt.

Wenn die Sicherheitsanforderungen für Ihren Cluster einen aggressiveren Patching-Rhythmus erfordern und Ihr Cluster die potenziellen Unterbrechungen tolerieren kann, verwenden Sie stattdessen den SecurityPatch-Upgradekanal. Microsoft testet diese Updates ebenfalls. Die Updates werden nur veröffentlicht, wenn Sicherheitsupgrades vorhanden sind, die Microsoft für wichtig genug hält, um vor dem nächsten anstehenden Knoten-Image-Upgrade freizugeben. Wenn Sie den Kanal SecurityPatch verwenden, erhalten Sie auch die Updates wie der Kanal NodeImage. Die SecurityPatch Kanaloption berücksichtigt weiterhin Ihre Wartungsfenster. Achten Sie daher darauf, dass Ihr Wartungsfenster häufiger Lücken (z. B. täglich oder jeden anderen Tag) aufweist, um diese unerwarteten Sicherheitsupdates zu unterstützen.

Die meisten Cluster, bei denen direkte Upgrades durchgeführt werden, sollten die Upgradekanaloptionen für Knotenimages None und Unmanaged vermeiden.

In-situ-Updates des Clusters

Kubernetes ist eine sich schnell entwickelnde Plattform, und regelmäßige Updates bringen wichtige Sicherheitsupdates sowie neue Funktionen mit sich. Es ist wichtig, dass Sie mit Kubernetes-Updates auf dem Laufenden bleiben. Sie sollten innerhalb der zwei neuesten Versionen (N-2) bleiben. Es ist wichtig, auf die neueste Version von Kubernetes zu aktualisieren, da häufig neue Versionen veröffentlicht werden.

Die meisten Cluster sollten in der Lage sein, AKS-Versionsupdates an Ort und Stelle mit ausreichender Vorsicht und Sorgfalt durchzuführen. Das Risiko, ein direktes AKS-Versionsupgrade durchzuführen, kann hauptsächlich durch ausreichende Präproduktionstests, Kontingentüberprüfung und Pod-Unterbrechungsbudgetkonfiguration abgemildert werden. Ein direktes Upgrade kann jedoch unerwartetes Verhalten aufweisen. Wenn direkte Upgrades für Ihre Workload als zu riskant eingestuft werden, empfehlen wir Ihnen, eine Blau-Grün-Bereitstellung von AKS-Clustern zu verwenden, anstatt den verbleibenden Empfehlungen zu folgen.

Wir empfehlen Ihnen, die Funktion automatische Cluster-Aktualisierung zu vermeiden, wenn Sie einen Kubernetes-Cluster zum ersten Mal bereitstellen. Verwenden Sie einen manuellen Ansatz, mit dem Sie eine neue AKS-Clusterversion in Ihren Präproduktionsumgebungen testen können, bevor die Updates auf Ihre Produktionsumgebung stoßen. Dieser Ansatz erreicht auch das größte Maß an Vorhersagbarkeit und Kontrolle. Sie müssen neue Updates für die Kubernetes-Plattform jedoch sorgfältig überwachen und schnell neue Versionen übernehmen, sobald sie veröffentlicht werden. Es ist besser, eine Denkweise zu übernehmen, die das 'auf dem neuesten Stand bleiben' bevorzugt statt einen Langzeitunterstützungs-Ansatz.

Warning

Es wird nicht empfohlen, automatisch einen AKS-Produktionscluster zu patchen oder zu aktualisieren, auch nicht mit Nebenversionsupdates, es sei denn, Sie testen diese Updates zunächst in Ihren niedrigeren Umgebungen. Weitere Informationen finden Sie unter Regelmäßige Aktualisierung auf die neueste Version von Kubernetes und Aktualisieren eines AKS-Clusters.

Sie können Benachrichtigungen empfangen, wenn eine neue AKS-Version für Ihren Cluster verfügbar ist, indem Sie das AKS-System für Azure Event Grid verwenden. Die Referenzimplementierung stellt dieses Ereignisrastersystem bereit, sodass Sie das ereignis Microsoft.ContainerService.NewKubernetesVersionAvailable aus Ihrer Eventstream-Benachrichtigungslösung abonnieren können. Lesen Sie die AKS-Versionshinweise für bestimmte Kompatibilitätsprobleme, Verhaltensänderungen oder veraltete Funktionen.

Möglicherweise erreichen Sie den Konfidenzpunkt mit Kubernetes-Versionen, AKS-Versionen, Ihrem Cluster, seinen Komponenten auf Clusterebene und der Workload, um die Funktion für automatische Upgrades zu entdecken. Für Produktionssysteme ist es selten, über patch hinauszugehen. Wenn Sie Ihre AKS-Version automatisch aktualisieren, überprüfen Sie außerdem die AKS-Versionseinstellung in Ihrer Infrastruktur als Code (IaC), damit die beiden nicht aus dem Gleichgewicht geraten. Konfigurieren Sie Ihr geplantes Wartungsfenster, um die automatische Aktualisierung zu unterstützen.

Sicherheitsüberwachung

Überwachen Sie Ihre Containerinfrastruktur sowohl auf aktive Bedrohungen als auch auf potenzielle Sicherheitsrisiken. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Microsoft Defender für Container identifiziert und korrigiert Defender for Cloud Empfehlungen für Ihre Containerimages.
• Defender für Container überwacht Ihre Container-Images regelmäßig auf Schwachstellen.
• Defender für Container generiert auch realzeit-Sicherheitswarnungen für verdächtige Aktivitäten.
• Security-Konzepte für Anwendungen und Cluster in AKS bieten ausführliche Informationen dazu, wie die Containersicherheit die gesamte End-to-End-Pipeline von der Erstellung bis zu den Anwendungs-Workloads schützt, die in AKS ausgeführt werden.

Cluster- und Workload-Operationen

Überlegungen zu Cluster- und Workloadvorgängen (DevOps) finden Sie in der Säule Entwurfsprinzipien für optimalen Betrieb.

Clusterbootstrapping

Nachdem Sie Ihren Cluster eingerichtet haben, ist es ein Arbeitscluster, aber Möglicherweise haben Sie weitere Schritte to do, bevor Sie Workloads bereitstellen können. Der Prozess der Vorbereitung des Clusters wird als Bootstrapping bezeichnet. Das Bootstrapping besteht häufig aus der Bereitstellung von erforderlichen Images auf Clusterknoten, dem Erstellen von Namespaces und anderen Aufgaben, die die Anforderungen des Anwendungsfalles Ihrer Organisation erfüllen.

Um den Übergang von einem neu eingerichteten Cluster zu einem ordnungsgemäß konfigurierten Cluster zu beschleunigen, müssen Sie Ihren eindeutigen Bootstrapping-Prozess definieren und relevante Ressourcen im Voraus vorbereiten. Wenn Sie beispielsweise ein Dienstgitter wie Linkerd oder Consul Connect verwenden, stellen Sie das Gitter normalerweise bereit, bevor Anwendungsworkloads geplant werden können. Bevor Sie den Cluster einrichten, müssen Sie überprüfen, ob die Images des Service Mesh in einer zuvor erstellten Containerregistrierung vorhanden sind. Diese Überprüfung trägt dazu bei, Bereitstellungsverzögerungen oder Fehler zu verhindern.

Sie können den Bootstrapping-Prozess mit einer der folgenden Methoden konfigurieren:

• GitOps Flux v2 Clustererweiterung
• Pipelines
• Beispielsweise eine Selbstkonfiguration mit Flux oder Argo CD

Note

Alle diese Methoden funktionieren mit jeder Clustertopologie, wir empfehlen jedoch die Clustererweiterung GitOps Flux v2 für Flotten aufgrund der Einheitlichkeit und einfacheren Verwaltung im großen Maßstab. Wenn Sie nur wenige Cluster ausführen, kann GitOps zu komplex sein. Sie können sich stattdessen dafür entscheiden, den Prozess in eine oder mehrere Bereitstellungspipelines zu integrieren, um sicherzustellen, dass Bootstrapping stattfindet. Verwenden Sie die Methode, die am besten zu den Zielen Ihrer Organisation und Ihres Teams passt.

Einer der Hauptvorteile der GitOps Flux v2-Clustererweiterung für AKS besteht darin, dass es praktisch keine Lücke zwischen einem bereitgestellten Cluster und einem Cluster nach dem Bootstrapping gibt. Dadurch wird die Umgebung mit einer soliden Verwaltungsgrundlage für die Zukunft eingerichtet; außerdem wird die Einbindung des Bootstrapping als Ressourcenvorlagen unterstützt, um Ihrer IaC-Strategie gerecht zu werden.

Wenn bootstrapped-Manifeste Werte erfordern, die nur zur Bereitstellungszeit bekannt sind, z. B. eine Containerregistrierungs-URL, einen Key Vault Namen oder eine Identitätsclient-ID, verwenden Sie die variable Ersetzung von Flux in der Kustomisierungskonfiguration. Eine Kustomisierung definiert, welcher Pfad im Git-Repository synchronisiert werden soll und welche Variablensubstitutionen nach dem Build angewendet werden sollen. Sie konfigurieren Kustomisierungen als Teil der Flux-Erweiterungsbereitstellung in Ihrer IaC-Vorlage, in der Sie die Ersetzungsvariablen definieren, sodass Werte aus den bereitgestellten Ressourcen zum Zeitpunkt der Clustererstellung aufgelöst werden. Dieser Ansatz beseitigt Timing-Probleme, die auftreten, wenn eine ConfigMap bereits vor der ersten Reconciliation vorhanden sein muss, und vermeidet, dass Benutzer das Repository eigens forken müssen, nur um umgebungsspezifische Werte anzupassen. Der Flux-Erweiterungs-Agent übersetzt diese IaC-Konfiguration in Kubernetes benutzerdefinierte Ressourcen, die der Flux Kustomize-Controller abgleicht, und wendet die variablen Ersetzungen an, wenn er jeden Pfad verarbeitet.

Wenn Sie die GitOps Flux v2-Clustererweiterung verwenden, ist kubectl nicht für einen Teil des Bootstrapping-Prozesses erforderlich. Sie können den kubectl-basierten Zugriff für Notfallsituationen zur Fehlerbehebung reservieren. Zwischen Vorlagen für Azure Ressourcendefinitionen und dem Bootstrapping von Manifesten über die GitOps-Erweiterung können Sie alle normalen Konfigurationsaktivitäten ausführen, ohne kubectl verwenden zu müssen.

Isolieren der Zuständigkeiten für Workloads

Teilen Sie Workloads nach Teams und Ressourcentypen ein, um jeden Teil einzeln verwalten zu können.

Beginnen Sie mit einer einfachen Workload, die die grundlegenden Komponenten enthält, und bauen Sie darauf auf. Eine erste Aufgabe ist die Konfiguration des Netzwerks. Richten Sie virtuelle Netzwerke für den Hub und die Speichen und auch Subnetze in diesen Netzwerken ein. Beispielsweise verfügt ein Spoke über separate Subnetze für System- und Benutzer-Knoten-Pools, Ingress-Ressourcen und den privaten AKS-API-Server. Stellen Sie ein Subnetz für Azure Firewall im Hub bereit.

Eine weitere Aufgabe besteht darin, die grundlegende Arbeitsauslastung in Microsoft Entra ID zu integrieren.

Verwenden Sie IaC

Wählen Sie nach Möglichkeit eher eine idempotente deklarative Methode als einen imperativen Ansatz aus. Anstatt eine Sequenz von Befehlen zu schreiben, die Konfigurationsoptionen angeben, verwenden Sie eine deklarative Syntax, die die Ressourcen und ihre Eigenschaften beschreibt. Die Referenzimplementierung verwendet Bicep, aber Sie können stattdessen Terraform- oder Azure Resource Manager-Vorlagen (ARM-Vorlagen) verwenden.

Stellen Sie sicher, dass Sie Ressourcen gemäß den geltenden Richtlinien einrichten. Wenn Sie beispielsweise VM-Größen auswählen, halten Sie die Kosteneinschränkungen und Optionen für Verfügbarkeitszonen ein, um den Anforderungen Ihrer Anwendung gerecht zu werden. Sie können auch Azure Policy verwenden, um die Richtlinien Ihrer Organisation für diese Entscheidungen zu erzwingen.

Wenn Sie eine Sequenz von Befehlen schreiben müssen, verwenden Sie die Azure CLI. Diese Befehle decken eine Reihe von Azure-Diensten ab, und Sie können sie durch Skripting automatisieren. Windows und Linux unterstützen die Azure CLI. Eine weitere plattformübergreifende Option ist Azure PowerShell. Ihre Wahl hängt von Ihren bevorzugten Fähigkeiten ab.

Speichern Sie Ihre Skripte und Vorlagendateien in Ihrem Quellcode-Verwaltungssystem, und verwalten Sie dort die Versionen.

CI/CD für Workloads

Pipelines für Workflow und Bereitstellung müssen in der Lage sein, Anwendungen kontinuierlich zu erstellen und bereitzustellen. Updates müssen sicher und schnell bereitgestellt und bei Problemen rückgängig gemacht werden können.

Ihre Bereitstellungsstrategie muss eine zuverlässige und automatisierte Continuous Delivery-Pipeline aufweisen. Stellen Sie Änderungen an Ihren Workload-Container-Images automatisch im Cluster bereit.

In dieser Architektur verwaltet GitHub Actions den Workflow und die Bereitstellung. Weitere beliebte Optionen sind Azure DevOps Services und Jenkins.

Cluster-System CI/CD

Das Diagramm zeigt den CI/CD-Workflow von links nach rechts. Links stellt ein Symbol "Infrastruktur als Code" die deklarative Konfiguration dar, die in der Quellcodeverwaltung gespeichert ist. Ein horizontaler Pfeil mit der Bezeichnung "Deploy" zeigt von "Infrastructure as Code" zu einer zentralen Box mit der Bezeichnung "GitOps". Dieses Feld enthält Azure Pipelines, GitHub Actions und Jenkins Pipelines. Im Feld GitOps zeigt ein Pfeil mit der Bezeichnung "Synchronisieren" auf ein AKS-Symbol.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Anstatt einen imperativen Ansatz wie Kubectl zu verwenden, verwenden Sie Tools, die Cluster- und Repositoryänderungen automatisch synchronisieren. Um den Workflow zu verwalten, z. B. die Veröffentlichung einer neuen Version und Validierung für diese Version vor der Bereitstellung in der Produktion, sollten Sie einen GitOps-Fluss in Betracht ziehen.

Ein wesentlicher Bestandteil des CI/CD-Flows ist das Bootstrapping eines neu bereitgestellten Clusters. Ein GitOps-Ansatz ist nützlich, da er es den Betreibern ermöglicht, den Bootstrapping-Prozess deklarativ als Teil der IaC-Strategie zu definieren und die Konfiguration automatisch im Cluster anzuwenden.

Wenn Sie GitOps verwenden, wird ein Agent im Cluster bereitgestellt, der den Status des Clusters mit der Konfiguration koordiniert, die in Ihrem privaten Git-Repository gespeichert ist. Ein solcher Agent ist Flux, der einen oder mehrere Operatoren im Cluster verwendet, um Bereitstellungen in Kubernetes auszulösen. Flux führt die folgenden Aufgaben aus:

• Überwacht alle konfigurierten Repositorys
• Erkennt neue Konfigurationsänderungen
• Löst Bereitstellungen aus
• Aktualisiert die gewünschte ausgeführte Konfiguration basierend auf diesen Änderungen.

Sie können auch Richtlinien festlegen, die die Bereitstellung der Änderungen steuern.

Das folgende Beispieldiagramm zeigt, wie Sie die Clusterkonfiguration mit GitOps und Flux automatisieren.

Das Diagramm veranschaulicht den GitOps-Workflow mit vier nummerierten Schritten von links nach rechts. Ganz links wird ein Entwicklersymbol mit einem Laptop als Schritt 1 angezeigt, in dem der Benutzer IaC-Änderungen an ein Git-Repository verschiebt. Schritt 2 zeigt das Git-Repository an, das über einen Pfeil mit der Bezeichnung Git Clone --mirror zu einem Flux-Symbol innerhalb der AKS-Clustergrenze verbunden wird. Schritt 3 zeigt einen Pfeil mit der Bezeichnung "kubectl apply", der vom Flux-Icon auf das Kubernetes-API-Serversymbol innerhalb des Clusters verweist. Schritt 4 zeigt einen roten Kreis mit einer diagonalen Linie zwischen dem Entwickler und dem Kubernetes-API-Server mit einer überkreuzten Kubectl-Bezeichnung an.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Ein Entwickler überträgt Änderungen am Quellcode, wie Konfigurations-YAML-Dateien, die in einem Git-Repository gespeichert sind. Die Änderungen werden dann auf einen Git-Server gepusht.

2. Flux wird zusammen mit der Workload in einem Pod ausgeführt. Flux hat schreibgeschützten Zugriff auf das Git-Repository, um sicherzustellen, dass Flux nur die Änderungen anwendet, die von Entwicklern angefordert werden.

3. Flux erkennt Änderungen an der Konfiguration und wendet diese Änderungen mithilfe von kubectl-Befehlen an.

4. Entwickler haben keine direkten access über Kubectl an die Kubernetes-API.

Sie können Verzweigungsrichtlinien auf Ihrem Git-Server haben, damit mehrere Entwickler Änderungen über eine Pullanforderung genehmigen können, bevor die Änderung auf die Produktion angewendet wird.

Während Sie GitOps und Flux manuell konfigurieren können, empfehlen wir die GitOps mit Flux v2 Cluster-Erweiterung für AKS.

Bereitstellungsstrategien für Workloads und Cluster

Stellen Sie alle Änderungen, z. B. Architekturkomponenten, Workload und Clusterkonfiguration, auf mindestens einem AKS-Cluster vor der Produktion bereit. Dieser Prozess simuliert die Änderung und kann Probleme identifizieren, bevor sie in der Produktion bereitgestellt werden.

Führen Sie Tests und Überprüfungen in jeder Phase aus, bevor Sie mit der nächsten Phase fortfahren. Dadurch wird sichergestellt, dass Sie Aktualisierungen streng kontrolliert in die Produktionsumgebung übertragen und Störungen durch unerwartete Bereitstellungsprobleme minimieren können. Die Bereitstellung sollte einem ähnlichen Muster folgen wie die Produktion, indem die gleichen GitHub Actions Pipeline- oder Flux-Operatoren verwendet werden.

Erweiterte Bereitstellungstechniken, wie blaugrüne Bereitstellung, A/B-Tests und Canary-Releases, erfordern zusätzliche Prozesse und potenziell zusätzliches Werkzeug. Flagger ist eine beliebte Open-Source-Lösung zur Lösung erweiterter Bereitstellungsszenarien.

Kostenmanagement

Überprüfen Sie zunächst die Prüfliste für die Kostenoptimierung und die Liste der Empfehlungen, die in Well-Architected Framework für AKS beschrieben sind. Allgemeine Workloadempfehlungen finden Sie in der Prüfliste Entwurfsüberprüfung für Kostenoptimierung.

Sie finden eine Kostenschätzung für die In dieser Basisarchitektur verwendeten Komponenten im Azure Preisrechner. Ändern Sie Ihre Schätzung so, dass sie die für Ihren Anwendungsfall erforderlichen Komponenten enthält. Diese Schätzung umfasst Ressourcen auf Speichenebene, die direkt mit dem Cluster verknüpft sind. Die gemeinsam genutzte Hubinfrastruktur, z. B. Azure Firewall, Hub-VNETs und Azure Privates DNS-Zonen, ist nicht enthalten, da diese Ressourcen in der Regel einem zentralen Plattformteam gehören und von ihm verwaltet werden.

Erwägen Sie die Verwendung von AKS-Kostenanalyse für die granulare Kostenzuordnung der Clusterinfrastruktur durch Kubernetes-spezifische Konstrukte.

Provision

• Verstehen Sie, woher Ihre Kosten kommen. Für die Bereitstellung und Verwaltung von AKS sowie den Betrieb des Kubernetes-Clusters selbst fallen nur minimale Kosten an. Was sich auf die Kosten auswirkt, sind die VM-Instanzen, storage, Protokolldaten und Netzwerkressourcen, die vom Cluster verbraucht werden. Wählen Sie für Systemknotenpools eventuell günstigere VMs aus. Die Serie Ddv5 ist ein typischer VM-Typ für den Systemknotenpool, und die Referenzimplementierung verwendet die Standard_D2d_v5-SKU.

• Verwenden Sie nicht dieselbe Konfiguration für Entwicklungs-/Test- und Produktionsumgebungen. Produktionsworkloads weisen zusätzliche Anforderungen für Hochverfügbarkeit auf und sind in der Regel teurer. Diese Konfiguration ist in der Dev/Test-Umgebung nicht erforderlich.

• Fügen Sie für Produktionsworkloads eine Betriebszeit-SLA hinzu. Bei Clustern für Dev/Test- oder experimentelle Workloads, bei denen keine Verfügbarkeit garantiert werden muss, sind Einsparungen möglich. Beispielsweise könnte Ihr SLO ausreichend sein. Wenn Ihre Workload dies unterstützt, sollten Sie auch dedizierte Spotknotenpools verwenden, die spot VMs ausführen.

  Bei Nichtproduktionsworkloads, die Azure SQL-Datenbank oder Azure App Service als Teil der AKS-Workloadarchitektur enthalten, bewerten Sie, ob Sie berechtigt sind, Azure Dev/Test-Abonnements zu verwenden und Servicerabatte zu erhalten.

• Stellen Sie einen Cluster mit der Mindestanzahl an Knoten bereit und aktivieren Sie die automatische Cluster-Skalierung, um die Überwachung und Größenentscheidungen zu ermöglichen, anstatt mit einem überdimensionierten Cluster zu beginnen, um die Skalierungsanforderungen zu erfüllen.

• Legen Sie Podanforderungen und Grenzwerte fest, damit Kubernetes Knotenressourcen mit höherer Dichte zuordnen kann, damit Sie die volle Kapazität der Knoten verwenden.

• Bedenken Sie, dass die Kosten erhöht werden können, wenn Sie die Diagnose auf dem Cluster aktivieren.

• Entscheiden Sie sich für ein oder drei Jahre Azure Reserved Virtual Machine Instances, um die Knotenkosten zu senken, wenn Ihre Workload über einen langen Zeitraum bestehen muss. Weitere Informationen finden Sie unter Kosten sparen mit Azure Reserved Virtual Machine Instanzen.

• Verwenden Sie beim Erstellen von Knotenpools Tags. Tags helfen beim Erstellen von benutzerdefinierten Berichten, um entstandene Kosten nachzuverfolgen. Mithilfe von Tags können Sie die Gesamtausgaben verfolgen und alle Kosten einer bestimmten Ressource oder einem bestimmten Team zuordnen. Wenn der Cluster von mehreren Teams gemeinsam genutzt wird, erstellen Sie Chargeback-Berichte für jeden Nutzer, um die gemessenen Kosten für gemeinsam genutzte Cloud-Dienste zu ermitteln. Weitere Informationen finden Sie unter Angeben von Taint, Bezeichnung oder Tag für einen Knotenpool.

• Rechnen Sie mit zusätzlichen Bandbreitenkosten, wenn Ihre Workload mehrere Regionen umfasst und Sie Daten zwischen Regionen replizieren. Weitere Informationen finden Sie unter Bandwidth pricing.

• Erstellen Sie Budgets, um die von Ihrem Unternehmen festgelegten Kostenbeschränkungen einzuhalten. Sie können Budgets über Microsoft Cost Management erstellen. Sie können auch Benachrichtigungen erstellen, um Benachrichtigungen zu erhalten, wenn bestimmte Schwellenwerte überschritten werden. Weitere Informationen finden Sie unter Erstellen eines Budgets mit einer Vorlage.

Monitor

Sie können den gesamten Cluster und die Kosten für die Berechnung, Speicher, Bandbreite, Protokolldaten und die Firewall überwachen. Azure bietet die folgenden Optionen zum Überwachen und Analysieren von Kosten:

• Azure Advisor
• Kostenmanagement

Überwachen Sie Ihre Kosten in Echtzeit oder in einem regelmäßigen Zeitplan, damit Sie vor Dem Monatsende Maßnahmen ergreifen können, wenn die Kosten bereits berechnet werden. Überwachen Sie die monatlichen Trends im Laufe der Zeit, um innerhalb des Budgets zu bleiben.

Um datengestützte Entscheidungen zu treffen, bestimmen Sie, welche Ressource auf granularer Ebene die meisten Kosten verursacht. Außerdem sollten Sie die Verbrauchseinheiten verstehen, die die Ressourcennutzung berechnen. Durch die Analyse von Metriken können Sie beispielsweise feststellen, ob die Plattform überdimensioniert ist. Sie können die Nutzungszähler in Azure Monitor Metriken sehen.

Optimize

Folgen Sie den Empfehlungen von Azure Advisor. Erkunden Sie weitere Möglichkeiten zur Optimierung:

• Aktivieren Sie die Autoskalierung für den Cluster, um wenig ausgelastete Knoten im Knotenpool zu erkennen und zu entfernen.

  Important

  Schnelle oder häufige Änderungen an den Einstellungen für die Automatische Skalierung von Clustern, z. B. die Mindest- und maximaler Knotenanzahl für einen Knotenpool, um die Kosten zu steuern, kann zu unbeabsichtigten oder kontraproduktiven Ergebnissen führen. Beispielsweise wird scale-down-unneeded-time auf 10 Minuten eingestellt, und die Mindest- und Höchsteinstellungen der Knoten werden alle 5 Minuten basierend auf den Merkmalen der Arbeitslast geändert, wodurch sich die Anzahl der Knoten niemals verringert. Der Grund dafür ist, dass die Berechnung der nicht benötigten Zeit für jeden Knoten zurückgesetzt wird, wenn die Einstellungen für die Automatische Skalierung des Clusters aktualisiert werden.

• Wählen Sie eine niedrigere SKU für die Knotenpools aus, wenn die Workload dies unterstützt.

• Wenn die Anwendung keine Burst-Skalierung erfordert, sollten Sie eine Anpassung der Clustergröße in Betracht ziehen, indem Sie die Leistungsmetriken im Zeitverlauf analysieren.

• Wenn Ihre Workload dies unterstützt, skalieren Sie Ihre Benutzerknotenpools auf null Knoten, wenn nicht erwartet wird, dass sie ausgeführt werden. Wenn in Ihrem Cluster keine Workloads ausgeführt werden müssen, sollten Sie die AKS-Start-/Stopp-Funktion verwenden, um alle Berechnungen zu beenden, die Ihren Systemknotenpool und die AKS-Steuerungsebene umfassen.

Weitere Informationen finden Sie unter AKS-Preise.

Nächste Schritte

• AKS-Roadmap zu GitHub

Verwandte Ressourcen

• Erweiterte AKS-Microservicearchitektur
• Microservices-Architektur auf AKS
• Use Azure Firewall, um einen AKS-Cluster zu schützen
• GitOps für AKS
• Datenstreaming mithilfe von AKS