Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)

Diese Referenzarchitektur bietet eine empfohlene Basisinfrastrukturarchitektur für die Bereitstellung eines AKS-Clusters (Azure Kubernetes Service) in Azure. Sie nutzt unsere Entwurfsprinzipien und basiert auf unseren bewährten Methoden für die Architektur aus dem Azure Well-Architected Framework, um ein interdisziplinäres Team oder unterschiedliche Teams (beispielsweise aus den Bereichen Netzwerk, Sicherheit und Identität) bei der Bereitstellung dieser universellen Infrastruktur zu unterstützen.

Bei dieser Architektur steht keine Workload, sondern der AKS-Cluster an sich im Fokus. Bei den hier angegebenen Informationen handelt es sich um die empfohlene Mindestbaseline für die meisten AKS-Cluster. Die Integration in Azure-Dienste bietet Einblicke, eine Netzwerktopologie, die multiregionales Wachstum unterstützt, und Schutz für den clusterinternen Datenverkehr.

Die Zielarchitektur ist Abhängig von Ihren geschäftlichen Anforderungen beeinflusst und kann daher zwischen verschiedenen Anwendungskontexten variieren. Sie sollte als Ausgangspunkt für Vorproduktions- und Produktionsphasen betrachtet werden.

Eine Implementierung dieser Architektur ist hier verfügbar: GitHub: Baselinereferenzimplementierung von Azure Kubernetes Service (AKS). Sie können diese als alternativen Startpunkt verwenden und gemäß Ihren Anforderungen konfigurieren.

Netzwerkkonfiguration

Netzwerktopologie
Planen der IP-Adressen
Bereitstellen von Eingangsressourcen

Clustercomputeressourcen

Compute für den Basiscluster
Containerimageverweis
Richtlinienverwaltung

Identitätsverwaltung

Integrieren der Microsoft Entra-ID für den Cluster
Integrieren der Microsoft Entra-ID für die Workload

Sicherer Datenfluss

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

Geschäftskontinuität

Skalierbarkeit
Cluster- und Knotenverfügbarkeit
Verfügbarkeit und Unterstützung von mehreren Regionen

Operationen (Operations)

CI/CD-Pipelines für Cluster und Workload
Clusterintegrität und Metriken
Kostenverwaltung und Berichterstellung

Netzwerktopologie

Bei dieser Architektur wird eine Hub-Spoke-Netzwerktopologie verwendet. Der Hub und die Spokes werden in separaten virtuellen Netzwerken bereitgestellt, die per Peering verbunden sind. Diese Topologie bietet u. a. folgende Vorteile:

• Getrennte Verwaltung. Ermöglicht die Anwendung von Governance sowie die Einhaltung des Prinzips der geringsten Rechte. Außerdem wird das Konzept einer Azure-Zielzone mit Aufgabentrennung unterstützt.

• Minimieren der direkten Verfügbarkeit von Azure-Ressourcen über das öffentliche Internet.

• Organisationen verwenden häufig regionale Hub-Spoke-Topologien. Hub-Spoke-Netzwerktopologien können in der Zukunft erweitert werden und Workloadisolation erreichen.

• Alle Webanwendungen sollten einen WAF-Dienst (Web Application Firewall) voraussetzen, der die Steuerung des HTTP-Datenverkehrsflusses unterstützt.

• Sie stellt die natürliche Wahl für Workloads dar, die mehrere Abonnements umfassen.

• Die Architektur bleibt erweiterbar. Um neue Features oder Workloads zu ermöglichen, können neue Spokes hinzugefügt werden, anstatt die Netzwerktopologie komplett neu zu entwerfen.

• Bestimmte Ressourcen, z. B. eine Firewall und DNS, können über mehrere Netzwerke hinweg gemeinsam genutzt werden.

• Ist auf die Azure-Zielzonen auf Unternehmensebene abgestimmt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

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

Informationen zu den Änderungen des Netzwerkentwurfs, die in der AKS-Baselinereferenzarchitektur für Windows-Container enthalten sind, finden Sie im Begleitartikel.

Hub

Der Hub des virtuellen Netzwerks ist der zentrale Punkt für Konnektivität und Einblicke. Ein Hub enthält immer eine Azure Firewall-Instanz mit globalen Firewallrichtlinien, die von Ihren zentralen IT-Teams definiert werden, um eine organisationsweite Firewallrichtlinie zu erzwingen. Außerdem enthält er Azure Bastion, ein Gatewaysubnetz für VPN-Konnektivität sowie Azure Monitor für die Netzwerkeinblicke.

Innerhalb des Netzwerks werden drei Subnetze bereitgestellt.

Subnetz zum Hosten von Azure Firewall

Azure Firewall ist eine Firewall, die als Dienst bereitgestellt wird. Die Firewallinstanz schützt den ausgehenden Netzwerkdatenverkehr. Ohne diese Sicherheitsebene kann dieser Datenverkehr mit einem böswilligen Drittanbieterdienst kommunizieren, der vertrauliche Unternehmensdaten herausfiltern könnte. Azure Firewall Manager ermöglicht die zentrale Bereitstellung und Konfiguration mehrerer Azure Firewall-Instanzen sowie die Verwaltung von Azure Firewall-Richtlinien für diese Netzwerkarchitektur vom Typ virtuelles Hubnetzwerk.

Subnetz zum Hosten eines Gateways

Dieses Subnetz ist ein Platzhalter für ein VPN- oder ExpressRoute-Gateway. Das Gateway stellt Verbindungen zwischen den Routern in Ihrem lokalen Netzwerk und dem virtuellen Netzwerk bereit.

Subnetz zum Hosten von Azure Bastion

Dieses Subnetz ist ein Platzhalter für Azure Bastion. Sie können Bastion für den sicheren Zugriff auf Azure-Ressourcen verwenden, ohne die Ressourcen im Internet verfügbar zu machen. Dieses Subnetz wird nur für die Verwaltung und den Betrieb genutzt.

Spoke

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

Subnetz zum Hosten von Azure Application Gateway

AzureApplication Gateway ist ein Lastenausgleich für Webdatenverkehr, der auf Schicht 7 betrieben wird. Bei der Referenzimplementierung wird die Application Gateway v2-SKU verwendet, die Web Application Firewall (WAF) aktiviert. WAF schützt eingehenden Datenverkehr vor gängigen Angriffen auf Webdatenverkehr (einschließlich Bots). Die Instanz verfügt über eine öffentliche IP-Konfiguration am Front-End, das die Benutzeranforderungen empfängt. Für Application Gateway ist standardmäßig ein dediziertes Subnetz erforderlich.

Subnetz zum Hosten der Eingangsressourcen

Zum Weiterleiten und Verteilen von Datenverkehr wird Traefik als Eingangscontroller verwendet, der die Kubernetes-Eingangsressourcen bedient. Dieses Subnetz enthält interne Azure-Lastenausgleiche. Weitere Informationen finden Sie unter Verwenden eines internen Lastenausgleichs mit Azure Kubernetes Service (AKS).

Subnetz zum Hosten der Clusterknoten

AKS verwaltet zwei separate Knotengruppen (oder Knotenpools). Der Systemknotenpool hostet Pods, die die Hauptclusterdienste ausführen. Der Benutzerknotenpool führt Ihre Workload und den Eingangsdatencontroller aus, um die eingehende Kommunikation mit der Workload zu ermöglichen.

Subnetz zum Hosten von Private Link-Endpunkten

Azure Private Link-Verbindungen werden für Azure Container Registry und Azure Key Vault erstellt, damit über private Endpunkte innerhalb des virtuellen Spoke-Netzwerks auf diese Dienste zugegriffen werden kann. Private Endpunkte benötigen kein dediziertes Subnetz und können auch im virtuellen Hub-Netzwerk platziert werden. In der Baselineimplementierung werden sie in einem dedizierten Subnetz innerhalb des virtuellen Spoke-Netzwerks bereitgestellt. Dadurch muss weniger Datenverkehr über die Peeringnetzwerkverbindung abgewickelt werden, die zum Cluster gehörenden Ressourcen befinden sich im gleichen virtuellen Netzwerk, und Sie können mithilfe von Netzwerksicherheitsgruppen präzise Sicherheitsregeln auf Subnetzebene anwenden.

Weitere Informationen finden Sie in der Entscheidungsstruktur für die Private Link-Bereitstellung.

Planen der IP-Adressen

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Adressraum des virtuellen Netzwerks sollte groß genug sein, um alle Subnetze aufnehmen zu können. Berücksichtigen Sie alle Entitäten, die Datenverkehr empfangen. Die IP-Adressen für diese Entitäten werden aus dem Adressraum des Subnetzes zugewiesen. Beachten Sie die folgenden Punkte.

• Aktualisieren

  AKS aktualisiert Knoten regelmäßig, um sicherzustellen, dass die Sicherheitsfeatures und andere Systempatches der zugrunde liegenden virtuellen Computer auf dem neuesten Stand sind. Während eines Upgradevorgangs erstellt AKS einen Knoten, der die Pods temporär hostet, während der Upgradeknoten gesperrt und entladen wird. Diesem temporären Knoten wird eine IP-Adresse aus dem Clustersubnetz zugewiesen.

  Für Pods benötigen Sie abhängig von Ihrer Strategie möglicherweise weitere Adressen. Für rollierende Updates benötigen Sie Adressen für die temporären Pods, die die Workloads ausführen, während die eigentlichen Pods aktualisiert werden. Wenn Sie die Ersetzungsstrategie verwenden, werden Pods entfernt und die neuen erstellt. Daher werden die Adressen, die den alten Pods zugeordnet sind, wiederverwendet.

• Skalierbarkeit

  Berücksichtigen Sie die Knotenanzahl aller System- und Benutzerknoten sowie deren maximale Skalierbarkeitsgrenzwerte. Angenommen, Sie möchten um 400 % aufskalieren. Für alle horizontal skalierten Knoten benötigen Sie die vierfache Anzahl von Adressen.

  In dieser Architektur kann jeder Pod direkt kontaktiert werden. Daher benötigt jeder Pod eine eigene Adresse. Die Podskalierbarkeit wirkt sich auf die Adressberechnung aus. Diese Entscheidung hängt von der ausgewählten Anzahl von Pods ab, auf die Sie vergrößern möchten.

• Adressen für Azure Private Link

  Der Faktor für Adressen, die für die Kommunikation mit anderen Azure-Diensten über Private Link erforderlich sind. In dieser Architektur sind den Links zu Azure Container Registry und Key Vault zwei Adressen zugewiesen.

• Bestimmte Adressen sind für die Verwendung durch Azure reserviert. 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. Bei mehreren Workloads können Sie die Benutzerknotenpools voneinander und vom Systemknotenpool isolieren. Dies führt zu mehr Subnetzen, die jeweils kleiner sind. Außerdem kann die Eingangsressource komplexer sein, sodass Sie möglicherweise mehrere Eingangsdatencontroller benötigen, die wiederum zusätzliche IP-Adressen erfordern.

Alle Überlegungen zu dieser Architektur finden Sie unter AKS baseline Network Topology (AKS-Baseline-Netzwerktopologie).

Informationen zum Planen der IP-Adressen für einen AKS-Cluster finden Sie unter Planen der IP-Adressierung für Ihren Cluster.

Informationen zu den IP-Adressplanungsüberlegungen, die in der AKS-Baseline-Referenzarchitektur für Windows-Container enthalten sind, finden Sie im Begleitartikel.

Add-Ons und Previewfunktionen

Kubernetes und AKS werden kontinuierlich weiterentwickelt und verfügen über kürzere Releasezyklen als Software für lokale Umgebungen. Diese Basisarchitektur hängt von bestimmten AKS-Previewfunktionen und AKS-Add-Ons ab. Sie unterscheiden sich wie folgt:

