Kubernetes-Knoten- und -Knotenpoolverwaltung

Azure Kubernetes Service (AKS)
Azure Virtual Machines

Die Kubernetes-Architektur basiert auf zwei Ebenen: Der Steuerungsebene und einem oder mehreren Knoten in Knotenpools. In diesem Artikel wird beschrieben und verglichen, wie Amazon Elastic Kubernetes Service (Amazon EKS) und Azure Kubernetes Service (AKS) Agent- oder Workerknoten verwalten.

Hinweis

Dieser Artikel ist Teil einer Artikelreihe, die Experten, die mit Amazon EKS vertraut sind, hilft, Azure Kubernetes Service (AKS) zu verstehen.

Sowohl in Amazon EKS als auch in AKS stellt die Cloudplattform die Steuerungsebene bereit und verwaltet diese, und der Kunde verwaltet die Knotenebene. Das folgende Diagramm zeigt die Beziehung zwischen der Steuerungsebene und Knoten in der AKS Kubernetes-Architektur.

Diagramm der Steuerungsebene und Knoten in der AKS-Architektur.

Verwaltete Knotengruppen in Amazon EKS

Verwaltete Knotengruppen in Amazon EKS automatisieren die Bereitstellung und Lebenszyklusverwaltung von Amazon Elastic Compute Cloud (EC2)-Workerknoten für Amazon EKS-Cluster. Amazon Web Services (AWS)-Benutzer können das Befehlszeilen-Hilfsprogramm eksctl verwenden, um Knoten für ihre EKS-Cluster zu erstellen, zu aktualisieren oder zu beenden. Knotenaktualisierungen und -beendigungen sperren Konten automatisch ab und gleichen diese aus, um sicherzustellen, dass Anwendungen verfügbar bleiben.

Jeder verwaltete Knoten wird als Teil einer Amazon EC2 Auto Scaling-Gruppe bereitgestellt, die von Amazon EKS betrieben und gesteuert wird. Die Kubernetes-Clusterautoskalierung passt die Anzahl der Workerknoten in einem Cluster automatisch an, wenn Pods ausfallen oder auf anderen Knoten neu geplant werden. Jede Knotengruppe kann so konfiguriert werden, dass sie in mehreren Verfügbarkeitszonen innerhalb einer Region ausgeführt wird.

Weitere Informationen zu verwalteten Amazon EKS-Knoten finden Sie unter Erstellen einer verwalteten Knotengruppe und Aktualisieren einer verwalteten Knotengruppe.

Sie können Kubernetes-Pods auch auf AWS Fargate ausführen. Fargate bietet On-Demand-Computekapazität im richtigen Umfang für Container. Weitere Informationen zur Verwendung von Fargate mit Amazon EKS finden Sie unter AWS Fargate.

Karpenter

Karpenter ist ein Open-Source-Projekt, das die Verwaltung des Knotenlebenszyklus in Kubernetes-Clustern verbessert. Sie automatisiert die Bereitstellung und Bereitstellung von Knoten basierend auf den spezifischen Planungsanforderungen von Pods und ermöglicht eine effiziente Skalierung und Kostenoptimierung. Die wichtigsten Funktionen sind:

  • Überwachen Sie Pods, die der Kubernetes-Scheduler aufgrund von Ressourceneinschränkungen nicht planen kann.
  • Bewerten Sie die Planungsanforderungen (Ressourcenanforderungen, Knotenselektoren, Affinitäten, Tolerationen usw.) der nicht geplanten Pods.
  • Stellen Sie neue Knoten bereit, die den Anforderungen dieser Pods entsprechen.
  • Entfernen Sie Knoten, wenn sie nicht mehr benötigt werden.

Mit Karpenter definieren Sie NodePools mit Einschränkungen für die Knotenbereitstellung wieTaints, Bezeichnungen, Anforderungen (Instanztypen, Zonen usw.) und Grenzwerte für die Gesamtbereitstellung von Ressourcen. Beim Bereitstellen von Workloads geben Sie verschiedene Planungseinschränkungen in den Pod-Spezifikationen an, z. B. Ressourcenanforderungen/Grenzwerte, Knotenselektoren, Knoten-/Pod-Affinitäten, Tolerationen und Topologie-Spreadeinschränkungen. Anschließend stellt Karpenter basierend auf diesen Spezifikationen die richtigen Knoten für die richtige Größe zur Seite.

Vor dem Start von Karpenter setzten Amazon EKS-Benutzer in erster Linie auf Amazon EC2 Auto Scaling-Gruppen und die Kubernetes Cluster Autoscaler (CAS), um die Rechenkapazität ihrer Cluster dynamisch anzupassen. Sie müssen nicht Dutzende von Knotengruppen erstellen, um die Flexibilität und Vielfalt zu erreichen, die Sie mit Karpenter erhalten. Im Gegensatz zum Kubernetes Cluster Autoscaler ist Karpenter nicht so eng mit Kubernetes-Versionen gekoppelt und erfordert nicht, dass Sie zwischen AWS und Kubernetes-APIs springen.

Karpenter konsolidiert Instanz-Orchestrierungsaufgaben innerhalb eines einzigen Systems, was einfacher, stabiler und clusterfähiger ist. Karpenter wurde entwickelt, um einige der Herausforderungen zu überwinden, die von Cluster Autoscaler präsentiert werden, indem es vereinfachte Möglichkeiten bietet:

  • Stellen Sie Knoten basierend auf Workloadanforderungen bereit.
  • Erstellen Sie verschiedene Knotenkonfigurationen nach Instanztyp mit flexiblen NodePool-Optionen. Anstatt viele bestimmte benutzerdefinierte Knotengruppen zu verwalten, könnte Karpenter Ihnen die Verwaltung verschiedener Arbeitsauslastungskapazitäten mit einem einzigen, flexiblen NodePool ermöglichen.
  • Erzielen Sie eine verbesserte Pod-Planung im großen Maßstab, indem Sie Knoten und Planungs-Pods schnell starten.

Informationen und Dokumentation zur Verwendung von Karpenter finden Sie auf der karpenter.sh-Website.

Karpenter bringt die Skalierungsverwaltung näher an kubernetes native APIs als Auto Scaling Groups (ASGs) und Managed Node Groups (MNGs). ASGs und MNGs sind AWS-native Abstraktionen, bei denen die Skalierung basierend auf METRIKen auf AWS-Ebene ausgelöst wird, z. B. EC2 CPU-Auslastung. Cluster Autoscaler überbrückt die Kubernetes-Abstraktionen in AWS-Abstraktionen, verliert jedoch aufgrund dessen einige Flexibilität, z. B. die Planung für eine bestimmte Verfügbarkeitszone.

Karpenter entfernt eine Ebene der AWS-Abstraktion, um einige der Flexibilität direkt in Kubernetes zu bringen. Karpenter wird am besten für Cluster mit Workloads verwendet, die auf Zeiträume mit hoher, spiky Nachfrage oder unterschiedlichen Berechnungsanforderungen stoßen. MNGs und ASGs eignen sich gut für Cluster, die Workloads ausführen, die tendenziell statischer und konsistenter sind. Sie können je nach Ihren Anforderungen eine Mischung aus dynamisch und statisch verwalteten Knoten verwenden.

Kata-Container

Kata Containers ist ein Open-Source-Projekt, das eine sichere Containerlaufzeit bereitstellt, die den einfachen Charakter von Containern mit den Sicherheitsvorteilen virtueller Computer kombiniert. Es behebt die Notwendigkeit einer stärkeren Workloadisolation und Sicherheit, indem jeder Container mit einem anderen Gastbetriebssystem gestartet wird, im Gegensatz zu herkömmlichen Containern, die denselben Linux-Kernel unter Workloads gemeinsam nutzen. Kata-Container führen Container auf einem OCI-kompatiblen virtuellen Computer aus, wodurch eine strikte Isolation zwischen Containern auf demselben Hostcomputer bereitgestellt wird. Kata Containers bieten die folgenden Features:

  • erweiterte Workloadisolation: Jeder Container wird in einer eigenen einfachen VM ausgeführt, wodurch die Isolation auf Hardwareebene sichergestellt wird.
  • Verbesserte Sicherheit: Die Verwendung der VM-Technologie bietet eine zusätzliche Sicherheitsebene, wodurch das Risiko von Containerunterbrechungen reduziert wird.
  • Kompatibilität mit Branchenstandards: Kata-Container sind in Branchenstandardtools wie das OCI-Containerformat und kubernetes CRI-Schnittstelle integriert.
  • Unterstützung für mehrere Architekturen und Hypervisoren: Kata-Container unterstützen AMD64- und ARM-Architekturen und können mit Hypervisoren wie Cloud-Hypervisor und Firecracker verwendet werden.
  • Einfache Bereitstellung und Verwaltung: Kata-Container abstrahieren die Komplexität der Orchestrierung von Workloads durch Nutzung des Kubernetes-Orchestrierungssystems.

AWS-Kunden können Kata Containers auf AWS einrichten und ausführen, indem sie einen Amazon Elastic Kubernetes Service (EKS) Cluster konfigurieren, um Firecrackerzu verwenden, eine open Source-Virtualisierungstechnologie, die von Amazon entwickelt wurde, um sichere container und funktionsbasierte Dienste zu erstellen und zu verwalten. Firecracker ermöglicht Es Kunden, Workloads auf einfachen virtuellen Computern, sogenannten MicroVMs, bereitzustellen, die eine verbesserte Sicherheits- und Workloadisolation über herkömmliche virtuelle Computer bieten und gleichzeitig die Geschwindigkeit und Ressourceneffizienz von Containern ermöglichen. Das Aktivieren von Kata-Containern auf AWS EKS erfordert eine Reihe manueller Schritte, die in Verbessern der Kubernetes-Workloadisolation und Sicherheit mithilfe von Kata-Containernbeschrieben werden.

Dedizierte Hosts

Wenn Sie Amazon Elastic Kubernetes Service (EKS) zum Bereitstellen und Ausführen von Containern verwenden, ist es möglich, sie auf dedizierten Amazon EC2-Hostsauszuführen. Beachten Sie jedoch, dass dieses Feature nur für selbstverwaltete Knotengruppen verfügbar ist. Dies bedeutet, dass Kunden manuell eine Startvorlage, Autoskalierungsgruppenerstellen und beim EKS-Cluster registrieren müssen. Der Erstellungsprozess für diese Ressourcen entspricht der allgemeinen EC2-Autoskalierung.

Ausführlichere Informationen zum Ausführen von Containern auf dedizierten EC2-Hosts mit AWS EKS finden Sie in der folgenden Dokumentation:

AKS-Knoten und -Knotenpools

Durch das Erstellen eines AKS-Clusters wird automatisch eine Steuerungsebene erstellt und konfiguriert, die Kubernetes-Kerndienste und Anwendungsworkloadorchestrierung bereitstellt. Die Azure-Plattform stellt die AKS-Steuerungsebene kostenlos als verwaltete Azure-Ressource bereit. Die Steuerungsebene und ihre Ressourcen sind nur in der Region vorhanden, in der Sie den Cluster erstellt haben.

Die Knoten, auch als Agent-Knoten oder Workerknoten bezeichnet, hosten die Workloads und Anwendungen. In AKS verwalten und bezahlen Kunden die Agent-Knoten vollständig, die an den AKS-Cluster angefügt sind.

Zum Ausführen von Anwendungen und unterstützenden Diensten benötigt ein AKS-Cluster mindestens einen Knoten: einen virtuellen Azure-Computer (VM) zum Ausführen der Kubernetes-Knotenkomponenten und -Containerlaufzeit. Jeder AKS-Cluster muss mindestens einen Systemknotenpool mit mindestens einem Knoten enthalten.

AKS gruppiert Knoten derselben Konfiguration in Knotenpools von VMs, die AKS-Workloads ausführen. Systemknotenpools dienen dem primären Zweck, kritische Systempods wie CoreDNS zu hosten. Benutzerknotenpools dienen dem primären Zweck, Workloadpods zu hosten. Wenn Sie nur einen Knotenpool in Ihrem AKS-Cluster haben möchten, z. B. in einer Entwicklungsumgebung, können Sie Anwendungspods im Systemknotenpool planen.

Diagramm eines einzelnen Kubernetes-Knotens.

Sie können auch mehrere Benutzerknotenpools erstellen, um unterschiedliche Workloads auf verschiedenen Knoten zu trennen, um das „Noisy Neighbor“-Problem (Beeinträchtigung durch andere Mandanten) zu vermeiden oder um Anwendungen mit unterschiedlichen Compute- oder Speicheranforderungen zu unterstützen.

Jeder Agent-Knoten eines System- oder Benutzerknotenpools ist eine VM, die als Teil von Azure Virtual Machine Scale Sets bereitgestellt und vom AKS-Cluster verwaltet wird. Weitere Informationen finden Sie unter Knoten und Knotenpools.

Sie können die Anfangszahl und -größe für Workerknoten definieren, wenn Sie einen AKS-Cluster erstellen, oder wenn Sie neue Knoten und Knotenpools zu einem vorhandenen AKS-Cluster hinzufügen. Wenn Sie keine VM-Größe angeben, ist die Standardgröße Standard_D2s_v3 für Windows-Knotenpools und Standard_DS2_v2 für Linux-Knotenpools.

Wichtig

Um für Aufrufe innerhalb des Knotens und für die Kommunikation mit Plattformdiensten bessere Wartezeiten bereitzustellen, wählen Sie eine VM-Serie aus, die beschleunigten Netzwerkbetrieb unterstützt.

Erstellung eines neuen Pools

Sie können einem neuen oder vorhandenen AKS-Cluster einen Knotenpool hinzufügen, indem Sie das Azure-Portal, Azure CLI, die AKS-REST-API oder IaC-Tools (Infrastructure-as-Code) wie Bicep, Azure Resource Manager-Vorlagen oder Terraform verwenden. Weitere Informationen zum Hinzufügen von Knotenpools zu einem vorhandenen AKS-Cluster finden Sie unter Erstellen und Verwalten mehrerer Knotenpools für einen Cluster in Azure Kubernetes Service (AKS).

Wenn Sie einen neuen Knotenpool erstellen, wird die zugeordnete VM-Skalierungsgruppe in der Knotenressourcengruppe erstellt, eine Azure-Ressourcengruppe, die alle Infrastrukturressourcen für den AKS-Cluster enthält. Diese Ressourcen umfassen die Kubernetes-Knoten, virtuelle Netzwerkressourcen, verwaltete Identitäten und Speicher.

Standardmäßig lautet der Name der Knotenressourcengruppe z. B. MC_<resourcegroupname>_<clustername>_<location>. AKS löscht die Knotenressourcengruppe automatisch beim Löschen eines Clusters, sodass Sie diese Ressourcengruppe nur für Ressourcen verwenden sollten, die denselben Lebenszyklus wie der Cluster haben.

Hinzufügen eines Knotenpools

Im folgenden Codebeispiel wird der Azure CLI-Befehl az aks nodepool add zum Hinzufügen eines Knotenpools namens mynodepool mit drei Knoten zu einem vorhandenen AKS-Cluster verwendet, der in der Ressourcengruppe myAKSClustermyResourceGroup genannt wird.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Spot-Knotenpools

Ein Spot-Knotenpool ist ein Knotenpool, der von einer Spot-VM-Skalierungsgruppe unterstützt wird. Durch die Verwendung von Spot-VMs für Knoten mit Ihrem AKS-Cluster können Sie die ungenutzte Azure-Kapazität mit erheblichen Kosteneinsparungen nutzen. Die Menge der verfügbaren, nicht genutzten Kapazität hängt von vielen Faktoren ab, einschließlich Größe, Region und Tageszeit des Knotens.

Bei der Bereitstellung eines Spot-Knotenpools ordnet Azure die Spot-Knoten zu, wenn Kapazität verfügbar ist. Es gibt jedoch keine Vereinbarung zum Servicelevel (SLA) für die Spot-Knoten. Eine Spot-Skalierungsgruppe, die den Spot-Knotenpool unterstützt, wird in einer einzelnen Fehlerdomäne bereitgestellt und bietet keine Hochverfügbarkeit. Wenn Azure die Kapazität wieder selbst benötigt, entfernt die Azure-Infrastruktur Spot-Knoten, wobei Sie maximal 30 Sekunden vor dem Entfernen eine Benachrichtigung erhalten. Bedenken Sie, dass ein Spot-Knotenpool nicht der Standardknotenpool des Clusters sein kann. Ein Spot-Knotenpool kann nur für einen sekundären Pool verwendet werden.

Spot-Knotenpunkte eignen sich für Workloads, die mit Unterbrechungen, vorzeitigen Beendigungen oder Entfernungen umgehen können. Beispielsweise sind Batchverarbeitungsaufträge, Entwicklungs- und Testumgebungen sowie große Computeworkloads gute Kandidaten für die Planung in einem Spot-Knotenpool. Weitere Details finden Sie unter Einschränkungen der Spot-Instanz.

Der folgende Befehl az aks nodepool add fügt einem vorhandenen Cluster mit aktivierter automatischer Skalierung einen Spot-Knotenpool hinzu.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Weitere Informationen zu Spot-Knotenpools finden Sie unter Hinzufügen eines Spot-Knotenpools zu einem Azure Kubernetes Service (AKS)-Cluster.

Kurzlebige Betriebssystemdatenträger

Standardmäßig repliziert Azure den Betriebssystemdatenträger einer VM automatisch in Azure Storage, um Datenverluste zu vermeiden, wenn die VM auf einen anderen Host verschoben werden muss. Da Container jedoch nicht darauf ausgelegt sind, den lokalen Zustand beizubehalten, bietet die Aufbewahrung des Betriebssystemdatenträgers im Speicher für AKS nur eingeschränkten Nutzen. Es gibt einige Nachteile, wie langsamere Knotenbereitstellung und höhere Lese-/Schreibwartezeiten.

Im Gegensatz dazu werden kurzlebige Betriebssystemdatenträger nur auf dem Hostcomputer gespeichert, z. B. ein temporärer Datenträger, und bieten niedrigere Lese-/Schreibwartezeiten sowie schnellere Knotenskalierung und Clusterupgrades. Ein kurzlebiger Betriebssystemdatenträger ist genau wie ein temporärer Datenträger im Preis des virtuellen Computers enthalten, weshalb also keine zusätzlichen Speicherkosten entstehen.

Wichtig

Wenn Sie verwaltete Datenträger nicht explizit für das Betriebssystem anfordern, verwendet AKS standardmäßig (soweit möglich) ein kurzlebiges Betriebssystem für eine bestimmte Knotenpoolkonfiguration.

Um ein kurzlebiges Betriebssystem zu verwenden, muss der Betriebssystemdatenträger in den VM-Cache passen. In der Azure-Dokumentation für VMs wird die VM-Cachegröße in Klammern neben dem E/A-Durchsatz als Cachegröße in Gibibytes (GiB) angezeigt.

Die AKS-VM-Standardgröße Standard_DS2_v2 mit der Standardgröße von 100 GB für den Betriebssystemdatenträger unterstützt z. B. ein kurzlebiges Betriebssystem, besitzt aber nur eine Cachegröße von 86 GB. Diese Konfiguration wird standardmäßig auf „verwalteter Datenträger“ festgelegt, wenn Sie nicht explizit etwas anderes angeben. Wenn Sie für diese Größe explizit ein kurzlebiges Betriebssystem anfordern, erhalten Sie einen Validierungsfehler.

Wenn Sie dieselbe Standard_DS2_v2-VM mit einem Betriebssystemdatenträger von 60 GB anfordern, erhalten Sie standardmäßig ein kurzlebiges Betriebssystem. Die angeforderte Betriebssystemgröße von 60 GB ist kleiner als die maximal Cachegröße von 86 GB.

Standard_D8s_v3 mit einem 100-GB-Betriebssystemdatenträger unterstützt ein kurzlebiges Betriebssystem und verfügt über 200 GB Cachespeicher. Wenn ein Benutzer keinen Typ für den Betriebssystemdatenträger angibt, erhält der Knotenpool standardmäßig ein kurzlebiges Betriebssystem.

Der folgende Befehl az aks nodepool add zeigt, wie Sie einem vorhandenen Cluster mit einem kurzlebigen Betriebssystemdatenträger einen neuen Knotenpool hinzufügen. Der --node-osdisk-type-Parameter legt den Datenträgertyp des Betriebssystems auf Ephemeral fest, und der --node-osdisk-size-Parameter definiert die Größe des Betriebssystemdatenträgers.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Weitere Informationen zu kurzlebigen Betriebssystemdatenträgern finden Sie unter Kurzlebiges Betriebssystem.

Knotenpools für virtuelle Computer in Azure Kubernetes Service (AKS)

Jede verwaltete Knotengruppe in EKS wird von einer Amazon EC2 Auto Scaling Groupunterstützt, die von Amazon EKS verwaltet wird. Diese Integration ermöglicht EKS die automatische Verarbeitung der Bereitstellung und Skalierung von EC2-Instanzen innerhalb der Knotengruppe. Obwohl Autoskalierungsgruppen so konfiguriert werden können, dass mehrere EC2-Instanztypen unterstützt werden, können sie nicht angeben, wie viele Knoten für jeden Instanztyp erstellt oder skaliert werden sollen. Stattdessen verwaltet EKS die Skalierung der Knotengruppe basierend auf der vom Benutzer definierten gewünschten Konfiguration und Richtlinien. Dies stellt einen vereinfachten und automatisierten Verwaltungsprozess für die Knotengruppe sicher und bietet flexibilität bei der Auswahl der EC2-Instanztypen, die Ihren Workloadanforderungen entsprechen. AWS-Kunden können jedoch selbstverwaltete Amazon Linux-Knoten mit eksctl oder der AWS Management Console starten.

Mit Knotenpools für virtuelle Computerverwaltet Azure Kubernetes Service (AKS) die Bereitstellung und Bootstrapping jedes Agentknotens. Bei Knotenpools für vm-Skalierungssätze verwaltet AKS das Modell der Skalierungssätze für virtuelle Computer und verwendet es, um Konsistenz für alle Agentknoten im Knotenpool zu erzielen. Stattdessen können Sie Mit Knotenpools für virtuelle Computer Ihren Cluster mit virtuellen Computern koordinieren, die am besten zu Ihren einzelnen Arbeitslasten passen, und angeben, wie viele Knoten für jede größe virtueller Computer erstellt oder skaliert werden sollen.

Ein Knotenpool besteht aus einer Reihe virtueller Computer mit unterschiedlichen Größen (SKUs), die für die Unterstützung verschiedener Arbeitsauslastungstypen vorgesehen sind. Diese virtuellen Computergrößen, die als SKUs bezeichnet werden, werden in verschiedene Familien unterteilt, die für bestimmte Zwecke optimiert sind. Weitere Informationen zu VM-SKUs finden Sie in der übersicht über VM-SKUs.

Um die Skalierung mehrerer virtueller Computergrößen zu ermöglichen, verwendet der Knotenpooltyp "Virtuelle Computer" eine ScaleProfile, die konfiguriert, wie der Knotenpool skaliert wird, insbesondere die gewünschte Liste der Größe und Anzahl virtueller Computer. Ein ManualScaleProfile ist ein Skalierungsprofil, das die gewünschte Größe und Anzahl virtueller Computer angibt. In einem ManualScaleProfileist nur eine Größe eines virtuellen Computers zulässig. Sie müssen für jede Größe des virtuellen Computers im Knotenpool eine separate ManualScaleProfile erstellen.

Wenn Sie einen neuen Knotenpool für virtuelle Computer erstellen, benötigen Sie mindestens eine ManualScaleProfile im ScaleProfile. Für einen einzelnen Knotenpool für virtuelle Computer können mehrere manuelle Skalierungsprofile erstellt werden.

Zu den Vorteilen von Knotenpools für virtuelle Computer gehören:

  • Flexibilität: Knotenspezifikationen können entsprechend Ihren Workloads und Anforderungen aktualisiert werden.
  • Feinabstimmung des Steuerelements: Steuerelemente auf einzelner Knotenebene ermöglichen das Angeben und Mischen von Knoten verschiedener Spezifikationen, um die Konsistenz zu verbessern.
  • Effizienz: Sie können den Knotenbedarf für Ihren Cluster reduzieren und Ihre betrieblichen Anforderungen vereinfachen.

Virtuelle Computerknotenpools bieten eine bessere Erfahrung für dynamische Workloads und hohe Verfügbarkeitsanforderungen. Sie ermöglichen es Ihnen, mehrere virtuelle Computer derselben Familie in einem Knotenpool einzurichten, wobei Ihre Workload automatisch für die verfügbaren Ressourcen geplant ist, die Sie konfigurieren.

In der folgenden Tabelle werden Knotenpools virtueller Computer mit standardmäßigen Scale Set Knotenpools verglichen.

Knotenpooltyp Fähigkeiten
Knotenpool für virtuelle Computer Sie können Knoten in einem Knotenpool hinzufügen, entfernen oder aktualisieren. Virtuelle Computertypen können jeder virtuelle Computer desselben Familientyps sein (z. B. D-Serie, A-Serie usw.).
Vm Scale Set based node pool Sie können Knoten derselben Größe hinzufügen oder entfernen und in einem Knotenpool eingeben. Wenn Sie dem Cluster eine neue Größe eines virtuellen Computers hinzufügen, müssen Sie einen neuen Knotenpool erstellen.

Knotenpools für virtuelle Computer weisen die folgenden Einschränkungen auf:

  • der Clusterautoskaler wird nicht unterstützt.
  • InfiniBand- ist nicht verfügbar.
  • Windows-Knotenpools werden nicht unterstützt.
  • Dieses Feature ist im Azure-Portal nicht verfügbar. Verwenden Sie Azure CLI- oder REST-APIs, um CRUD-Vorgänge auszuführen oder den Pool zu verwalten.
  • Knotenpoolmomentaufnahme wird nicht unterstützt.
  • Alle in einem Knotenpool ausgewählten VM-Größen müssen aus derselben virtuellen Computerfamilie stammen. Sie können z. B. keinen virtuellen Computertyp der N-Serie mit einem virtuellen Computertyp der D-Serie im selben Knotenpool kombinieren.
  • Knotenpools für virtuelle Computer ermöglichen bis zu fünf verschiedene virtuelle Computergrößen pro Knotenpool.

Virtuelle Knoten

Sie können virtuelle Knoten verwenden, um Anwendungsworkloads in einem AKS-Cluster schnell aufzuskalieren. Virtuelle Knoten bieten Ihnen schnelle Podbereitstellung, und Sie bezahlen nur pro Sekunde für die Ausführungszeit. Sie müssen nicht warten, bis die Autoskalierung des Clusters neue Workerknoten bereitstellen muss, um weitere Podreplikate auszuführen. Virtuelle Knoten werden nur von Linux-Pods und -Knoten unterstützt. Das Add-On für virtuelle Knoten für AKS basiert auf dem Open-Source-Projekt Virtual Kubelet.

Die Funktionalität virtueller Knoten hängt von Azure Container Instances ab. Weitere Informationen zu virtuellen Knoten finden Sie unter Erstellen und Konfigurieren eines Azure Kubernetes Services-Clusters (AKS) zur Verwendung virtueller Knoten.

Taints, Bezeichnungen und Tags

Wenn Sie einen Knotenpool erstellen, können Sie Kubernetes-Taints und -Bezeichnungen sowie Azure-Tags zu diesem Knotenpool hinzufügen. Wenn Sie einen Taint, eine Bezeichnung oder ein Tag hinzufügen, erhalten alle Knoten innerhalb dieses Knotenpools diesen Taint, diese Bezeichnung oder dieses Tag.

Um einen Knotenpool mit einem Taint zu erstellen, können Sie den Befehl az aks nodepool add mit dem --node-taints-Parameter verwenden. Um die Knoten in einem Knotenpool zu bezeichnen, können Sie den --labels-Parameter verwenden und eine Liste mit Bezeichnungen angeben, wie im folgenden Code dargestellt:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Weitere Informationen finden Sie unter Angeben von Taint, Bezeichnung oder Tag für einen Knotenpool.

Reservierte Systembezeichnungen

Amazon EKS fügt automatisierte Kubernetes-Bezeichnungen zu allen Knoten in einer verwalteten Knotengruppe wie eks.amazonaws.com/capacityType hinzu, die den Kapazitätstyp angibt. AKS fügt außerdem automatisch Systembezeichnungen zu Agent-Knoten hinzu.

Die folgenden Präfixe sind für die Verwendung durch AKS reserviert und können nicht für Knoten verwendet werden:

  • kubernetes.azure.com/
  • kubernetes.io/

Weitere reservierte Präfixe finden Sie unter Bekannte Bezeichnungen, Anmerkungen und Taints in Kubernetes.

In der folgenden Tabelle sind Bezeichnungen aufgeführt, die für die Verwendung durch AKS reserviert sind und nicht für Knoten verwendet werden können. In der Tabelle gibt die Spalte Verwendung auf virtuellen Knoten an, ob die Bezeichnung auf virtuellen Knoten unterstützt wird.

In der Spalte Verwendung auf virtuellen Knoten:

  • N/V bedeutet, dass die Eigenschaft nicht für virtuelle Knoten gilt, da sie eine Änderung des Hosts erfordern würde.
  • Identisch bedeutet, dass die erwarteten Werte für einen virtuellen Knotenpool mit denen für einen Standardknotenpool identisch sind.
  • Virtuell ersetzt VM-SKU-Werte, weil virtuelle Knotenpods keine zugrunde liegende VM verfügbar machen.
  • Die Version des virtuellen Knotens bezieht sich auf die aktuelle Version des Releases des virtuellen Kubelet-ACI-Connectors.
  • Der Subnetzname des virtuellen Knotens ist das Subnetz, das Pods für virtuelle Knoten in Azure Container Instances bereitstellt.
  • Das virtuelle Netzwerk des virtuellen Knotens ist das virtuelle Netzwerk, das das Subnetz des virtuellen Knotens enthält.
Bezeichnung Wert Beispiel, Optionen Verwendung virtueller Knoten
kubernetes.azure.com/agentpool <agent pool name> nodepool1 identisch
kubernetes.io/arch amd64 runtime.GOARCH N/V
kubernetes.io/os <OS Type> Linux oder Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 identisch
topology.kubernetes.io/zone <Azure zone> 0 identisch
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 identisch
kubernetes.azure.com/mode <mode> User oder System User
kubernetes.azure.com/role agent Agent identisch
kubernetes.azure.com/scalesetpriority <scale set priority> Spot oder Regular N/V
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 identisch
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N/V
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N/V
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Version des virtuellen Knotens
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Subnetzname des virtuellen Knotens
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Virtuelles Netzwerk des virtuellen Knotens
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N/V
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N/V
kubernetes.azure.com/accelerator <accelerator> Nvidia N/V
kubernetes.azure.com/fips_enabled <fips enabled> True N/V
kubernetes.azure.com/os-sku <os/sku> Siehe Betriebssystem-SKU erstellen oder aktualisieren. Linux-SKU

Windows-Knotenpools

AKS unterstützt das Erstellen und Verwenden von Windows Server-Containerknotenpools über das Azure CNI (Container Network Interface)-Netzwerk-Plug-In. Informationen zur Planung der erforderlichen Subnetzbereiche sowie Überlegungen zum Netzwerk finden Sie unter Konfigurieren von Azure CNI-Netzwerken.

Der folgende Befehl az aks nodepool add fügt einen Knotenpool hinzu, der Windows Server-Container ausführt.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Der vorherige Befehl verwendet das Standardsubnetz im virtuellen Netzwerk des AKS-Clusters. Weitere Informationen zum Erstellen eines AKS-Clusters mit einem Windows-Knotenpool finden Sie unter Erstellen eines Windows Server-Containers in AKS.

Überlegungen zu Knotenpools

Die folgenden Überlegungen und Einschränkungen gelten beim Erstellen und Verwalten eines und mehrerer Knotenpools:

  • Für AKS-Knotenpools gelten Kontingente, VM-Größenbeschränkungen und Regionsverfügbarkeit.
  • Systempools müssen mindestens einen Knoten enthalten. Sie können einen Systemknotenpool löschen, wenn im AKS-Cluster ein anderer Systemknotenpool als Ersatz für diesen vorhanden ist. Benutzerknotenpools können keinen oder mehr Knoten enthalten.
  • Sie können die VM-Größe eines Knotenpools nach der Erstellung nicht mehr ändern.
  • Für mehrere Knotenpools muss der AKS-Cluster Load Balancer der Standard-SKU verwenden. Load Balancer der Basic-SKU unterstützen keine mehreren Knotenpools.
  • Alle Clusterknotenpools müssen sich im selben virtuellen Netzwerk befinden, und alle Subnetze, die den Knotenpools zugewiesen sind, müssen sich im selben virtuellen Netzwerk befinden.
  • Wenn Sie zur Clustererstellungszeit mehrere Knotenpools erstellen, müssen die Kubernetes-Versionen für alle Knotenpools mit der Steuerungsebenenversion übereinstimmen. Sie können Versionen nach der Bereitstellung des Clusters mithilfe von Poolvorgängen pro Knoten aktualisieren.

Skalierung des Knotenpools

Wenn sich die Workload Ihrer Anwendung ändert, müssen Sie möglicherweise die Anzahl der Knoten in einem Knotenpool ändern. Sie können die Anzahl der Knoten manuell hoch- oder herunterskalieren, indem Sie den Befehl az aks nodepool scale verwenden. Das folgende Beispiel skaliert die Anzahl der Knoten in mynodepool auf 5:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Automatisches Skalieren von Knotenpools durch Verwendung der automatischen Clusterskalierung

AKS unterstützt die automatische Skalierung von Knotenpools mit der automatischen Clusterskalierung. Sie aktivieren dieses Feature für jeden Knotenpool und definieren eine Mindest- und eine Höchstzahl von Knoten.

Der folgende Befehl az aks nodepool add fügt einem vorhandenen Cluster einen neuen Knotenpool namens mynodepool hinzu. Der --enable-cluster-autoscaler-Parameter aktiviert die automatische Clusterskalierung im neuen Knotenpool, und die Parameter --min-count und --max-count geben die Mindest- und Höchstzahl der Knoten im Pool an.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Der folgende Befehl az aks nodepool update aktualisiert die Mindestzahl von Knoten für den Knotenpool mynewnodepool von 1 auf 3.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Sie können die automatische Clusterskalierung mit az aks nodepool update deaktivieren, indem Sie den Parameter --disable-cluster-autoscaler übergeben.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Um die automatische Clusterskalierung für einen vorhandenen Cluster erneut zu aktivieren, verwenden Sie az aks nodepool update, wobei Sie die Parameter --enable-cluster-autoscaler, --min-count und --max-count angeben.

Weitere Informationen zur Verwendung der automatischen Clusterskalierung für einzelne Knotenpools finden Sie unter Automatisches Skalieren eines Clusters zur Erfüllung von Anwendungsanforderungen in Azure Kubernetes Service (AKS).

Pod Sandboxing

AKS-Kunden können Kata Containers auf AKS problemlos einrichten und ausführen. Dies wird durch die Verwendung von Pod Sandboxingermöglicht, ein Feature, das eine Isolationsgrenze zwischen der Containeranwendung und dem freigegebenen Kernel und Computeressourcen des Containerhosts erstellt.

AKS enthält einen Mechanismus namens Pod Sandboxing-, der eine Isolationsgrenze zwischen der Containeranwendung und dem gemeinsam genutzten Kernel und Computeressourcen des Containerhosts bereitstellt, z. B. CPU, Arbeitsspeicher und Netzwerk. Pod Sandboxing ergänzt andere Sicherheitsmaßnahmen oder Datenschutzkontrollen, um Mandantenarbeitslasten dabei zu helfen, vertrauliche Informationen zu sichern und behördliche, branchenspezifische oder Governance-Compliance-Anforderungen zu erfüllen, z. B. PCI DSS (Payment Card Industry Data Security Standard), International Organization for Standardization (ISO) 27001 und Health Insurance Portability and Accountability Act (HIPAA).

Durch die Bereitstellung von Anwendungen in separaten Clustern oder Knotenpools können Sie die Mandantenarbeitslasten verschiedener Teams oder Kunden stark isolieren. Die Verwendung mehrerer Cluster und Knotenpools eignet sich möglicherweise für die Isolationsanforderungen vieler Organisationen und SaaS-Lösungen, aber es gibt Szenarien, in denen ein einzelner Cluster mit gemeinsam genutzten VM-Knotenpools effizienter ist. Sie können z. B. einen einzelnen Cluster verwenden, wenn Sie nicht vertrauenswürdige und vertrauenswürdige Pods auf demselben Knoten ausführen oder DaemonSets und privilegierte Container auf demselben Knoten für eine schnellere lokale Kommunikation und funktionale Gruppierung verlagern. Pod Sandboxing- können Sie Mandantenanwendungen auf denselben Clusterknoten stark isolieren, ohne diese Workloads in separaten Cluster- oder Knotenpools ausführen zu müssen. Andere Methoden erfordern, dass Sie Ihren Code neu kompilieren oder andere Kompatibilitätsprobleme verursachen, aber Pod Sandboxing in AKS kann jeden Container ohne Änderungen innerhalb einer erweiterten Sicherheits-VM-Grenze ausführen.

Pod Sandboxing auf AKS basiert auf Kata-Containern, die auf dem Azure Linux-Containerhost für AKS Stack ausgeführt werden, um hardwaregezwingte Isolation bereitzustellen. Kata-Container auf AKS basieren auf einem sicherheitsfesten Azure-Hypervisor. Sie erreicht die Isolation pro Pod über eine geschachtelte, einfache Kata-VM, die Ressourcen von einem übergeordneten VM-Knoten nutzt. In diesem Modell erhält jeder Kata-Pod seinen eigenen Kernel in einer geschachtelten Kata-Gast-VM. Verwenden Sie dieses Modell, um viele Kata-Container in einer einzelnen Gast-VM zu platzieren und weiterhin Container in der übergeordneten VM auszuführen. Dieses Modell bietet eine starke Isolationsgrenze in einem freigegebenen AKS-Cluster.

Weitere Informationen finden Sie unter:

Dedizierter Azure-Host

Azure Dedicated Host ist ein Dienst, der physische Server bereitstellt, die einem einzelnen Azure-Abonnement zugeordnet sind und Hardwareisolation auf physischer Serverebene bereitstellen. Sie können diese dedizierten Hosts innerhalb einer Region, Verfügbarkeitszone und Fehlerdomäne bereitstellen und virtuelle Computer direkt in die bereitgestellten Hosts platzieren.

Es gibt mehrere Vorteile für die Verwendung von Azure Dedicated Host mit AKS, darunter:

  • Die Hardwareisolation stellt sicher, dass keine anderen virtuellen Computer auf den dedizierten Hosts platziert werden, die eine zusätzliche Isolationsebene für Mandantenworkloads bieten. Dedizierte Hosts werden in den gleichen Rechenzentren bereitgestellt und nutzen die gleiche Netzwerk- und zugrunde liegende Speicherinfrastruktur wie andere nicht isolierte Hosts.
  • Azure Dedicated Host bietet Kontrolle über Wartungsereignisse, die die Azure-Plattform initiiert. Sie können ein Wartungsfenster auswählen, um die Auswirkungen auf Dienste zu verringern und die Verfügbarkeit und den Datenschutz von Mandantenarbeitslasten sicherzustellen.

Azure Dedicated Host kann SaaS-Anbieter dabei unterstützen, sicherzustellen, dass Mandantenanwendungen behördliche, branchenspezifische und Governance-Complianceanforderungen für die Sicherung vertraulicher Informationen erfüllen. Weitere Informationen finden Sie unter Hinzufügen von Azure Dedicated Host zu einem AKS-Cluster.

Karpenter

Karpenter ist ein Open-Source-Node-Lifecycle-Management-Projekt, das für Kubernetes entwickelt wurde. Das Hinzufügen von Karpenter zu einem Kubernetes-Cluster kann die Effizienz und kosten der Ausführung von Workloads auf diesem Cluster verbessern. Karpenter überwacht pods, die der Kubernetes-Scheduler als nicht geplant markiert. Sie stellt außerdem Knoten, die die Podanforderungen erfüllen können, dynamisch fest und verwaltet sie.

Karpenter bietet eine differenzierte Kontrolle über die Bereitstellung von Knoten und die Workloadplatzierung in einem verwalteten Cluster. Dieses Steuerelement verbessert die Mehrinstanzenfähigkeit, indem die Ressourcenzuordnung optimiert wird, die Isolation zwischen den Anwendungen der einzelnen Mandanten gewährleistet und die Betriebskosten reduziert werden. Wenn Sie eine Mehrinstanzenlösung auf AKS erstellen, bietet Karpenter nützliche Funktionen, mit denen Sie verschiedene Anwendungsanforderungen verwalten können, um verschiedene Mandanten zu unterstützen. Beispielsweise benötigen Sie möglicherweise einige Mandantenanwendungen, um auf GPU-optimierten Knotenpools und anderen für die Ausführung auf speicheroptimierten Knotenpools auszuführen. Wenn Ihre Anwendung eine geringe Latenz für den Speicher erfordert, können Sie mit Karpenter angeben, dass ein Pod einen Knoten erfordert, der in einer bestimmten Verfügbarkeitszone ausgeführt wird, damit Sie Ihren Speicher und die Anwendungsebene verlagern können.

AKS ermöglicht die automatische Bereitstellung von Knoten auf AKS-Clustern über Karpenter. Die meisten Benutzer sollten den Knoten-Autoprovisionsmodus verwenden, um Karpenter als verwaltetes Addon zu aktivieren. Weitere Informationen finden Sie unter node autoprovisioning. Wenn Sie erweiterte Anpassungen benötigen, können Sie sich für den Self-Host Karpenter entscheiden. Weitere Informationen finden Sie im AKS Karpenter-Anbieter.

Vertrauliche virtuelle Computer

Vertrauliches Computing ist eine Sicherheitsmaßnahme zum Schutz von Daten während der Verwendung durch Software oder hardwaregestützte Isolation und Verschlüsselung. Diese Technologie fügt herkömmlichen Ansätzen eine zusätzliche Sicherheitsebene hinzu, um Ruhedaten zu schützen und während der Übertragung zu schützen.

AWS-Plattform unterstützt vertrauliches Computing über Nitro Enklaven, die auf EC2-Instanzen sowie auf Amazon Elastic Kubernetes Service (EKS)verfügbar sind. Weitere Informationen finden Sie in diesem Artikel in der Amazon-Dokumentation. Darüber hinaus unterstützen Amazon EC2-Instanzen AMD SEV-SNP-. Dieses GitHub Repository bietet Artefakte zum Erstellen und Bereitstellen eines Amazon Machine Image (AMI)- für EKS mit AMD SEV-SNP--Unterstützung.

Andererseits bietet Azure Kunden vertrauliche VMs, um strenge Isolations-, Datenschutz- und Sicherheitsanforderungen innerhalb eines AKS-Clusters zu erfüllen. Diese vertraulichen VMs verwenden eine hardwarebasierte vertrauenswürdige Ausführungsumgebung. Insbesondere verwenden vertrauliche Azure-VMs AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) Technologie, die Hypervisor und anderen Hostverwaltungscodezugriff auf VM-Speicher und -Zustand verweigert. Dadurch wird eine zusätzliche Schutzebene und ein Schutz vor Operatorzugriff hinzugefügt. Weitere Details finden Sie in der Dokumentation zu Verwendung vertraulicher VMs in einem AKS-Cluster- und der Übersicht über vertrauliche VMs in Azure.

Federal Information Process Standards (FIPS)

FIPS 140-3 ist ein US-Regierungsstandards, der mindestsicherheitsanforderungen für kryptografische Module in Informationstechnologieprodukten und -systemen definiert. Indem Sie FIPS-Compliance für AKS-Knotenpoolsaktivieren, können Sie die Isolation, den Datenschutz und die Sicherheit Ihrer Mandantenworkloads verbessern. FIPS- Compliance stellt sicher, dass validierte kryptografische Module für Verschlüsselung, Hashing und andere sicherheitsbezogene Vorgänge verwendet werden. Mit FIPS-fähigen AKS-Knotenpools können Sie gesetzliche und branchenspezifische Complianceanforderungen erfüllen, indem Sie robuste kryptografische Algorithmen und Mechanismen verwenden. Azure bietet Dokumentation zum Aktivieren von FIPS für AKS-Knotenpools, mit der Sie den Sicherheitsstatus Ihrer mehrinstanzenfähigen AKS-Umgebungen stärken können. Weitere Informationen finden Sie unter Aktivieren von FIPS für AKS-Knotenpools.

Hostbasierte Verschlüsselung

In EKS hat Ihre Architektur möglicherweise die folgenden Features verwendet, um die Datensicherheit zu verbessern:

hostbasierte Verschlüsselung auf AKS stärkt die Mandantenauslastungsisolation, den Datenschutz und die Sicherheit weiter. Wenn Sie die hostbasierte Verschlüsselung aktivieren, verschlüsselt AKS ruhende Daten auf den zugrunde liegenden Hostcomputern, wodurch sichergestellt wird, dass vertrauliche Mandanteninformationen vor unbefugtem Zugriff geschützt sind. Temporäre Datenträger und kurzlebige Betriebssystemdatenträger werden mit plattformverwalteten Schlüsseln verschlüsselt, wenn Sie die End-to-End-Verschlüsselung aktivieren.

In AKS verwenden Betriebssystem- und Datendatenträger standardmäßig serverseitige Verschlüsselung mit plattformverwalteten Schlüsseln. Die Caches für diese Datenträger werden mit plattformverwalteten Schlüsseln verschlüsselt. Sie können ihren eigenen Schlüsselverschlüsselungsschlüssel angeben,, um den Datenschutzschlüssel mithilfe der Umschlagverschlüsselung zu verschlüsseln, auch als Wrappingbezeichnet. Der Cache für das Betriebssystem und Die Datenträger werden auch über die von Ihnen angegebenen BYOK- verschlüsselt.

Die hostbasierte Verschlüsselung fügt eine Sicherheitsebene für Mehrinstanzenumgebungen hinzu. Die Daten jedes Mandanten im Betriebssystem und datenträgercaches werden in Ruhe mit vom Kunden verwalteten oder plattformverwalteten Schlüsseln verschlüsselt, je nach ausgewähltem Datenträgerverschlüsselungstyp. Weitere Informationen finden Sie unter:

Updates und Upgrades

Azure aktualisiert seine VM-Hostingplattform regelmäßig, um Zuverlässigkeit, Leistung und Sicherheit zu verbessern. Diese Updates reichen von Patches für Softwarekomponenten in der Hostumgebung über Upgrades von Netzwerkkomponenten bis hin zur Außerbetriebnahme von Hardware. Weitere Informationen dazu, wie Azure VMs aktualisiert, finden Sie unter Wartung virtueller Computer in Azure.

Updates der VM-Hostinginfrastruktur wirken sich in der Regel nicht auf gehostete VMs aus, z. B. Agent-Knoten vorhandener AKS-Cluster. Bei Updates, die sich auf gehostete VMs auswirken, minimiert Azure die Fälle, in denen Neustarts erforderlich sind, indem der virtuelle Computer während des Updates des Hosts angehalten oder die VM live zu einem bereits aktualisierten Host migriert wird.

Wenn ein Update einen Neustart erfordert, gibt Azure eine Benachrichtigung mit einem Zeitfenster aus, damit Sie das Update starten können, wenn es für Sie passt. Das Zeitfenster für die automatische Wartung von Hostcomputern beträgt in der Regel 35 Tage, sofern die Wartung nicht dringend ist.

Sie können geplante Wartung verwenden, um VMs zu aktualisieren, und Benachrichtigungen über geplante Wartungen mit Azure CLI, PowerShell oder über das Azure-Portal verwalten. Die geplante Wartung erkennt, ob Sie automatische Upgrades für Cluster verwenden, und plant Upgrades während Ihres Wartungsfensters automatisch. Weitere Informationen zur geplanten Wartung finden Sie unter dem Befehl az aks maintenanceconfiguration und unter Verwenden der geplanten Wartung, um Wartungsfenster für AKS-Cluster (Azure Kubernetes Service) zu planen.

Kubernetes-Upgrades

Teil des AKS-Clusterlebenszyklus sind regelmäßige Upgrades auf die aktuelle Kubernetes-Version. Es ist wichtig, Upgrades anzuwenden, um die neuesten Sicherheitsreleases und -features zu erhalten. Um die Kubernetes-Version vorhandener Knotenpool-VMs upzugraden, müssen Sie Knoten absperren und ausgleichen und sie durch neue Knoten ersetzen, die auf einem aktualisierten Kubernetes-Datenträgerimage basieren.

Standardmäßig konfiguriert AKS Upgrades für einen Anstieg mit einem zusätzlichen Knoten. Ein Standardwert von 1 für die max-surge-Einstellungen minimiert Workloadunterbrechungen, indem ein zusätzlicher Knoten erstellt wird, um Knoten mit älteren Versionen vor dem Absperren oder Ausgleichen vorhandener Anwendungen zu ersetzen. Sie können den max-surge-Wert pro Knotenpool anpassen, um einen Kompromiss zwischen der Geschwindigkeit des Upgrades und den Unterbrechungen durch das Upgrade zu ermöglichen. Wenn Sie den max-surge-Wert erhöhen, wird der Upgradevorgang schneller abgeschlossen, doch ein hoher max-surge-Wert kann zu Unterbrechungen während des Upgradevorgangs führen.

Beispielsweise liefert ein max-surge-Wert von 100 % den schnellstmöglichen Upgradevorgang, indem die Knotenanzahl verdoppelt wird, führt aber auch dazu, dass alle Knoten im Knotenpool gleichzeitig ausgeglichen werden. Sie können diesen hohen Wert für Tests verwenden, aber für Knotenpools in der Produktion ist eine Einstellung von 33 % für max-surge besser geeignet.

AKS akzeptiert sowohl ganzzahlige Werte als Prozentsätze für max-surge. Eine ganze Zahl wie 5 gibt für den Anstieg fünf zusätzliche Knoten an. Prozentwerte für max-surge können von mindestens 1% bis höchstens 100% gehen, wobei auf die nächste Knotenanzahl aufgerundet wird. Der Wert 50% gibt einen Anstiegswert von der Hälfte der aktuellen Knoten im Pool an.

Während eines Upgrades kann der max-surge-Wert mindestens 1 betragen und höchstens der Anzahl der Knoten im Knotenpool entsprechen. Sie können größere Werte festlegen, aber die maximale Anzahl von Knoten, die für max-surge verwendet wird, wird nicht größer als die Anzahl der Knoten im Pool sein.

Wichtig

Für Upgradevorgänge benötigen Knotenanstiege ein ausreichendes Abonnementkontingent für die angeforderte max-surge-Anzahl. Beispielsweise umfasst ein Cluster mit 5 Knotenpools, von denen jeder über 4 Knoten verfügt, insgesamt 20 Knoten. Wenn für jeden Knotenpool ein max-surge-Wert von 50 % festgelegt ist, benötigen Sie zusätzliche Compute- und IP-Adressen-Kontingente von 10 Knoten (2 Knoten * 5 Pools), um das Upgrade abzuschließen.

Wenn Sie Azure Container Networking Interface (CNI) verwenden, müssen Sie außerdem sicherstellen, dass Sie über genügend IP-Adressen im Subnetz verfügen, um die CNI-Anforderungen für AKS zu erfüllen.

Upgrade von Knotenpools

Um verfügbare Upgrades anzuzeigen, verwenden Sie az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Um den Status von Knotenpools anzuzeigen, verwenden Sie az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Der folgende Befehl verwendet az aks nodepool upgrade, um einen einzelnen Knotenpool upzugraden.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Weitere Informationen zum Upgrade der Kubernetes-Version für eine Clustersteuerungsebene und Knotenpools finden Sie unter:

Überlegungen zur Aktualisierung

Beachten Sie diese bewährten Methoden und Überlegungen zum Upgrade der Kubernetes-Version in einem AKS-Cluster.

  • Es ist optimal, alle Knotenpools in einem AKS-Cluster auf dieselbe Kubernetes-Version zu aktualisieren. Das Standardverhalten von az aks upgrade ist, alle Knotenpools und die Steuerungsebene upzugraden.

  • Führen Sie Upgrades manuell durch, oder legen Sie einen „Kanal für automatische Upgrades“ für Ihren Cluster fest. Wenn Sie geplante Wartung verwenden, um VMs zu patchen, starten auch automatische Upgrades während des angegebenen Wartungsfensters. Weitere Informationen finden Sie unter Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS).

  • Der Befehl az aks upgrade mit dem --control-plane-only-Flag upgradet nur die Clustersteuerungsebene und ändert keinen der zugeordneten Knotenpools im Cluster. Für ein Upgrade einzelner Knotenpools geben Sie den Zielknotenpool und die Kubernetes-Version in dem Befehl az aks nodepool upgrade an.

  • Durch ein AKS-Clusterupgrade werden Ihre Knoten als nicht planbar markiert und entleert (cordon/drain). Wenn Sie nur über ein niedriges Computekontingent verfügen, kann das Upgrade fehlschlagen. Weitere Informationen zum Erhöhen Ihres Kontingents finden Sie unter Erhöhen regionaler vCPU-Kontingente.

  • Konfigurieren Sie den Parameter max-surge basierend auf Ihren Anforderungen unter Verwendung eines ganzzahligen Werts oder eines Prozentsatzes. Verwenden Sie für Produktionsknotenpools eine max-surge-Einstellung von 33 %. Weitere Informationen finden Sie unter Anpassen des Knotenanstiegsupgrades.

  • Stellen Sie beim Upgrade eines AKS-Clusters, der CNI-Netzwerke verwendet, sicher, dass das Subnetz über genügend private IP-Adressen für die zusätzlichen Knoten verfügt, die durch die max-surge-Einstellungen erstellt werden. Weitere Informationen finden Sie unter Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS).

  • Wenn sich Ihre Clusterknotenpools über mehrere Verfügbarkeitszonen innerhalb einer Region erstrecken, kann der Upgradevorgang vorübergehend zu einer unausgeglichenen Zonenkonfiguration führen. Weitere Informationen finden Sie unter Besondere Überlegungen für Knotenpools, die sich über mehrere Verfügbarkeitszonen erstrecken.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte