Verwalten von Kubernetes-Knoten und Knotenpools

Kubernetes-Architektur besteht aus zwei Ebenen: der Steuerebene und mindestens einem Knoten in einem Knotenpool. In diesem Artikel wird beschrieben und verglichen, wie Amazon Elastic Kubernetes Service (EKS) und Azure Kubernetes Service (AKS) Agentknoten und 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 und entleeren Knoten automatisch, um sicherzustellen, dass Anwendungen verfügbar bleiben.

Jeder verwaltete Knoten wird als Teil einer Amazon EC2-Autoskalierungsgruppe bereitgestellt, die Amazon EKS betreibt und steuert. Die Kubernetes-Clusterautoskalierung passt die Anzahl der Workerknoten in einem Cluster automatisch an, wenn Pods ausfallen oder auf anderen Knoten neu geplant werden. Sie können jede Knotengruppe so konfigurieren, dass sie über mehrere Verfügbarkeitszonen innerhalb einer Region hinweg ausgeführt wird.

Weitere Informationen 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 finden Sie unter Vereinfachen der Berechnungsverwaltung.

Karpenter

Karpenter ist ein Open-Source-Projekt, das die Verwaltung des Knotenlebenszyklus in Kubernetes-Clustern verbessert. Automatisiert die Bereitstellung und das Aufheben der Bereitstellung von Knoten basierend auf den spezifischen Planungsanforderungen der Pods, wodurch die Skalierung und Kostenoptimierung verbessert wird. Verwenden Sie Karpenter für die folgenden Hauptfunktionen:

• Überwachen Sie Pods, die der Kubernetes-Scheduler aufgrund von Ressourceneinschränkungen nicht planen kann.

• Bewerten Sie die Planungsanforderungen der nicht planbaren Pods, wie Ressourcenanforderungen, Knotenselektoren, Affinitäten und Toleranzen.

• Konfigurieren Sie neue Knoten, die den Anforderungen der nicht planbaren Pods entsprechen.

• Entfernen Sie Knoten, wenn Sie sie nicht mehr benötigen.

Sie können Karpenter verwenden, um Knotenpools zu definieren, für die Einschränkungen für die Knotenbereitstellung, wie z. B. Taints, Bezeichnungen, Anforderungen (Instanztypen und Zonen), sowie Grenzwerte für alle bereitgestellten Ressourcen gelten. Wenn Sie Workloads bereitstellen, geben Sie verschiedene Planungseinschränkungen in den Pod-Spezifikationen an. Sie können z. B. Ressourcenanforderungen oder Grenzwerte, Knotenselektoren, Knoten- oder Podaffinitäten, Tolerationen und Topologie-Spreadeinschränkungen angeben. Anschließend konfiguriert Karpenter basierend auf diesen Spezifikationen Knoten mit der rechten Größe.

Vor der Einführung von Karpenter vertrauten Amazon EKS-Benutzer hauptsächlich auf Auto-Skalierungsgruppen von Amazon EC2 und der Kubernetes-Cluster-Autoscaler , um die Computekapazität ihrer Cluster dynamisch anzupassen. Sie müssen nicht Dutzende von Knotengruppen erstellen, um die Flexibilität und Vielfalt zu erreichen, die Karpenter bereitstellt. Im Gegensatz zum Kubernetes-Cluster autoscaler ist Karpenter weniger von Kubernetes-Versionen abhängig und erfordert keine Übergänge zwischen AWS- und Kubernetes-APIs.

Karpenter konsolidiert Instanz-Orchestrierungsaufgaben innerhalb eines einzelnen Systems, was einfacher, stabiler und clusterfähiger ist. Karpenter hilft bei der Bewältigung von Herausforderungen der Cluster-Autoskalierung, indem es vereinfachte Möglichkeiten bietet:

• Konfigurieren Sie Knoten basierend auf Workloadanforderungen.

• Erstellen Sie verschiedene Knotenkonfigurationen nach Instanztyp mithilfe flexibler Knotenpooloptionen. Anstatt mehrere bestimmte benutzerdefinierte Knotengruppen zu verwalten, verwenden Sie Karpenter, um verschiedene Arbeitsauslastungskapazitäten mithilfe eines einzelnen, flexiblen Knotenpools zu verwalten.

• Verbessern Sie die Podplanung im großen Maßstab, indem Sie schnell Knoten starten und Pods planen.

Im Vergleich zu Automatischen Skalierungsgruppen und verwalteten Knotengruppen integriert Karpenter die Skalierungsverwaltung enger mit Kubernetes-nativen APIs. Auto-Skalierungsgruppen und verwaltete Knotengruppen sind AWS-native Abstraktionen, die die Skalierung basierend auf AWS-Ebenenmetriken auslösen, z. B. EC2 CPU-Auslastung. Obwohl die Cluster-Autoskaler Kubernetes-Abstraktionen mit AWS-Abstraktionen verbindet, opfert sie einige Flexibilität, z. B. die Planung für eine bestimmte Verfügbarkeitszone.

Karpenter vereinfacht die Knotenverwaltung, indem AWS-spezifische Komponenten eliminiert werden, die eine größere Flexibilität direkt in Kubernetes bieten. Verwenden Sie Karpenter für Cluster, die Workloads ausführen, die auf Zeiträume mit hoher Nachfrage bzw. Lastspitzen stoßen, oder für die unterschiedliche Berechnungsanforderungen erfüllt werden müssen. Verwenden Sie verwaltete Knotengruppen und Automatische Skalierungsgruppen für Cluster, die statischere und konsistentere Workloads ausführen. Je nach Ihren Anforderungen können Sie eine Kombination aus dynamisch und statisch verwalteten Knoten verwenden.

Kata-Container

Kata Containers ist ein Open-Source-Projekt, das eine hochsichere Containerlaufzeit bereitstellt. Sie kombiniert die einfache Art von Containern mit den Sicherheitsvorteilen virtueller Computer (VMs). Kata-Container verbessern die 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 Containers führt Container in einer open Container Initiative (OCI)-kompatiblen VM aus, die eine strikte Isolation zwischen Containern auf demselben Hostcomputer bietet. Kata Containers bietet die folgenden Features:

• Verbesserte Workloadisolation: Jeder Container wird in einer eigenen einfachen VM ausgeführt, um die Isolation auf Hardwareebene sicherzustellen.

• 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 integriert, z. B. das OCI-Containerformat und kubernetes Container Runtime Interface.

• Unterstützung für mehrere Architekturen und Hypervisoren: Kata Containers unterstützt AMD64- und ARM-Architekturen, und Sie können sie mit Hypervisoren wie Cloud Hypervisor und Firecracker verwenden.

• Einfache Bereitstellung und Verwaltung: Kata Containers vereinfacht die Workload-Orchestrierung, da sie das Kubernetes-Orchestrierungssystem verwendet.

Um Kata-Container auf AWS einzurichten und auszuführen, konfigurieren Sie einen Amazon EKS-Cluster für die Verwendung von Firecracker. Firecracker ist eine Open-Source-Virtualisierungstechnologie von Amazon, die Ihnen hilft, sichere, multitenant containerbasierte und funktionsbasierte Dienste zu erstellen und zu verwalten. Verwenden Sie Firecracker, um Workloads in einfachen VMs bereitzustellen, die als MicroVMs bezeichnet werden, die eine verbesserte Sicherheits- und Workloadisolation im Vergleich zu herkömmlichen VMs bieten. MicroVMs verbessern auch die Geschwindigkeit und Ressourceneffizienz von Containern. Befolgen Sie die Schritte, um Kata Containers auf AWS EKS auszuführen.

Dedizierte Hosts

Wenn Sie Amazon EKS zum Bereitstellen und Ausführen von Containern verwenden, können Sie die Container auf dedizierten Amazon EC2-Hosts ausführen. Dieses Feature ist jedoch nur für selbstverwaltete Knotengruppen verfügbar. Daher müssen Sie manuell eine Startvorlage und Automatische Skalierungsgruppen erstellen. Registrieren Sie dann die dedizierten Hosts, die Startvorlage und die gruppen für die automatische Skalierung mit dem EKS-Cluster. Verwenden Sie zum Erstellen dieser Ressourcen dieselbe Methode wie die allgemeine EC2-Automatische Skalierung.

Weitere Informationen zur Verwendung von AWS EKS zum Ausführen von Containern auf dedizierten EC2-Hosts finden Sie in den folgenden Ressourcen:

• Amazon EKS-Knoten
• Dedizierte Hosteinschränkungen
• Zuweisen dedizierter Hosts
• Erwerben von dedizierten Hostreservierungen
• Automatische Platzierung

AKS-Knoten und -Knotenpools

Wenn Sie einen AKS-Cluster automatisch erstellen, wird eine Steuerungsebene erstellt und konfiguriert, die Kern-Kubernetes-Dienste und die Orchestrierung von Anwendungsworkloads bereitstellt. Die Azure-Plattform bietet die AKS-Steuerebene ohne Kosten als verwaltete Azure-Ressource. Die Steuerungsebene und die zugehörigen Ressourcen sind nur in der Region vorhanden, in der Sie den Cluster erstellen.

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

Zum Ausführen von Anwendungen und unterstützenden Diensten benötigt ein AKS-Cluster mindestens einen Knoten, bei dem es sich um eine Azure-VM handelt, auf der die Kubernetes-Knotenkomponenten und die Containerlaufzeit ausgeführt werden. Jeder AKS-Cluster muss mindestens einen Systemknotenpool mit mindestens einem Knoten enthalten.

AKS kombiniert Knoten derselben Konfiguration in Knotenpools von VMs, die AKS-Workloads ausführen. Verwenden Sie Systemknotenpools, um wichtige System pods wie CoreDNS zu hosten. Verwenden Sie Benutzerknotenpools zum Hosten von Workload-Pods. 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. Dieser Ansatz trägt dazu bei, das laute Nachbarproblem zu verhindern und Anwendungen mit unterschiedlichen Compute- oder Speicheranforderungen zu unterstützen.

Jeder Agentknoten innerhalb eines System- oder Benutzerknotenpools ist im Wesentlichen eine VM. Azure Virtual Machine Scale Sets konfiguriert die virtuellen Computer, und der AKS-Cluster verwaltet sie. Weitere Informationen finden Sie unter Knotenpools.

Sie können beim Erstellen eines AKS-Clusters oder beim Hinzufügen neuer Knoten und Knotenpools zu einem vorhandenen AKS-Cluster die anfängliche Anzahl und Größe für Arbeitsknoten definieren. 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.

Erstellen eines Knotenpools

Wenn Sie einen neuen Knotenpool erstellen, wird der zugeordnete Skalierungssatz für virtuelle Computer in der Knotenressourcengruppe erstellt. Diese Azure-Ressourcengruppe enthält alle Infrastrukturressourcen für den AKS-Cluster. 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, wenn sie einen Cluster löscht. Sie sollten diese Ressourcengruppe nur für Ressourcen verwenden, die den Lebenszyklus des Clusters gemeinsam nutzen.

Weitere Informationen finden Sie unter Erstellen von Knotenpools für einen Cluster in AKS.

Hinzufügen eines Knotenpools

Um einem neuen oder vorhandenen AKS-Cluster einen Knotenpool hinzuzufügen, verwenden Sie das Azure-Portal, die Azure CLI oder die AKS-REST-API. Sie können die Infrastruktur auch als Codetools (IaC) verwenden, z. B . Bicep, Azure Resource Manager-Vorlagen oder Terraform.

Das folgende Codebeispiel verwendet den Azure CLI-Befehl az aks nodepool add, um einen Knotenpool mit dem Namen mynodepool hinzuzufügen, der drei Knoten enthält. Er fügt den Knotenpool zu einem vorhandenen AKS-Cluster namens myAKSCluster in der myResourceGroup Ressourcengruppe hinzu.

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

Spot-Knotenpools

Ein Spotknotenpool ist ein Knotenpool, den ein Spot-VM-Skalierungssatz unterstützt. Verwenden Sie Spot-VMs für Knoten in Ihrem AKS-Cluster, um nicht verwendete Azure-Kapazität zu reduzierten Kosten zu nutzen. Die Verfügbare nicht genutzte Kapazität variiert je nach Faktoren, z. B. Knotengröße, Region und Tageszeit.

Wenn Sie einen Spotknotenpool bereitstellen, weist Azure die Spotknoten zu, wenn kapazität verfügbar ist. Spotknoten haben jedoch keine Service Level Agreement (SLA). Eine Spot-Skalierungsgruppe, die den Spot-Knotenpool unterstützt, wird in einer einzelnen Fehlerdomäne bereitgestellt und gewährleistet keine Hochverfügbarkeit. Wenn Azure die Kapazität benötigt, räumt die Azure-Infrastruktur Spotknoten aus. Sie erhalten eine Benachrichtigung bis zu 30 Sekunden vor der Entfernung. Sie können keinen Spotknotenpool als Standardknotenpool des Clusters verwenden. Verwenden Sie einen Spotknotenpool nur als sekundären Pool.

Verwenden Sie Spot-Knotenpunkte für Workloads, die mit Unterbrechungen, vorzeitigen Beendigungen oder Entfernungen umgehen können. Planen Sie beispielsweise in einem Spot-Knotenpool Batchverarbeitungsaufträge, Entwicklungs- und Testumgebungen und große Computeworkloads ein. Weitere Informationen finden Sie unter Spotinstanzbeschränkungen.

Der folgende az aks nodepool add Befehl fügt einen Spotknotenpool zu einem vorhandenen Cluster hinzu, der die automatische Skalierung aktiviert hat.

  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 finden Sie unter Hinzufügen eines Spotknotenpools zu einem AKS-Cluster.

Kurzlebige Betriebssystemdatenträger

Standardmäßig repliziert Azure automatisch den VM-Betriebssystemdatenträger in Azure Storage. Dieser Ansatz verhindert Datenverlust, wenn der virtuelle Computer auf einen anderen Host verschoben werden muss. Container sind jedoch nicht für die Beibehaltung des lokalen Zustands konzipiert, sodass das Speichern des Betriebssystemdatenträgers in Azure Storage nur begrenzte Vorteile für AKS bietet. Dieser Ansatz kann zu einer langsameren Bereitstellung von Knoten und zu einer erhöhten Lese- und Schreiblatenz führen.

Im Gegensatz dazu werden kurzlebige Betriebssystemdatenträger nur auf dem Hostcomputer gespeichert, z. B. auf einem temporären Datenträger. Sie bieten auch niedrigere Lese- und Schreiblatenz und schnellere Knotenskalierung und Clusterupgrades. Wie bei einem temporären Datenträger enthält der VM-Preis einen kurzlebigen Betriebssystemdatenträger, sodass keine zusätzlichen Speicherkosten anfallen.

Um ein kurzlebiges Betriebssystem zu verwenden, muss der Betriebssystemdatenträger in den VM-Cache passen. Die Azure VM-Dokumentation zeigt die Größe des VM-Caches in Klammern neben dem Eingabe-/Ausgabedurchsatz (E/A) als Cachegröße in Gibibytes (GiB) an.

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 verwalteten Datenträgern festgelegt, wenn Sie andernfalls nicht explizit 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 Betriebssystemdatenträger mit 100 GB unterstützt kurzlebige Betriebssysteme und verfügt über eine Cachegröße von 200 GB. Wenn Sie den Betriebssystemdatenträgertyp nicht angeben, erhält ein 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.

Azure Virtual Machines-Knotenpools in AKS

Jede verwaltete Knotengruppe in EKS wird von einer Amazon EC2-Autoskalierungsgruppe unterstützt, die Amazon EKS verwaltet. Mit dieser Integration kann EKS EC2-Instanzen innerhalb der Knotengruppe automatisch konfigurieren und skalieren.

Sie können Automatische Skalierungsgruppen so konfigurieren, dass sie mehrere EC2-Instanztypen unterstützen, aber Sie können nicht angeben, wie viele Knoten für jeden Instanztyp erstellt oder skaliert werden sollen. Stattdessen verwaltet EKS die Skalierung der Knotengruppe basierend auf deiner gewünschten Konfiguration und deinen Richtlinien. Dieser Ansatz vereinfacht und automatisiert den Verwaltungsprozess für die Knotengruppe, sodass Sie EC2-Instanztypen auswählen können, die Ihren Workloadanforderungen entsprechen. Sie können auch selbstverwaltete Amazon Linux-Knoten mit dem eksctl Befehlszeilentool oder der AWS Management Console starten.

Für Azure Virtual Machines-Knotenpools konfiguriert und initialisiert AKS jeden Agentknoten. Für Azure Virtual Machine Scale Sets-Knotenpools verwaltet AKS das Modell von Vm Scale Sets und verwendet es, um Konsistenz über alle Agentknoten im Knotenpool hinweg zu erzielen. Sie können Knotenpools für virtuelle Computer verwenden, um Ihren Cluster mit VMs zu koordinieren, die am besten zu Ihren individuellen Workloads passen. Sie können auch angeben, wie viele Knoten für jede VM-Größe erstellt oder skaliert werden sollen.

Ein Knotenpool besteht aus einer Reihe von VMs, die unterschiedliche Größen aufweisen. Jede VM unterstützt eine andere Art von Workload. Diese VM-Größen, die als SKUs bezeichnet werden, werden in verschiedene Familien kategorisiert, die für bestimmte Zwecke optimiert sind. Weitere Informationen finden Sie unter VM-Größen in Azure.

Um die Skalierung mehrerer VM-Größen zu ermöglichen, verwendet der Knotenpooltyp "Virtuelle Computer" einen ScaleProfile. Dieses Profil konfiguriert, wie der Knotenpool skaliert wird, indem die gewünschte VM-Größe und -Anzahl angegeben wird. A ManualScaleProfile ist ein Skalierungsprofil, das die gewünschte VM-Größe und -Anzahl angibt. In einer ManualScaleProfileVM ist nur eine VM-Größe zulässig. Sie müssen für jede VM-Größe im Knotenpool ein separates ManualScaleProfile erstellen.

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

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

• Flexibilität: Sie können Knotenspezifikationen entsprechend Ihren Workloads und Anforderungen aktualisieren.

• Feinabstimmungssteuerung: Steuerelemente auf einzelner Knotenebene helfen beim Angeben und Kombinieren von Knoten verschiedener Spezifikationen, um die Konsistenz zu verbessern.

• Effizienz: Sie können den Knotenbedarf für Ihren Cluster reduzieren, um Ihre betrieblichen Anforderungen zu vereinfachen.

Knotenpools für virtuelle Computer bieten eine bessere Benutzererfahrung für dynamische Workloads und Anforderungen an hohe Verfügbarkeit. Sie können sie verwenden, um mehrere VMs derselben Familie in einem Knotenpool einzurichten, und Ihre Arbeitsauslastung wird automatisch für die verfügbaren Ressourcen geplant, die Sie konfigurieren.

In der folgenden Tabelle werden Knotenpools virtueller Maschinen mit standardmäßigen virtuellen Maschinen-Skalierungsgruppen-Knotenpools verglichen.

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

• Die Automatische Clusterskala 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 die Azure CLI - oder REST-APIs zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) oder zum Verwalten des Pools.
• Die Momentaufnahme des Knotenpools wird nicht unterstützt.
• Alle VM-Größen in einem Knotenpool müssen aus derselben VM-Familie stammen. Sie können z. B. keinen VM-Typ der N-Serie mit einem VM-Typ der D-Serie im selben Knotenpool kombinieren.
• Virtuelle Computer-Knotenpools ermöglichen bis zu fünf verschiedene VM-Größen pro Knotenpool.

Virtuelle Knoten

Sie können virtuelle Knoten verwenden, um Anwendungsworkloads in einem AKS-Cluster schnell aufzuskalieren. Virtuelle Knoten ermöglichen eine schnelle Podbereitstellung, und Sie zahlen für die Laufzeit nur pro Sekunde. Sie müssen nicht warten, bis die Autoskalierung des Clusters neue Workerknoten bereitstellen muss, um weitere Podreplikate auszuführen. Nur Linux-Pods und -Knoten unterstützen virtuelle Knoten. 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 finden Sie unter Erstellen und Konfigurieren eines AKS-Clusters für die Verwendung virtueller Knoten.

Taints, Bezeichnungen und Tags

Wenn Sie einen Knotenpool erstellen, können Sie Kubernetes-Taints und Bezeichnungen und Azure-Tags hinzufügen. Alle Taints, Bezeichnungen oder Tags gelten für alle Knoten innerhalb dieses Knotenpools.

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

  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 von 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 von AKS reserviert sind und nicht für Knoten verwendet werden können. In der Tabelle gibt die Spalte "Virtuelle Knotenverwendung " an, ob virtuelle Knoten die Bezeichnung unterstützen.

In der Spalte Nutzung virtueller Knoten:

• N/A bedeutet, dass die Eigenschaft nicht auf virtuelle Knoten angewendet wird, da der Host geändert werden muss.
• Dies bedeutet, dass die erwarteten Werte für einen virtuellen Knotenpool und einen Standardknotenpool identisch sind.
• Virtual ersetzt VM-SKU-Werte, da virtuelle Knoten pods keine zugrunde liegenden VMs verfügbar machen.
• Die Version des virtuellen Knotens bezieht sich auf die aktuelle Version des virtuellen Kubelet-ACI-Connector-Releases.
• Der Subnetzname des virtuellen Knotens bezeichnet 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

Sie können AKS verwenden, um Windows Server-Containerknotenpools über das Azure Container Networking Interface-Netzwerk-Plug-In zu erstellen und zu verwenden. Informationen zum Planen der erforderlichen Subnetzbereiche und Netzwerküberlegungen finden Sie unter Konfigurieren der Azure-Containernetzwerkschnittstelle.

Mit dem folgenden az aks nodepool add Befehl wird ein Knotenpool hinzugefügt, in dem Windows Server-Container ausgeführt werden:

  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 von einzelnen oder mehreren 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 Standard-SKU-Lastenausgleichsgeräte 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 einem Knotenpool zugewiesen sind, müssen sich im selben virtuellen Netzwerk befinden.

• Wenn Sie beim Erstellen eines Clusters mehrere Knotenpools erstellen, müssen die Kubernetes-Versionen für alle Knotenpools mit der Steuerebenenversion übereinstimmen. Wenn Sie Versionen aktualisieren möchten, nachdem Sie den Cluster konfiguriert haben, verwenden Sie Vorgänge pro Knotenpool.

Skalieren von Knotenpools

Wenn sich die Workload Ihrer Anwendung ändert, müssen Sie möglicherweise die Anzahl der Knoten in einem Knotenpool ändern. Wenn Sie die Anzahl der Knoten manuell nach oben oder unten skalieren möchten, verwenden Sie den Befehl "az aks nodepool scale" . 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

AKS unterstützt die automatische Skalierung von Knotenpools mithilfe der Cluster-Autoskalierung. Aktivieren Sie dieses Feature für jeden Knotenpool, und definieren Sie ein Minimum und eine maximale Anzahl 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 Cluster-Autoscaler im neuen Knotenpool. Die --min-count Parameter --max-count geben die minimale und maximale Anzahl von 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

Verwenden Sie den Befehl mit dem az aks nodepool update--disable-cluster-autoscaler Parameter, um die Cluster-Autoscaler zu deaktivieren.

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

Um den Cluster-Autoscaler in einem vorhandenen Cluster erneut zu aktivieren, verwenden Sie den Befehl az aks nodepool update und geben Sie die Parameter --enable-cluster-autoscaler, --min-count und --max-count an.

Weitere Informationen zur Verwendung der Cluster-Autoscaler für einzelne Knotenpools finden Sie unter Verwenden der Cluster-Autoscaler in AKS.

Pod Sandboxing

Verwenden Sie pod Sandboxing, um Kata-Container auf AKS als vollständig verwaltete Lösung auf einfache Weise einzurichten und auszuführen. Pod Sandboxing ist ein AKS-Feature, das eine Isolationsgrenze zwischen der Containeranwendung und dem freigegebenen Kernel und Computeressourcen des Containerhosts erstellt, 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-Complianceanforderungen zu erfüllen. Zu diesen Anforderungen gehören Payment Card Industry Data Security Standard (PCI DSS), International Organization for Standardization (ISO) 27001 und Health Insurance Portability and Accountability Act (HIPAA).

Stellen Sie Anwendungen in separaten Clustern oder Knotenpools bereit, um die Mandantenarbeitslasten verschiedener Teams oder Kunden zu isolieren. Sie können mehrere Cluster und Knotenpools verwenden, wenn Ihre Organisation oder Software as a Service (SaaS)-Lösung sie erfordert. Einige Szenarien profitieren jedoch von einem einzelnen Cluster mit gemeinsam genutzten VM-Knotenpools. Sie können beispielsweise einen einzelnen Cluster verwenden, um auf demselben Knoten nicht vertrauenswürdige und vertrauenswürdige Pods auszuführen oder DaemonSets und privilegierte Container auf demselben Knoten zu platzieren, um eine schnellere lokale Kommunikation und funktionale Gruppierung zu ermöglichen.

Pod Sandboxing kann Ihnen dabei helfen, Mandantenanwendungen auf denselben Clusterknoten zu isolieren, ohne diese Workloads in separaten Clustern oder Knotenpools ausführen zu müssen. Andere Methoden erfordern möglicherweise, dass Sie den Code neu kompilieren oder andere Kompatibilitätsprobleme verursachen. Pod Sandboxing in AKS kann jeden nicht geänderten Container innerhalb einer erweiterten Sicherheits-VM-Grenze ausführen.

Pod Sandboxing basiert auf Kata-Containern , die auf dem Azure Linux-Containerhost für AKS-Stapel ausgeführt werden, um hardwareverzwingte Isolation bereitzustellen. Kata-Container auf AKS basieren auf einem sicherheitsfesten Azure-Hypervisor. Die Isolierung der einzelnen Pods wird durch eine geschachtelte Lightweight-Kata-VM gewährleistet, die Ressourcen eines übergeordneten VM-Knotens verwendet. In diesem Modell erhält jeder Kata-Pod seinen eigenen Kernel in einer geschachtelten Kata-Gast-VM. Verwenden Sie dieses Modell, um mehrere 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 gemeinsam genutzten AKS-Cluster.

Weitere Informationen finden Sie unter Support für isolierte Kata-VM-Container auf AKS für Pod Sandboxing.

Dedizierter Azure-Host

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

Verwenden Sie dedizierten Host mit AKS, um die folgenden Vorteile zu bieten:

• 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 dieselbe Netzwerk- und zugrunde liegende Speicherinfrastruktur wie andere nicht isolierte Hosts.

• Der dedizierte 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.

Der dedizierte Host kann SaaS-Anbieter dabei unterstützen, sicherzustellen, dass Mandantenanwendungen behördliche, branchenspezifische und Governance-Complianceanforderungen erfüllen, um vertrauliche Informationen zu schützen. Weitere Informationen finden Sie unter Hinzufügen eines dedizierten Hosts zu einem AKS-Cluster.

Karpenter

Karpenter ist ein Open-Source-Projekt für das Node-Lifecycle-Management, das für Kubernetes erstellt wurde. Fügen Sie Karpenter zu einem Kubernetes-Cluster hinzu, um die Effizienz und kosten der Ausführung von Workloads auf diesem Cluster zu verbessern. Karpenter überwacht Pods, die der Kubernetes-Scheduler als nicht planbar markiert. Es stellt auch dynamisch Knoten bereit und verwaltet Knoten, die in der Lage sind, die Podanforderungen zu erfüllen.

Karpenter bietet eine differenzierte Kontrolle über die Bereitstellung von Knoten und die Workloadplatzierung in einem verwalteten Cluster. Mit diesem Steuerelement wird die Ressourcenzuordnung optimiert, die Isolation zwischen den Anwendungen der einzelnen Mandanten gewährleistet und die Betriebskosten reduziert, wodurch die Mehrinstanzenfähigkeit verbessert wird. Wenn Sie eine mehrinstanzenfähige Lösung auf AKS erstellen, bietet Karpenter nützliche Funktionen, um verschiedene Anwendungsanforderungen zu verwalten, um verschiedene Mandanten zu unterstützen.

Beispielsweise benötigen Sie möglicherweise Anwendungen einiger Mandanten, die auf GPU-optimierten Knotenpools laufen, während andere auf speicheroptimierten Knotenpools ausgeführt werden sollen. 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. Anschließend können Sie für Ihre Speicher- und Anwendungsebene eine Colocation ausführen.

AKS ermöglicht die automatische Bereitstellung von Knoten auf AKS-Clustern über Karpenter. Die meisten Benutzer sollten den Knotenmodus für die automatische Bereitstellung verwenden, um Karpenter als verwaltetes Add-On zu aktivieren. Weitere Informationen finden Sie unter node autoprovisioning. Wenn Sie erweiterte Anpassungen benötigen, können Sie Karpenter selbst hosten. Weitere Informationen finden Sie unter AKS Karpenter-Anbieter.

Vertrauliche virtuelle Computer

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

Die AWS-Plattform unterstützt vertrauliches Computing über Nitro Enklaven, die auf EC2-Instanzen und Amazon EKS verfügbar sind. Amazon EC2-Instanzen unterstützen auch AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP). Das GitHub-Repository 'Runtime Attestation' stellt Artefakte für die Erstellung und Bereitstellung eines Amazon Machine Image für EKS mit Unterstützung für AMD SEV-SNP bereit.

Azure bietet 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 SEV-SNP Technologie. Diese Technologie verweigert Hypervisor und anderen Hostverwaltungscodezugriff auf VM-Speicher und -Zustand. Verwenden Sie diesen Ansatz, um eine zusätzliche Schutzebene und schutz vor Operatorzugriff hinzuzufügen. Weitere Informationen finden Sie unter Verwenden vertraulicher VMs in einem AKS-Cluster und übersicht über vertrauliche VMs in Azure.

Bundesnormen für Informationsprozesse

Federal Information Process Standards (FIPS) 140-3 ist ein US-Regierungsstandards, der mindestsicherheitsanforderungen für kryptografische Module in Informationstechnologieprodukten und -systemen definiert. Aktivieren Sie die FIPS-Compliance für AKS-Knotenpools , um die Isolation, den Datenschutz und die Sicherheit Ihrer Mandantenworkloads zu verbessern. FIPS-Compliance trägt dazu bei, die Verwendung validierter kryptografischer Module für Verschlüsselung, Hashing und andere sicherheitsbezogene Vorgänge sicherzustellen. Verwenden Sie FIPS-fähige AKS-Knotenpools, um robuste kryptografische Algorithmen und Mechanismen zu verwenden, die dazu beitragen, behördliche und branchenspezifische Complianceanforderungen zu erfüllen. Weitere Informationen zur Stärkung des Sicherheitsstatus Ihrer mehrinstanzenfähigen AKS-Umgebungen finden Sie unter Aktivieren von FIPS für AKS-Knotenpools.

Hostbasierte Verschlüsselung

In EKS kann Ihre Architektur die folgenden Features verwenden, um die Datensicherheit zu verbessern:

• Amazon Elastic Block Store (EBS)-Verschlüsselung: Sie können ruhende Daten auf Amazon EBS-Volumes verschlüsseln, die an Ihre EKS-Workerknoten angefügt sind.

• AWS Key Management Service (KMS): Sie können AWS KMS verwenden, um Verschlüsselungsschlüssel zu verwalten und die Verschlüsselung Ihrer ruhenden Daten zu erzwingen. Wenn Sie die Verschlüsselung geheimer Schlüssel aktivieren, können Sie Kubernetes-Geheimnisse mithilfe Ihres eigenen AWS KMS-Schlüssels verschlüsseln. Weitere Informationen finden Sie unter Verschlüsseln von Kubernetes-Geheimnissen mit AWS KMS auf vorhandenen Clustern.

• Amazon S3 serverseitige Verschlüsselung: Wenn Ihre EKS-Anwendungen mit Amazon S3 interagieren, können Sie die serverseitige Verschlüsselung für Ihre S3-Buckets aktivieren, um ruhende Daten zu schützen.

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. Dieser Ansatz schützt vertrauliche Mandanteninformationen vor unbefugtem Zugriff. Wenn Sie die End-to-End-Verschlüsselung aktivieren, werden temporäre Datenträger und kurzlebige Betriebssystemdatenträger über plattformverwaltete Schlüssel verschlüsselt.

In AKS verwenden Betriebssystemdatenträger und -datenträger standardmäßig serverseitige Verschlüsselung über plattformverwaltete Schlüssel. Die Caches für diese Datenträger sind im Ruhezustand durch von der Plattform verwaltete Schlüssel verschlüsselt. Sie können ihren eigenen Schlüsselverschlüsselungsschlüssel verwenden, um den Datenschutzschlüssel zu verschlüsseln. Diese Methode wird als Umschlagverschlüsselung oder Verpackung bezeichnet. Der von Ihnen angegebene Verschlüsselungsschlüssel verschlüsselt auch den Cache für die Betriebssystemdatenträger und -datenträger.

Die hostbasierte Verschlüsselung fügt eine Sicherheitsebene für Mehrinstanzenumgebungen hinzu. Die Daten jedes Mandanten auf dem Betriebssystemdatenträger und den Datenträger-Caches werden verschlüsselt, wenn sie nicht aktiv genutzt werden, entweder über vom Kunden verwaltete oder plattformverwaltete Schlüssel, je nach ausgewähltem Verschlüsselungstyp der Datenträger. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Hostbasierte Verschlüsselung auf AKS-
• BYOK mit Azure-Datenträgern in AKS
• Serverseitige Verschlüsselung des Azure-Datenträgerspeichers

Updates und Upgrades

Azure aktualisiert regelmäßig seine VM-Hostingplattform, 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 finden Sie unter Wartung für VMs in Azure.

VM-Hosting-Infrastrukturupdates wirken sich in der Regel nicht auf gehostete VMs aus, z. B. Agentknoten vorhandener AKS-Cluster. Bei Updates, die sich auf gehostete VMs auswirken, minimiert Azure die Anzahl der Fälle, in denen Neustarts erforderlich sind, indem die VM beim Aktualisieren des Hosts pausiert oder durch Livemigration auf einen bereits aktualisierten Host verschoben wird.

Wenn ein Update einen Neustart erfordert, stellt Azure Benachrichtigungen und ein Zeitfenster bereit, wenn Sie das Update starten können. 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 virtuelle Computer zu aktualisieren. Verwalten Sie geplante Wartungsbenachrichtigungen mithilfe der Azure CLI, Azure PowerShell oder des Azure-Portals. Geplante Wartung erkennt, ob Sie das Feature für automatisches Upgrade des Clusters verwenden und Upgrades während des Wartungsfensters automatisch planen. Weitere Informationen finden Sie unter Verwenden Sie geplante Wartung, um Wartungsfenster für Ihren AKS-Cluster zu planen und den Befehl az aks maintenanceconfiguration.

Kubernetes-Upgrades

Ein Teil des AKS-Clusterlebenszyklus umfasst regelmäßig ein Upgrade auf die neueste Kubernetes-Version. Sie sollten Upgrades anwenden, um die neuesten Sicherheitsversionen und -features zu erhalten. Um die Kubernetes-Version vorhandener Knotenpool-VMs zu aktualisieren, müssen Sie Knoten abkoppeln und entleeren und sie durch neue Knoten ersetzen, die auf einem aktualisierten Kubernetes-Image 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 Arbeitsauslastungsunterbrechungen. Diese Konfiguration erstellt einen zusätzlichen Knoten, um ältere Versionsknoten zu ersetzen, bevor vorhandene Anwendungen abgebunden oder entwässert werden. Sie können den max-surge Wert pro Knotenpool anpassen, um den Kompromiss zwischen Upgradegeschwindigkeit und Upgradeunterbrechungen zu optimieren. Ein höherer max-surge Wert erhöht die Geschwindigkeit des Upgradeprozesses, aber ein großer Wert kann während max-surge des Upgradeprozesses zu Unterbrechungen führen.

Beispielsweise bietet ein max-surge Wert von 100% den schnellstmöglichen Upgradeprozess, indem die Knotenanzahl verdoppelt wird. Dieser Wert entwässert aber auch alle Knoten im Knotenpool gleichzeitig. Möglicherweise möchten Sie diesen hohen Wert zum Testen verwenden, aber für Produktionsknotenpools sollten Sie eine max-surge Einstellung von 33%nutzen.

AKS akzeptiert sowohl ganze Zahlen als auch Prozentwerte für den max-surge Wert. Eine ganze Zahl wie 5 gibt für den Anstieg fünf zusätzliche Knoten an. Sie können den Prozentwert für max-surge von 1% zu 100%, aufgerundet auf die nächste Knotenanzahl festlegen. Ein Wert von 50% weist auf einen Spitzenwert hin, der der Hälfte der aktuellen Anzahl der Knoten im Pool entspricht.

Während eines Upgrades können Sie den max-surge Wert auf ein Minimum und 1 einen Maximalwert festlegen, der der Anzahl der Knoten im Knotenpool entspricht. Sie können größere Werte festlegen, aber die maximale Anzahl von Knoten für max-surge die Anzahl der Knoten im Pool darf nicht überschreiten.

Knotenpools aktualisieren

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>

Verwenden Sie das Az aks nodepool-Upgrade, um ein Upgrade eines einzelnen Knotenpools durchzuführen.

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

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Aktualisierung des AKS-Knotenabbilds
• Aktualisieren einer Clustersteuerungsebene mit mehreren Knotenpools

Überlegungen zur Aktualisierung

Beachten Sie beim Upgrade der Kubernetes-Version in einem AKS-Cluster die folgenden bewährten Methoden:

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

• Führen Sie Upgrades manuell aus, oder legen Sie einen automatischen Upgradekanal auf Ihrem Cluster fest. Wenn Sie geplante Wartung zum Patchen von virtuellen Computern verwenden, beginnen automatische Upgrades auch während des angegebenen Wartungsfensters. Weitere Informationen finden Sie unter Aktualisieren eines AKS-Clusters.

• Der az aks upgrade Befehl mit der --control-plane-only Kennzeichnung aktualisiert die Clustersteuerungsebene und ändert nicht die 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 ein niedriges Computekontingent verfügbar haben, kann das Upgrade fehlschlagen. Weitere Informationen finden Sie unter Regionale vCPU-Kontingente erhöhen.

• Konfigurieren Sie den max-surge Parameter basierend auf Ihren Anforderungen. Verwenden Sie eine ganze Zahl oder einen Prozentwert. Verwenden Sie für Produktionsknotenpools eine max-surge-Einstellung von 33 %. Weitere Informationen finden Sie unter Anpassen des Knotenanstiegsupgrades.

• Wenn Sie ein AKS-Cluster aktualisieren, der Azure Container Networking Interface-Netzwerknetzwerke verwendet, stellen Sie sicher, dass das Subnetz über genügend private IP-Adressen für die zusätzlichen Knoten verfügt, die die max-surge Einstellungen erstellen. Weitere Informationen finden Sie unter Konfigurieren des Azure Container Networking Interface-Netzwerks in AKS.

• Wenn Ihre Clusterknotenpools mehrere Verfügbarkeitszonen innerhalb einer Region umfassen, kann der Upgradeprozess vorübergehend eine nicht ausgeglichene Zonenkonfiguration erstellen. Weitere Informationen finden Sie unter Knotenpools, die mehrere Verfügbarkeitszonen umfassen.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• Paolo Salvadori | Principal System Engineer

Andere Mitwirkende:

• Laura Nicolas | Senior Software Engineer
• Chad Kittel | Principal Software Engineer – Azure Patterns & Practices
• Ed Preis | Senior Content Program Manager
• Theano Petersen | Technischer Autor

Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Best Practices für AKS-Cluster
• Schützen eines AKS-Clusters mit Azure Firewall
• Schulung: Einführung in Kubernetes
• Schulung: Einführung in Kubernetes in Azure
• Schulung: Entwickeln und Bereitstellen von Anwendungen auf Kubernetes
• Schulung: Optimieren der Berechnungskosten für AKS

Verwandte Ressourcen

• 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
• AKS-Lösungsreise
• AKS Day-2-Betriebsanleitung
• Wählen Sie eine Rechenoption für Kubernetes am Netzwerkrand
• GitOps für AKS