Freigeben über

Kubernetes-Clusterarchitektur und Workloads für AKS, die von Azure Arc aktiviert werden

  • Artikel

Gilt für: AKS in Azure Stack HCI 22H2, AKS unter Windows Server

Azure Kubernetes Service (AKS) in Azure Stack HCI und Windows Server ist eine für Unternehmen konzipierte Kubernetes-Containerplattform, die von Azure Stack HCI unterstützt wird. Darin enthalten sind ein von Microsoft unterstütztes grundlegendes Kubernetes, ein speziell erstellter Windows-Containerhost und ein von Microsoft unterstützter Linux-Containerhost mit dem Ziel, über eine einfache Bereitstellung und Umgebung für die Lebenszyklusverwaltung zu verfügen.

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.

Kubernetes-Cluster – Architektur

Kubernetes ist die Kernkomponente von AKS, die von Azure Arc aktiviert wird. AKS verwendet eine Reihe vordefinierter Konfigurationen, um Kubernetes-Cluster effektiv und unter Berücksichtigung der Skalierbarkeit bereitzustellen.

Der Bereitstellungsvorgang erstellt mehrere virtuelle Linux- oder Windows-Computer und verknüpft diese zu Kubernetes-Clustern.

Hinweis

Wenn Sie mehrere freigegebene Clustervolumes (Cluster Shared Volumes, CSVs) in Ihrem Cluster ausführen, werden die Daten des virtuellen Computers 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. Dies gilt nur für neue Installationen (nicht für Upgrades).

Das bereitgestellte System ist bereit, standardmäßige Kubernetes-Workloads zu empfangen.Es kann diese Workloads skalieren und sogar die Anzahl der virtuellen Computer und der Cluster nach Bedarf erhöhen oder verringern.

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

  • Der Verwaltungscluster (auch AKS-Host genannt) stellt den zentralen Orchestrierungsmechanismus und die Schnittstelle für die Bereitstellung und Verwaltung eines oder mehrerer Workload-Cluster bereit.
  • Workload-Cluster (auch als Ziel-Cluster bezeichnet) sind der Ort, an dem Container-Anwendungen bereitgestellt werden.

Abbildung der technischen Architektur von Azure Kubernetes Service in Azure Stack HCI und Windows Server.

Verwalten von AKS, das von Arc aktiviert ist

Sie können AKS mit den folgenden Verwaltungsoptionen verwalten:

  • Windows Admin Center bietet eine intuitive Benutzeroberfläche für den Kubernetes-Operator zum Verwalten des Lebenszyklus von Clustern.
  • Ein PowerShell-Modul erleichtert das Herunterladen, Konfigurieren und Bereitstellen von AKS. Das PowerShell-Modul unterstützt auch die Bereitstellung und Konfiguration weiterer Workload-Cluster und die Neukonfiguration bestehender Cluster.

Der Verwaltungscluster

Wenn Sie einen Kubernetes-Cluster erstellen, wird automatisch ein Verwaltungscluster erstellt und konfiguriert. Dieser Verwaltungscluster ist zuständig für die Bereitstellung und Verwaltung von Workload-Clustern, in denen Workloads ausgeführt werden. Ein Verwaltungscluster umfasst die folgenden Kubernetes-Kernkomponenten:

  • API-Server: Auf dem API-Server werden die zugrunde liegenden Kubernetes-APIs verfügbar gemacht. Diese Komponente bietet die Interaktion für Verwaltungstools wie Windows Admin Center, PowerShell-Module oder kubectl.
  • Lastenausgleich: Der Lastenausgleich ist eine einzelne dedizierte Linux-VM mit einer Lastenausgleichsregel für den API-Server des Verwaltungsclusters.

Der Workload-Cluster

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. Ein Verwaltungscluster kann mehrere Workload-Cluster verwalten.

Komponenten eines Workload-Clusters

Der Workload-Cluster verfügt über viele Komponenten, die in den folgenden Abschnitten beschrieben werden.

Steuerungsebene

  • API-Server: Der API-Server ermöglicht die Interaktion mit der Kubernetes-API. Diese Komponente bietet die Interaktion für Verwaltungstools wie Windows Admin Center, PowerShell-Module oder kubectl.
  • 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 mit Linux und HAProxy sowie KeepAlive zur Bereitstellung von Diensten für den Lastenausgleich für die vom Verwaltungscluster bereitgestellten Workload-Cluster. Für jeden Workloadcluster fügt AKS mindestens einen virtuellen Load Balancer-Computer hinzu. Jeder Kubernetes-Dienst vom Typ LoadBalancer , der im Workloadcluster erstellt wird, erstellt schließlich eine Lastenausgleichsregel auf dem virtuellen Computer.

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 hosten die Pods und Dienste, die die Anwendungsworkload bilden.

Es gibt kerne Kubernetes-Workloadkomponenten, die in AKS-Workloadclustern wie Pods und Bereitstellungen bereitgestellt werden können.

Pods

Kubernetes verwendet Pods, um eine Instanz Ihrer Anwendung auszuführen. Ein Pod repräsentiert eine einzelne Instanz der Anwendung. In der Regel verfügen Pods über eine 1:1-Zuordnung zu einem Container, obwohl es erweiterte Szenarien gibt, in denen ein Pod mehrere Container enthalten kann. Diese Pods mit mehreren Containern werden zusammen auf dem gleichen Knoten geplant und ermöglichen es Containern, zugehörige Ressourcen gemeinsam zu nutzen. Weitere Informationen finden Sie unter Kubernetes Pods (Kubernetes-Pods) und Kubernetes Pod Lifecycle (Lebenszyklus von Kubernetes-Pods).

Bereitstellungen

Eine Bereitstellung repräsentiert einen oder mehrere identische Pods, die vom Kubernetes-Bereitstellungscontroller verwaltet werden. Eine Bereitstellung definiert die Anzahl der zu erstellenden Replikate (Pods), und der Kubernetes-Scheduler stellt sicher, dass zusätzliche Pods auf fehlerfreien Knoten geplant werden, wenn Bei Pods oder Knoten Probleme auftreten. Weitere Informationen finden Sie unter Kubernetes-Bereitstellungen.

StatefulSets und DaemonSets

Der Bereitstellungscontroller verwendet den Kubernetes-Scheduler, um eine bestimmte Anzahl von Replikaten auf einem beliebigen verfügbaren Knoten mit verfügbaren Ressourcen auszuführen. Dieser Ansatz der Verwendung von Bereitstellungen ist möglicherweise für zustandslose Anwendungen ausreichend, aber nicht für Anwendungen, die eine persistente Benennungskonvention oder speicher erfordern. Bei Anwendungen, für die auf jedem Knoten oder auf ausgewählten Knoten in einem Cluster ein Replikat vorhanden sein muss, überprüft der Bereitstellungscontroller nicht, wie die Replikate auf den Knoten verteilt sind.

  • StatefulSets: Ein StatefulSet ähnelt einer Bereitstellung, da mindestens ein identischer Pod erstellt und verwaltet wird. Replikate in einem StatefulSet folgen einem ordnungsgemäßen, sequenziellen Verfahren für Bereitstellung, Skalierung, Upgrades und Beendigungen. In einem StatefulSet bleiben Namenskonvention, Netzwerknamen und Speicher permanent erhalten, wenn Replikate neu geplant werden. Replikate in einem StatefulSet werden geplant und auf jedem verfügbaren Knoten in einem Kubernetes-Cluster ausgeführt. Wenn Sie sicherstellen müssen, dass mindestens ein Pod in Ihrer Gruppe auf einem Knoten ausgeführt wird, können Sie stattdessen ein DaemonSet verwenden. Weitere Informationen finden Sie unter Kubernetes StatefulSets.
  • DaemonSets: Für bestimmte Protokollsammlungs- oder Überwachungsanforderungen müssen Sie möglicherweise einen bestimmten Pod auf allen oder ausgewählten Knoten ausführen. Ein DaemonSet wird erneut verwendet, um einen oder mehrere identische Pods bereitzustellen, aber der DaemonSet-Controller stellt sicher, dass jeder angegebene Knoten eine instance des Pods ausführt. Weitere Informationen finden Sie unter Kubernetes DaemonSets.

Namespaces

Kubernetes-Ressourcen wie Pods und Bereitstellungen werden logisch in einen Namespace gruppiert. Diese Gruppierungen bieten eine Möglichkeit, Workloadcluster logisch aufzuteilen und den Zugriff auf das Erstellen, Anzeigen oder Verwalten von Ressourcen einzuschränken. Sie können z. B. Namespaces erstellen, um Unternehmensgruppen voneinander zu trennen. Benutzer können nur mit den Ressourcen innerhalb der ihnen zugewiesenen Namespaces interagieren. Weitere Informationen finden Sie unter Kubernetes-Namespaces.

Wenn Sie einen Azure Kubernetes Service Cluster in AKS erstellen, der von Arc aktiviert ist, sind die folgenden Namespaces verfügbar:

  • default: Ein Namespace, in dem Pods und Bereitstellungen standardmäßig erstellt werden, wenn keine bereitgestellt werden. In kleineren Umgebungen können Sie Anwendungen direkt im Standardnamespace bereitstellen, ohne weitere logische Unterteilungen zu erstellen. Wenn Sie mit der Kubernetes-API interagieren, z.B. mit kubectl get pods, wird der Standardnamespace verwendet, wenn kein anderer Namespace angegeben wurde.
  • kube-system: Ein Namespace, in dem Kernressourcen vorhanden sind, z. B. Netzwerkfeatures wie DNS und Proxy, oder die Kubernetes-Dashboard. In diesem Namespace stellen Sie in der Regel keine eigenen Anwendungen bereit.
  • kube-public: Ein Namespace wird in der Regel nicht verwendet, kann aber verwendet werden, damit Ressourcen im gesamten Cluster sichtbar sind und von jedem Benutzer angezeigt werden können.

Geheimnisse

Mit Kubernetes-Geheimnissen können Sie vertrauliche Informationen wie Kennwörter, OAuth-Token und SSH-Schlüssel (Secure Shell) speichern und verwalten. Standardmäßig speichert Kubernetes Geheimnisse als unverschlüsselte Base64-codierte Zeichenfolgen, und sie können von jedem Benutzer mit API-Zugriff als Nur-Text abgerufen werden. Weitere Informationen finden Sie unter Kubernetes Secrets.

Persistente Volumes

Ein persistentes Volume ist eine Speicherressource in einem Kubernetes-Cluster, die entweder vom Administrator bereitgestellt oder dynamisch mithilfe von Speicherklassen bereitgestellt wurde. Um persistente Volumes zu verwenden, fordern Pods den Zugriff mithilfe eines PersistentVolumeClaim an. Weitere Informationen finden Sie unter Persistente Datenträger.

Bereitstellungen mit gemischten Betriebssystemen

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

  • Die Knotenauswahl ist ein einfaches Feld in der Podspezifikation, das einschränkt, dass Pods nur auf fehlerfreie Knoten geplant werden, die dem Betriebssystem entsprechen.
  • Taints und Toleranzen arbeiten zusammen, um sicherzustellen, dass Pods nicht unbeabsichtigt auf Knoten geplant werden. Ein Knoten kann so "befleckt" werden, dass er keine Pods akzeptiert, die seinen Taint nicht explizit durch eine "Toleranz" in der Podspezifikation tolerieren.

Weitere Informationen finden Sie unter Knotenselektoren und Taints und Toleranzen.

Nächste Schritte

In diesem Artikel haben Sie mehr über die Clusterarchitektur von AKS erfahren, die von Azure Arc aktiviert wird, und die Komponenten des Workloadclusters. Weitere Informationen zu diesen Konzepten finden Sie in den folgenden Artikeln: