Kubernetes-Knoten- und -Knotenpoolverwaltung

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.

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.

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.

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.

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.

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 myResourceGroupmyAKSCluster 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.

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.

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.

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).

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.

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:

• Upgrade für AKS-Knotenimages (Azure Kubernetes Service)
• Aktualisieren einer Clustersteuerungsebene mit mehreren Knotenpools

Ü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.

Virtuelle Knotennetzwerke

Wenn Sie einen neuen Cluster erstellen oder einem vorhandenen Cluster einen neuen Knotenpool hinzufügen, geben Sie die Ressourcen-ID eines Subnetzes innerhalb des virtuellen Clusternetzwerks an, in dem Sie die Agent-Knoten bereitstellen. Eine Workload erfordert für die logische Isolation möglicherweise das Aufteilen der Knoten eines Clusters in getrennte Knotenpools. Diese Isolation können Sie mit separaten Subnetzen erreichen, von denen jedes dediziert einem gesonderten Knotenpool zugeordnet ist. Die Knotenpool-VMs erhalten jeweils eine private IP-Adresse aus ihrem zugeordneten Subnetz.

AKS unterstützt zwei Netzwerk-Plug-Ins:

• Kubenet ist ein grundlegendes, einfaches Netzwerk-Plug-In für Linux. Mit kubenet erhalten Knoten eine private IP-Adresse aus dem Azure Virtual Network-Subnetz. Pods erhalten eine IP-Adresse aus einem logisch anderen Adressraum. Die Netzwerkadressenübersetzung (NAT) ermöglicht es den Pods, Ressourcen im virtuellen Azure-Netzwerk zu erreichen, indem die IP-Adresse des Quelldatenverkehrs in die primäre IP-Adresse des Knotens übersetzt wird. Dieser Ansatz verringert die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkadressraum für Pods reservieren müssen.

• Azure Container Networking Interface (CNI) vergibt an jeden Pod eine IP-Adresse für den direkten Aufruf und Zugriff. Diese IP-Adressen müssen in Ihrem Netzwerkadressraum eindeutig sein. Jeder Knoten verfügt über einen Konfigurationsparameter für die maximale Anzahl von Pods, die er unterstützt. Die entsprechende Anzahl von IP-Adressen pro Knoten wird dann für diesen Knoten reserviert. Dieser Ansatz erfordert Vorausplanung und kann häufig zu einer Erschöpfung der IP-Adressen oder der Notwendigkeit zur Neuerstellung von Clustern in einem größeren Subnetz führen, wenn die Anforderungen Ihrer Anwendung wachsen.

  Wenn Sie einen neuen Cluster erstellen oder einen neuen Knotenpool zu einem Cluster hinzufügen, der Azure CNI verwendet, können Sie die Ressourcen-ID zweier separater Subnetze angeben, eine für die Knoten und eine für die Pods. Weitere Informationen finden Sie unter Dynamische IP-Adressenzuordnung und erweiterte Subnetzunterstützung.

Dynamische IP-Zuordnung

Pods, die Azure CNI verwenden, rufen private IP-Adressen aus einem Subnetz des Hostingknotenpools ab. Die dynamische IP-Zuordnung von Azure CNI kann Pods private IP-Adressen aus einem Subnetz zuordnen, das vom Hostingsubnetz des Knotenpools getrennt ist. Dieses Feature bietet folgende Vorteile:

• Das Podsubnetz ordnet Pods IP-Adressen dynamisch zu. Die dynamische Zuordnung bietet eine bessere Auslastung der IP-Adressen im Vergleich zur herkömmlichen CNI-Lösung, bei der die IP-Adressen für jeden Knoten statisch zugeordnet werden.

• Sie können Knoten- und Podsubnetze unabhängig voneinander skalieren und freigeben. Sie können ein einzelnes Podsubnetz über mehrere Knotenpools oder Cluster hinweg freigeben, die im selben virtuellen Netzwerk bereitgestellt sind. Sie können auch ein separates Podsubnetz für einen Knotenpool konfigurieren.

• Da Pods über private Netzwerk-IP-Adressen verfügen, besitzen sie eine direkte Verbindung mit anderen Clusterpods und -ressourcen im virtuellen Netzwerk. Diese Fähigkeit unterstützt eine bessere Leistung für sehr große Cluster.

• Wenn Pods ein separates Subnetz besitzen, können Sie VNET-Richtlinien für Pods konfigurieren, die von den Knotenrichtlinien abweichen. Getrennte Richtlinien ermöglichen viele nützliche Szenarien wie die Beschränkung der Internetkonnektivität auf Pods statt auf Pods und Knoten, das Korrigieren der Quell-IP-Adresse für einen Pod in einem Knotenpool mithilfe von NAT Gateway und den Einsatz von Netzwerksicherheitsgruppen (NSGs), um Datenverkehr zwischen Knotenpools zu filtern.

• Sowohl Netzwerkrichtlinien als auch Calico Kubernetes-Netzwerkrichtlinien arbeiten mit dynamischer Zuordnung von IP-Adressen.

Beitragende

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

Hauptautoren:

• Paolo Salvatori | Principal System Engineer

Andere Mitwirkende:

• Laura Nicolas | Senior Software Engineer
• Chad Kittel | Principal Software Engineer
• Ed Price | Senior Content Program Manager
• Theano Petersen | Technical Writer

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

Nächste Schritte

• AKS für Amazon EKS-Experten
• Kubernetes-Identitäts- und Zugriffsverwaltung
• Kubernetes-Überwachung und -Protokollierung
• Sicherer Netzwerkzugriff auf Kubernetes
• Speicheroptionen für einen Kubernetes-Cluster
• Kostenmanagement für Kubernetes
• Clustergovernance
• Der Weg zur AKS-Lösung (Azure Kubernetes Service)
• Azure Kubernetes Services (AKS): Leitfaden für Day-2-Vorgänge
• Auswählen einer Computeoption für Kubernetes am Edge
• GitOps für Azure Kubernetes Service

Zugehörige Ressourcen

• Best Practices für AKS-Cluster
• Erstellen eines privaten AKS-Clusters mit einer öffentlichen DNS-Zone
• Erstellen eines privaten Azure Kubernetes Service-Clusters mithilfe von Terraform und Azure DevOps
• Erstellen eines öffentlichen oder privaten Azure Kubernetes Service-Clusters mit Azure NAT Gateway und Azure Application Gateway
• Verwenden privater Endpunkte mit einem privaten AKS-Cluster
• Erstellen eines Azure Kubernetes Service-Clusters mit dem Application Gateway-Eingangsdatencontroller
• Einführung in Kubernetes
• Einführung in Kubernetes unter Azure
• Implementieren von Azure Kubernetes Service (AKS)
• Entwickeln und Bereitstellen von Anwendungen auf Kubernetes
• Optimieren von Computekosten in Azure Kubernetes Service (AKS)