Cluster-Architektur und Workloads von Kubernetes für Azure Kubernetes Service in Azure Stack HCI und Windows Server

Gilt für: Azure Stack HCI und 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 in Azure Stack HCI und Windows Server. AKS in Azure Stack HCI verwendet eine Reihe von vordefinierten 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 Volume, CSV) in Ihrem Azure Stack HCI- oder Windows Server-Cluster betreiben, werden die Daten der VM 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 ist in Azure Stack HCI beinhaltet folgende 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.

Veranschaulicht die technische Architektur von AKS in Azure Stack HCI und Windows Server

Verwalten von AKS in Azure Stack HCI und Windows Server

Sie können AKS in Azure Stack HCI und Windows Server verwalten, indem Sie die folgenden Verwaltungsoptionen verwenden:

  • Windows Admin Center bietet eine intuitive Benutzeroberfläche für den Kubernetes-Operator zur Verwaltung des Lebenszyklus von Azure Kubernetes Service-Clustern in Azure Stack HCI.
  • Das PowerShell-Modul ist eine einfache Möglichkeit, AKS in Azure Stack HCI und Windows Server herunterzuladen, zu konfigurieren und bereitzustellen. Das PowerShell-Modul unterstützt auch die Bereitstellung und Konfiguration weiterer Workload-Cluster und die Neukonfiguration bestehender Cluster.

Der Verwaltungscluster

Wenn Sie einen AKS-Cluster in Azure Stack HCI 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 – Über den 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.
  • Azure Load Balancer: Der Lastenausgleich ist ein einzelner dedizierter virtueller Linux-Computer 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 zur Einrichtung 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, in dem Daten gespeichert werden, 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 Workload-Cluster fügt AKS in Azure Stack HCI mindestens einen virtuellen Computer für den Lastenausgleich hinzu. Jeder Kubernetes-Dienst von dem Typ LoadBalancer, der auf dem Workload-Cluster erstellt wird, erstellt am Ende eine Lastenausgleichsregel auf dem virtuellen Computer für den Lastenausgleich.

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 Kubernetes-Workloadkernkomponenten, die auf „AKS in Azure Stack HCI und Windows Server“-Workloadclustern bereitgestellt werden können, z. B. Pods und Bereitstellungen.

Pods

Kubernetes verwendet Pods, um eine Instanz Ihrer Anwendung auszuführen. Ein Pod repräsentiert eine einzelne Instanz der Anwendung. Pods weisen in der Regel eine 1:1-Zuordnung mit einem Container auf. Es gibt jedoch auch erweiterte Szenarien, 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 von Replikaten (Pods), die erstellt werden sollen. Der Kubernetes Scheduler stellt sicher, dass weitere Pods auf intakten Knoten geplant werden, falls Probleme mit Pods oder Knoten auftreten sollten. 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. Diese Art der Verwendung von Bereitstellungen mag für zustandslose Anwendungen ausreichend sein, nicht aber für Anwendungen, die eine permanente Namenskonvention oder einen permanenten Speicher benötigen. 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 insofern, als ein oder mehrere 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 auf einem beliebigen verfügbaren Knoten in einem „AKS in Azure Stack HCI“-Cluster geplant und ausgeführt. Wenn Sie sicherstellen müssen, dass mindestens ein Pod in Ihrem Set auf einem Knoten ausgeführt wird, können Sie stattdessen ein DaemonSet verwenden. Weitere Informationen finden Sie unter Kubernetes StatefulSets.

  • DaemonSets: Bei spezifischen Anforderungen an die Protokollsammlung oder Überwachung müssen Sie möglicherweise einen bestimmten Pod auf allen bzw. auf ausgewählten Knoten ausführen. Auch ein DaemonSet wird zum Bereitstellen von einem oder mehreren identischen Pods verwendet, 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 ermöglichen, „AKS in Azure Stack HCI und Windows Server“-Workloadcluster logisch zu unterteilen und den Zugriff zum Erstellen, Anzeigen oder Verwalten von Ressourcen einzuschränken. Sie können Namespaces erstellen, um beispielsweise 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 Azure Stack HCI erstellen, stehen Ihnen die folgenden Namespaces zur Verfügung:

  • default: In diesem Namespace werden Pods und Bereitstellungen standardmäßig erstellt, wenn kein anderer Namespace angegeben 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: In diesem Namespace befinden sich grundlegende Ressourcen, beispielsweise Netzwerkfeatures wie DNS und Proxy oder das Kubernetes-Dashboard. In diesem Namespace stellen Sie in der Regel keine eigenen Anwendungen bereit.
  • kube-public: Dieser Namespace wird in der Regel nicht genutzt. Er kann jedoch für Ressourcen verwendet werden, die über den gesamten Cluster hinweg sichtbar sein sollen, und er kann von allen Benutzern angezeigt werden.

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 kann 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:

  • Knotenselektor ist ein einfaches Feld in der Podspezifikation, mit dem Pods nur auf fehlerfreien Knoten geplant werden können, die mit dem Betriebssystem übereinstimmen.
  • Taints und Toleranzen arbeiten zusammen, um sicherzustellen, dass Pods nicht unbeabsichtigt auf Knoten geplant werden. Ein Knoten kann „verfälscht“ sein, um keine Pods zu akzeptieren, die seinen Taint nicht ausdrücklich durch eine „Toleranz“ in der Podspezifikation zu tolerieren.

Weitere Informationen finden Sie unter Knotenselektoren und Taints und Toleranzen.

Nächste Schritte

In diesem Artikel haben Sie die Clusterarchitektur von AKS in Azure Stack HCI und Windows Server und die Komponenten von Workloadclustern kennengelernt. Weitere Informationen zu diesen Konzepten finden Sie in den folgenden Artikeln: