Share via


AKS Arc- und Workloadclusterarchitektur

Gilt für: Azure Stack HCI, Version 23H2

Azure Kubernetes Service (AKS) in Azure Stack HCI ist eine Kubernetes-Containerplattform für Unternehmen. Es umfasst von Microsoft unterstützte Kern-Kubernetes, einen speziell entwickelten Windows-Containerhost und einen von Microsoft unterstützten Linux-Containerhost mit dem Ziel, eine einfache Bereitstellungs- und Lebenszyklusverwaltung zu ermöglichen.

In diesem Artikel werden die grundlegenden Kubernetes-Infrastrukturkomponenten wie Steuerungsebene, Knoten und Knotenpools vorgestellt. Darüber hinaus werden Workloadressourcen wie Pods, Bereitstellungen und Sets erläutert, und es wird beschrieben, wie Sie Ressourcen in Namespaces gruppieren.

Clusterarchitektur

Ein Azure Kubernetes Service Cluster verfügt über die folgenden Komponenten:

  • Arc Resource Bridge (auch als Arc Anwendung bezeichnet) stellt den zentralen Orchestrierungsmechanismus und die Schnittstelle zum Bereitstellen und Verwalten eines oder mehrerer Workloadcluster bereit.
  • In Workloadclustern (auch als Zielcluster bezeichnet) werden containerisierte Anwendungen bereitgestellt.

Diagramm mit Clusterarchitektur

AKS Arc verwendet eine Reihe vordefinierter Konfigurationen, um Kubernetes-Cluster effektiv und unter Berücksichtigung der Skalierbarkeit bereitzustellen. Ein Bereitstellungsvorgang erstellt mehrere virtuelle Linux- oder Windows-Computer und verbindet diese, um einen oder mehrere Kubernetes-Cluster zu erstellen.

Hinweis

Wenn Sie mehrere freigegebene Clustervolumes (CLUSTER Shared Volumes, CSVs) in Ihrem Cluster ausführen, werden die Vm-Daten standardmäßig automatisch auf alle verfügbaren CSVs im Cluster verteilt, um die Zuverlässigkeit des Systems zu verbessern. So wird sichergestellt, dass Anwendungen bei CSV-Ausfällen erhalten bleiben.

Arc-Ressourcenbrücke

Die Arc Resource Bridge verbindet eine private Cloud (z. B. Azure Stack HCI, VMWare/vSphere oder SCVMM) mit Azure und ermöglicht die lokale Ressourcenverwaltung von Azure aus. Azure Arc Resource Bridge bietet die Möglichkeit, private Clouds zu nutzen, die zum Verwalten von Ressourcen wie z. B. Kubernetes-Clustern lokal über Azure erforderlich sind. Arc Resource Bridge enthält die folgenden AKS Arc-Kernkomponenten:

  • AKS Arc-Clustererweiterungen: Eine Clustererweiterung ist die lokale Entsprechung eines Azure Resource Manager-Ressourcenanbieters. Genau wie der Microsoft.ContainerService-Ressourcenanbieter AKS-Cluster in Azure verwaltet, hilft die AKS Arc-Clustererweiterung, sobald sie Ihrer Arc Resource Bridge hinzugefügt wurde, bei der Verwaltung von Kubernetes-Clustern über Azure.
  • Benutzerdefinierter Speicherort: Ein benutzerdefinierter Standort ist das lokale Äquivalent einer Azure-Region und eine Erweiterung des Azure-Standortkonstrukts. Benutzerdefinierte Standorte bieten Mandantenadministratoren die Möglichkeit, ihr Rechenzentrum mit installierten Erweiterungen als Zielstandorte für die Bereitstellung von Azure-Dienstinstanzen zu verwenden.

Workloadcluster

Der Workload-Cluster ist eine Bereitstellung von Kubernetes mit einer Hochverfügbarkeit unter Verwendung von virtuellen Linux-Computern zur Ausführung von Komponenten der Kubernetes-Steuerungsebene und von Linux-Workerknoten. Windows Server Core-basierte VMs werden zum Einrichten von Windows-Workerknoten verwendet. Es kann mindestens ein Workloadcluster sein, der von einem Verwaltungscluster verwaltet wird.

Ein Workloadcluster verfügt über viele Komponenten, wie in den folgenden Abschnitten beschrieben.

Steuerungsebene

  • API-Server: Der API-Server ermöglicht die Interaktion mit der Kubernetes-API. Diese Komponente stellt die Interaktion für Verwaltungstools wie Windows Admin Center, PowerShell-Module oder kubectl bereit.
  • Etcd: Etcd ist ein verteilter Schlüssel-Wert-Speicher, der daten speichert, die für die Lebenszyklusverwaltung des Clusters erforderlich sind. Er speichert den Zustand der Steuerungsebene.

Load Balancer

Der Lastenausgleich ist ein virtueller Computer, auf dem Linux und HAProxy und KeepAlive ausgeführt werden, um Dienste mit Lastenausgleich für die Workloadcluster bereitzustellen, die vom Verwaltungscluster bereitgestellt werden. Für jeden Workloadcluster fügt AKS Arc mindestens einen virtuellen Load Balancer-Computer hinzu. Jeder Kubernetes-Dienst vom Typ LoadBalancer, der auf dem Workloadcluster erstellt wird, erstellt eine Lastenausgleichsregel auf dem virtuellen Computer.

Die MetalLB Arc-Erweiterung ist ein Tool, mit dem Sie externe IP-Adressen für Ihre Anwendungen und Dienste generieren können. Arc-fähige Kubernetes-Cluster können mithilfe der Arc Networking k8s-Erweiterung in MetalLB integriert werden. Informationen zum MetalLB-Lastenausgleich für AKS, der von Arc Kubernetes-Clustern aktiviert wird, finden Sie in der Übersicht über MetalLB für Kubernetes-Cluster.

Workerknoten

Zum Ausführen Ihrer Anwendungen und der unterstützenden Dienste benötigen Sie einen Kubernetes-Knoten. Ein AKS-Workloadcluster verfügt über einen oder mehrere Workerknoten. Workerknoten fungieren als virtuelle Computer (VMs), die die Kubernetes-Knotenkomponenten ausführen und die Pods und Dienste hosten, aus denen die Anwendungsworkload besteht.

Es gibt Kernkomponenten der Kubernetes-Workload, die Sie in AKS-Workloadclustern bereitstellen können, z. B. Pods und Bereitstellungen.

Lebenszyklusverwaltung

Azure Arc wird automatisch für alle Kubernetes-Cluster aktiviert, die mit AKS Arc erstellt wurden. Sie können Ihre Microsoft Entra Identität verwenden, um von überall aus eine Verbindung mit Ihren Clustern herzustellen. Mit Azure Arc können Sie vertraute Tools wie Azure-Portal, Azure CLI und Azure Resource Manager-Vorlagen verwenden, um Ihre Kubernetes-Cluster zu erstellen und zu verwalten.

Bereitstellungen mit gemischten Betriebssystemen

Wenn ein bestimmter Workloadcluster sowohl aus Linux- als auch aus Windows-Workerknoten besteht, muss er für ein Betriebssystem geplant werden, das die Bereitstellung der Workload unterstützen kann. Kubernetes bietet zwei Mechanismen, um sicherzustellen, dass Workloads auf Knoten mit einem Zielbetriebssystem landen:

  • Node Selector ist ein einfaches Feld in der Podspezifikation, das pods einschränkt, nur auf fehlerfreie Knoten zu planen, die dem Betriebssystem entsprechen.
  • Taints und Tolerationen arbeiten zusammen, um sicherzustellen, dass Pods nicht unbeabsichtigt auf Knoten eingeplant werden. Ein Knoten kann "verfleckt" werden, um keine Pods zu akzeptieren, die seinen Taint durch eine "Toleranz" in der Podspezifikation nicht explizit tolerieren.

Weitere Informationen finden Sie unter Knotenselektoren und Taints und Toleranzen.

Nächste Schritte