Freigeben über

Häufig gestellte Fragen zu AKS

Dieser Artikel enthält Antworten auf einige der häufigsten Fragen zu Azure Kubernetes Service (AKS).

Support

Bietet AKS eine Vereinbarung zum Servicelevel?

AKS bietet Servicelevelvereinbarungen (SLA) im Standard Preis-Tier mit der Funktion Uptime SLA.

Was ist Plattformunterstützung, und was beinhaltet sie?

Der Plattform-Support ist ein reduzierter Plan für nicht unterstützte Cluster der Version n-3. Der Plattform-Support umfasst nur die Unterstützung der Azure-Infrastruktur.

Weitere Informationen finden Sie unter der Richtlinie zum Plattform-Support.

Führt AKS ein automatisches Upgrade für meine nicht unterstützten Cluster durch?

Ja, AKS initiiert automatische Upgrades für nicht unterstützte Cluster. Wenn ein Cluster in einer Version n-3 (wobei n die letzte unterstützte und allgemein verfügbare AKS-Unterversion ist) kurz vor dem Drop auf n-4 steht, führt AKS automatisch ein Upgrade des Clusters auf n-2 durch, um in einer AKS-Support-Richtlinie zu bleiben.

Weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen, Geplante Wartungsfenster und Automatische Upgrades.

Kann ich Rabatte für Azure-Reservierungen auf meine AKS-Agent-Knoten anwenden?

AKS-Agent-Knoten werden als virtuelle Maschinen (VMs) in Azure abgerechnet. Wenn Sie also Azure-Reservierungen für die von Ihnen in AKS verwendete VM-Größe erworben haben, werden diese Rabatte automatisch angewendet.

Operationen (Operations)

Kann ich Windows Server-Container unter AKS ausführen?

Ja, AKS unterstützt Windows Server Container. Weitere Informationen finden Sie unter Windows Server auf AKS - FAQ.

Welche Linux-Betriebssysteme (OS) werden unter AKS unterstützt?

AKS unterstützt vier Hauptbetriebssysteme für Linux, einschließlich Ubuntu Linux, Azure Linux,Azure Linux OS Guard und Flatcar Container Linux für AKS. Wenn Sie während der Erstellung des Knotenpools oder der Clustererstellung angeben --os-type Linux , ist das Standardbetriebssystem Ubuntu Linux.

Welche Betriebssystemversionen werden unter AKS unterstützt?

Bei Verwendung --os-sku Ubuntuwird AKS standardmäßig auf Ubuntu 22.04 in Kubernetes-Versionen 1.25-1.34 festgelegt. AKS ist standardmäßig auf Ubuntu 24.04 in Kubernetes-Versionen 1.35+ festgelegt. Wenn Sie --os-sku AzureLinux verwenden, verwendet AKS standardmäßig Azure Linux 3.0 in Kubernetes Versionen 1.32+. In einigen Szenarien, z. B. FIPS-fähigen Knotenpools, kann sich die Standardversion des Betriebssystems unterscheiden. Weitere Informationen finden Sie unter Knotenabbildungen.

Kann ich meinen Cluster zwischen Azure-Mandanten verschieben oder migrieren?

Nein. Das Verschieben Ihres AKS-Clusters zwischen Mandanten wird derzeit nicht unterstützt.

Kann ich meinen Cluster zwischen Abonnements verschieben oder migrieren?

Nein. Das Verschieben Ihres AKS-Clusters zwischen Abonnements wird derzeit nicht unterstützt.

Kann ich meine AKS-Cluster- oder AKS-Infrastrukturressourcen in andere Ressourcengruppen verschieben oder sie umbenennen?

Nein. Das Verschieben oder Umbenennen Ihres AKS-Clusters und der zugehörigen Ressourcen wird nicht unterstützt.

Kann ich meinen Cluster wiederherstellen, nachdem ich ihn gelöscht habe?

Nein. Sie können Ihren Cluster nicht wiederherstellen, nachdem Sie ihn gelöscht haben. Wenn Sie den Cluster löschen, werden auch die Knotenressourcengruppe und alle zugehörigen Ressourcen gelöscht.

Wenn Sie eine Ihrer Ressourcen behalten möchten, verschieben Sie sie in eine andere Ressourcengruppe, bevor Sie Ihren Cluster löschen. Wenn Sie sich gegen versehentliches Löschen schützen möchten, können Sie die von AKS verwaltete Ressourcengruppe, die Ihre Cluster-Ressourcen hostet, sperren, indem Sie Knoten Ressourcengruppe sperren verwenden.

Kann ich meinen AKS-Cluster auf 0 (null) skalieren?

Sie können einen laufenden AKS-Cluster vollständig anhalten oder skalieren oder alle oder bestimmte User-Knoten-Pools auf Null skalieren.

Systemknotenpools können nicht direkt auf Null skaliert werden.

Kann ich die VM-Skalierungsgruppen-APIs für eine manuelle Skalierung verwenden?

Nein. Skalierungsvorgänge, die die APIs für die Skalierung virtueller Maschinen verwenden, werden nicht unterstützt. Sie können die AKS-APIs verwenden (az aks scale).

Kann ich VM-Skalierungsgruppen verwenden, um manuell auf null Knoten zu skalieren?

Nein. Skalierungsvorgänge, die die APIs für die Skalierung virtueller Maschinen verwenden, werden nicht unterstützt. Sie können stattdessen die AKS-API verwenden, um systemfremde Knoten-Pools auf Null zu skalieren oder Ihren Cluster anzuhalten.

Kann ich alle meine VMs anhalten oder deallokieren?

Nein. Diese Konfiguration wird nicht unterstützt. Beenden Sie den Cluster stattdessen.

Warum werden zwei Ressourcengruppen mit AKS erstellt?

AKS baut auf vielen Azure-Infrastrukturressourcen auf, einschließlich VM-Skalierungsgruppen, virtueller Netzwerke und verwalteter Datenträger. Diese Integrationen ermöglichen Ihnen, viele der Kernfunktionen der Azure-Plattform in der von AKS bereitgestellten verwalteten Kubernetes-Umgebung zu nutzen. Sie können zum Beispiel die meisten Azure VM-Typen direkt mit AKS verwenden, und Sie können Azure Reservierungen nutzen, um automatisch Rabatte auf diese Ressourcen zu erhalten.

Um diese Architektur zu ermöglichen, umfass jede AKS-Bereitstellung zwei Ressourcengruppen:

  1. Die erste Ressourcengruppe wird von Ihnen erstellt. Diese Gruppe enthält nur die Kubernetes-Dienstressource. Der AKS-Ressourcenanbieter erstellt während der Bereitstellung automatisch die zweite Ressourcengruppe. MC_myResourceGroup_myAKSCluster_eastus ist ein Beispiel für die zweite Ressourcengruppe. Informationen dazu, wie Sie den Namen dieser zweiten Ressourcengruppe angeben, finden Sie im nächsten Abschnitt.
  2. Die zweite Ressourcengruppe, als Knotenressourcengruppe bezeichnet, enthält alle Infrastrukturressourcen für den Cluster. Diese Ressourcen umfassen die virtuellen Computer des Kubernetes-Knotens, virtuelle Netzwerke und Speicher. Standardmäßig lautet der Name der Knotenressourcengruppe z. B. MC_myResourceGroup_myAKSCluster_eastus. AKS löscht die Knotenressourcengruppe automatisch, wenn Sie den Cluster löschen. Verwenden Sie diese Ressourcengruppe nur für Ressourcen, die den Lebenszyklus des Clusters teilen.

Hinweis

Das Ändern einer Ressource unter der Knotenressourcengruppe im AKS-Cluster ist eine nicht unterstützte Aktion und führt zu Fehlern im Clusterbetrieb. Sie können verhindern, dass Änderungen an der Ressourcengruppe Knoten vorgenommen werden. Blockieren Sie Benutzer von der Änderung von Ressourcen, die der AKS-Cluster verwaltet.

Kann ich einen eigenen Namen für die AKS-Knotenressourcengruppe angeben?

Standardmäßig benennt AKS die Knoten-Ressourcengruppe MC_resourcegroupname_clustername_location, aber Sie können einen eigenen Namen vergeben.

Installieren Sie die aks-preview-Erweiterungsversion 0.3.2 oder höher der Azure CLI, wenn Sie einen eigenen Ressourcengruppennamen angeben möchten. Verwenden Sie bei der Erstellung eines AKS-Clusters mit dem Befehl az aks create den Parameter --node-resource-group, und geben Sie einen Namen für die Ressourcengruppe an. Wenn Sie eine Azure Resource Manager Vorlage verwenden, um einen AKS-Cluster bereitzustellen, können Sie den Namen der Ressourcengruppe über die nodeResourceGroupEigenschaft definieren.

  • Der Azure-Ressourcenanbieter erstellt automatisch die sekundäre Ressourcengruppe.
  • Sie können einen angepassten Namen für die Ressourcengruppe nur beim Erstellen des Clusters angeben.

Während Sie mit der Knoten-Ressourcengruppe arbeiten, können Sie das nicht:

  • Angeben einer vorhandenen Ressourcengruppe als Knotenressourcengruppe
  • Angeben eines anderen Abonnements für die Knotenressourcengruppe
  • Den Namen der Knoten-Ressourcengruppe ändern, nachdem Sie den Cluster erstellt haben.
  • Angeben von Namen für die verwalteten Ressourcen innerhalb der Knotenressourcengruppe
  • Ändern oder Löschen von Azure erstellter Tags für verwaltete Ressourcen innerhalb der Knotenressourcengruppe

Kann ich Tags und andere Eigenschaften der AKS-Ressourcen in der Knotenressourcengruppe ändern?

Wenn Sie die in Azure erstellten Tags und andere Ressourceneigenschaften in der Knotenressourcengruppe ändern oder löschen, kann dies zu unerwarteten Skalierungs- und Aktualisierungsfehlern führen. AKS bietet Ihnen die Möglichkeit, von Anwendern erstellte angepasste Tags zu erstellen und zu ändern, und Sie können diese Tags hinzufügen, wenn Sie einen Knoten-Pool erstellen. Sie können benutzerdefinierte Tags erstellen oder ändern, um beispielsweise eine Geschäftseinheit oder eine Kostenstelle zuzuweisen. Eine weitere Option besteht darin, Richtlinien anzuwenden und Tags über die AKS-Ressource selbst zu ändern , insbesondere über die Cluster- und Knotenpools.

Von Azure erstellte Tags werden für die jeweiligen Azure Dienste erstellt, und Sie sollten ihnen immer die Möglichkeit bieten. Für AKS gibt es die Tags aks-managed und k8s-azure. Von Azure erstellte Tags für Ressourcen unter der Knotenressourcengruppe im AKS-Cluster dürfen nicht geändert werden, da dies zu einer Verletzung des Servicelevelziels (Service-Level Objective, SLO) führt.

Hinweis

In der Vergangenheit war der Tag-Name Owner für AKS reserviert, um die öffentliche IP zu verwalten, die auf die Frontend-IP des Load-Balancers verteilt wird. Jetzt verwenden die Dienste das Präfix aks-managed. Verwenden Sie für veraltete Ressourcen keine Azure Richtlinien, um den Owner Tag-Namen anzuwenden. Andernfalls treten bei allen Ressourcen für Ihre AKS-Clusterbereitstellungs- und -Updatevorgänge Fehler auf. Diese Einschränkung gilt nicht für neu erstellte Ressourcen.

Warum sehe ich auf meinem Cluster von AKS verwaltete, mit einem Präfix versehene Helm-Versionen, und warum steigt deren Revisionszahl ständig an?

AKS verwendet Helm, um Komponenten für Ihren Cluster bereitzustellen. Sie können die Helm-Versionen mit dem Präfix aks-managed ignorieren. Kontinuierlich steigende Revisionen dieser Helm-Versionen sind zu erwarten und sicher.

Kontingente, Limits und die Verfügbarkeit von Regionen

In welchen Azure-Regionen wird AKS derzeit zur Verfügung gestellt?

Eine vollständige Liste der verfügbaren Regionen finden Sie unter AKS-Regionen und Verfügbarkeit.

Kann ich einen AKS-Cluster regionsübergreifend verteilen?

Nein. AKS-Cluster sind regionale Ressourcen und können sich nicht über mehrere Regionen erstrecken. Eine Anleitung zum Erstellen einer Architektur, die mehrere Regionen umfasst, finden Sie unter Bewährte Verfahren für Business-Continuity und Disaster-Recovery.

Kann ich einen AKS-Cluster über Verfügbarkeitszonen hinweg verteilen?

Ja, Sie können einen AKS-Cluster über eine oder mehrere Verfügbarkeitszonen in Regionen bereitstellen, die diese unterstützen.

Kann ich unterschiedliche VM-Größen in einem einzigen Cluster verwenden?

Ja, Sie können verschiedene VM-Größen in Ihrem AKS-Cluster verwenden, indem Sie mehrere Knoten-Pools erstellen.

Was ist die Größenbeschränkung für ein Containerimage in AKS?

AKS legt keinen Grenzwert für die Größe des Containerimages fest. Aber je größer das Image ist, desto höher ist der Bedarf an Speicher. Eine höhere Größe könnte potenziell Ressourcenlimits oder den gesamten verfügbaren Arbeitsspeicher von Workerknoten überschreiten. Standardmäßig ist der Arbeitsspeicher für die VM-Größe Standard_DS2_v2 für einen AKS-Cluster auf 7 GiB festgelegt.

Wenn ein Container-Image übermäßig groß ist, z.B. im Terabyte (TB) Bereich, kann das Kubelet es möglicherweise nicht aus Ihrer Container Registry auf einen Knoten pullen, weil der Datenträger nicht ausreicht.

Für Windows Server-Knoten werden die neuesten Updates von Windows Update nicht automatisch ausgeführt und angewendet. Sie sollten ein Upgrade für den Cluster und die Windows Server Knoten-Pools in Ihrem AKS-Cluster durchführen. Halten Sie sich dabei an einen regelmäßigen Zeitplan, der auf dem Windows Update-Releasezyklus und Ihrem eigenen Validierungsprozess basiert. Dieser Upgrade-Prozess erstellt Knoten, die das neueste Windows Server Image und die neuesten Patches ausführen, und entfernt dann die älteren Knoten. Weitere Informationen zu diesem Prozess finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS.

Sind AKS-Images für eine Ausführung als root erforderlich?

Die folgenden Images haben funktionale Anforderungen, um als Root ausgeführt werden zu können, und für alle Richtlinien müssen Ausnahmen eingereicht werden:

  • mcr.microsoft.com/oss/kubernetes/coredns
  • mcr.microsoft.com/azuremonitor/containerinsights/ciprod
  • mcr.microsoft.com/oss/calico/node
  • mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Sicherheit, Zugriff und Identität

Kann ich einschränken, wer Zugriff auf den Kubernetes-API-Server hat?

Ja, es gibt zwei Möglichkeiten, den Zugriff auf den API-Server zu limitieren:

  • Verwenden Sie API-Server autorisierte IP-Bereiche, wenn Sie einen öffentlichen Endpunkt für den API-Server beibehalten, den Zugriff jedoch auf ein Set von vertrauenswürdigen IP-Bereichen festlegen möchten.
  • Verwenden Sie einen privaten Cluster, wenn Sie den Zugriff auf den API-Server auf nur innerhalb Ihres virtuellen Netzwerks limitieren möchten.

Werden Sicherheitsupdates auf AKS-Agent-Knoten angewendet?

AKS patcht wöchentlich CVEs, für die es eine Anbieterkorrektur gibt. CVEs ohne Korrektur warten auf eine Korrektur des Anbieters, bevor sie behoben werden können. Die AKS-Images werden automatisch innerhalb von 30 Tagen aktualisiert. Wir empfehlen Ihnen, regelmäßig ein aktualisiertes Image des Knotens aufzuspielen, um sicherzustellen, dass alle gepatchten Images und Betriebssystem-Patches auf dem neuesten Stand sind. Sie können diese Aufgabe übernehmen:

  • Manuell über das Azure-Portal oder die Azure-CLI.
  • Durch ein Upgrade des AKS-Clusters. Der Cluster aktualisiert Knoten einkreisen und entleeren automatisch. Dann wird ein neuer Knoten mit dem neuesten Ubuntu Image und einer neuen Patch-Version oder einer niedrigeren Kubernetes-Version online gestellt. Weitere Informationen finden Sie unter Aktualisieren eines AKS-Clusters.
  • Mit einem Node Image Upgrade.

Gibt es Sicherheitsbedrohungen, die auf AKS abzielen und über die ich mir bewusst sein sollte?

Microsoft bietet Anleitungen für andere Maßnahmen, die Sie ergreifen können, um Ihre Workloads durch Dienste wie Microsoft Defender for Containers zu sichern. Informationen zu einer Sicherheitsbedrohung im Zusammenhang mit AKS und Kubernetes finden Sie unter Neue groß angelegte Kampagne zielt auf Kubeflow (8. Juni 2021).

Speichert AKS irgendwelche Kundendaten außerhalb der Region des Clusters?

Nein. Alle Daten werden in der Region des Clusters gespeichert.

Wie kann ich vermeiden, dass das Festlegen von Berechtigungen zu langsamen Problemen führt, wenn das Volume zahlreiche Dateien enthält?

Wenn Ihr Pod als nicht-root Benutzer ausgeführt wird (was er sollte), müssen Sie traditionell einen fsGroup Parameter im Sicherheitskontext des Pods angeben, damit das Volume für den Pod lesbar und beschreibbar ist. Weitere Informationen zu dieser Anforderung finden Sie unter Konfigurieren Sie einen Sicherheitskontext für einen Pod oder Container.

Ein Nebeneffekt der Einstellung fsGroup ist, dass Kubernetes jedes Mal, wenn ein Volume gemountet wird, die chown()- und chmod()-Befehle rekursiv für alle Dateien und Verzeichnisse innerhalb des Volumes verwenden muss (mit ein paar Ausnahmen). Dieses Szenario tritt selbst dann ein, wenn der Gruppenbesitz des Volumes bereits mit dem angefragten fsGroup Parameter übereinstimmt. Diese Konfiguration kann bei größeren Volumes mit vielen kleinen Dateien sehr aufwendig sein, was dazu führen kann, dass der Start eines Pods sehr lange dauert. Dieses Szenario war ein bekanntes Problem vor v1.20. Die Abhilfe besteht darin, den Pod so festzulegen, dass er als Root ausgeführt wird:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Das Problem wurde mit Kubernetes Version 1.20 behoben. Weitere Informationen finden Sie unter Kubernetes 1.20: Granulare Steuerung von Änderungen der Berechtigungen für Volumes.

Netzwerk

Wie kommuniziert die verwaltete Steuerungsebene mit meinen Knoten?

AKS verwendet eine sichere Tunnelkommunikation, um den api-server und den einzelnen Knoten-Kubelets die Möglichkeit zu bieten, selbst in getrennten virtuellen Netzwerken zu kommunizieren. Der Tunnel ist durch gegenseitige Secure Socket Layer Security-Verschlüsselung gesichert. Der aktuelle Haupttunnel, den AKS verwendet, ist Konnectivity, früher bekannt als apiserver-network-proxy. Verifizieren Sie, dass alle Netzwerkregeln den Azure erforderlichen Netzwerkregeln und vollqualifizierten Domänennamen (FQDNs) entsprechen.

Können meine Pods den FQDN des API-Servers anstelle der Cluster-IP-Adresse verwenden?

Ja, Sie können Pods die Anmerkung kubernetes.azure.com/set-kube-service-host-fqdn hinzufügen, um die Variable KUBERNETES_SERVICE_HOST auf den Domänennamen des API-Servers anstelle der IP-Adresse des Clusterdiensts festzulegen. Diese Änderung ist in Fällen nützlich, in denen der Egress Ihres Clusters über eine Layer 7 Firewall erfolgt. Zum Beispiel, wenn Sie Azure Firewall mit Anwendungsregeln verwenden.

Kann ich Netzwerksicherheitsgruppen mit AKS konfigurieren?

AKS wendet keine Netzwerksicherheitsgruppen (NSGs) auf sein Subnetz an und ändert keine der NSGs, die diesem Subnetz zugeordnet sind. AKS modifiziert nur die Einstellungen der Netzwerkschnittstelle NSG. Wenn Sie Container Network Interface (CNI) verwenden, müssen Sie außerdem sicherstellen, dass die Sicherheitsregeln in den NSGs die Möglichkeit bieten, den Datenverkehr zwischen dem Knoten und dem Pod über Classless Interdomain Routing (CIDR) Bereiche zu leiten. Wenn Sie Kubenet verwenden, müssen Sie außerdem sicherstellen, dass die Sicherheitsregeln in den NSGs dem Datenverkehr zwischen dem Knoten und dem Pod CIDR die Möglichkeit bieten. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Wie funktioniert die Zeitsynchronisierung in AKS?

AKS-Knoten führen den Dienst chrony aus, der die Zeit vom lokalen Host zieht. Container, die auf Pods ausgeführt werden, erhalten die Zeit von den AKS-Knoten. Anwendungen, die innerhalb eines Containers geöffnet werden, verwenden die Zeit aus dem Container des Pods.

Add-ons, Erweiterungen und Integrationen

Kann ich benutzerdefinierte VM-Erweiterungen verwenden?

Nein. AKS ist ein verwalteter Dienst. Die Manipulation von Infrastructure-as-a-Service (IaaS)-Ressourcen wird nicht unterstützt. Nutzen Sie die Kubernetes-APIs und -Mechanismen zum Installieren benutzerdefinierter Komponenten. Verwenden Sie zum Beispiel DaemonSets, um alle erforderlichen Komponenten zu installieren.

Welche Kubernetes-Zugangssteuerungen werden von AKS unterstützt? Können Zulassungscontroller hinzugefügt oder entfernt werden?

AKS unterstützt die folgenden Zugangssteuerungen:

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultIngressClass
  • DefaultStorageClass
  • DefaultTolerationSeconds
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook
  • ResourceQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • ExtendedResourceToleration

Derzeit können Sie die Liste der Zugriffssteuerungen in AKS nicht ändern.

Kann ich in AKS Zugangscontrollerwebhooks verwenden?

Ja, Sie können Zugangscontrollerwebhooks in AKS verwenden. Wir empfehlen Ihnen, interne AKS Namespaces, die mit der Bezeichnung control-plane gekennzeichnet sind, auszuschließen. Beispiel:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS stellt eine Firewall für den API-Server zur Verfügung, so dass die Webhooks Ihres Admission Controllers von innerhalb des Clusters zugänglich sein müssen.

Können Webhooks der Zulassungssteuerung kube-system und interne AKS-Namespaces beeinflussen?

Um die Stabilität des Systems zu schützen und zu verhindern, dass angepasste Zulassungscontroller interne Dienste im kube-system Namespace beeinträchtigen, verfügt AKS über einen Zulassungserzwinger, der kube-system und AKS-interne Namespaces automatisch ausschließt. Dieser Dienst stellt sicher, dass die angepassten Zulassungscontroller keine Auswirkungen auf die Dienste haben, die in kube-system ausgeführt werden.

Wenn Sie einen kritischen Anwendungsfall für die Bereitstellung von etwas auf kube-system (nicht empfohlen) zur Unterstützung Ihres angepassten Webhooks haben, können Sie die folgende Bezeichnung oder Annotation hinzufügen, damit der Admissions Enforcer sie ignoriert:

  • Bezeichnung: "admissions.enforcer/disabled": "true"
  • Annotation: "admissions.enforcer/disabled": true

Ist Azure Key Vault in AKS integriert?

Der Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber ermöglicht die native Integration von Azure Key Vault in AKS.

Kann ich kryptografische FIPS-Bibliotheken bei Bereitstellungen in AKS verwenden?

Knoten, die mit Federal Information Processing Standards (FIPS) aktiviert sind, werden jetzt auf Linux-basierten Knoten-Pools unterstützt. Weitere Informationen finden Sie unter Hinzufügen eines FIPS-fähigen Knotenpools.

Wie werden AKS-Add-ons aktualisiert?

Alle Patches, einschließlich ein Sicherheitspatch, werden automatisch auf den AKS-Cluster angewendet. Alles, was über einen Patch hinausgeht, wie größere oder kleinere Versionsänderungen (die fehlerhafte Änderungen an Ihren bereitgestellten Objekten zur Folge haben können), wird bei der Aktualisierung Ihres Clusters aktualisiert, wenn eine neue Version verfügbar ist. Informationen darüber, wann eine neue Version verfügbar ist, finden Sie unter AKS Versionshinweise.

Wozu dient die AKS-Linux-Erweiterung, die ich auf den Instanzen meiner virtuellen Maschine mit Linux-Scale-Sets installiert sehe?

Die AKS Linux-Erweiterung ist eine Azure VM-Erweiterung, die Überwachungstools auf Kubernetes Worker-Knoten installiert und konfiguriert. Die Erweiterung ist auf allen neuen und vorhandenen Linux-Knoten installiert. Sie konfiguriert die folgenden Überwachungstools:

  • Node-exporter: Sammelt Hardware-Telemetrie von der VM und stellt sie über einen Metriken-Endpunkt zur Verfügung. Anschließend kann ein Monitoring Tool, wie z. B. Prometheus, diese Metriken auswerten.
  • Knotenproblemerkennung: Zielt darauf ab, verschiedene Knotenprobleme für Upstream-Ebenen im Clusterverwaltungsstapel sichtbar zu machen. Es handelt sich um eine systemd-Einheit, die auf jedem Knoten ausgeführt wird, Knotenprobleme erkennt und diese mit Hilfe von Events und NodeConditions an den API-Server des Clusters liefert.
  • ig: Ist ein eBPF-gestütztes Open-Source Framework zum Debuggen und Beobachten von Linux- und Kubernetes-Systemen. Es legt ein Set von Tools (oder Gadgets) fest, die relevante Informationen sammeln, mit denen die Benutzer die Ursache von Leistungsproblemen, Abstürzen oder anderen Anomalien ermitteln können. Dank seiner Unabhängigkeit von Kubernetes können Benutzer*innen es auch zur Fehlersuche bei Problemen auf der Steuerungsebene einsetzen.

Diese Tools helfen bei der Beobachtung vieler Probleme im Zusammenhang mit dem Zustand von Knoten, wie z. B.:

  • Infrastruktur-Daemon-Probleme: NTP-Dienst ausgefallen
  • Hardware-Probleme: Schlechte CPU, Speicher oder Datenträger
  • Kernel-Probleme: Kernel Deadlock, fehlerhaftes Dateisystem
  • Probleme mit der Laufzeit von Containern: Nicht reagierender Runtime-Daemon

Die Erweiterung erfordert keinen zusätzlichen ausgehenden Zugriff auf irgendwelche URLs, IP-Adressen oder Ports, der über die dokumentierten AKS-Egress-Anforderungen hinausgeht. Es sind keine besonderen in Azure erteilten Berechtigungen erforderlich. Sie verwendet kubeconfig zur Verbindung mit dem API-Server, um die gesammelten Überwachungsdaten zu senden.

Behandeln von Clusterproblemen

Warum dauert es so lange, meinen Cluster zu löschen?

Die meisten Cluster werden auf Benutzeranforderung gelöscht. In einigen Fällen, insbesondere wenn Sie Ihre eigene Ressourcengruppe mitbringen oder ressourcengruppenübergreifende Aufgaben durchführen, kann das Löschen mehr Zeit in Anspruch nehmen oder sogar fehlschlagen. Wenn Sie ein Problem mit Löschungen haben, überprüfen Sie, ob die Ressourcengruppe nicht gesperrt ist. Vergewissern Sie sich auch, dass alle Ressourcen außerhalb der Ressourcengruppe von der Ressourcengruppe abgekoppelt sind.

Warum dauert es so lange, meinen Cluster zu erstellen oder zu aktualisieren?

Wenn Sie Probleme beim Erstellen und Aktualisieren von Clustern haben, stellen Sie sicher, dass Sie keine zugewiesenen Richtlinien oder Service-Beschränkungen haben, die Ihren AKS-Cluster bei der Verwaltung von Ressourcen wie VMs, Load-Balancern oder Tags blockieren könnten.

Wenn ich Pods oder Bereitstellungen im Status „NodeLost“ oder „Unknown“ habe, kann ich dann trotzdem ein Upgrade meines Clusters durchführen?

Das können Sie, aber wir raten davon ab. Führen Sie Aktualisierungen durch, wenn der Status des Clusters bekannt und intakt ist.

Kann ich ein Upgrade durchführen, wenn sich ein Cluster mit einem oder mehreren Knoten in einem fehlerhaften Status befindet oder wenn er heruntergefahren ist?

Nein. Löschen oder entfernen Sie alle Knoten, die sich in einem ausgefallenen Status befinden oder anderweitig aus dem Cluster, bevor Sie ein Upgrade durchführen.

Ich habe versucht, meinen Cluster zu löschen, aber ich erhalte die Fehlermeldung „[Errno 11001] getaddrinfo failed.“

In den meisten Fällen tritt dieser Fehler auf, wenn Sie einen oder mehrere NSGs verwenden, die noch mit dem Cluster verbunden sind. Entfernen Sie diese und versuchen Sie erneut, den Cluster zu löschen.

Ich habe ein Upgrade ausgeführt, aber jetzt befinden sich meine Pods in Absturzschleifen und Readiness Probes schlagen fehl.

Stellen Sie sicher, dass Ihr Dienstprinzipal nicht abgelaufen ist. Weitere Informationen finden Sie unter AKS Dienstprinzipal und AKS Anmeldeinformationen aktualisieren.

Mein Cluster hat funktioniert, aber plötzlich kann ich weder Load-Balancer bereitstellen noch Ansprüche auf persistente Volumes mounten.

Stellen Sie sicher, dass Ihr Dienstprinzipal nicht abgelaufen ist. Weitere Informationen finden Sie unter AKS Dienstprinzipal und AKS Anmeldeinformationen aktualisieren.

Abschaffungen und Abschaffungen außer Betrieb nehmen

Welche Linux-Betriebssystemversionen sind auf AKS veraltet?

Ubuntu 16.04 und Ubuntu 18.04 werden auf AKS nicht mehr unterstützt. Ab dem 17. März 2027 unterstützt AKS Ubuntu 20.04 nicht mehr. Weitere Informationen zu dieser Einstellung finden Sie unter Retirement: Ubuntu 20.04 node pools on AKS.

Welche Windows-Betriebssystemversionen sind auf AKS veraltet?

Ab dem 1. März 2026 unterstützt AKS keine Windows Server 2019-Knotenpools mehr. Kubernetes-Versionen 1.33+ können Windows Server 2019 nicht verwenden. Weitere Informationen zu dieser Ablösung finden Sie unter Ablösung: Windows Server 2019-Knotenpools auf AKS. Ab dem 15. März 2027 unterstützt AKS keine Windows Server 2022-Knotenpools mehr. Kubernetes-Versionen 1.36+ können Windows Server 2022 nicht verwenden. Weitere Informationen zu dieser Außerbetriebnahme finden Sie unter Außerbetriebnahme: Windows Server 2022-Knotenpools auf AKS.