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

Dieser Artikel bietet eine empfohlene Architektur für die Basisinfrastruktur zur Bereitstellung eines AKS-Clusters (Azure Kubernetes Service). Sie verwendet unsere Designprinzipien und basiert auf den bewährten Methoden der Architektur des Azure Well-Architected Framework. Dieser Artikel unterstützt mehrere unterschiedliche interdisziplinäre Gruppen, beispielsweise Netzwerk-, Sicherheits- und Identitätsteams, bei der Bereitstellung dieser allgemeinen Infrastruktur.

Diese Architektur ist nicht auf eine Workload ausgerichtet. 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. Sie lässt sich in Azure-Dienste integrieren, die Einblicke bieten, eine Netzwerktopologie bereitstellen, die multiregionales Wachstum unterstützen und den clusterinternen Datenverkehr sichern.

Die Zielarchitektur ist von Ihren geschäftlichen Anforderungen abhängig und kann je nach Anwendungskontext unterschiedlich sein. Betrachten Sie die Architektur als Ausgangspunkt für die Vorproduktions- und Produktionsphasen.

Kubernetes ist ein leistungsstarkes Ökosystem, das sich über die Technologien von Azure und Microsoft erstreckt. Wenn Sie einen AKS-Cluster bereitstellen, übernehmen Sie die Verantwortung für zahlreiche Entscheidungen darüber, wie Ihr Cluster konzipiert und betrieben werden soll. Für die Ausführung eines AKS-Clusters ist eine Mischung aus Closed-Source-Komponenten zahlreicher Anbieter, einschließlich Microsoft, und Open-Source-Komponenten aus dem Kubernetes-Ökosystem erforderlich. Die Umgebung ändert sich häufig. Deshalb werden Sie Ihre Entscheidungen möglicherweise regelmäßig überdenken müssen. Durch die Einführung von Kubernetes bestätigen Sie, dass Ihre Workload seine Funktionen benötigt und dass das Workload-Team bereit ist, kontinuierlich zu investieren.

Sie können eine Implementierung dieser Architektur auf GitHub verwenden: Baselinereferenzimplementierung von AKS. Nutzen Sie sie als alternativen Ausgangspunkt, und konfigurieren Sie die Referenzarchitektur entsprechend Ihren Anforderungen.

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-and-Spoke-Netzwerktopologie verwendet. Die Hub- und Spoke-Ressourcen werden in separaten virtuellen Netzwerken bereitgestellt, die über das Peering virtueller Netzwerke verbunden sind. Diese Topologie hat mehrere Vorteile. Verwenden Sie diese Topologie für folgende Aufgaben:

• Ermöglichen einer getrennten Verwaltung Sie können Governance sowie die Einhaltung des Prinzips der geringsten Rechte anwenden. Außerdem wird das Konzept einer Azure-Zielzone mit Aufgabentrennung unterstützt.

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

• Bereitstellen von regionalen Hub-and-Spoke-Technologien Sie können Hub-and-Spoke-Netzwerktopologien in der Zukunft erweitern und eine Workloadisolation ermöglichen.

• Verwenden eines Web Application Firewall-Dienstes, um den HTTP-Datenverkehrfluss für alle Webanwendungen zu überprü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.

• Unterstützen Sie die Freigabe von Ressourcen wie einer Firewall und DNS-Zonen (Domain Name System) über Netzwerke hinweg.

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

Laden Sie eine Visio-Datei dieser Architektur herunter.

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

Weitere Informationen zu den Änderungen am Netzwerkdesign, die in der Basisreferenzarchitektur „Windows-Container in AKS“ enthalten sind, finden Sie unter Windows-Container in AKS.

Virtuelles Hubnetzwerk

Der Hub des virtuellen Netzwerks ist der zentrale Punkt für Konnektivität und Einblicke. In dieser Architektur enthält der Hub Folgendes:

• Eine Azure Firewall-Instanz mit globalen Firewallrichtlinien, die von Ihren zentralen IT-Teams definiert werden, um organisationsweite Firewallrichtlinien zu erzwingen
• Eine Azure Bastion-Instanz für den Remotezugriff auf virtuelle Computer (VMs)
• Ein Gatewaysubnetz für VPN-Konnektivität (Virtual Private Network, virtuelles privates Netzwerk)
• Azure Monitor für Netzwerkeinblicke

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

Subnetz zum Hosten von Azure Firewall

Azure Firewall ist ein verwalteter Firewall-Dienst. Die Azure Firewall-Instanz schützt den ausgehenden Netzwerkdatenverkehr. Ohne diese Sicherheitsebene kann der betreffende Datenverkehr mit einem böswilligen, nicht von Microsoft stammenden Dienst kommunizieren, der vertrauliche Workloaddaten herausfiltern könnte. Verwenden Sie den Azure Firewall Manager, um mehrere Azure Firewall-Instanzen zentral bereitzustellen und zu konfigurieren und Azure Firewall-Richtlinien für den Architekturtyp des virtuellen Hubnetzwerks zu verwalten.

Subnetz zum Hosten eines Gateways

Dieses Subnetz ist ein Platzhalter für ein VPN- oder ein Azure 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 Azure Bastion für den sicheren Zugriff auf Azure-Ressourcen verwenden, ohne die Ressourcen im Internet verfügbar zu machen. Dieses Subnetz dient nur der Verwaltung und dem Betrieb.

Virtuelles Spoke-Netzwerk

Das virtuelle Spoke-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

Application Gateway ist ein Lastenausgleich für Webdatenverkehr, der auf Ebene 7 betrieben wird. Bei der Referenzimplementierung wird die Application Gateway v2-SKU verwendet, die Azure Web Application Firewall aktiviert. Web Application Firewall 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 AKS.

Subnetz zum Hosten der Clusterknoten

AKS verwaltet zwei Knotenpools, bei denen es sich um separate Knotengruppen handelt. 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 Azure Private Link-Endpunkten

Erstellen Sie Private Link-Verbindungen werden für Azure Container Registry und Azure Key Vault, damit Benutzer über private Endpunkte innerhalb des virtuellen Spoke-Netzwerks auf diese Dienste zugreifen können. Private Endpunkte erfordern kein dediziertes Subnetz. Sie können auch private Endpunkte im virtuellen Hubnetzwerk 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. Dabei bleiben die Ressourcen, die zum Cluster gehören, im selben virtuellen Netzwerk. Sie können auch granulare Sicherheitsregeln auf Subnetzebene anwenden, indem Sie Netzwerksicherheitsgruppen verwenden.

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.

Diese Referenzarchitektur verwendet mehrere Netzwerkansätze, für die jeweils ein IP-Adressraum erforderlich ist:

• Ihr virtuelles Azure-Netzwerk, das für Ressourcen wie Clusterknoten, private Endpunkte und Application Gateway verwendet wird.
• Der Cluster verwendet das Azure CNI Overlay, das Pods IP-Adressen ausgehend von einem anderen Adressraum als Ihrem virtuellen Azure-Netzwerk zuweist.

IP-Adressraum des virtuellen Netzwerks

Der Adressraum Ihres virtuellen Azure-Netzwerks sollte groß genug sein, um alle Ihre Subnetze aufnehmen zu können. Berücksichtigen Sie alle Entitäten, die Datenverkehr empfangen. Kubernetes weist diesen Entitäten IP-Adressen aus dem Subnetzadressraum zu. Berücksichtigen Sie diese Punkte bei der Planung Ihrer IP-Adressen für das virtuelle Azure-Netzwerk.

• Upgrades: AKS aktualisiert Knoten regelmäßig, um sicherzustellen, dass die Sicherheitsfeatures und andere Systempatches der zugrunde liegenden VMs 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. Vergewissern Sie sich, dass der Adressraum für die IP-Adressen dieser temporären Knoten ausreicht.

  In dieser Architektur sowie während paralleler Updates werden Pods IP-Adressen aus dem Pod-Adressraum des Azure CNI Overlay zugewiesen. Im Vergleich zu anderen Kubernetes-Ansätzen für den Netzwerkbetrieb reduziert dieser Ansatz die Gesamtanzahl der IP-Adressen, die ausgehend von Ihrem virtuellen Azure-Netzwerk verwendet werden.

• 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.

  Da diese Architektur Azure CNI Overlay verwendet, hat die Skalierbarkeit Ihrer Pods keinerlei Auswirkung auf den Adressraum Ihres virtuellen Netzwerks.

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

• Reservierte IP-Adressen: Azure reserviert bestimmte Adressen für seine Verwendung. 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. Wenn Sie das tun, entstehen mehr Subnetze mit kleinerer Größe. Außerdem kann die Eingangsressource komplexer sein, sodass Sie möglicherweise mehrere Eingangsdatencontroller benötigen, die wiederum zusätzliche IP-Adressen erfordern.

IP-Adressraum des Pods

Azure CNI Overlay weist Pods IP-Adressen zu, indem es einen dedizierten Adressraum verwendet. Dabei handelt es sich nicht um den Adressraum, den Sie in Ihrem virtuellen Netzwerk verwenden, sondern um einen anderen Adressraum. 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 auf den einzelnen Clustern bedenkenlos denselben Pod-Adressraum verwenden.

Jedem Knoten wird für seine Pods ein /24-Adressraum zugewiesen. Daher sollten Sie sicherzustellen, dass der Pod-Adressraum groß genug ist, um alle für die Anzahl Ihrer Clusterknoten benötigten /24-Blöcke genehmigen zu können. Denken Sie daran, alle temporären Knoten einzuschließen, die während Upgrades oder Vorgängen zur horizontalen Skalierung erstellt wurden. Wenn Sie für Ihren CIDR-Bereich z. B. einen /16-Adressraum verwenden, kann Ihr Cluster auf maximal 250 Knoten erweitert werden.

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 im Leitfaden zur Planung von IP-Adressen für Azure CNI Overlay

Weitere Überlegungen zum IP-Adressraum

Alle netzwerkbezogenen Überlegungen zu dieser Architektur finden Sie unter AKS-Baseline-Netzwerktopologie. Informationen zum Planen der IP-Adressierung für einen AKS-Cluster finden Sie unter Planen der IP-Adressierung für Ihren Cluster.

Weitere Informationen zu den Überlegungen zur IP-Adressplanung, die in den Windows-Containern in der AKS-Basisreferenzarchitektur enthalten sind, finden Sie unter Windows-Container in AKS.

Add-Ons und Previewfunktionen

Kubernetes und AKS entwickeln sich kontinuierlich weiter 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. Dies ist der Unterschied zwischen beiden Erweiterungen:

• Das AKS-Team beschreibt Previewfunktionen als ausgeliefert und im Status der kontinuierlichen Verbesserung, da viele der Previewfunktionen nur einige Monate in diesem Zustand verbleiben, bevor sie in die Phase der allgemeinen Verfügbarkeit (GA) übergehen.

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

Diese Basisarchitektur enthält nicht alle Previewfunktionen oder Add-Ons. 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 andere Previewfunktionen oder AKS-Add-Ons, die Sie möglicherweise in Präproduktionsclustern auswerten möchten. Diese Features können Ihre Sicherheit, Verwaltbarkeit oder andere Anforderungen verbessern. Bei Add-Ons, die nicht von Microsoft stammen, müssen Sie diese installieren und verwalten. Dazu gehört auch die Nachverfolgung verfügbarer Versionen und die Installation von Updates nach dem Upgrade der Kubernetes-Version eines Clusters.

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 diese Punkte, wenn Sie die Images in Ihren Cluster pullen.

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

• Importieren Sie ein öffentliches Image in die Containerregistrierung, das Ihrem Service-Level-Ziel (SLO) entspricht, wenn Sie ein öffentliches Image verwenden. Andernfalls unterliegt das Image möglicherweise unerwarteten Verfügbarkeitsproblemen. Wenn das Image bei Bedarf nicht verfügbar ist, kann dies zu Betriebsproblemen führen. Im Folgenden finden Sie einige Vorteile der Verwendung einer privaten Containerregistrierung, z. B. Azure Container Registry, anstelle einer öffentlichen Registrierung:

  • 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 können von integrierter Containerüberwachung und Imagekonformität profitieren.

• Damit können Sie Images aus autorisierten Registrierungen pullen. Sie können diese Einschränkung über Azure Policy erzwingen. In dieser Referenzimplementierung ruft der Cluster nur Images aus der Containerregistrierungsinstanz ab, die bereitgestellt wird.

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. Große Knoten minimieren den Platzbedarf von Diensten, die auf allen Knoten ausgeführt werden, wie 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 im Artikel zu den Größen für virtuelle Computer in Azure.

• Stellen Sie mindestens zwei Knoten bereit. Auf diese Weise verfügt die Workload über ein Hochverfügbarkeitsmuster mit zwei Replikaten. 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 von Ihrem Designteam ermittelten Anforderungen. Basierend auf den Geschäftsanforderungen verwendet diese Architektur DS4_v2 für die Produktionsworkload. Um die Kosten zu senken, können Sie die Größe auf DS3_v2 verringern. Dies ist auch die minimale Empfehlung.

• Gehen Sie davon aus, dass Ihre Workload bis zu 80 % jedes Knotens verbraucht, wenn Sie die Kapazität für Ihren Cluster planen. 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.

Auswählen eines Betriebssystems

Die meisten AKS-Cluster verwenden für ihre Knotenpools Linux als Betriebssystem. In dieser Referenzimplementierung verwenden wir Azure Linux, eine einfache, gehärtete Linux-Distribution, die für Azure optimiert wurde. Wenn Sie es vorziehen, oder wenn Sie Anforderungen erfüllen müssen, die Azure Linux nicht erfüllen kann, können Sie eine andere Linux-Distribution wie z. B. Ubuntu verwenden.

AKS unterstützt auch Knotenpools, die das Windows Server-Betriebssystem ausführen. Für einige Aspekte eines Clusters, der Windows ausführt, müssen spezielle Anforderungen erfüllt werden. Weitere Informationen zur Architektur des Windows-Knotenpools finden Sie unter Ausführen von Windows-Containern auf AKS.

Wenn Sie über eine Workload verfügen, die aus einer Mischung aus Technologien besteht, können Sie in verschiedenen Knotenpools verschiedene Betriebssysteme verwenden. Wenn Sie für Ihre Workload keine unterschiedlichen Betriebssysteme benötigen, empfiehlt es sich, für alle Knotenpools Ihrer Workload ein einzelnes Betriebssystem zu verwenden.

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: Berücksichtigen Sie den AKS-Zugriff auf Azure-Komponenten wie Netzwerkinfrastruktur, Azure Container Registry und Azure Key Vault. Autorisieren Sie nur die Ressourcen, auf die der Cluster zugreifen darf.
• Zugriff von außen: Gewähren Sie Identitäten Zugriff auf den Kubernetes-Cluster. 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 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.

Wir empfehlen, dass sie verwaltete Identitäten aktivieren und verwenden, damit der Cluster über Microsoft Entra ID mit externen Azure-Ressourcen interagieren kann. Auch wenn Sie die Microsoft Entra ID-Integration nicht sofort nutzen, können Sie sie später einbinden.

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 einschließlich Lastenausgleichsmodulen für eingehenden Datenverkehr und von AKS verwalteten öffentlichen IP-Adressen zu verwalten. Die Kubelet-Identität authentifiziert sich mit Container Registry. 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 diese Aktion muss der Cluster die Anmeldeinformationen der Registrierung abrufen. Wenn Sie keine verwaltete Identität verwenden, können Sie diese Informationen in Form des Kubernetes-Geheimnisobjekts speichern und imagePullSecrets zum Abrufen des Geheimnisses verwenden. Aus Sicherheitsgründen empfehlen wir diesen Ansatz nicht. Sie müssen das Geheimnis nicht nur im Voraus kennen, sondern es auch in der DevOps-Pipeline speichern. Ein weiterer Grund, warum wir diesen Ansatz nicht empfehlen, ist der betriebliche Aufwand 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 diese Bedenken behandelt.

In dieser Architektur greift der Cluster auf Azure-Ressourcen zu, die durch Microsoft Entra ID gesichert sind, und der Cluster führt Vorgänge aus, die verwaltete Identitäten unterstützen. Weisen Sie den verwalteten Identitäten des Clusters je nach den vom Cluster ausgeführten Vorgängen die rollenbasierte Zugriffssteuerung (Azure RBAC) und Berechtigungen von Azure zu. 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:

• Rolle „Netzwerkmitwirkender“ Verwaltet die Fähigkeit des Clusters, das virtuelle Spoke-Netzwerk zu steuern Mit dieser Rollenzuweisung kann die vom AKS-Clustersystem zugewiesene Identität mit dem dedizierten Subnetz für den internen Eingangscontrollerdienst arbeiten.

• Rolle „Herausgeber von Überwachungsmetriken“. Verwaltet die Fähigkeit des Clusters, Metriken an Azure Monitor zu senden

• AcrPull-Rolle. Verwaltet die Fähigkeit des Clusters, Images aus den angegebenen Azure Container Registry-Instanzen zu pullen

Clusterzugriff

Die Integration von Microsoft Entra vereinfacht auch die Sicherheit beim Zugriff von außen. 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 anhand der Azure-Rollen, die für die Nutzung von Azure zugelassen sind. Weitere Informationen finden Sie unter Verfügbare Clusterrollenberechtigungen.

AKS unterstützt 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 Methode wird die native Azure RBAC zum Steuern des Clusterzugriffs verwendet. In den folgenden Abschnitten werden beide Ansätze beschrieben.

Zuordnen von Kubernetes RBAC zu Microsoft Entra ID

Kubernetes unterstützt RBAC durch Folgendes:

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

• Bindungen, die Benutzer und Gruppen zuweisen, die über die Berechtigung zum Ausführen der Aktionen verfügen. Definieren Sie Bindungen mithilfe eines RoleBinding- oder ClusterRoleBinding-Objekts.

Kubernetes verfügt über einige integrierte Rollen wie „cluster-admin“, „edit“ und „view“. 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üfungen enthalten sind.

Verwenden von Azure RBAC für die Kubernetes-Autorisierung

Anstelle der nativen RBAC von Kubernetes ClusterRoleBindings und RoleBindings für die Autorisierung mit integrierter Microsoft Entra-Authentifizierung wird empfohlen, Azure RBAC und Azure-Rollenzuweisungen zu verwenden. Dieser Ansatz erzwingt Autorisierungsprüfungen für den Cluster. Sie können diese Rollen sogar auf Verwaltungsgruppen-, Abonnement- oder Ressourcengruppenebene zuweisen. Alle Cluster im Rahmen dieses Bereichs erben dann einen konsistenten Satz von Rollenzuweisungen in Bezug darauf, wer über Berechtigungen zum Zugriff auf die Objekte im Kubernetes-Cluster verfügt.

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

Lokale Konten

AKS unterstützt die native Kubernetes-Benutzerauthentifizierung. Es wird nicht empfohlen, diese Methode zu verwenden, um Benutzerzugriff auf Cluster zu gewähren. Diese Methode 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 auf lokale Clusterkonten explizit deaktiviert, wenn das System den Cluster bereitstellt.

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 stellt die Microsoft Entra ID-Workloadidentität auf AKS die verwalteten Identitäten für Pods bereit. Dieser Ansatz 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-Verbund finden Sie unter Workload-Identitätsverbund.

Auswählen eines Netzwerkmodells

AKS unterstützt mehrere Netzwerkmodelle, darunter kubenet, CNI und Azure CNI Overlay. Die CNI-Modelle sind fortschrittlichere und sehr leistungsstarke Modelle. Die Leistung von CNI bei der Kommunikation zwischen Pods ähnelt der Leistung von virtuellen Computern in einem virtuellen Netzwerk. CNI bietet außerdem eine verbesserte Sicherheitskontrolle, da es die Verwendung der Azure-Netzwerkrichtlinie ermöglicht. Wir empfehlen ein CNI-basiertes Netzwerkmodell.

Bei diesem Modell ohne Überlagerung erhält jeder Pod eine IP-Adresse aus dem Adressraum des Subnetzes. Ressourcen innerhalb desselben Netzwerks (oder mittels Peering verbundene Ressourcen) können direkt über ihre IP-Adresse auf die Pods zugreifen. Für die Weiterleitung dieses Datenverkehrs ist keine Network Address Translation (NAT) erforderlich.

In dieser Referenzimplementierung verwenden wir Azure CNI Overlay, das die Knoten nur IP-Adressen aus dem Knotenpoolsubnetz zuordnet und eine hochoptimierte Overlay-Schicht für Pod-IPs verwendet. Da Azure CNI Overlay im Vergleich zu vielen anderen Ansätzen weniger VNet-IP-Adressen verwendet, empfehlen wir es für Bereitstellungen mit eingeschränkten IP-Adressen.

Informationen zu den Modellen finden Sie unter Auswählen eines zu verwendenden Netzwerkmodis (Container Networking Interface) und Vergleichen der Netzwerkmodi kubenet und Azure CNI (Container Networking Interface) in AKS.

Bereitstellen von Eingangsressourcen

Kubernetes-Eingangsressourcen kümmern sich um das Routing und die Verteilung des eingehenden Datenverkehrs zum Cluster. Es gibt zwei Kategorien von Eingangsressourcen:

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

  Diese Architektur verwendet Azure Load Balancer. 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 (Transport Layer Security) erfolgt. Weitere Informationen zur TLS-Verschlüsselung für eingehenden Datenverkehr finden Sie unter Eingehender Datenverkehrsfluss.

• Der Eingangscontroller. In diesem Beispiel wird Traefik verwendet. 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.

• Beschränken Sie den Eingangscontroller auf einen bestimmten Umfang von Vorgängen im Rahmen Ihrer Entwurfsentscheidungen. 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 sicherzustellen, 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 Application Gateway.

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

• Beschränken Sie den Zugriff des Eingangsdatencontrollers auf bestimmte Ressourcen und auf die Ausführung bestimmter Aktionen. Sie können diese Einschränkung durch die RBAC-Berechtigungen von Kubernetes implementieren. 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.

Weitere Informationen zum Eingangsdesign für die Windows-Container in AKS in der Basisreferenzarchitektur finden Sie unter Windows-Container in AKS.

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. Die Optionen annotations, tls und entrypoints geben an, dass Routen über HTTPS bedient werden. Die Option middlewares gibt an, dass nur Datenverkehr aus dem Subnetz von Application Gateway zulässig ist. Für die Antworten wird Gzip-Codierung verwendet, sofern der Client diese akzeptiert. Da Traefik den TLS-Abschluss 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

In dieser Architektur umfasst der Netzwerkfluss Folgendes:

• Eingehender Datenverkehr vom Client an die 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 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 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 Verschlüsselungsverfahren umfasst. Die genaue Übereinstimmung mit der Servernamensanzeige (Server Name Indication, SNI) ist aktiviert. End-to-End-TLS wird über Application Gateway eingerichtet, wobei zwei verschiedene TLS-Zertifikate verwendet werden, wie im folgenden Diagramm 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 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 handelt den TLS-Handshake für bicycle.contoso.com aus, sodass nur sichere Chiffren möglich sind. Application Gateway ist ein TLS-Abschlusspunkt, der wichtig ist, da die Web Application Firewall des Application Gateway die Nur-Text-Antwort prüfen muss. Key Vault speichert das TLS-Zertifikat. Der Cluster greift mit einer benutzerseitig zugewiesenen verwalteten Identität darauf zu, die in Application Gateway integriert ist. Weitere Informationen finden Sie unter TLS-Terminierung mit Key Vault-Zertifikaten.

   Das Anwendungsgateway verarbeitet Überprüfungsregeln für die Web Application Firewall und führt Routingregeln aus, die den Datenverkehr an das konfigurierte Back-End weiterleiten.

3. Während der Übertragung von Application Gateway zum Back-End wird Datenverkehr nochmals mit einem weiteren TLS-Zertifikat verschlüsselt. Hierbei handelt es sich um einen Platzhalter für „*.aks-ingress.contoso.com”, wenn er an den internen Lastenausgleich weitergeleitet wird. Durch diese erneute Verschlüsselung wird sichergestellt, dass kein ungesicherter 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 und leitet den Datenverkehr über HTTP an die Workloadpods weiter. Die Zertifikate werden in Key Vault gespeichert und vom Container Storage Interface-Treiber (CSI) in den Cluster eingebunden. Weitere Informationen finden Sie unter Hinzufügen einer Geheimnisverwaltung.

Sie können End-to-End-TLS-Datenverkehr vollständig an jedem Hop 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 aus. Dieser Ansatz minimiert den Aufwand bei der Workloadverwaltung und den Aufwand aufgrund einer schlechten Netzwerkleistung. Ihre Workload- und Complianceanforderungen geben vor, wo der TLS-Abschluss erfolgt.

Ausgehender Datenverkehrsfluss

In dieser Architektur wird empfohlen, dass der gesamte ausgehende Datenverkehr des Clusters über die Azure Firewall kommuniziert. Oder Sie können Ihr eigenes, ähnliches virtuelles Netzwerkgerät verwenden. Es wird nicht empfohlen, andere ausgehende Optionen wie das Azure NAT Gateway oder einen HTTP-Proxy zu verwenden, da sie keine Netzwerkdatenverkehrsprüfung bereitstellen. Für die Zero-Trust-Steuerung und die Möglichkeit, den Datenverkehr zu überprüfen, wird der gesamte ausgehende Datenverkehr aus dem Cluster über die Firewall geleitet. Sie können diese Konfiguration mit benutzerdefinierten Routen (UDRs) implementieren. Der nächste Hop auf der Route ist die private IP-Adresse von Azure Firewall. Azure Firewall entscheidet, 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 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.

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 Key Vault pullen muss. In diesen Szenarien wird empfohlen, Private Link zu verwenden. 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 -Produkte 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 Sie diese Adressen der Liste zugelassener IP-Adressen des Diensts hinzufügen. Ein Nachteil ist, dass Azure Firewall dann 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. Andernfalls könnten Sie die Portausschöpfung erreichen. Weitere Informationen zum Planen mehrerer IP-Adressen finden Sie unter Erstellen einer Azure Firewall mit mehreren IP-Adressen.

Informationen zu den Windows-spezifischen Überlegungen zum ausgehenden Datenverkehr in der Baselinereferenzarchitektur für Windows-Container in AKS finden Sie unter Windows-Container in AKS.

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 ansonsten 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 diese später nicht mehr hinzufügen können. Es gibt einige Auswahlmöglichkeiten an Technologien, die NetworkPolicy implementieren. Wir empfehlen die Azure-Netzwerkrichtlinie, die Azure Container Networking Interface (CNI) erfordert. Weitere Informationen finden Sie im folgenden 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-Netzwerkrichtlinienmodulen.

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 zum Skalieren des Clusters. Beispiele für diese Ressourcen sind der Build-Agent-Pool in einer DevOps-Pipeline, eine Azure Bastion-Instanz mit dem Azure Bastion-Subnetz und die eigentlichen Knotenpools. Anstatt diesen Verwaltungsdatenverkehr von allen IP-Adressen zu akzeptieren, verwenden Sie die Funktion für AKS-autorisierte IP-Bereiche, um nur Datenverkehr von Ihren autorisierten IP-Bereichen zum API-Server zuzulassen.

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

Für eine weitere Kontrollebene können Sie auf Kosten der zusätzlichen Komplexität einen privaten AKS-Cluster bereitstellen. 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 niemals im Internet verfügbar gemacht wird. Weitere Informationen finden Sie unter Private AKS-Cluster.

Hinzufügen einer Geheimnisverwaltung

Speichern Sie Geheimnisse in einem verwalteten Schlüsselspeicher wie Key Vault. Der Vorteil besteht darin, dass ein verwalteter Schlüsselspeicher die Rotation der Geheimnisse übernimmt. Es bietet eine starke Verschlüsselung und ein Zugriffsüberwachungsprotokoll. Außerdem werden wichtige Geheimschlüssel aus der Bereitstellungspipeline beibehalten. In dieser Architektur wird eine Key Vault-Firewall aktiviert und konfiguriert und Private Link wird für die Verbindung von Ressourcen in Azure verwendet, die auf Geheimnisse und Zertifikate zugreifen müssen.

Key Vault ist gut mit anderen Azure-Diensten integriert. Verwenden Sie die integrierten Funktionen dieser Dienste für den Zugriff auf Geheimnisse. Weitere Informationen für den Zugriff auf TLS-Zertifikate für den eingehenden Datenverkehr durch 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 Zugriff auf Key Vault mithilfe von RBAC.

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. Bei dieser Implementierung wird der Key Vault mit dem Secrets Store CSI-Treiber verwendet. Das Add-On ruft das TLS-Zertifikat aus Key Vault ab und lädt den Treiber im Pod, der den Eingangscontroller ausführt. Dieser Vorgang 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 finden Sie unter Speicheroptionen 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. Bei AKS werden Richtlinien über Azure Policy bereitgestellt. 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 für Folgendes verwenden:

• Verhindern oder Einschränken der 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.
• 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 und andere Richtlinien für den Cluster und die Ressourcen auszuwählen, z. B. Container Registry, Application Gateway oder Key Vault, die mit dem Cluster interagieren. Wählen Sie Richtlinien basierend auf den Anforderungen Ihrer Organisation aus.

• 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 bietet 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 finden Sie unter Erstellen und Zuweisen von benutzerdefinierten Richtliniendefinitionen.

• 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 Ihre Organisation über generische Richtlinien verfügt.

• Weisen Sie Azure-Richtlinien bestimmten Bereichen zu? 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 Sie in der Präproduktionsumgebung nicht berücksichtigt haben.

Diese Referenzimplementierung aktiviert Azure Policy, wenn der AKS-Cluster erstellt wird. Die restriktive Initiative wird im Prüfungsmodus zugewiesen, um Verstöße sichtbar zu machen.

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 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.

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.

Weitere Informationen zu Windows-spezifischen Azure Policy-Überlegungen finden Sie im Artikel Windows-Container in der AKS-Richtlinienverwaltung.

Skalierbarkeit für Knoten und Pods

Mit zunehmender Nachfrage kann Kubernetes aufskaliert werden, indem vorhandenen Knoten über die horizontale automatische Podskalierung weitere Pods hinzugefügt werden. 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 Anzahl der Knoten über die Azure-Befehlszeilenschnittstelle oder das Azure-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. Weitere 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.

Wir empfehlen, in der HPA-Ressource die minimale und maximale Anzahl an Replikaten 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. Standardmäßig wird nur die CPU-Auslastung berücksichtigt. Die HorizontalPodAutoscaler-Definition gibt Zielwerte für die Metriken an. Die Spezifikation legt beispielsweise die CPU-Zielauslastung fest. 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. Weitere Informationen finden Sie unter Abkühlung der Skalierung von Ereignissen.

Wenn Ihre Workload ereignisgesteuert ist, stellt Kubernetes event-driven autoscaling (KEDA) eine beliebte Open-Source-Option dar. Erwägen Sie KEDA, wenn Ihre Workload von einer Ereignisquelle wie einer Nachrichtenwarteschlange gesteuert wird und nicht von der CPU oder dem Arbeitsspeicher. KEDA unterstützt viele Ereignisquellen oder Scaler. Verwenden Sie die Liste der Ereignisquellen, die KEDA bei KEDA-Scalern skalieren kann. Die Liste enthält den Azure Monitor-Scaler, der eine praktische Möglichkeit darstellt, KEDA-Workloads basierend auf Azure Monitor-Metriken zu skalieren.

Cluster Autoscaler

Die automatische Clusterskalierung 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-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 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 einfachen Workload auf zwei festgelegt.

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

Informationen zu Windows-spezifischen Skalierungsüberlegungen, die in dieser grundlegenden Referenzarchitektur enthalten sind, finden Sie im Artikel Windows-Container in AKS.

Entscheidungen zur Geschäftskontinuität

Um die Geschäftskontinuität aufrechtzuerhalten, definieren Sie eine Vereinbarung zum SLO für die Infrastruktur und Ihre Anwendung. Weitere Informationen finden Sie unter Empfehlungen zum Definieren von Zuverlässigkeitszielen. Überprüfen Sie die Bedingungen für die Vereinbarung zum Servicelevel (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 benötigen, stellen Sie weitere Knoten bereit.

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 Systemknotenpool mit dem CriticalAddonsOnly Taint behaftet ist.

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

Podverfügbarkeit

Angeben von 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.

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 eines Namespace trägt dazu bei, sicherzustellen, dass Pod-Anforderungen und -Grenzwerte bei einer Bereitstellung richtig festgelegt werden. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten.

Festlegen von Podanforderungen und -grenzwerten: Durch Festlegen der Anforderungen und Grenzwerte kann Kubernetes den Pods effizient CPU- und Arbeitsspeicherressourcen zuweisen, was Ihnen eine höhere Containerdichte auf einem Knoten ermöglicht. 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 nach und nach, bis Sie einen Schwellenwert festgelegt haben, der eine Instabilität im Cluster verursachen kann.

Sie können Anforderungen und Grenzwerte in Ihren Bereitstellungsmanifesten angeben. Weitere Informationen finden Sie unter Festlegen von Podanforderungen und -grenzwerten.

Verfügbarkeitszonen und Unterstützung von mehreren Regionen

Verwenden Sie Verfügbarkeitszonen, um sich vor bestimmten Ausfällen zu schützen, sofern diese 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. Der AKS-Dienst verwaltet Skalierungssatzvorgänge und -konfigurationen. Beachten Sie Folgendes, wenn Sie mehrere Zonen aktivieren:

• Gesamte Infrastruktur: Wählen Sie eine Region aus, die Verfügbarkeitszonen unterstützt. Weitere Informationen finden Sie unter Einschränkungen. Um ein SLA für Betriebszeit zu erhalten, müssen Sie die Stufe „Standard“ oder „Premium“ wählen. Bei Verwendung von Verfügbarkeitszonen ist die Betriebszeit-SLA höher.

• Cluster: Sie können Verfügbarkeitszonen nur festlegen, wenn Sie den Knotenpool erstellen. 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.

  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 Container Registry aktiviert.

Mehrere Regionen

Wenn Sie Verfügbarkeitszonen aktivieren, reicht die Abdeckung im unwahrscheinlichen Fall, dass eine ganze Region ausfällt, nicht aus. Um eine höhere Verfügbarkeit zu erhalten, führen Sie mehrere AKS-Cluster in unterschiedlichen Regionen aus.

• Verwenden Sie vorzugsweise gekoppelte Regionen (Regionspaare), sofern diese 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 verfügen nicht über 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 Bereitstellung in mehreren Regionen vereinfachen.

• Geben Sie den Standort an, an dem der redundante Dienst seine sekundäre Instanz hat, wenn eine Azure-Ressource Georedundanz unterstützt. Wenn Sie z. B. die Georeplikation für Container Registry aktivieren, repliziert sie automatisch Images in die ausgewählten Azure-Regionen. Sie bietet auch weiterhin Zugriff auf Images, auch wenn die primäre Region einen Ausfall erlebt.

• Wählen Sie einen Datenverkehrsrouter aus, der den Datenverkehr abhängig von Ihrer Anforderung über Zonen oder Regionen verteilen kann. In dieser Architektur wird 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 Optionen finden Sie unter Auswählen eines Lastenausgleichs.

Notfallwiederherstellung

Wenn in der primären Region ein Fehler auftritt, können Sie im Idealfall schnell eine neue Instanz in einer anderen Region erstellen. Hier sind einige Empfehlungen dafür:

• 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 Status im Cluster speichern müssen, was wir nicht empfehlen, achten Sie darauf, die Daten regelmäßig in einer anderen Region zu sichern.

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

• Stellen Sie jeden Azure-Dienst bereit, indem Sie Funktionen verwenden, die die Notfallwiederherstellung unterstützen. In dieser Architektur ist beispielsweise Container Registry für die Georeplikation aktiviert. Wenn eine Region ausfällt, können Sie weiterhin Images aus dem replizierten Bereich pullen.

• 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

Bei vielen Architekturen können Sie einen neuen Cluster bereitstellen und ihn in den Betriebszustand über GitOps-basiertes Cluster-Boottrapping gefolgt von der Anwendungsbereitstellung zurückgeben. Wenn jedoch ein kritischer Ressourcenzustand vorliegt, z. B. bei Konfigurationszuordnungen, Aufträgen und Geheimnissen, die in Ihrem Bootstrapping-Prozess 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 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 können Sie 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 Sicherungsbereich als Tresorkonfiguration in Azure Backup externalisiert werden.

Die Referenzimplementierung führt keine Sicherung durch, für deren Verwaltung, Überwachung, Erwerb und Sicherung zusätzliche Azure-Ressourcen erforderlich sind. Zu diesen Ressourcen können ein Azure Storage-Konto, Azure Backup-Tresor und -Konfiguration sowie die Funktion des vertrauenswürdigen Zugriffs zählen. Stattdessen stellen GitOps in Kombination mit der Absicht, zustandslose Workloads auszuführen, die Wiederherstellungslösung dar.

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

Kubernetes-API-Server-SLA

Sie können AKS als kostenlosen Dienst verwenden, dieser Tarif bietet jedoch keine finanziell abgesicherte SLA. Um eine SLA zu erhalten, müssen Sie den Standard-Tarif (Standardebene) auswählen. Es wird empfohlen, diese Standardebene für alle Produktionscluster zu verwenden. Verwenden Sie den Free-Tarif nur für Präproduktionscluster und den Premium-Tarif ausschließlich für unternehmenskritische Workloads. Wenn Sie Azure-Verfügbarkeitszonen verwenden, ist die Kubernetes-API-Server-SLA 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

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 Container Registry sind in Premium-SKUs verfügbar, die jedoch kostenaufwendiger sind. Bei Bereitstellungen in mehreren Regionen steigen die Kosten auch, da Bandbreitengebühren anfallen, wenn der Datenverkehr über 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

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

Weitere Informationen finden Sie unter Chaos Studio.

Überwachen und Sammeln von Protokollen und Metriken

Wir empfehlen Container Insights von Azure Monitor 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 Containereinblicke auch verwenden, um die Leistung beim Skalieren der Pods zu überwachen. Es umfasst Telemetrie, die für die Überwachung, Analyse und Visualisierung der gesammelten Daten von entscheidender Bedeutung ist. Containereinblicke identifizieren Trends und ermöglichen es Ihnen, Warnungen zu konfigurieren, um proaktive Benachrichtigungen zu kritischen Problemen zu erhalten.

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

Die meisten in Pods gehosteten Workloads geben Prometheus-Metriken aus. Containereinblicke können in Prometheus integriert werden. Sie können die von Knoten und Kubernetes gesammelten Anwendungs- und Workloadmetriken anzeigen.

Einige nicht von Microsoft stammenden 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.

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

• ClusterAutoscaler: Gewinnung von Einblicken in die Skalierungsvorgänge mit Protokollierung. Weitere Informationen finden Sie unter Abrufen von Protokollen und Status der automatischen Clusterskalierung.
• KubeControllerManager: Gewinnen von Einblicken in die Interaktion zwischen Kubernetes und der Azure-Steuerungsebene.
• kube-audit-admin: Gewinnen von Einblicken in Aktivitäten, die Ihren Cluster ändern. Es gibt keinen Grund, dass kube-audit und kube-audit-admin aktiviert sind. kube-audit ist eine Obermenge von kube-audit-admin, die auch nicht modifizierende (Lese-)Vorgänge umfasst.
• guard: Erfassen von Microsoft Entra ID- und Azure RBAC-Überprüfungen.

Es kann hilfreich sein, dass Sie andere Protokollkategorien, z. B. KubeScheduler oder kube-audit, während der frühen Cluster- oder Workload-Lebenszyklusentwicklung 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 die erweiterten Problembehandlungsprotokolle jedoch dauerhaft aktiviert lassen, nachdem Ihr Problembehandlungsbedarf beendet ist, entstehen Ihnen möglicherweise unnötige Kosten für die Erfassung und Speicherung der Daten in Azure Monitor.

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 Bibliothek mit Abfragen bietet mehr Einblicke in die Integrität und Leistung Ihrer AKS-Cluster. Sie unterstützt das Erreichen Ihrer SLOs.

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

Weitere Informationen zu Windows-spezifischen Überwachungsaspekten finden Sie unter Windows-Container in AKS.

Netzwerkmetriken

Grundlegende Netzwerkmetriken auf Clusterebene sind über native Plattform- und Prometheus-Metriken verfügbar. Sie können die AKS-Netzwerk observability weiter verwenden, um Netzwerkmetriken auf Knotenebene mithilfe von Prometheus-Metriken 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-Containereinblicke, die auch einige netzwerkbezogene Metriken sammelt. Die Referenzimplementierung deaktiviert die Sammlung von Metriken aus Azure Monitor-Containereinblicken und sammelt stattdessen die Metriken der Netzwerk observability mithilfe eines Azure Monitor-Arbeitsbereichs mit verwaltetem 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 finden Sie diese Detailebene mit dem erweiterten Feature für die Netzwerk observability . Für die meisten Workloads ist diese Tiefe der Netzwerkeinblicke nicht erforderlich. Sie sollten die erweiterte Netzwerkbeobachtbarkeit nur aktivieren, wenn Ihre Pods ein hochoptimiertes Netzwerk erfordern, mit der Vertraulichkeit bis zur Paketebene.

Kostenoptimierung für die Protokollierung

Die Referenzimplementierung konfiguriert die ContainerLogV2 Tabelle, um den Standardplan als Ausgangspunkt zu verwenden. Microsoft Defender für Container und die warnungen, die für die Referenzimplementierung erstellt wurden, fragen diese Tabelle nicht ab, sodass der Standardplan wahrscheinlich kostenwirksam ist, da die Kosten für die Aufnahme reduziert werden.

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 beseitigt Abfragegebühren, die für Szenarien optimiert werden, in denen die Abfrageaktivität die Kosten für die Erfassung überwiegt. Indem 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 Auswählen eines Tabellenplans basierend auf der Datennutzung in einem Log Analytics-Arbeitsbereich.

Aktivieren der Selbstreparatur

Ü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.

Routineupdates für AKS-Cluster

Teil von „Day 2“-Vorgängen für Kubernetes-Cluster führt routinebasierte Plattform- und Betriebssystemupdates durch. Es gibt drei Update-Ebenen, die auf jedem AKS-Cluster adressiert werden müssen:

• Die Kubernetes-Version (z. B. Kubernetes 1.30.3 bis 1.30.7 oder Kubernetes 1.30.7 bis 1.31.1), bei der möglicherweise Kubernetes-API-Änderungen und -Einstellungen enthalten sind. 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 native 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.

Umfassende Informationen zum Patchen und Aktualisieren finden Sie im Leitfaden zu Patches und Upgrades in AKS von AKS: Anleitung zu „Day 2“-Vorgängen. 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 Knotenimage-Upgrade auf none und das automatische Cluster-Upgrade 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 das Update in einer Präproduktionsumgebung testen und seine Kompatibilität auf einem neuen Cluster bewerten. Stellen Sie anschließend einen Produktionsreplikatstempel bereit, der die aktualisierte AKS-Version und die Knotenpool-VHDs enthält. Wenn der neue Produktionscluster fertig ist, wird der alte Cluster geleert und schließlich außer Betrieb gesetzt.

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 direkte Upgradestrategie haben.

Direkte Aktualisierungen

In Workloads, bei denen keine AKS-Cluster als unveränderliche Infrastruktur betrieben werden, sollten ihre ausgeführten Cluster regelmäßig aktualisieren werden, wobei alle drei Ebenen adressiert werden. 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 die AKS-Funktion Geplante Wartung, um Upgrades in Ihrem Cluster zu planen und zu steuern. 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 Knotenupgrades blockieren, da die meisten Upgrades für jeden Knoten einen Prozess des Absperrens und Ausgleichens erfordern.
• Bestätigen Sie das Azure-Ressourcenkontingent und die Azure-Ressourcenverfügbarkeit. Bei direkten Upgrades werden neue Instanzen von Knoten, sogenannte Surge-Knoten, bereitgestellt, bevor alte Knoten entfernt werden. Dies bedeutet, dass das Azure-Kontingent und der IP-Adressbereich 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 wie Dienstnetze oder Sicherheitsagents, die Sie Ihrem Cluster hinzugefügt haben. Und testen Sie Ihre Workloadkomponenten, z. B. Eingangscontroller, Dienstnetze und Ihre Workload-Pods. Führen Sie Tests in einer Präproduktionsumgebung durch.

Direkte 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 Updates auf Knotenebene aktualisiert wird. Microsoft testet die Updates für Ihre AKS-Version. Für Windows-Knoten erfolgen die Updates etwa einmal pro Monat. Bei Linux-Knoten erfolgen diese Updates ca. 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 Knotenimage-Betriebssystem Sie verwenden, um eine zeitnahe Anwendung sicherzustellen.
• Zu diesen Updates gehören Sicherheits-, Kompatibilitäts- und Funktionsupdates auf Betriebssystemebene, Betriebssystemkonfigurationseinstellungen und AKS-Komponentenupdates.
• Imageversionen und die darin enthaltenen Komponentenversionsnummern 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 es Sicherheitsupgrades gibt, die Microsoft für wichtig genug hält, um sie vor dem nächsten geplanten Knotenimage-Upgrade zu veröffentlichen. Wenn Sie den Kanal SecurityPatch verwenden, erhalten Sie auch die Updates wie der Kanal NodeImage. Bei der Kanaloption SecurityPatch werden weiterhin Ihre Wartungsfenster berücksichtigt. Stellen Sie daher sicher, dass Ihr Wartungsfenster häufiger Lücken (z. B. täglich oder jeden zweiten 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.

Direkte Clusterupdates

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 beiden neuesten Versionen oder 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, direkte AKS-Versionsupdates mit ausreichend Vorsicht und Präzision 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.

Es wird empfohlen, die Funktion für das automatische Clusterupgrade zu vermeiden, wenn Sie zuerst einen Kubernetes-Cluster 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 „Immer auf dem neuesten Stand bleiben”-Denkweise bei einem langfristigen Supportansatz an den Tag zu legen.

Sie können Benachrichtigungen empfangen, wenn eine neue AKS-Version für Ihren Cluster verfügbar ist, indem Sie das AKS-Systemthema für Azure Event Grid verwenden. Von der Referenzimplementierung wird dieses Event Grid-Systemthema bereitgestellt, sodass Sie das Ereignis Microsoft.ContainerService.NewKubernetesVersionAvailable über Ihre Ereignisdatenstrom-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 wäre es selten, über patch hinauszugehen. Überprüfen Sie beim automatischen Upgrade Ihrer AKS-Version auch die AKS-Versionseinstellung Ihrer Infrastruktur als Code (IaC) für Ihren Cluster, damit die Synchronisierung nicht unterbrochen wird. Konfigurieren Sie Ihr geplantes Wartungsfenster, um diesen automatischen Upgradevorgang zu unterstützen.

Sicherheitsüberwachung

Überwachen Sie Ihre Containerinfrastruktur sowohl auf aktive Bedrohungen als auch auf potenzielle Sicherheitsrisiken. Nachstehend finden Sie einige Ressourcen:

• Aktivieren Sie Microsoft Defender for Containers, um für Ihre Containerimages Empfehlungen von Defender for Cloud zu identifizieren und zu implementieren.
• Defender for Containers führt regelmäßig eine Überprüfung Ihrer Containerimages auf Sicherheitsrisiken durch.
• Des Weiteren generiert Defender for Containers Sicherheitswarnungen für verdächtige Aktivitäten in Echtzeit.
• Sicherheitskonzepte für Anwendungen und Cluster in AKS enthalten ausführliche Informationen dazu, wie die Containersicherheit die gesamte End-to-End-Pipeline vor buildbasierten Anwendungsworkloads schützt, die in AKS ausgeführt werden.

Cluster- und Workloadvorgänge

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

Clusterbootstrapping

Nachdem Sie die Bereitstellung durchgeführt haben, verfügen Sie über einen funktionierenden Cluster, aber Sie müssen möglicherweise noch einige Schritte ausführen, bevor Sie Workloads bereitstellen können. Der Prozess der Vorbereitung des Clusters wird als Bootstrapping bezeichnet. Bootstrapping kann aus der Bereitstellung von erforderlichen Images auf Clusterknoten, dem Erstellen von Namespaces und anderen Aufgaben bestehen, die die Anforderungen des Anwendungsfalles Ihrer Organisation erfüllen.

Um die Lücke zwischen einem bereitgestellten und einem ordnungsgemäß konfigurierten Cluster zu verringern, sollten Clusterbetreiber darüber nachdenken, wie ihr einzigartiger Bootstrappingprozess aussieht. Sie müssen die relevanten Ressourcen im Voraus vorbereiten. Wenn es z. B. wichtig ist, dass Kured auf jedem Knoten ausgeführt wird, bevor Anwendungsworkloads bereitgestellt werden, sollte der Clusterbetreiber sicherstellen, dass eine Container Registry-Instanz, die das Kured-Zielimage enthält, bereits vorhanden ist, bevor er den Cluster bereitstellt.

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

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.

Schließlich ist kubectl bei Verwendung der Erweiterung für einen Teil des Bootstrapping-Prozesses nicht 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 ganz ohne kubectl ausführen.

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

Eine weitere Aufgabe könnte die Integration der grundlegenden Arbeitsauslastung in die Microsoft Entra ID sein.

Verwenden von 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. Sie können Bicep, Azure Resource Manager-Vorlagen (ARM-Vorlagen) oder Terraform verwenden.

Stellen Sie sicher, dass Sie Ressourcen gemäß den geltenden Richtlinien bereitstellen. 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 bei diesen Entscheidungen die Richtlinien Ihrer Organisation zu erzwingen.

Wenn Sie eine Sequenz von Befehlen schreiben müssen, verwenden Sie die Azure CLI. Diese Befehle behandeln eine Reihe von Azure-Diensten, 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 kontinuierlich Anwendungen erstellen und bereitstellen können. 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 Workflows und die Bereitstellung. Andere verbreitete Optionen sind Azure DevOps 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. 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. 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 der Ä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 hat nur Lesezugriff auf das Git-Repository. Dadurch wird sichergestellt, dass Flux nur Änderungen anwendet, die von 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.

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.

Auch wenn Sie GitOps und Flux manuell konfigurieren können, empfehlen wir die Clusterweiterung „GitOps mit Flux v2“ für AKS.

Bereitstellungsstrategien für Workloads und Cluster

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

Führen Sie in jeder Phase Tests und Validierungen durch, bevor Sie mit der nächsten 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 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 erweiterter 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 unter Kostenoptimierung.

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

Informationen zu Windows-spezifischen Kostenverwaltungsaspekten finden Sie unter Windows-Container in AKS.

Bereitstellen

• 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. Die Kosten werden durch die vom Cluster genutzten VM-Instanzen, Speicher- und Protokolldaten sowie Netzwerkressourcen beeinflusst. Wählen Sie für Systemknotenpools eventuell günstigere VMs aus. Die DS2_v2-Serie 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.

• 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 und so die Kapazität Ihrer Hardware vollständig genutzt wird.

• 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 mit Azure Reserved Virtual Machine Instances sparen.

• 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 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.

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

• 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 Warnungen erstellen, um Benachrichtigungen zu erhalten, wenn bestimmte Schwellenwerte überschritten werden. Weitere Informationen finden Sie unter Erstellen eines Budgets mithilfe einer Vorlage.

Überwachen

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

• Azure Advisor

• Microsoft Cost Management

Im Idealfall überwachen Sie Ihre Kosten in Echtzeit oder zumindest in regelmäßigen Abständen. Sie können dann vor Ende des Monats Maßnahmen ergreifen, wenn die Kosten bereits berechnet werden. Überwachen Sie außerdem die monatlichen Trends, um das Budget einzuhalten.

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 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.

  Wichtig

  Eine aggressive Änderung der Einstellungen für die Cluster-Autoskalierung, wie etwa der minimalen und maximalen Knoteneinstellungen für einen Knotenpool, um die Kosten zu beeinflussen, kann kontraproduktiv sein. Wenn scale-down-unneeded-time beispielswiese auf 10 Minuten festgelegt ist und die Minimum- und Maximum-Knoteneinstellungen alle fünf Minuten basierend auf den Workloadmerkmalen geändert werden, wird die Anzahl der Knoten niemals sinken. Dies liegt daran, dass die Berechnung der nicht benötigten Zeit für jeden Knoten aufgrund der aktualisierten Einstellungen zur Autoskalierung für Cluster zurückgesetzt wird.

• 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 auch 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

• Erweiterte AKS-Microservicearchitektur
• AKS-Baseline für Cluster in mehreren Regionen
• Regulierter AKS-Cluster für PCI-DSS 3.2.1
• Baseline-Referenzarchitektur für Windows-Container in AKS

Zugehörige Ressourcen

• AKS-Roadmap auf GitHub
• Einführung in Kubernetes
• Entwickeln und Bereitstellen von Anwendungen auf Kubernetes
• Gut durchdachte Rahmenüberprüfung für AKS
• Beschleuniger für AKS-Zielzonen
• AKS: Anleitung zu „Day 2“-Vorgängen
• Microservicearchitektur in AKS
• Schützen eines AKS-Clusters mit Azure Firewall
• Git-Vorgänge für AKS
• Datenstreaming mit AKS