• Das AKS-Team beschreibt Previewfunktionen als ausgelieferte Funktionen, die noch weiter verbessert werden. Der Grund dafür ist, dass sich viele der Previewfunktionen nur wenige Monate in diesem Zustand befinden und dann allgemein verfügbar werden.
• AKS-Add-Ons und -Erweiterungen bieten zusätzliche unterstützte Funktionen. Installation, Konfiguration und Lebenszyklus von Add-Ons werden von AKS verwaltet.

Diese Basisarchitektur enthält nicht alle Previewfunktionen oder Add-Ons, sondern nur diejenigen, die einen erheblichen Nutzen für einen universellen Cluster haben. Wenn diese Funktionen die Vorschauphase verlassen, wird die Basisarchitektur entsprechend überarbeitet. Es gibt einige zusätzliche Previewfunktionen oder AKS-Add-Ons, die zur Verbesserung der Sicherheit oder Verwaltbarkeit oder zur Erfüllung anderer Anforderungen beitragen und die Sie ggf. in Vorabproduktionsclustern evaluieren können. Drittanbieter-Add-Ons müssen von Ihnen installiert und verwaltet werden. Dies schließt die Nachverfolgung verfügbarer Versionen und die Installation von Updates nach dem Upgraden der Kubernetes-Version eines Clusters mit ein.

Containerimageverweis

Neben der Workload enthält der Cluster möglicherweise mehrere andere Images, z. B. den Eingangsdatencontroller. Einige dieser Images befinden sich möglicherweise in öffentlichen Registrierungen. Berücksichtigen Sie die folgenden Punkte, wenn Sie diese Images in Ihren Cluster pullen:

• Der Cluster ist dazu berechtigt, das Image zu pullen.

• Wenn Sie ein öffentliches Image verwenden, empfiehlt es sich, dieses in eine Containerregistrierung zu importieren, die Ihrem SLO entspricht. Andernfalls unterliegt das Image möglicherweise unerwarteten Verfügbarkeitsproblemen. Dadurch können Betriebsprobleme entstehen, da das Image nicht verfügbar ist, wenn Sie es benötigen. Im Folgenden werden einige Vorteile der Verwendung Ihrer Containerregistrierung anstelle einer öffentlichen Registrierung aufgeführt:

  • Sie können den nicht autorisierten Zugriff auf Ihre Images blockieren.
  • Es liegen keine öffentlichen Abhängigkeiten vor.
  • Sie können auf Imagepullprotokolle zugreifen, um Aktivitäten zu überwachen und Konnektivitätsprobleme zu selektieren.
  • Sie profitieren von integrierter Containerüberwachung und Imagekonformität.

  Eine Option ist Azure Container Registry (ACR).

• Damit können Sie Images aus autorisierten Registrierungen pullen. Sie können diese Einschränkung über Azure Policy erzwingen. In dieser Referenzimplementierung pullt der Cluster nur Images aus der ACR-Instanz, die als Teil der Architektur bereitgestellt wurde.

Konfigurieren der Computeressourcen für den Basiscluster

In AKS ist jeder Knotenpool einer VM-Skalierungsgruppe zugeordnet. Knoten sind 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 DS2_v2-Knoten bereit. Diese Größe reicht aus, um die erwartete Last der Systempods zu erfüllen. Der Betriebssystemdatenträger ist 512 GB groß.

Im Folgenden finden Sie einige Überlegungen zum Benutzerknotenpool:

• Wählen Sie größere Knoten aus, um die maximale Anzahl der auf einem Knoten festgelegten Pods zu unterstützen. Dadurch wird der Speicherbedarf von Diensten minimiert, die auf allen Knoten ausgeführt werden, z. B. Überwachung und Protokollierung.

• Stellen Sie mindestens zwei Knoten bereit. Auf diese Weise wird für die Workload ein Hochverfügbarkeitsmuster mit zwei Replikaten verwendet. Mit AKS können Sie die Knotenanzahl ändern, ohne den Cluster neu zu erstellen.

• Die tatsächlichen Knotengrößen für Ihre Workload sind von den Anforderungen abhängig, die vom Entwurfsteam festgelegt werden. Basierend auf den Geschäftsanforderungen haben wir für die Produktionsworkload DS4_v2 ausgewählt. Um die Kosten zu senken, können Sie die Größe auf DS3_v2 verringern. Dies ist auch die minimale Empfehlung.

• Wenn Sie die Kapazität für Ihren Cluster planen, gehen Sie davon aus, dass die Workload bis zu 80 % auf den einzelnen Knoten verbrauchen kann. Die verbleibenden 20 % sind für AKS-Dienste reserviert.

• Legen Sie basierend auf Ihrer Kapazitätsplanung die maximale Anzahl von Pods pro Knoten fest. Wenn Sie versuchen, eine Kapazitätsbaseline einzurichten, beginnen Sie mit dem Wert 30. Passen Sie diesen Wert gemäß den Anforderungen der Workload, der Knotengröße und der IP-Einschränkungen an.

Integrieren der Microsoft Entra-ID für den Cluster

Das Schützen des Zugriffs auf den Cluster und aus diesem heraus ist sehr wichtig. Treffen Sie Entscheidungen hinsichtlich der Sicherheit aus der Perspektive des Clusters:

• Zugriff von innen: AKS-Zugriff auf Azure-Komponenten wie Netzwerkinfrastruktur, Azure Container Registry und Azure Key Vault. Autorisieren Sie nur solche Ressourcen, auf die der Cluster zugreifen darf.
• Zugriff von außen: Bereitstellen von Kubernetes-Clusterzugriff für Identitäten. Autorisieren Sie nur externe Entitäten, denen der Zugriff auf den Kubernetes-API-Server und Azure Resource Manager gestattet ist.

AKS-Zugriff auf Azure

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 diesen beiden Möglichkeiten werden verwaltete Identitäten empfohlen. Mit Dienstprinzipalen sind Sie für das Verwalten und Rotieren von Geheimnissen zuständig, das manuell oder programmgesteuert erfolgen kann. Mit verwalteten Identitäten verwaltet Microsoft Entra ID die Authentifizierung und die rechtzeitige Rotation der Geheimnisse für Sie.

Es wird empfohlen, verwaltete Identitäten zu aktivieren, damit der Cluster über Microsoft Entra ID mit externen Azure-Ressourcen interagieren kann. Sie können diese Einstellung nur während der Clustererstellung aktivieren. Auch wenn Microsoft Entra ID nicht sofort verwendet wird, können Sie diese später integrieren.

Standardmäßig werden vom Cluster zwei primäre Identitäten verwendet: die Clusteridentität und die Kubelet-Identität. Die Clusteridentität wird von Komponenten der AKS-Steuerungsebene verwendet, um Clusterressourcen wie Lastenausgleichsmodule für eingehenden Datenverkehr, von AKS verwaltete öffentliche IP-Adressen usw. zu verwalten. Die Kubelet-Identität wird für die Authentifizierung bei Azure Container Registry (ACR) verwendet. Einige Add-Ons unterstützen auch die Authentifizierung mithilfe einer verwalteten Identität.

Betrachten wir als Beispiel für den Zugriff von innen unter Verwendung verwalteter Identitäten den Fall, dass der Cluster Images aus einer Containerregistrierung pullen muss. Für diese Aktion muss der Cluster die Anmeldeinformationen der Registrierung abrufen. Eine Möglichkeit besteht darin, diese Informationen in Form eines Kubernetes-Geheimnisobjekts zu speichern und mit imagePullSecrets abzurufen. Diese Vorgehensweise wird aufgrund der hohen Komplexität bei der Sicherheit nicht empfohlen. Sie müssen nicht nur vorab das Geheimnis kennen, sondern dieses auch über die DevOps-Pipeline offenlegen. Ein weiterer Grund ist der betriebliche Mehraufwand für die Verwaltung der Rotation des Geheimnisses. Erteilen Sie stattdessen der verwalteten Kubelet-Identität Ihres Clusters das Zugriffsrecht acrPull für Ihre Registrierung. Mit diesem Ansatz werden beide Probleme behandelt.

In dieser Architektur greift der Cluster auf Azure-Ressourcen zu, die durch Microsoft Entra ID gesichert sind, und führt Operationen durch, die verwaltete Identitäten unterstützen. Weisen Sie den verwalteten Identitäten des Clusters über die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) Berechtigungen basierend auf den Vorgängen zu, die der Cluster ausführen soll. Der Cluster authentifiziert sich bei Microsoft Entra ID und erhält dann auf der Grundlage der ihm zugewiesenen Rollen Zugriff oder verweigert ihn. Im Folgenden finden Sie einige Beispiele aus dieser Referenzimplementierung, bei denen dem Cluster in Azure integrierte Rollen zugewiesen wurden:

• Netzwerkmitwirkender: Ermöglicht dem Cluster das Steuern des virtuellen Spoke-Netzwerks. Diese Rollenzuweisung ermöglicht der dem AKS-Cluster vom System zugewiesenen Identität, im dedizierten Subnetz für die internen Eingangscontrollerdienste zu arbeiten.
• Herausgeber von Überwachungsmetriken: Ermöglicht dem Cluster das Senden von Metriken an Azure Monitor.
• AcrPull: Ermöglicht dem Cluster das Pullen von Images aus den angegebenen Azure Container Registry-Instanzen.

Clusterzugriff

Die Integration von Microsoft Entra vereinfacht auch die Sicherheit beim Zugriff von außen. Angenommen, ein Benutzer möchte kubectl verwenden. Als Erstes führt er den Befehl az aks get-credentials aus, um die Anmeldeinformationen des Clusters abzurufen. Microsoft Entra ID authentifiziert die Identität des Benutzers anhand der Azure-Rollen, die für die Nutzung von Azure zugelassen sind. Weitere Informationen finden Sie unter Verfügbare Clusterrollenberechtigungen.

AKS ermöglicht den Kubernetes-Zugang über Microsoft Entra ID auf zwei Arten. Die erste ist die Verwendung von Microsoft Entra ID als Identitätsanbieter, der in das native Kubernetes RBAC-System integriert ist. Bei der anderen wird die native Azure RBAC zum Steuern des Clusterzugriffs verwendet. Beide werden nachfolgend beschrieben.

Zuordnen von Kubernetes RBAC zu Microsoft Entra ID

Kubernetes unterstützt die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) wie folgt:

• Ein Satz von Berechtigungen. Dieser wird durch ein Role- oder ClusterRole-Objekt für clusterweite Berechtigungen definiert.

• Bindungen zum Zuweisen der Benutzer und Gruppen, die die Aktionen ausführen dürfen. Diese werden durch ein RoleBinding- oder ClusterRoleBinding-Objekt definiert.

Kubernetes verfügt über einige integrierte Rollen wie „cluster-admin“, „edit“, „view“ usw. Binden Sie diese Rollen an Microsoft Entra-Benutzer und -Gruppen, um das Unternehmensverzeichnis zum Verwalten des Zugriffs zu verwenden. Weitere Informationen finden Sie unter Verwenden von Kubernetes RBAC mit der Microsoft Entra-Integration.

Achten Sie darauf, dass Ihre Microsoft Entra-Gruppen, die für den Cluster- und Namespace-Zugriff verwendet werden, in Ihren Microsoft Entra-Zugriffsüberprüfungenenthalten sind.

Verwenden von Azure RBAC für die Kubernetes-Autorisierung

Anstatt native Kubernetes-RBAC (ClusterRoleBindings und RoleBindings) zur Autorisierung mit integrierter Microsoft Entra-Authentifizierung zu verwenden, empfehlen wir die Verwendung von Azure RBAC und Azure-Rollenzuweisungen, um Autorisierungsprüfungen für den Cluster zu erzwingen. Diese Rollenzuweisungen können sogar im Abonnement- oder Ressourcengruppenbereich hinzugefügt werden. Dadurch erben alle Cluster im Bereich einheitliche Rollenzuweisungen in Bezug auf die Zugriffsberechtigungen auf die Objekte im Kubernetes-Cluster.

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

Lokale Konten

AKS unterstützt die native Kubernetes-Benutzerauthentifizierung. Der Benutzerzugriff auf Cluster mithilfe dieser Methode wird nicht empfohlen. Sie ist zertifikatsbasiert und wird außerhalb Ihres primären Identitätsanbieters ausgeführt. Dies erschwert eine zentrale Benutzerzugriffssteuerung und -verwaltung. Verwalten Sie den Zugriff auf Ihren Cluster immer mit Microsoft Entra ID und konfigurieren Sie Ihren Cluster so, dass der Zugriff auf lokale Konten ausdrücklich deaktiviert wird.

In dieser Referenzimplementierung wird der Zugriff über lokale Clusterkonten bei der Bereitstellung des Clusters explizit deaktiviert.

Integrieren der Microsoft Entra ID für die Workload

Ähnlich wie bei einer systemseitig zugewiesenen verwalteten Azure-Identität für den gesamten Cluster können Sie verwaltete Identitäten auch auf Podebene zuweisen. Mit einer Workload-Identität kann die gehostete Workload über Microsoft Entra ID auf Ressourcen zugreifen. Angenommen, die Workload 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 werden verwaltete Identitäten für Pods über die Microsoft Entra ID-Workloadidentität auf AKS bereitgestellt. Sie lässt sich in die nativen Funktionen von Kubernetes integrieren, um mit externen Identitätsanbietern einen Verbund zu bilden. Weitere Informationen zum Microsoft Entra Workload ID-Partnerverbund finden Sie in der folgenden Übersicht.

Bereitstellen von Eingangsressourcen

Kubernetes-Eingangsressourcen leiten den eingehenden Datenverkehr an den Cluster weiter und verteilen ihn. Es gibt zwei Kategorien von Eingangsressourcen:

• Interner Lastenausgleich Verwaltung durch AKS. Dieses Lastenausgleichsmodul macht den Eingangscontroller über eine private statische IP-Adresse verfügbar. Es dient als einziger Kontaktpunkt, der eingehende Datenflüsse empfängt.

  In dieser Architektur wird Azure Load Balancer verwendet. Der Lastenausgleich befindet sich außerhalb des Clusters in einem dedizierten Subnetz für Eingangsressourcen. Er empfängt Datenverkehr von Azure Application Gateway, wobei die Kommunikation über TLS erfolgt. Weitere Informationen zur TLS-Verschlüsselung für eingehenden Datenverkehr finden Sie unter Eingehender Datenverkehrsfluss.

• Eingangscontroller. Wir haben uns für Traefik entschieden. Er wird im Benutzerknotenpool im Cluster ausgeführt. Er empfängt Datenverkehr vom internen Lastenausgleich, schließt TLS ab und leitet ihn über HTTP an die Workloadpods weiter.

Der Eingangscontroller ist eine wichtige Komponente des Clusters. Beachten Sie die folgenden Punkte, wenn Sie diese Komponente konfigurieren.

• Wählen Sie im Rahmen Ihrer Entwurfsentscheidungen einen Bereich aus, in dem der Eingangscontroller zugelassen ist. Beispielsweise können Sie zulassen, dass der Controller nur mit den Pods interagiert, die eine bestimmte Workload ausführen.

• Vermeiden Sie das Platzieren von Replikaten auf demselben Knoten, um die Last zu verteilen und Geschäftskontinuität zu gewährleisten, wenn ein Knoten ausfällt. Verwenden Sie zu diesem Zweck podAntiAffinity.

• Beschränken Sie die zu planenden Pods auf den Benutzerknotenpool, indem Sie nodeSelectorsverwenden. Mit dieser Einstellung werden Workload- und Systempods isoliert.

• Öffnen Sie Ports und Protokolle, die bestimmten Entitäten das Senden von Datenverkehr an den Eingangscontroller ermöglichen. In dieser Architektur empfängt Traefik nur Datenverkehr von Azure Application Gateway.

• Der Eingangscontroller sollte Signale senden, die die Integrität der Pods angeben. Konfigurieren Sie die Einstellungen readinessProbe und livenessProbe, mit denen die Integrität der Pods im angegebenen Intervall überwacht wird.

• Beschränken Sie den Zugriff des Eingangsdatencontrollers auf bestimmte Ressourcen und auf die Ausführung bestimmter Aktionen. Diese Einschränkung kann über RBAC-Berechtigungen in Kubernetes implementiert werden. In dieser Architektur wurden Traefik z. B. mithilfe von Regeln im Kubernetes-Objekt ClusterRole Berechtigungen zum Überwachen, Abrufen und Auflisten von Diensten und Endpunkten erteilt.

Informationen zum Eingangsentwurf, der in der AKS-Baselinereferenzarchitektur für Windows-Container verwendet wird, finden Sie im Begleitartikel.

Routereinstellungen

Der Eingangscontroller verwendet Routen, um das Ziel von Datenverkehr zu bestimmen. Routen geben den Quellport an, an dem der Datenverkehr empfangen wurde, sowie Informationen zu den Zielports und Protokollen.

Im Folgenden finden Sie ein Beispiel aus dieser Architektur:

Traefik verwendet den Kubernetes-Anbieter, um Routen zu konfigurieren. annotations, tls und entrypoints geben an, dass Routen über HTTPS bedient werden. middlewares gibt an, dass nur Datenverkehr aus dem Subnetz von Azure Application Gateway zulässig ist. Für die Antworten wird Gzip-Codierung verwendet, sofern der Client diese akzeptiert. Da Traefik den TLS-Anschluss ausführt, erfolgt die Kommunikation mit den Back-End-Diensten über HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Schützen des Datenflusses im Netzwerk

Der Netzwerkdatenfluss kann in diesem Kontext wie folgt kategorisiert werden:

• Eingehender Datenverkehr: Vom Client zu der im Cluster ausgeführten Workload.

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

• Datenverkehr zwischen Pods: Für die Kommunikation zwischen den Pods. Dieser Datenverkehr umfasst die Kommunikation zwischen dem Eingangscontroller 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: Der Datenverkehr zwischen dem Client und dem Kubernetes-API-Server.

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 Chiffren umfasst. Für die Servernamensanzeige (SNI) ist „strict“ aktiviert. End-to-End-TLS wird über Application Gateway eingerichtet, wobei zwei verschiedene TLS-Zertifikate verwendet werden, wie in dieser Abbildung dargestellt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Der Client sendet eine HTTPS-Anforderung an den Domänennamen: bicycle.contoso.com. Dieser Name wird über einen DNS-A-Datensatz der öffentlichen IP-Adresse von Azure Application Gateway zugeordnet. Dieser Datenverkehr wird verschlüsselt, um sicherzustellen, dass der Datenverkehr 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 (WAF) und handelt den TLS-Handshake für bicycle.contoso.com aus, sodass nur sichere Chiffren möglich sind. Application Gateway ist ein TLS-Abschlusspunkt, erzwingt die Verarbeitung von WAF-Überprüfungsregeln und führt Routingregeln aus, mit denen der Datenverkehr an das konfigurierte Back-End weitergeleitet wird. Das TLS-Zertifikat wird in Azure Key Vault gespeichert. Der Zugriff erfolgt über eine benutzerseitig zugewiesene verwaltete Identität, die in Application Gateway integriert ist. Weitere Informationen zu diesem Feature finden Sie unter TLS-Terminierung mit Key Vault-Zertifikaten.

3. Der Datenverkehr von Application Gateway zum Back-End wird nochmals mit einem anderen TLS-Zertifikat (Platzhalter für „*.aks-ingress.contoso.com“) verschlüsselt, während er an den internen Lastenausgleich weitergeleitet wird. Durch diese erneute Verschlüsselung wird sichergestellt, dass kein unsicherer Datenverkehr in das Clustersubnetz gelangt.

4. Der Eingangscontroller empfängt den verschlüsselten Datenverkehr über den Lastenausgleich. Der Controller ist ein weiterer TLS-Abschlusspunkt für *.aks-ingress.contoso.com, der den Datenverkehr über HTTP an die Workloadpods weiterleitet. Die Zertifikate werden in Azure Key Vault gespeichert und mit dem Container Storage Interface-Treiber (CSI) im Cluster eingebunden. Weitere Informationen finden Sie unter Hinzufügen einer Geheimnisverwaltung.

Sie können End-to-End-TLS-Datenverkehr vollständig an jedem Hop im Pfad zum Workloadpod 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 Cluster mit nur einem Mandanten und ordnungsgemäßer RBAC auf Steuerungsebene sowie ausgereiften Verfahren für den Lebenszyklus der Softwareentwicklung reicht eine TLS-Verschlüsselung bis zum Eingangsdatencontroller und der Schutz mit Web Application Firewall (WAF) aus. Dadurch werden der Aufwand bei der Verwaltung von Workloads und die Auswirkungen auf die Netzwerkleistung minimiert. Ihre Workload- und Complianceanforderungen geben vor, wo der TLS-Abschluss erfolgt.

Ausgehender Datenverkehrsfluss

In dieser Architektur empfehlen wir, den gesamten ausgehenden Datenverkehr des Clusters, der über Azure Firewall oder über Ihre eigene ähnliche virtuelle Netzwerkappliance kommuniziert, über andere Optionen wie NAT Gateway oder HTTP-Proxy abzuwickeln. Für die Zero-Trust-Steuerung und die Möglichkeit, den Datenverkehr zu überprüfen, wird der gesamte ausgehende Datenverkehr aus dem Cluster über Azure Firewall geleitet. Sie können dies mithilfe von benutzerdefinierten Routen (User-Defined Route, UDR) implementieren. Der nächste Hop auf der Route ist die private IP-Adresse von Azure Firewall. Hier entscheidet Azure Firewall, ob der ausgehende Datenverkehr blockiert oder zugelassen wird. Diese Entscheidung basiert auf den spezifischen Regeln, die in Azure Firewall definiert sind, oder auf den integrierten Threat Intelligence-Regeln.

Eine Alternative zu Azure Firewall stellt das Feature HTTP-Proxy von AKS dar. Der gesamte ausgehende Datenverkehr des Clusters wird zunächst auf die IP-Adresse des HTTP-Proxys festgelegt. Dieser entscheidet dann, ob der Datenverkehr weitergeleitet oder verworfen wird.

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

Eine Ausnahme von der Zero-Trust-Steuerung ist, wenn der Cluster mit anderen Azure-Ressourcen kommunizieren muss, z. B., wenn er ein aktualisiertes Image aus der Containerregistrierung oder Geheimnisse aus Azure Key Vault abrufen muss. Die empfohlene Vorgehensweise ist die Verwendung von Azure Private Link. Der Vorteil besteht darin, dass bestimmte Subnetze den Dienst direkt erreichen und der Datenverkehr zwischen Cluster und Diensten nicht über das Internet übermittelt wird. Ein Nachteil ist, dass Private Link eine zusätzliche Konfiguration erfordert, anstatt den Zieldienst über seinen öffentlichen Endpunkt zu verwenden. Außerdem unterstützen nicht alle Azure-Dienste oder SKUs Private Link. In diesen Fällen empfiehlt es sich gegebenenfalls, einen VNET-Dienstendpunkt im Subnetz zu aktivieren, um auf den Dienst zuzugreifen.

Wenn Private Link oder Dienstendpunkte keine Option sind, können Sie andere Dienste über deren öffentliche Endpunkte erreichen und den Zugriff über Azure Firewall-Regeln und die in den Zieldienst integrierte Firewall steuern. Da dieser Datenverkehr über die statischen IP-Adressen der Firewall geleitet wird, können diese Adressen der Liste zugelassener IP-Adressen des Diensts hinzugefügt werden. Ein Nachteil ist, dass Azure Firewall zusätzliche Regeln benötigt, um sicherzustellen, dass nur Datenverkehr aus einem bestimmten Subnetz zugelassen wird. Berücksichtigen Sie diese Adressen, wenn Sie mehrere IP-Adressen für ausgehenden Datenverkehr mit Azure Firewall planen, da Ihnen sonst womöglich die Ports ausgehen. Weitere Informationen zur Planung mehrerer IP-Adressen finden Sie unter Einschränken von ausgehendem Datenverkehr mithilfe von Azure Firewall.

Informationen zu Windows-spezifischen Ausgangsüberlegungen, die in der AKS-Baseline-Referenzarchitektur für Windows-Container verwendet werden, finden Sie im Begleitartikel.

Datenverkehr zwischen Pods

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 mit Bedacht an, da es andernfalls vorkommen kann, dass ein wichtiger Netzwerkdatenfluss blockiert wird. Erlauben Sie bestimmte Kommunikationspfade nur, wenn sie wirklich erforderlich sind, z. B. den Datenverkehr zwischen dem Eingangscontroller und der Workload. Weitere Informationen finden Sie unter Netzwerkrichtlinien.

Aktivieren Sie die Netzwerkrichtlinie bei der Bereitstellung des Clusters, da sie später nicht mehr hinzugefügt werden kann. Es gibt einige Auswahlmöglichkeiten an Technologien, die NetworkPolicy implementieren. Die Azure-Netzwerkrichtlinie wird empfohlen. Sie erfordert Azure Container Networking Interface (CNI). Weitere Informationen hierzu finden Sie im nachstehenden Hinweis. 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 durch den Azure-Standardsupport abgedeckt.

Weitere Informationen finden Sie unter Unterschiede zwischen Azure- und Calico-Richtlinien und zwischen ihren Funktionen.

Verwaltungsdatenverkehr

Im Rahmen der Clusterausführung empfängt der Kubernetes-API-Server Datenverkehr von Ressourcen, die Verwaltungsvorgänge im Cluster durchführen möchten, z. B. Anforderungen zum Erstellen von Ressourcen oder zum Skalieren des Clusters. Beispiele für diese Ressourcen sind der Build-Agent-Pool in einer DevOps-Pipeline, ein Bastion-Subnetz und die eigentlichen Knotenpools. Anstatt diesen Verwaltungsdatenverkehr von allen IP-Adressen zu akzeptieren, verwenden Sie das AKS-Feature für autorisierte IP-Bereiche, um nur Datenverkehr von Ihren autorisierten IP-Adressbereichen an den API-Server zuzulassen.

Weitere Informationen finden Sie unter Definieren der vom API-Server autorisierten IP-Bereiche.

Wenn Sie eine zusätzliche Steuerungsebene benötigen, können Sie einen privaten AKS-Cluster bereitstellen. Dies führt allerdings zu mehr Komplexität. Durch die Verwendung eines privaten Clusters können Sie sicherstellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und den Knotenpools das private Netzwerk nicht verlässt und nicht für das Internet verfügbar gemacht wird. Weitere Informationen finden Sie unter Erstellen eines privaten Azure Kubernetes Service-Clusters.

Hinzufügen einer Geheimnisverwaltung

Speichern Sie Geheimnisse in einem verwalteten Schlüsselspeicher wie Azure Key Vault. Der Vorteil besteht darin, dass der verwaltete Speicher die Rotation von Geheimnissen übernimmt, starke Verschlüsselung bietet, ein Zugriffsüberwachungsprotokoll bereitstellt und zentrale Geheimnisse von der Bereitstellungspipeline fern hält. In dieser Architektur ist Azure Key Vault Firewall aktiviert und mit Private Link-Verbindungen für die Ressourcen in Azure konfiguriert, die auf Geheimnisse und Zertifikate zugreifen müssen.

Azure Key Vault ist gut mit anderen Azure-Diensten integriert. Verwenden Sie die integrierten Funktionen dieser Dienste für den Zugriff auf Geheimnisse. Ein Beispiel für den Zugriff auf TLS-Zertifikate für den eingehenden Datenverkehr durch Azure Application Gateway finden Sie im Abschnitt Eingehender Datenverkehrsfluss.

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 Gewähren des Zugriffs auf Key Vault-Schlüssel, -Zertifikate und -Geheimnisse mit der rollenbasierten Zugriffssteuerung in Azure.

Zugreifen auf Clustergeheimnisse

Sie müssen vom Workloadidentitäten verwenden, um einem Pod den Zugriff auf Geheimnisse in einem bestimmten Speicher zu ermöglichen. Verwenden Sie zum Vereinfachen des Abrufvorgangs den Secrets Store CSI-Treiber. Wenn der Pod ein Geheimnis erfordert, stellt der Treiber eine Verbindung mit dem angegebenen Speicher her, ruft das Geheimnis auf einem Volume ab und bindet 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. In dieser Implementierung wurde der Treiber für Azure Key Vault mit Secrets Store CSI ausgewählt, um das TLS-Zertifikat unter Verwendung des Add-Ons aus Azure Key Vault abzurufen und in den Pod zu laden, auf dem der Eingangsdatencontroller ausgeführt wird. Dies erfolgt bei der Poderstellung, und auf dem Volume werden sowohl die öffentlichen als auch die privaten Schlüssel gespeichert.

Workloadspeicher

Die in dieser Architektur verwendete Workload ist zustandslos. Wenn Sie den Zustand speichern müssen, wird empfohlen, diesen außerhalb des Clusters persistent zu speichern. Ein Leitfaden zum Workloadzustand überschreitet den Rahmen dieses Artikels.

Weitere Informationen zu Speicheroptionen finden Sie unter Speicheroptionen für Anwendungen in Azure Kubernetes Service (AKS).

Richtlinienverwaltung

Eine effektive Möglichkeit zur Verwaltung eines AKS-Clusters ist das Erzwingen von Governance über Richtlinien. Kubernetes implementiert Richtlinien über den OPA-Gatekeeper. Bei AKS werden Richtlinien über Azure Policy bereitgestellt. Jede Richtlinie wird auf alle Cluster in ihrem Bereich angewendet. Die Azure Policy-Erzwingung wird letztendlich von OPA-Gatekeeper im Cluster verarbeitet, und alle Richtlinienüberprüfungen werden protokolliert. Richtlinienänderungen werden nicht sofort in Ihrem Cluster widergespiegelt. Einige Verzögerungen sind zu erwarten.

Für die Verwaltung Ihrer AKS-Cluster bietet Azure Policy zwei verschiedene Szenarien:

• Verhindern oder Einschränken der Bereitstellung von AKS-Clustern in einer Ressourcengruppe oder in einem Abonnement durch Auswerten der Standards Ihrer Organisation. Beispielsweise Einhalten einer Benennungskonvention, Angeben eines Tags usw.
• Schützen Ihres AKS-Clusters über Azure Policy für Kubernetes

Beim Festlegen von Richtlinien wenden Sie diese basierend auf den Anforderungen der Workload an. Beachten Sie folgende Faktoren:

• Möchten Sie eine Sammlung von Richtlinien (sogenannte Initiativen) festlegen oder einzelne Richtlinien auswählen? Azure Policy bietet zwei integrierte Initiativen: „basic“ und „restricted“. Jede Initiative ist eine Sammlung integrierter Richtlinien, die für einen AKS-Cluster gelten. Es wird empfohlen, eine Initiative auswählen und zusätzliche Richtlinien für den Cluster und die Ressourcen (ACR, Application Gateway, Key Vault und andere) auswählen, die gemäß den Anforderungen Ihrer Organisation mit dem Cluster interagieren.

• Möchten Sie die Aktion überwachen oder verweigern? 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 Modus Verweigern wird die Aktion blockiert, da sie gegen die Richtlinie verstößt. Seien Sie vorsichtig bei der Auswahl dieses Modus, da er u. U. so restriktiv ist, dass die Workload nicht funktioniert.

• Gibt es Bereiche in der Workload, die nicht entwurfsbedingt konform sein sollten? Azure Policy verfügt über die Möglichkeit, Kubernetes-Namespaces anzugeben, die von der Richtlinienerzwingung ausgenommen sind. Es wird empfohlen, Richtlinien weiterhin im Überwachungsmodus anzuwenden, damit Sie diese Instanzen kennen.

• Verfügen Sie über Anforderungen, die nicht von den integrierten Richtlinien abgedeckt werden? Sie können eine benutzerdefinierte Azure Policy-Definition erstellen, mit der die benutzerdefinierten OPA-Gatekeeper-Richtlinien angewendet werden. Wenden Sie benutzerdefinierte Richtlinien nicht direkt auf den Cluster an. Weitere Informationen zur Erstellung benutzerdefinierter Richtlinien finden Sie unter Erstellen und Zuweisen einer benutzerdefinierten Richtliniendefinition (Vorschau).

• Haben Sie organisationsweite Anforderungen? 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 die Organisation über generische Richtlinien verfügt.

• Azure-Richtlinien werden bestimmten Bereichen zugewiesen. Stellen Sie sicher, dass die Richtlinien für die Produktion auch anhand ihrer Präproduktionsumgebung überprüft werden. Andernfalls können bei der Bereitstellung in der Produktionsumgebung unerwartete zusätzliche Einschränkungen auftreten, die in der Präproduktionsumgebung nicht berücksichtigt wurden.

In dieser Referenzimplementierung ist Azure Policy beim Erstellen des AKS-Clusters aktiviert und weist die restriktive Initiative im Überwachungsmodus zu, um Einblick in die Nichtkonformität zu erhalten.

Außerdem werden durch die Implementierung zusätzliche Richtlinien festgelegt, die nicht Teil integrierter Initiativen sind. Diese Richtlinien werden im Modus Verweigern festgelegt. Beispielsweise gibt es eine Richtlinie, um sicherzustellen, dass Images nur aus dem bereitgestellten ACR abgerufen werden. Erstellen Sie ggf. eigene benutzerdefinierte Initiativen. Fassen Sie die Richtlinien, die für Ihre Workload gelten, in einer einzigen Zuweisung zusammen.

Greifen Sie auf die Podprotokolle für alle Pods im gatekeeper-system-Namespace sowie auf die Protokolle für die azure-policy- und azure-policy-webhook-Pods im kube-system-Namespace zu, um zu beobachten, wie Azure Policy innerhalb Ihres Clusters funktioniert.

Informationen zu Windows-spezifischen Azure Policy-Überlegungen, die in der AKS-Baseline-Referenzarchitektur für Windows-Container enthalten sind, finden Sie im Begleitartikel.

Skalierbarkeit für Knoten und Pods

Mit zunehmender Nachfrage kann Kubernetes aufskaliert werden, indem vorhandenen Knoten über HPA (horizontale automatische Podskalierung) weitere Pods hinzugefügt werden. Wenn keine weiteren Pods mehr geplant werden können, muss die Anzahl der Knoten über die 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.

Bei der manuellen oder programmgesteuerten Methode müssen Sie die CPU-Auslastung oder benutzerdefinierte Metriken überwachen und entsprechende Warnungen einrichten. Für die Podskalierung kann der Anwendungsbediener die Anzahl von Podreplikaten erhöhen oder verringern, indem er ReplicaSet über Kubernetes-APIs anpasst. Bei der Clusterskalierung besteht eine Möglichkeit 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 Anzahl der Knoten über die Azure-Befehlszeilenschnittstelle oder das Portal anpassen.

Die automatische Skalierung ist der empfohlene Ansatz, da einige dieser manuellen Mechanismen in die automatische Skalierung 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. Informationen zu einem Leistungsoptimierungsszenario mit AKS finden Sie unter Leistungsoptimierungsszenario: Verteilte Geschäftstransaktionen.

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.

Es wird für die HPA-Ressource empfohlen, die Mindest- und Höchstanzahl von Replikaten festzulegen. Diese Werte schränken die Grenzen für die automatische Skalierung ein.

HPA kann anhand der CPU-Auslastung, der Speicherauslastung und benutzerdefinierter Metriken skalieren. Standardmäßig wird nur die CPU-Auslastung berücksichtigt. Die Definition HorizontalPodAutoscaler gibt Zielwerte für diese Metriken an. Beispielsweise wird in der Spezifikation eine CPU-Zielauslastung festgelegt. Während der Ausführung von Pods überprüft der HPA-Controller die CPU-Auslastung der einzelnen Pods mithilfe der Kubernetes-Metrik-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.

Möglicherweise gibt es eine Racebedingung, bei der HPA die Überprüfung durchführt, bevor ein Skalierungsvorgang abgeschlossen ist. Das Ergebnis ist möglicherweise eine falsche Verhältnisberechnung. Ausführliche Informationen finden Sie unter Abkühlung der Skalierung von Ereignissen.

Wenn Ihre Workload ereignisgesteuert ist, stellt KEDA eine beliebte Open-Source-Option dar. Wenn Ihre Workload von einer Ereignisquelle wie einer Nachrichtenwarteschlange gesteuert wird und nicht an CPU oder Speicher gebunden ist, sollten Sie KEDA in Erwägung ziehen. KEDA unterstützt viele Ereignisquellen (oder Scaler). Sie finden die Liste der unterstützten KEDA-Scaler hier einschließlich Azure Monitor Scaler. Dies stellt eine bequeme Möglichkeit zum Skalieren von KEDA-Workloads basierend auf Azure Monitor-Metriken dar.

Automatische Clusterskalierung

Die automatische Clusterskalierung ist eine AKS-Add-On-Komponente, die die Anzahl der Knoten in einem Knotenpool skaliert. Sie sollte bei der Clusterbereitstellung hinzugefügt werden. Für jeden Benutzerknotenpool wird eine separate automatische Clusterskalierung benötigt.

Die automatische Clusterskalierung wird vom Kubernetes-Planer ausgelöst. Wenn der Kubernetes-Planer aufgrund von Ressourcenbeschränkungen einen Pod nicht planen kann, stellt die automatische Skalierung automatisch einen neuen Knoten im Knotenpool bereit. Umgekehrt überprüft die automatische Clusterskalierung die nicht genutzte Kapazität der Knoten. Wenn der Knoten nicht mit der erwarteten Kapazität ausgeführt wird, werden die Pods auf einen anderen Knoten verschoben, und der nicht genutzte Knoten wird entfernt.

Beim Aktivieren der automatischen Skalierung 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 einfachen Workload auf 2 festgelegt.

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

Informationen zu Skalierungsüberlegungen, die in der AKS-Baseline-Referenzarchitektur für Windows-Container enthalten sind, finden Sie im Begleitartikel.

Entscheidungen zur Geschäftskontinuität

Um die Geschäftskontinuität aufrechtzuerhalten, definieren Sie eine Vereinbarung zum Servicelevel für die Infrastruktur und Ihre Anwendung. Informationen zur Berechnung der monatlichen Betriebszeit finden Sie in der SLA für Azure Kubernetes Service (AKS).

Clusterknoten

Um die Mindestverfügbarkeit für Workloads zu erreichen, sind mehrere Knoten in einem Knotenpool erforderlich. Wenn ein Knoten ausfällt, kann die Anwendung auf einem anderen Knoten im Knotenpool im selben Cluster weiterhin ausgeführt werden. Aus Gründen der Zuverlässigkeit werden für den Systemknotenpool drei Knoten empfohlen. Beginnen Sie für den Benutzerknotenpool mit mindestens zwei Knoten. Wenn Sie eine höhere Verfügbarkeit benötigen, stellen Sie weitere Knoten bereit.

Isolieren Sie Ihre Anwendungen von den Systemdiensten, indem Sie sie in einem separaten Knotenpool (Benutzerknotenpool) platzieren. Dadurch werden Kubernetes-Dienste auf dedizierten Knoten ausgeführt und konkurrieren nicht mit Ihrer Workload. Die Verwendung von Tags, Bezeichnungen und Taints wird empfohlen, um den Knotenpool für die Workloadplanung anzugeben und sicherzustellen, dass Ihr Systemknotenpool mit dem [Taint] (/azure/aks/use-system-pools#system-and-user-node-pools) CriticalAddonsOnly versehen ist.

Für die Zuverlässigkeit ist eine regelmäßige Wartung Ihres Clusters entscheidend, z. B. mit schnellen Updates. Außerdem wird empfohlen, die Integrität der Pods mithilfe von Tests zu überwachen.

Podverfügbarkeit

Sicherstellen von Podressourcen. Es wird dringend empfohlen, in Bereitstellungen Podressourcenanforderungen anzugeben. Der Planer kann den Pod dann ordnungsgemäß planen. Die Zuverlässigkeit nimmt deutlich ab, wenn Pods nicht geplant werden können.

Festlegen von Budgets für die Unterbrechung von Pods. Mit dieser Einstellung wird festgelegt, wie viele Replikate in einer Bereitstellung bei einem Update- oder Upgradereignis außer Betrieb genommen werden können. Weitere Informationen finden Sie unter Budgets für die Unterbrechung von Pods.

Konfigurieren Sie mehrere Replikate in der Bereitstellung, um Unterbrechungen wie Hardwarefehler zu behandeln. Bei geplanten Ereignissen wie Updates und Upgrades kann ein Unterbrechungsbudget sicherstellen, dass die erforderliche Anzahl von Podreplikaten für die erwartete Anwendungslast vorhanden ist.

Festlegen von Ressourcenkontingenten für die Workloadnamespaces. Das Ressourcenkontingent für einen Namespace stellt sicher, dass Podanforderungen und -grenzwerte für eine Bereitstellung ordnungsgemäß festgelegt werden. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten.

Festlegen von Podanforderungen und -grenzwerten. Durch Festlegen dieser Grenzwerte kann Kubernetes den Pods effizient CPU- und/oder Arbeitsspeicherressourcen zuweisen und eine höhere Containerdichte auf einem Knoten erreichen. Grenzwerte können durch bessere Hardwarenutzung auch die Zuverlässigkeit mit geringeren Kosten erhöhen.

Um die Grenzwerte abzuschätzen, testen und erstellen Sie eine Baseline. Beginnen Sie mit gleichen Werten für Anforderungen und Grenzwerte. Optimieren Sie diese Werte dann nach und nach, bis Sie einen Schwellenwert festgelegt haben, der eine Instabilität im Cluster verursachen kann.

Diese Grenzwerte können in Ihren Bereitstellungsmanifesten angegeben werden. Weitere Informationen finden Sie unter Festlegen von Podanforderungen und -grenzwerten.

Verfügbarkeitszonen und Unterstützung von mehreren Regionen

Wenn Ihre SLA eine höhere Uptime erfordert, verwenden Sie Verfügbarkeitszonen, um sich vor Ausfällen zu schützen. Sie können Verfügbarkeitszonen verwenden, wenn sie von der Region unterstützt werden. Sowohl die Komponenten der Steuerungsebene als auch die Knoten in den Knotenpools können sich dann über Zonen hinweg erstrecken. 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. Vorgänge in Skalierungsgruppen und Konfigurationen werden vom AKS-Dienst verwaltet. Hier sind einige Aspekte angegeben, die beim Aktivieren der Verfügbarkeit in mehreren Zonen berücksichtigt werden sollten:

• Gesamte Infrastruktur. Wählen Sie eine Region aus, die Verfügbarkeitszonen unterstützt. Weitere Informationen finden Sie unter Einschränkungen und regionale Verfügbarkeit. Wenn Sie eine Betriebszeit-SLA erwerben möchten, wählen Sie eine Region aus, die diese Option unterstützt. Bei Verwendung von Verfügbarkeitszonen ist die Betriebszeit-SLA höher.

• Cluster. Verfügbarkeitszonen können nur beim Erstellen des Knotenpools festgelegt und 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 dieselbe Hardwarekonfiguration zonenübergreifend bereit.

  Die Unterstützung mehrerer Zonen gilt nicht nur für Knotenpools, sondern auch für die Steuerungsebene. Die AKS-Steuerungsebene erstreckt sich wie die Knotenpools über die angeforderten Zonen. Wenn Sie keine Zonenunterstützung in Ihrem Cluster verwenden, ist nicht gewährleistet, dass sich die Komponenten der Steuerungsebene über mehrere Verfügbarkeitszonen erstrecken.

• Abhängige Ressourcen. Um alle Vorteile aus den Zonen schöpfen zu können, müssen alle Dienstabhängigkeiten ebenfalls 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.

Beispielsweise ist ein verwalteter Datenträger in der Zone verfügbar, in der er bereitgestellt wurde. Bei einem Ausfall wird der Knoten möglicherweise in eine andere Zone verschoben, der verwaltete Datenträger wird jedoch nicht mit dem Knoten in diese Zone verschoben.

Der Einfachheit halber wird AKS in dieser Architektur in einer einzelnen Region mit Knotenpools bereitgestellt, die die Verfügbarkeitszonen 1, 2 und 3 umfassen. Andere Ressourcen der Infrastruktur wie z. B. Azure Firewall und Application Gateway werden in derselben Region ebenfalls mit Unterstützung mehrerer Zonen bereitgestellt. Die Georeplikation ist für Azure Container Registry aktiviert.

Mehrere Regionen

Die Aktivierung von Verfügbarkeitszonen ist nicht ausreichend, wenn die gesamte Region ausfällt. Um eine höhere Verfügbarkeit zu erhalten, führen Sie mehrere AKS-Cluster in unterschiedlichen Regionen aus.

• Verwenden Sie Regionspaare. Ziehen Sie die Verwendung einer CI/CD-Pipeline ein Betracht, die für die Verwendung eines Regionspaars für die Wiederherstellung nach Regionsausfällen konfiguriert ist. Ein Vorteil der Verwendung von Regionspaaren ist die Zuverlässigkeit bei Updates. Azure stellt sicher, dass jeweils nur eine Region im Paar aktualisiert wird. Bestimmte DevOps-Tools wie Flux können die Bereitstellung in mehreren Regionen vereinfachen.

• Wenn eine Azure-Ressource georedundante Redundanz unterstützt, geben Sie den Standort an, an dem sich die sekundäre Datenbank des redundanten Diensts befinden soll. Durch Aktivieren der Georeplikation für Azure Container Registry werden Images beispielsweise automatisch in die ausgewählten Azure-Regionen repliziert, und der Zugriff auf Images wird auch dann fortgesetzt, wenn ein Ausfall in einer Region auftritt.

• Wählen Sie einen Datenverkehrsrouter aus, der den Datenverkehr abhängig von Ihrer Anforderung über Zonen oder Regionen verteilen kann. In dieser Architektur wird Azure Load Balancer bereitgestellt, da hiermit websitefremder Datenverkehr über Zonen hinweg verteilt werden kann. Wenn Sie Datenverkehr über Regionen hinweg verteilen müssen, sollten Sie Azure Front Door in Erwägung ziehen. Weitere Überlegungen finden Sie unter Auswählen eines Lastenausgleichs.

Notfallwiederherstellung

Bei einem Ausfall in der primären Region sollten Sie in der Lage sein, schnell eine neue Instanz in einer anderen Region zu erstellen. Hier sind einige Empfehlungen dafür:

• Verwenden Sie Regionspaare.

• Eine nicht zustandsbehaftete Workload kann effizient repliziert werden. Wenn Sie den Zustand im Cluster speichern müssen (nicht empfohlen), stellen Sie sicher, dass die Daten in der gekoppelten Region häufig gesichert werden.

• Integrieren Sie die Wiederherstellungsstrategie, etwa die Replikation in eine andere Region, als Teil der DevOps-Pipeline, um Ihre Service Level-Ziele (Service Level Objectives, SLO) zu erfüllen.

• Wählen Sie bei der Bereitstellung der einzelnen Azure-Dienste Features aus, die die Notfallwiederherstellung unterstützen. In dieser Architektur ist beispielsweise Azure Container Registry für die Georeplikation aktiviert. Wenn eine Region ausfällt, können Sie weiterhin Images aus dem replizierten Bereich pullen.

Clustersicherung

Viele Architekturen ermöglichen die Bereitstellung eines neuen Clusters und dessen Rückgabe in den Betriebszustand über GitOps-basiertes [Cluster bootstrapping}(#cluster-bootstrapping) gefolgt von der Anwendungsbereitstellung. Wenn es jedoch kritische Ressourcenzustände wie Konfigurationszuordnungen, Aufträge und potenziell Geheimnisse gibt, die aus irgendeinem Grund nicht innerhalb Ihres Bootstrapping-Prozesses erfasst werden können, sollten Sie Ihre Wiederherstellungsstrategie überdenken. Es wird allgemein empfohlen, zustandslose Workloads in Kubernetes auszuführen. Sollte Ihre Architektur jedoch einen datenträgerbasierten Zustand umfassen, müssen Sie auch Ihre Wiederherstellungsstrategie für diesen Inhalt überdenken.

Wenn die Clustersicherung Teil Ihrer Wiederherstellungsstrategie sein muss, müssen Sie eine Lösung installieren, die Ihren geschäftlichen Anforderungen innerhalb des Clusters entspricht. Dieser Agent ist für das Pushen des Clusterressourcenstatus an ein Ziel Ihrer Wahl und die Koordinierung von Momentaufnahmen persistenter Datenträger in Azure-Datenträgern verantwortlich.

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

Die Referenzimplementierung implementiert keine Sicherung, die zusätzliche Azure-Ressourcen in der Architektur zum Verwalten, Überwachen, Bezahlen und Sichern umfasst, wie ein Azure Storage-Konto, eine Azure Backup Tresor und Konfiguration und vertrauenswürdiger Zugriff. GitOps in Kombination mit der Absicht, zustandslose Workloads auszuführen, ist die implementierte Wiederherstellungslösung.

Wählen und überprüfen Sie eine Lösung, die Ihr Geschäftsziel erfüllt, einschließlich Ihres definierten Recovery-Point Objective (RPO) und Recovery-Time Objective (RTO). Definieren Sie diesen Wiederherstellungsprozess in einem Teamrunbook, und setzen Sie ihn für alle unternehmenskritischen Workloads um.

Kubernetes-API-Server-SLA

AKS kann als kostenloser Dienst verwendet werden, dieser Tarif bietet jedoch keine finanziell abgesicherte SLA. Um diese SLA zu erhalten, müssen Sie die Standardebene auswählen. Es wird empfohlen, diese Standardebene für alle Produktionscluster zu verwenden. Reservieren Sie Cluster des Free-Tarifs für Vorproduktionscluster. In Kombination mit Azure-Verfügbarkeitszonen wird die SLA des Kubernetes-API-Servers auf 99,95 % erhöht. Ihre Knotenpools und andere Ressourcen sind unter einer eigenen SLA abgedeckt.

Kompromiss

Für die Bereitstellung der Architektur über Zonen und insbesondere über Regionen hinweg bringen Kostenersparnisse eine geringere Verfügbarkeit mit sich. Einige Replikationsfunktionen wie die Georeplikation in Azure Container Registry sind in Premium-SKUs verfügbar, die jedoch kostenaufwendiger sind. Die Kosten steigen auch, da Bandbreitengebühren anfallen, wenn der Datenverkehr über Zonen und Regionen hinweg übertragen wird.

Rechnen Sie außerdem mit einer zusätzlichen Netzwerklatenz bei der Knotenkommunikation zwischen Zonen oder Regionen. Messen Sie die Auswirkung dieser Architekturentscheidung auf Ihre Workload.

Testen mit Simulationen und erzwungenen Failovern

Gewährleisten Sie die Zuverlässigkeit durch erzwungene Failovertests mit simulierten Ausfällen, z. B. durch Beenden eines Knotens, durch Herunterfahren aller AKS-Ressourcen in einer bestimmten Zone, um einen Zonenausfall zu simulieren, oder durch Herbeiführen eines externen Abhängigkeitsfehlers. Azure Chaos Studio kann auch genutzt werden, um verschiedene Arten von Ausfällen in Azure und im Cluster zu simulieren.

Weitere Informationen finden Sie unter Was ist Azure Chaos Studio (Vorschauversion)?.

Überwachen und Sammeln von Metriken

Azure Monitor Container Insights ist das empfohlene Tool für die Überwachung der Leistung von Containerworkloads, da Ereignisse in Echtzeit betrachtet werden können. Es erfasst Containerprotokolle von den ausgeführten Pods und aggregiert sie für die Anzeige. 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 damit auch die Leistung beim Skalieren von Pods überwachen. Es umfasst die Sammlung wichtiger Telemetriedaten für die Überwachung, die Analyse und Visualisierung der gesammelten Daten, um Trends zu identifizieren, sowie die Konfiguration von Warnungen, um proaktiv über kritische Probleme informiert zu werden.

Die meisten in Pods gehosteten Workloads geben Prometheus-Metriken aus. Container Insights kann in Prometheus integriert werden, um gesammelte Anwendungs- und Workloadmetriken von Knoten und Kubernetes anzuzeigen.

Es gibt auch einige Drittanbieterlösungen mit Kubernetes-Integration, die Sie nutzen können, falls Ihre Organisation sie bereits verwendet. Beispiele wären etwa Datadog, Grafana und New Relic.

Mit AKS verwaltet Azure einige wichtige Kubernetes-Dienste, und die Protokolle für die AKS-Steuerungsebenenkomponenten werden in Azure als Ressourcenprotokolle implementiert. Es wird empfohlen, dass für die meisten Cluster jederzeit Folgendes aktiviert ist, da sie Ihnen bei der Behandlung von Clusterproblemen helfen können und eine relativ niedrige Protokolldichte aufweisen:

• Protokollierung von ClusterAutoscaler für Einblicke in die Skalierungsvorgänge. Weitere Informationen finden Sie unter Abrufen von Protokollen und Status der automatischen Clusterskalierung.
• KubeControllerManager für Einblicke in die Interaktion zwischen Kubernetes und der Azure-Steuerungsebene.
• KubeAuditAdmin für Einblicke in Aktivitäten, die Ihren Cluster ändern. Es gibt keinen Grund, sowohl KubeAudit als auch KubeAuditAdmin aktiviert zu haben, da KubeAudit eine Obermenge von KubeAuditAdmin ist, die ebenfalls nicht ändernde (Lese-)Vorgänge enthält.
• Guard erfasst Microsoft Entra ID- und Azure RBAC-Audits.

Die Aktivierung anderer Protokollkategorien (z. B. KubeScheduler oder KubeAudit) kann während der frühen Entwicklung des Cluster- oder Workloadlebenszyklus möglicherweise sehr hilfreich sein, wo dem Cluster die hinzugefügte automatische Skalierung, Podplatzierung und Planung sowie ähnliche Daten bei der Beseitigung von Bedenken hinsichtlich des Cluster- oder Workloadbetriebs helfen können. Die dauerhafte Aktivierung der erweiterten Problembehandlungsprotokolle kann, sobald sich die Problembehandlungsanforderungen erledigt haben, als unnötige Kosten für die Erfassung und Speicherung in Azure Monitor betrachtet werden.

In Azure Monitor ist bereits eine Reihe von Protokollabfragen vorhanden. Diese können auch als Grundlage für Ihre eigenen Abfragen genutzt werden. Mit zunehmender Größe Ihrer Bibliothek können Sie Protokollabfragen unter Verwendung von Abfragepaketen speichern und wiederverwenden. Ihre benutzerdefinierte Abfragebibliothek bietet zusätzliche Einblicke in die Integrität und Leistung Ihrer AKS-Cluster und unterstützt Ihre Servicelevelziele (Service Level Objectives, SLOs).

Weitere Informationen zu unseren bewährten Methoden für die Überwachung von AKS finden Sie unter Überwachen von Azure Kubernetes Service (AKS) mit Azure Monitor.

Informationen zu Windows-spezifischen Aspekten der Überwachung, die in der AKS-Baseline-Referenzarchitektur für Windows-Container enthalten sind, finden Sie im Begleitartikel.

Aktivieren der Selbstreparatur

Überwachen Sie die Integrität von Pods, indem Sie Live- und Bereitschaftstests festlegen. Wenn ein nicht reagierender Pod erkannt wird, startet Kubernetes den Pod neu. Mit dem Livetest wird ermittelt, ob der Pod fehlerfrei ist. Wenn der Pod nicht antwortet, wird er von Kubernetes neu gestartet. Der Bereitschaftstest ermittelt, ob der Pod zum Empfangen von Anforderungen/Datenverkehr bereit ist.

AKS-Cluster-Updates

Die Festlegung einer Aktualisierungsstrategie, die mit den Geschäftsanforderungen übereinstimmt, ist von größter Bedeutung. Der Grad der Vorhersagbarkeit des Datums und der Uhrzeit, zu der die AKS-Cluster-Version oder die Knoten aktualisiert werden, und der gewünschte Grad der Kontrolle darüber, welches spezifische Image oder welche Binärdateien installiert werden, sind grundlegende Aspekte, die Ihren AKS-Cluster-Aktualisierungsplan abstecken werden. Die Vorhersagbarkeit ist an zwei Haupteigenschaften von AKS-Cluster-Updates gebunden, nämlich an die Aktualisierungshäufigkeit und das Wartungsfenster. Kontrollieren Sie, ob Updates manuell oder automatisch installiert werden. Unternehmen mit AKS-Clustern, die keinen strengen Sicherheitsvorschriften unterliegen, können wöchentliche oder sogar monatliche Updates in Betracht ziehen, während die übrigen Unternehmen sicherheitsrelevante Patches aktualisieren müssen, sobald sie verfügbar sind (täglich). Unternehmen, die AKS-Cluster als unveränderliche Infrastruktur betreiben, aktualisieren diese nicht. Das bedeutet, dass weder automatische noch manuelle Aktualisierungen durchgeführt werden. Wenn ein gewünschtes Update verfügbar ist, wird stattdessen ein Replikationsstempel bereitgestellt, und erst wenn die neue Infrastrukturinstanz bereit ist, wird die alte geleert, was ihnen ein Höchstmaß an Kontrolle bietet.

Sobald der AKS-Cluster-Update-Blueprint festgelegt ist, kann dieser einfach auf die verfügbaren Update-Optionen für AKS-Knoten und AKS-Cluster-Version abgebildet werden:

• AKS-Knoten:

  1. Keine/manuelle Aktualisierungen: Dies gilt für unveränderliche Infrastrukturen oder wenn manuelle Aktualisierungen bevorzugt werden. Dadurch wird ein höheres Maß an Vorhersehbarkeit und Kontrolle über die Aktualisierungen der AKS-Knoten erreicht.
  2. Automatische unbeaufsichtigte Updates: AKS führen native Betriebssystem-Updates aus. Dies bietet Vorhersehbarkeit durch die Konfiguration von Wartungsfenstern, die auf die Bedürfnisse des Unternehmens abgestimmt sind. Sie könnte sich an den Stoßzeiten orientieren und daran, was aus betrieblicher Sicht am besten ist. Der Grad der Kontrolle ist gering, da es nicht möglich ist, im Voraus zu wissen, was genau im AKS-Knoten installiert werden soll.
  3. Automatische Aktualisierung der Knotenbilder: Es wird empfohlen, AKS-Knoten-Images automatisch zu aktualisieren, wenn neue virtuelle Festplatten (VHDs) verfügbar sind. Gestalten Sie die Wartungsfenster so, dass sie so weit wie möglich mit den Geschäftsanforderungen übereinstimmen. Für sicherheitsrelevante VHD-Updates wird empfohlen, ein tägliches Wartungsfenster zu konfigurieren, das die geringste Vorhersagbarkeit bietet. Regelmäßige VHD-Updates können mit einem wöchentlichen Wartungsfenster, alle zwei Wochen oder sogar monatlich konfiguriert werden. Je nachdem, ob sicherheitsgekennzeichnete oder reguläre VHDs benötigt werden, und je nachdem, wie groß das geplante Wartungsfenster ist, schwankt die Vorhersagbarkeit und bietet mehr oder weniger Flexibilität, um den Geschäftsanforderungen gerecht zu werden. Während es ideal wäre, dies immer den geschäftlichen Anforderungen zu überlassen, zwingt die Realität die Unternehmen dazu, den Wendepunkt zu finden. Der Grad der Kontrolle ist gering, da es nicht möglich ist, im Voraus zu wissen, welche spezifischen Binärdateien in einer neuen VHD enthalten sind, und dennoch ist diese Art von automatischen Aktualisierungen die empfohlene Option, da die Images geprüft werden, bevor sie verfügbar sind.

  Hinweis

  Weitere Informationen zur Konfiguration von automatischen AKS-Knoten-Updates finden Sie unter Auto-upgrade node OS images.

• AKS-Cluster-Version:

  1. Keine/manuelle Aktualisierungen: Dies gilt für unveränderliche Infrastrukturen oder wenn manuelle Aktualisierungen bevorzugt werden. Dadurch wird ein höheres Maß an Vorhersehbarkeit und Kontrolle über die Aktualisierungen der AKS-Cluster-Version erreicht. Es wird empfohlen, sich dafür anzumelden, da man so die volle Kontrolle behält und die Möglichkeit hat, eine neue AKS-Cluster-Version (z. B. 1.14.x bis 1.15.x) in niedrigeren Umgebungen zu testen, bevor sie in Produktion geht.
  2. Automatische Aktualisierungen: Es wird nicht empfohlen, dass ein Produktionscluster automatisch gepatcht oder auf irgendeine Art und Weise auf eine neue Version des AKS-Clusters aktualisiert wird (z. B. 1.16.x auf 1.16.y), ohne dass dies in niedrigeren Umgebungen ordnungsgemäß getestet wurde. Während Kubernetes-Upstream-Releases und AKS-Cluster-Versions-Updates koordiniert und in regelmäßigen Abständen bereitgestellt werden, wird empfohlen, mit AKS-Clustern in der Produktion defensiv zu sein, um die Vorhersehbarkeit und Kontrolle über den Update-Prozess zu verbessern. Dagegen ist diese Konfiguration für niedrigere Umgebungen als Teil der Operational Excellence zu betrachten, die proaktive Routinetests ermöglicht, um potenzielle Probleme so früh wie möglich zu erkennen.

Halten Sie die Kubernetes-Version mit den unterstützten Versionen (N-2) auf dem neuesten Stand. Das Upgrade auf die neueste Version von Kubernetes ist wichtig, da häufig neue Versionen veröffentlicht werden.

Weitere Informationen finden Sie unter Regelmäßiges Update auf die neueste Version von Kubernetes und Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS).

Die Benachrichtigung über Ereignisse, die von Ihrem Cluster ausgelöst werden (beispielsweise die Verfügbarkeit einer neuen AKS-Version für Ihren Cluster), kann über das AKS-Systemthema für Azure Event Grid erreicht werden. Von der Referenzimplementierung wird dieses Event Grid-Systemthema bereitgestellt, sodass Sie das Ereignis Microsoft.ContainerService.NewKubernetesVersionAvailable über Ihre Ereignisdatenstrom-Benachrichtigungslösung abonnieren können.

Wöchentliche Updates

AKS stellt neue Knotenimages mit den neuesten Betriebssystem- und Runtime-Updates zur Verfügung. Diese neuen Images werden nicht automatisch angewendet. Sie müssen entscheiden, wie oft die Images aktualisiert werden sollen. Es wird empfohlen, dass Sie einen Prozess zur wöchentlichen Aktualisierung des Basisimages Ihrer Knotenpools einrichten. Weitere Informationen finden Sie unter Upgrade für AKS-Knotenimages (Azure Kubernetes Service) und in den Hinweisen zur AKS-Version.

Tägliche Updates

Zwischen den Upgrades von Images werden Betriebssystem- und Runtimepatches von AKS-Knoten einzeln heruntergeladen und installiert. Eine Installation erfordert möglicherweise einen Neustart der Knoten-VMs. AKS startet Knoten aufgrund ausstehender Updates nicht neu. Richten Sie einen Prozess ein, der Knoten auf die angewendeten Updates überwacht, die einen Neustart erfordern, und den Neustart dieser Knoten auf kontrollierte Weise durchführt. Eine Open-Source-Option ist Kured (Kubernetes Reboot Daemon).

Wenn Sie Ihre Knotenimages mit dem neuesten wöchentlichen Release synchron halten, werden diese gelegentlichen Neustartanforderungen auf ein Minimum reduziert, und gleichzeitig wird die Sicherheit verbessert. Wenn Sie sich lediglich auf Upgrades von Knotenimages verlassen, werden AKS-Kompatibilität und wöchentliche Sicherheitspatches gewährleistet. Obwohl durch die Anwendung täglicher Updates Sicherheitsprobleme schneller behoben werden können, wurden diese nicht unbedingt in AKS getestet. Setzen Sie nach Möglichkeit auf das Upgrade von Knotenimages als primäre wöchentliche Patchstrategie zum Verbessern der Sicherheit.

Sicherheitsüberwachung

Überwachen Sie Ihre Containerinfrastruktur sowohl auf aktive Bedrohungen als auch auf potenzielle Sicherheitsrisiken:

• Aktivieren Sie Microsoft Defender für Container, um für Ihre Containerimages Empfehlungen von Defender für Cloud zu identifizieren und zu implementieren.
• Microsoft Defender für Container führt regelmäßig eine Überprüfung Ihrer Containerimages auf Sicherheitsrisiken durch.
• Des Weiteren generiert Microsoft Defender für Container Sicherheitswarnungen für verdächtige Aktivitäten in Echtzeit.
• Informationen zur Sicherheitshärtung für AKS-VM-Hosts finden Sie unter Sicherheitshärtung im Hostbetriebssystem.

Cluster- und Workloadvorgänge (DevOps)

Hier finden Sie einige Überlegungen dazu. Weitere Informationen finden Sie unter Optimaler Betrieb.

Clusterbootstrapping

Nach Abschluss der Bereitstellung verfügen Sie über einen funktionierenden Cluster. Vor der Bereitstellung von Workloads sind jedoch möglicherweise noch weitere Schritte erforderlich. Der Prozess der Clustervorbereitung wird als Bootstrapping bezeichnet und kann beispielsweise das Bereitstellen von erforderlichen Images auf Clusterknoten, das Erstellen von Namespaces sowie andere Aktionen umfassen, die zur Erfüllung der Anforderungen Ihres Anwendungsfalls oder Ihrer Organisation erforderlich sind.

Um die Lücke zwischen einem bereitgestellten Cluster und einem ordnungsgemäß konfigurierten Cluster zu verkleinern, müssen sich Clusteroperatoren Gedanken zu ihrem individuellen Bootstrappingprozess machen und relevante Ressourcen im Voraus vorbereiten. Wenn also beispielsweise Kured auf jedem Knoten ausgeführt werden muss, bevor Anwendungsworkloads bereitgestellt werden, sollte der Clusteroperator dafür sorgen, dass bereits eine ACR-Instanz mit dem Kured-Zielimage vorhanden ist, bevor der Cluster bereitgestellt wird.

Der Bootstrappingprozess kann mit einer der folgenden Methoden konfiguriert werden:

• Selbstkonfiguration mithilfe von Flux oder Argo CD
• Pipelines
• GitOps Flux v2-Clustererweiterung

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. Sie richtet ein solides Fundament für die zukünftige Verwaltung der Umgebung ein und unterstützt auch die Einbeziehung dieses Bootstrappings in Form von Ressourcenvorlagen im Sinne Ihrer IaC-Strategie.

Bei Verwendung der Erweiterung wird außerdem kubectl nicht für den Bootstrappingprozess benötigt, und kubectl-basierter Zugriff kann auf Notfallproblemlösungen beschränkt werden. Zwischen Vorlagen für Azure-Ressourcendefinitionen und dem Bootstrapping von Manifesten über die GitOps-Erweiterung können alle normalen Konfigurationsaktivitäten ganz ohne kubectl ausgeführt werden.

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. Stellen Sie virtuelle Netzwerke für den Hub, die Spokes und die Subnetze in diesen Netzwerken bereit. Beispielsweise verfügt ein Spoke über separate Subnetze für System- und Benutzerknotenpools sowie Eingangsressourcen und ein Subnetz für Azure Firewall im Hub.

Ein weiterer Teil könnte die Integration der grundlegenden Arbeitsauslastung in die Microsoft Entra ID sein.

Verwenden der Infrastruktur als Code (Infrastructure as Code, 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. Eine Option hierfür sind ARM-Vorlagen (Azure Resource Manager). Eine andere ist Terraform.

Stellen Sie sicher, dass Sie Ressourcen gemäß den geltenden Richtlinien bereitstellen. Wenn Sie z. B. die VM-Größen auswählen, achten Sie auf Kosteneinschränkungen und Optionen für Verfügbarkeitszonen entsprechend den Anforderungen Ihrer Anwendung.

Wenn Sie eine Sequenz von Befehlen schreiben müssen, verwenden Sie die Azure CLI. Diese Befehle behandeln eine Reihe von Azure-Diensten und können mithilfe von Skripts automatisiert werden. Die Azure-Befehlszeilenschnittstelle wird unter Windows und Linux unterstützt. Eine weitere plattformübergreifende Option ist Azure PowerShell. Ihre Auswahl hängt von Ihren Kenntnissen ab.

Speichern Sie Skripts 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 kontinuierlich Anwendungen erstellen und bereitstellen können. Updates müssen für den Fall, dass Probleme auftreten, sicher und schnell bereitgestellt und zurückgesetzt werden.

Ihre Bereitstellungsstrategie muss eine zuverlässige und automatisierte CD-Pipeline (Continuous Delivery) aufweisen. Änderungen an den Containerimages für Ihre Workload sollten automatisch im Cluster bereitgestellt werden.

In dieser Architektur haben wir GitHub Actions zum Verwalten des Workflows und der Bereitstellung ausgewählt. Andere verbreitete Optionen sind Azure DevOps Services und Jenkins.

CI/CD für Cluster

Laden Sie eine Visio-Datei dieser Architektur herunter.

Verwenden Sie anstelle eines imperativen Ansatzes wie kubectl Tools, die Cluster- und Repositoryänderungen automatisch synchronisieren. Um den Workflow zu verwalten, z. B. das Release einer neuen Version und die Validierung dieser Version vor der Bereitstellung in der Produktion, sollten Sie einen GitOps-Flow in Erwägung ziehen.

Ein wesentlicher Bestandteil des CI/CD-Flows ist das Bootstrapping eines neu bereitgestellten Clusters. Hierbei ist ein GitOps-Ansatz hilfreich, der es Operatoren ermöglicht, den Bootstrappingprozess im Rahmen der IaC-Strategie deklarativ zu definieren und die Konfiguration automatisch im Cluster anzuwenden.

Bei Verwendung von GitOps wird ein Agent im Cluster bereitgestellt, der sicherstellt, dass der Status des Clusters mit der in Ihrem privaten Git-Repository gespeicherten Konfiguration koordiniert wird. Flux ist ein solcher Agent. Er verwendet einen oder mehrere Operatoren im Cluster, um Bereitstellungen in Kubernetes auszulösen. Flux übernimmt folgende Aufgaben:

• Überwachen alle konfigurierten Depots
• Erkennen neuer Konfigurationsänderungen
• Auslösen von Bereitstellungen
• Aktualisieren der gewünschten Konfiguration anhand dieser Änderungen

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

Das folgende Beispiel zeigt die Automatisierung der Clusterkonfiguration mit GitOps und Flux:

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Ein Entwickler committet Änderungen am Quellcode, z. B. YAML-Konfigurationsdateien, die in einem Git-Repository gespeichert werden. Die Änderungen werden dann auf einen Git-Server gepusht.

2. Flux wird zusammen mit der Workload in einem Pod ausgeführt. Flux verfügt nur über Lesezugriff auf das Git-Repository, um sicherzustellen, dass von Flux nur Änderungen angewendet werden, die von den Entwicklern angefordert wurden.

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

4. Die Entwickler haben über kubectl keinen direkten Zugriff auf die Kubernetes-API.

5. Richten Sie auf Ihrem Git-Server Branchrichtlinien ein. Dadurch können mehrere Entwickler eine Änderung mittels Pull Request genehmigen, bevor sie in der Produktion angewendet wird.

GitOps und Flux können zwar manuell konfiguriert werden, für AKS wird jedoch die Clustererweiterung GitOps mit Flux v2 empfohlen.

Bereitstellungsstrategien für Workloads und Cluster

Stellen Sie alle Änderungen (Architekturkomponenten, Workload, Clusterkonfiguration) in mindestens einem AKS-Präproduktionscluster bereit. Dadurch wird die Änderung so simuliert, sodass Probleme vor der Bereitstellung in der Produktion behoben werden können.

Führen Sie Tests/Überprüfungen jeder Phase aus, bevor Sie zur nächsten übergehen, um sicherzustellen, dass Sie Updates auf kontrollierte Weise in die Produktionsumgebung pushen und Unterbrechungen aufgrund unvorhergesehener Bereitstellungsprobleme minimieren können. Diese Bereitstellung sollte einem ähnlichen Muster wie die Produktion folgen und die gleichen GitHub Actions-Pipeline bzw. die gleichen flux-Operatoren verwenden.

Erweiterte Bereitstellungsverfahren wie Blau-Grün-Bereitstellung, A/B-Tests und Canary-Releases erfordern eine weitere Verarbeitung und möglicherweise zusätzliche Tools. Flagger ist eine verbreitete Open-Source-Lösung, die Sie bei der Behandlung Ihrer erweiterten Bereitstellungsszenarien unterstützt.

Kostenverwaltung

Überprüfen Sie zunächst die Prüfliste für den Kostenoptimierungsentwurf und die Liste der Empfehlungen aus dem Well Architected Framework für AKS. Mithilfe des Azure-Preisrechners können Sie die Kosten für die in der Architektur verwendeten Dienste schätzen. Weitere bewährte Methoden finden Sie im Microsoft Azure Well-Architected Framework im Abschnitt Kostenoptimierung.

Erwägen Sie die Aktivierung AKS-Kostenanalyse für die granulare Kostenzuordnung von Clusterinfrastrukturen durch Kubernetes spezifische Konstrukte.

Informationen zu Kostenverwaltungsüberlegungen für Windows-basierte Workloads, die in der Referenzarchitektur für Windows-Container auf AKS-Baseline enthalten sind, finden Sie im Begleitartikel.

Bereitstellen

• Bei der Bereitstellung und Verwaltung sowie beim Betrieb des Kubernetes-Clusters fallen keine Kosten für AKS an. Die Kosten werden durch die VM-Instanzen sowie durch die Speicher-, Protokolldaten- und Netzwerkressourcen beeinflusst, die vom Cluster beansprucht werden. Wählen Sie für Systemknotenpools eventuell günstigere VMs aus. Die SKU DS2_v2 ist ein typischer VM-Typ für den Systemknotenpool.

• Verwenden Sie für Dev/Test- und Produktionsumgebungen unterschiedliche Konfigurationen. 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 ist das SLO ausreichend. Wenn Ihre Workload dies unterstützt, sollten Sie auch dedizierte Spot-Knotenpools verwenden, in denen Spot-VMs ausgeführt werden.

  Bewerten Sie bei Nicht-Produktionsworkloads, die Azure SQL-Datenbank oder Azure App Service als Teil der AKS-Workloadarchitektur enthalten, ob Sie berechtigt sind, Azure Dev/Test-Abonnements zu nutzen und Dienstrabatte zu erhalten.

• Beginnen Sie nicht mit einem überdimensionalen Cluster, um die Skalierungsanforderungen zu erfüllen, sondern stellen Sie einen Cluster mit der Mindestanzahl von Knoten bereit, und aktivieren Sie die Autoskalierung, um die Größe zu überwachen und Entscheidungen über Größenänderungen zu treffen.

• Legen Sie Podanforderungen und -grenzwerte fest, damit Kubernetes Knotenressourcen mit höherer Dichte zuordnen kann und so die Kapazität der Hardware vollständig genutzt wird.

• Die Aktivierung der Diagnose im Cluster kann zu höheren Kosten führen.

• Wenn Ihre Workload über einen längeren Zeitraum verwendet wird, können Sie reservierte VM-Instanzen für ein oder drei Jahre erwerben, um die Knotenkosten zu senken. Weitere Informationen finden Sie unter Reservierte VMs.

• Verwenden Sie beim Erstellen von Knotenpools Tags. Tags sind nützlich für das Erstellen benutzerdefinierter Berichte, um die anfallenden Kosten zu verfolgen. Mit Tags haben Sie die Möglichkeit, die Gesamtausgaben zu verfolgen und einer Ressource oder einem Team bestimmte Kosten zuzuordnen. Wenn der Cluster von mehreren Teams gemeinsam verwendet wird, erstellen Sie darüber hinaus Berichte zur verbrauchsbasierten Kostenzuteilung pro Consumer, um die gemessenen Kosten für freigegebene Clouddienste zu ermitteln. Weitere Informationen finden Sie unter Angeben von Taint, Bezeichnung oder Tag für einen Knotenpool.

• Datenübertragungen zwischen Verfügbarkeitszonen in einer Region sind nicht kostenlos. Wenn die Workload mehrere Regionen umfasst oder Übertragungen zwischen Verfügbarkeitszonen erfolgen, müssen Sie mit zusätzlichen Bandbreitenkosten rechnen. Weitere Informationen finden Sie unter Datenverkehr über Abrechnungszonen und Regionen hinweg.

• Erstellen Sie Budgets, um innerhalb der durch die Organisation festgelegten Kosteneinschränkungen zu bleiben. Eine Möglichkeit besteht darin, Budgets über Azure Cost Management zu erstellen. Sie können auch Warnungen erstellen, um Benachrichtigungen zu erhalten, wenn bestimmte Schwellenwerte überschritten werden. Weitere Informationen finden Sie unter Erstellen eines Budgets mithilfe einer Vorlage.

Überwachen

Um die Kosten für den gesamten Cluster zu überwachen, sammeln Sie zusammen mit den Computekosten auch Kosteninformationen zu Speicher, Bandbreite, Firewall und Protokollen. Azure bietet verschiedene Dashboards zum Überwachen und Analysieren von Kosten:

• Azure Advisor

• Azure Cost Management

Im Idealfall überwachen Sie die Kosten in Echtzeit oder zumindest in regelmäßigen Abständen, um ggf. Maßnahmen schon vor dem Monatsende vorzunehmen, wenn die Kosten bereits berechnet werden. Überwachen Sie außerdem den monatlichen Trend, um das Budget einzuhalten.

Um datenzentrische Entscheidungen zu treffen, legen Sie fest, welche Ressource (granulare Ebene) die meisten Kosten verursacht. Außerdem sollten Sie die Verbrauchseinheiten verstehen, die zur Berechnung der Nutzung der einzelnen Ressourcen verwendet werden. Durch die Analyse von Metriken können Sie beispielsweise feststellen, ob die Plattform zu groß ist. Sie finden die Verbrauchseinheiten in den Azure Monitor-Metriken.

Optimieren

Handeln Sie entsprechend den Empfehlungen, die von Azure Advisor bereitgestellt werden. Es gibt auch andere Möglichkeiten für die Optimierung:

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

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

• Wenn die Anwendung keine Burstskalierung erfordert, legen Sie für den Cluster eine gerade ausreichende Größe fest, indem Sie die Leistungsmetriken im Zeitverlauf analysieren.

• Skalieren Sie Ihre Benutzerknotenpools auf 0 Knoten, wenn nicht erwartet wird, dass diese ausgeführt werden, sofern von Ihrer Workload unterstützt. Wenn in Ihrem Cluster keine weitere Ausführung von Workloads geplant ist, können Sie darüber hinaus die Start-/Beendigungsfunktion von AKS verwenden, um alle Computekomponenten herunterzufahren, einschließlich des Systemknotenpools und der AKS-Steuerungsebene.

Weitere kostenbezogene Informationen finden Sie unter Azure Kubernetes Service (AKS) – Preise.

Nächste Schritte

Informieren Sie sich weiter über die AKS-Baselinearchitektur:

• Weitere Informationen zum Hosten von Microservices in der AKS-Baseline finden Sie unter Erweiterte Microservicearchitektur in Azure Kubernetes Service (AKS).
• Informationen zum Bereitstellen der AKS-Baseline in mehreren Regionen finden Sie unter AKS-Baseline für Cluster mit mehreren Regionen.
• Informationen zum Bereitstellen der AKS-Baseline in einer PCI-DSS 3.2.1-Umgebung finden Sie unter Regulierter AKS-Cluster für PCI-DSS 3.2.1.
• Weitere Informationen zu Überlegungen zum Hinzufügen von Windows-Containern zur Referenzarchitektur finden Sie im Begleitartikel AKS-Baselinereferenzarchitektur für Windows-Container

Weitere Informationen zu AKS

• Die Produktroadmap für AKS finden Sie unter Azure Kubernetes Service-Roadmap auf GitHub.
• Wenn Sie Ihre Kubernetes-Kenntnisse auffrischen möchten, empfehlen wir die Lernpfade Einführung in Kubernetes unter Azure sowie Entwickeln und Bereitstellen von Anwendungen auf Kubernetes.

Zugehörige Ressourcen

Weitere Informationen finden Sie im folgenden Leitfaden:

• Azure Well-Architected Framework-Bewertung: Azure Kubernetes Service (AKS)
• Der AKS Landing Zone Accelerator, der eine auf dieser Architektur basierende Implementierung auf Unternehmensmaßstab ist. Die Zugriffstaste unterstützt Sie beim Einrichten Ihrer Azure-Umgebung auf konsistente und wiederholte Weise mithilfe von Infrastructure-As-Code (IaC) für eine Azure Kubernetes Service (AKS)-Bereitstellung.
• Azure Kubernetes Services (AKS): Leitfaden für Day-2-Vorgänge

Weitere Informationen finden Sie in den folgenden Artikeln zur Architektur:

• Microservicearchitektur in Azure Kubernetes Service
• Schützen eines AKS-Clusters (Azure Kubernetes Service) mit Azure Firewall
• GitOps für Azure Kubernetes Service
• Datenstreaming mit AKS