Freigeben über

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

  • Artikel

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

Azure Kubernetes Service (AKS) auf Azure Local und Windows Server ist eine Kubernetes-Containerplattform auf Unternehmensniveau, die von Azure Local 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 ist. AKS verwendet eine Reihe vordefinierter Konfigurationen, um Kubernetes-Cluster effektiv und skalierbarkeitsgerecht bereitzustellen.

Der Bereitstellungsvorgang erstellt mehrere virtuelle Linux- oder Windows-Computer und verbindet sie zusammen, um Kubernetes-Cluster(n) zu erstellen.

Hinweis

Um die Zuverlässigkeit des Systems zu verbessern, werden standardmäßig virtuelle Computerdaten automatisch auf alle verfügbaren CSVs verteilt, wenn Sie mehrere freigegebene Clustervolumes (Cluster Shared Volumes, CSVs) in Ihrem Cluster ausführen. 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-Dienstcluster 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 auf Azure Local und Windows Server.

Verwalten von von Arc aktivierten AKS

Sie können AKS mithilfe der 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: Der API-Server stellt fest, wie die zugrunde liegenden Kubernetes-APIs verfügbar gemacht werden. Diese Komponente bietet die Interaktion für Verwaltungstools wie Windows Admin Center, PowerShell-Module oder kubectl.
  • Lastenausgleich: Der Lastenausgleichsmodul 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üsselwertspeicher, 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 Computer zum Lastenausgleich hinzu. Jeder Kubernetes-Dienst vom Typ LoadBalancer , der auf dem Workloadcluster erstellt wird, erstellt schließlich eine Lastenausgleichsregel in der VM.

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 wichtige Kubernetes-Workloadkomponenten, die auf 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 mit 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 Pods oder Knoten Probleme haben. Weitere Informationen finden Sie unter Kubernetes-Bereitstellungen.

StatefulSets und DaemonSets

Der Bereitstellungscontroller verwendet den Kubernetes-Scheduler, um eine bestimmte Anzahl von Replikaten auf jedem verfügbaren Knoten mit verfügbaren Ressourcen auszuführen. Dieser Ansatz bei der Verwendung von Bereitstellungen kann für zustandslose Anwendungen ausreichen, aber nicht für Anwendungen, die eine persistente Benennungskonvention oder einen beständigen 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, in der mindestens eine identische Pods erstellt und verwaltet werden. 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 Instanz 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 zu unterteilen 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-Dienstcluster auf AKS erstellen, die von Arc aktiviert sind, stehen die folgenden Namespaces zur Verfügung:

  • standard: ein Namespace, in dem Pods und Bereitstellungen standardmäßig erstellt werden, wenn keine bereitgestellt wird. 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 das 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 jedoch verwendet werden, damit Ressourcen im gesamten Cluster sichtbar sind und von jedem Benutzer angezeigt werden können.

Geheimnisse

Kubernetes-Schlüssel ermöglichen es Ihnen, vertrauliche Informationen wie Kennwörter, OAuth-Token und SSH-Schlüssel (Secure Shell) zu speichern und zu verwalten. Standardmäßig speichert Kubernetes geheime Schlüssel als unverschlüsselte base64-codierte Zeichenfolgen, und sie können von jedem 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 Pod-Spezifikation, das die Planung von Pods nur auf fehlerfreie Knoten beschränkt, die mit dem Betriebssystem übereinstimmen.
  • 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 "Toleration" in der Pod-Spezifikation 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 wurden, und die Workloadclusterkomponenten. Weitere Informationen zu diesen Konzepten finden Sie in den folgenden Artikeln: