Behandeln von Kubernetes-Verwaltungs- und Workloadclusterproblemen in AKS Arc

Wenn Sie den Befehl Remove-ClusterNode ausführen, wird der Knoten aus dem Failovercluster entfernt. Ohne anschließendes Ausführen von Remove-AksHciNode ist der Knoten allerdings weiterhin im Cloud-Agent vorhanden.

Da der Knoten aus dem Cluster entfernt wurde, aber nicht aus CloudAgent, wird ein Fehler "Datei nicht gefunden" angezeigt, wenn Sie die VHD zum Erstellen eines neuen Knotens verwenden. Dieses Problem tritt auf, da sich die VHD im freigegebenen Speicher befindet und der entfernte Knoten keinen Zugriff darauf hat.

Um dieses Problem zu beheben, entfernen Sie einen physischen Knoten aus dem Cluster, und führen Sie dann die folgenden Schritte aus:

1. Führen Sie Remove-AksHciNode aus, um die Registrierung des Knotens im Cloud-Agent zu aufzuheben.
2. Führen Sie routinemäßige Wartungsmaßnahmen durch – etwa ein Reimaging des Computers.
3. Fügen Sie den Knoten wieder zum Cluster hinzu.
4. Führen Sie Add-AksHciNode aus, um den Knoten beim Cloud-Agent zu registrieren.

Bei großen Clustern kann der Befehl Get-AksHciLogs eine Ausnahme auslösen, bei der Enumeration von Knoten zu einem Fehler führen oder die Ausgabedatei „c:\wssd\wssdlogs.zip“ nicht generieren.

Dies liegt daran, dass der PowerShell-Befehl zum Komprimieren einer Datei , "Compress-Archive", einen Grenzwert für die Ausgabedatei von 2 GB aufweist.

Nach dem Upgrade oder Hochskalieren des Workloadclusters befindet sich der Zertifikaterneuerungspod nun in einem Absturzschleifenzustand, da der Pod die YAML-Datei mit dem Zertifikat-Tattoo vom Dateispeicherort /etc/Kubernetes/pki erwartet.

Dieses Problem kann an einer Konfigurationsdatei liegen, die auf den VMs der Steuerungsebene, aber nicht auf den Workerknoten-VMs vorhanden ist.

Um dieses Problem zu beheben, kopieren Sie die YAML-Datei mit dem Zertifikat-Tattoo manuell vom Knoten der Steuerungsebene auf alle Workerknoten.

1. Kopieren Sie die YAML-Datei von der Steuerungsebenen-VM im Workloadcluster in das aktuelle Verzeichnis Ihres Hostcomputers:

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Kopieren Sie die YAML-Datei vom Hostcomputer auf die Workerknoten-VM. Bevor Sie die Datei kopieren, müssen Sie den Namen des Computers in der YAML-Datei in den Knotennamen ändern, auf den Sie kopieren möchten (dies ist der Knotenname für die Steuerungsebene des Workloadclusters).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Wenn die Besitzer- und Gruppeninformationen in der YAML-Datei noch nicht auf das Stammverzeichnis (root) festgelegt sind, legen Sie die Informationen auf das Stammverzeichnis fest:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Wiederholen Sie die Schritte 2 und 3 für alle Workerknoten.

Die Aks-Hci-PowerShell-Befehle überprüfen vor dem Erstellen von Kubernetes-Knoten nicht den verfügbaren Arbeitsspeicher auf dem Hostserver. Dieses Problem kann dazu führen, dass der Speicher ausgelastet ist und virtuelle Computer nicht starten.

Dieser Fehler wird derzeit nicht angemessen behandelt, und die Bereitstellung reagiert nicht mehr, ohne dass eine eindeutige Fehlermeldung angezeigt wird. Wenn Ihre Bereitstellung nicht mehr reagiert, öffnen Sie die Ereignisanzeige, und suchen Sie nach Hyper-V-bezogenen Fehlermeldungen, die darauf hinweist, dass nicht genügend Arbeitsspeicher zum Starten der VM vorhanden ist.

Wenn Sie Get-AksHciCluster ausführen, um den Status einer AKS Arc-Installation in Windows Admin Center zu überprüfen, zeigt die Ausgabe einen Fehler an: "Eine Version mit Version 1.0.3.10818 wurde NICHT GEFUNDEN." Beim Ausführen von Get-AksHciVersion wurde jedoch die gleiche Version installiert. Dieser Fehler gibt an, dass der Build abgelaufen ist.

Führen Sie Uninstall-AksHcizum Beheben dieses Problems einen neuen AKS Arc-Build aus, und führen Sie dann einen neuen AKS Arc-Build aus.

Wenn Sie das Clusterverwaltungstool verwenden, um einen virtuellen Computer von einem Knoten (Knoten A) in einen anderen Knoten (Knoten B) im lokalen Azure-Cluster zu verschieben, kann der virtuelle Computer auf dem neuen Knoten nicht gestartet werden. Die VM kann auch nicht gestartet werden, nachdem sie wieder auf den ursprünglichen Knoten verschoben wurde.

Dieses Problem tritt auf, da die Logik zur Bereinigung der ersten Migration asynchron ausgeführt wird. Infolgedessen findet die Logik „VM-Standort aktualisieren“ von Azure Kubernetes Service die VM auf dem ursprünglichen Hyper-V auf Knoten A und löscht sie, anstatt die Registrierung aufzuheben.

Um dieses Problem zu umgehen, müssen Sie sicherstellen, dass der virtuelle Computer erfolgreich auf dem neuen Knoten gestartet wurde, bevor Sie ihn wieder zurück auf den ursprünglichen Knoten verschieben.

Wenn Sie PowerShell zum Erstellen eines Clusters mit statischen IP-Adressen verwenden und dann versuchen, die Anzahl der Arbeitsknoten im Workloadcluster zu erhöhen, bleibt die Installation bei "Anzahl der Steuerungsebenen bei 2, wartet weiterhin auf den gewünschten Zustand: 3". Nach einem bestimmten Zeitraum wird eine weitere Fehlermeldung angezeigt: "Fehler: Timed out waiting for the condition."

Beim Ausführen von Get-AksHciCluster wurde angezeigt, dass die Knoten der Steuerungsebene erstellt und bereitgestellt worden waren und sich im Zustand Bereit befanden. Wenn jedoch kubectl get nodes ausgeführt wurde, wurde angezeigt, dass die Knoten der Steuerungsebene erstellt, aber nicht bereitgestellt worden waren und sich nicht im Zustand Bereit befanden.

Wenn dieser Fehler angezeigt wird, überprüfen Sie, ob die IP-Adressen den erstellten Knoten mithilfe von Hyper-V-Manager oder PowerShell zugewiesen wurden:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Überprüfen Sie dann die Netzwerkeinstellungen, um sicherzustellen, dass genügend IP-Adressen im Pool vorhanden sind, um weitere VMs zu erstellen.

Befehle wie Update-AksHci, Update-AksHciCertificates, und Update-AksHciClusterCertificatesalle Interaktionen mit dem Verwaltungscluster können "Fehler zurückgeben: Sie müssen beim Server angemeldet sein (nicht autorisiert)."

Dieser Fehler kann auftreten, wenn die Kubeconfig-Datei abgelaufen ist. Führen Sie das folgende Skript aus, um zu überprüfen, ob es abgelaufen ist:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Wenn dieses Skript ein Datum anzeigt, das vor dem aktuellen Datum liegt, ist die Kubeconfig-Datei abgelaufen.

Um das Problem zu beheben, kopieren Sie die Datei "admin.conf ", die sich in der Verwaltungssteuerungsebene befindet, auf den lokalen Azure-Host:

• SSH zur Verwaltungssteuerungsebene VM:

  • Abrufen der VM-IP der Verwaltungssteuerungsebene:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • SSH in ihr:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Kopieren Sie die Datei an den Speicherort des Cloudbenutzers :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Zugriff auf Cloudbenutzer gewähren:

  sudo chown clouduser:clouduser admin.conf
  

• [Optional] Erstellen Sie eine Sicherung der Kubeconfig-Datei :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Kopieren Sie die Datei:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Wenn Sie den Hyper-V-Manager überprüfen, können hohe CPU- und Arbeitsspeicheranforderungen für den Verwaltungscluster problemlos ignoriert werden. Sie beziehen sich auf Spitzen der Computeressourcennutzung beim Bereitstellen von Workloadclustern.

Das Erhöhen der Arbeitsspeicher- oder CPU-Größe für den Verwaltungscluster hat keine bedeutende Verbesserung gezeigt und kann problemlos ignoriert werden.

Sie sehen dieses Problem, wenn Sie die folgenden Schritte ausführen:

1. Erstellen Sie einen Kubernetes-Cluster.
2. Skalieren Sie den Cluster auf mehr als zwei Knoten.
3. Löschen Sie einen Knoten, indem Sie den folgenden Befehl ausführen:

kubectl delete node <node-name>

4. Geben Sie eine Liste der Knoten zurück, indem Sie den folgenden Befehl ausführen:

kubectl get nodes

Der entfernte Knoten ist in der Ausgabe nicht aufgeführt. 5. Öffnen Sie ein PowerShell-Fenster mit Administratorrechten, und führen Sie den folgenden Befehl aus:

get-vm

Der entfernte Knoten ist weiterhin aufgeführt.

Dieser Fehler führt dazu, dass das System nicht erkennt, dass der Knoten fehlt, und daher wird kein neuer Knoten hochgefahren.

Wenn Sie einen Verwaltungs- oder Workloadcluster nicht länger als 60 Tage verwenden, laufen die Zertifikate ab, und Sie müssen sie verlängern, bevor Sie AKS Arc aktualisieren können. Wenn ein AKS-Cluster innerhalb von 60 Tagen nicht aktualisiert wird, laufen das KMS-Plug-In-Token und die Zertifikate innerhalb der 60 Tage ab. Der Cluster ist weiterhin funktionsfähig. Da es jedoch über 60 Tage hinausgeht, müssen Sie den Microsoft-Support anrufen, um ein Upgrade durchzuführen. Wenn der Cluster nach diesem Zeitraum neu gestartet wird, verbleibt er in einem nicht funktionsfähigen Zustand.

Führen Sie zum Beheben dieses Problems die folgende Schritte aus:

1. Reparieren Sie das Verwaltungsclusterzertifikat, indem Sie das Token manuell drehen und dann das KMS-Plug-In und den Container neu starten.
2. Reparieren Sie die mocctl-Zertifikate, indem Sie Repair-MocLogin ausführen.
3. Reparieren Sie die Workloadclusterzertifikate, indem Sie das Token manuell drehen und dann das KMS-Plug-In und den Container neu starten.

Der Workloadcluster kann nicht gefunden werden, wenn die IP-Adresspools von zwei AKS in lokalen Azure-Bereitstellungen identisch oder überlappen. Wenn Sie zwei AKS-Hosts bereitstellen und für beide dieselbe AksHciNetworkSetting-Konfiguration verwenden, können PowerShell und Windows Admin Center den Workload-cluster möglicherweise nicht finden, da dem API-Server in beiden Clustern dieselbe IP-Adresse zugewiesen wird, was zu einem Konflikt führt.

Die Fehlermeldung, die Sie erhalten, ähnelt dem unten gezeigten Beispiel.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

Die Bereitstellung eines großen Clusters kann nach zwei Stunden ausfallen. Dies ist jedoch ein statisches Timeout.

Sie können dieses Timeout-Vorkommen ignorieren, da der Vorgang im Hintergrund ausgeführt wird. Verwenden Sie den Befehl kubectl get nodes, um auf Ihren Cluster zuzugreifen und den Status zu überwachen.

Beim Versuch, eine AKS in der lokalen Azure-Bereitstellung nach ein paar Tagen aufzuführen, Kubectl wurden keine der Befehle ausgeführt. Im Plug-In-Protokoll des Schlüsselverwaltungsdiensts (KMS) wurde die Fehlermeldung rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates angezeigt.

Das Cmdlet Repair-AksHciClusterCerts schlägt fehl, wenn der API-Server ausgefallen ist. Wenn AKS auf Azure Local seit 60 oder mehr Tagen nicht aktualisiert wurde, wird das KMS-Plug-In nicht gestartet, wenn Sie versuchen, das KMS-Plug-In neu zu starten. Dieser Fehler führt auch zu einem Ausfall des API-Servers.

Um dieses Problem zu beheben, müssen Sie das Token manuell rotieren und dann das KMS-Plug-In und den Container neu starten, um die API-Serversicherung abzurufen. Führen Sie zu diesem Zweck die folgenden Schritte aus:

1. Rotieren Sie das Token, indem Sie den folgenden Befehl ausführen:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Kopieren Sie das Token mithilfe des folgenden Befehls auf den virtuellen Computer. Die Einstellung ip im folgenden Befehl bezieht sich auf die IP-Adresse der Steuerungsebene des AKS-Hosts.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Starten Sie das KMS-Plug-In und den Container neu.

   Führen Sie zum Abrufen der Container-ID den folgenden Befehl aus:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   Die Ausgabe sollte die folgenden Felder enthalten:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Starten Sie den Container abschließend mithilfe des folgenden Befehls neu:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

Bei einer AKS auf der lokalen Azure-Installation mit der Windows Admin Center-Erweiterung Version 1.82.0 wurde der Verwaltungscluster mit PowerShell eingerichtet, und es wurde versucht, einen Workloadcluster mit Windows Admin Center bereitzustellen. Auf einem der Computer war Version 1.0.2 des PowerShell-Moduls installiert, auf anderen Computern das PowerShell-Modul 1.1.3. Fehler beim Bereitstellen des Workloadclusters mit dem Fehler "Ein Parameter kann nicht gefunden werden, der dem Parameternamen 'nodePoolName' entspricht.". Dieser Fehler ist möglicherweise aufgrund eines Versionskonflikts aufgetreten. In der PowerShell-Version 1.1.0 wurde der Parameter -nodePoolName <String> dem Cmdlet New-AksHciCluster hinzugefügt. Entwurfsbedingt ist dieser Parameter nun bei der Verwendung der Windows Admin Center-Erweiterungsversion 1.82.0 erforderlich.

Führen Sie Lösen dieses Problems eine der folgenden Aktionen aus:

• Verwenden Sie PowerShell, um den Workloadcluster manuell auf Version 1.1.0 oder eine höhere Version zu aktualisieren.
• Verwenden Sie Windows Admin Center, um den Cluster auf Version 1.1.0 oder auf die neueste PowerShell-Version zu aktualisieren.

Dieses Problem tritt nicht auf, wenn der Verwaltungscluster mithilfe von Windows Admin Center bereitgestellt wird, da in diesem Fall bereits die neuesten PowerShell-Module installiert sind.

Wenn Sie AKS auf Azure Local bereitstellen und dann ausführen kubectl get pods, bleiben Pods im selben Knoten im Zustand "Beenden" hängen. Der Computer lehnt SSH-Verbindungen ab, da der Knoten wahrscheinlich eine hohe Speichernachfrage hat. Dieses Problem ist auf eine Überbereitstellung der Windows-Knoten sowie auf eine mangelnde Reserve für Kernkomponenten zurückzuführen.

Fügen Sie zur Vermeidung dieser Situation die Ressourcenlimits und Ressourcenanforderungen für CPU und Arbeitsspeicher der Podspezifikation hinzu, um eine Überbereitstellung der Knoten zu vermeiden. Von Windows-Knoten wird das Entfernen auf der Grundlage von Ressourcenlimits nicht unterstützt. Daher müssen Sie den Bedarf der Container schätzen und dann sicherstellen, dass die Knoten über eine ausreichende Anzahl von CPUs und genügend Arbeitsspeicher verfügen. Weitere Informationen finden Sie in den Systemanforderungen.

Die automatische Clusterskalierung kann fehlschlagen, wenn Sie die folgende Azure-Richtlinie für Ihren AKS-Hostverwaltungscluster verwenden: "Kubernetes-Cluster sollten nicht den Standardnamespace verwenden." Dies geschieht, da die Richtlinie, wenn sie im AKS-Hostverwaltungscluster implementiert wird, die Erstellung von AutoScaler-Profilen im Standardnamespace blockiert. Um dieses Problem zu beheben, wählen Sie eine der folgenden Optionen aus:

• Deinstallieren Sie die Azure-Richtlinienerweiterung im AKS-Hostverwaltungscluster. Weitere Informationen zum Deinstallieren von Azure-Richtlinienerweiterungen finden Sie hier.
• Ändern Sie den Umfang der Azure-Richtlinie, um AKS-Hostverwaltungscluster auszuschließen. Weitere Informationen zu Azure-Richtlinienbereichen finden Sie hier.
• Legen Sie den Richtlinienerzwingungsmodus für den AKS-Hostverwaltungscluster auf "Deaktiviert" fest. Erfahren Sie hier mehr über den Erzwingungsmodus.

Dies ist ein bekanntes Problem mit dem AKS im lokalen Azure July Update (Version 1.0.2.10723). Der Fehler tritt auf, weil der CloudAgent-Dienst während der Verteilung virtueller Computer auf mehrere gemeinsam genutzte Clustervolumes im System ein Timeout verursacht.

Um dieses Problem zu beheben, sollten Sie ein Upgrade auf die neueste AKS in Azure Local Release durchführen.

Wenn Sie einen AKS-Cluster auf Azure Local mit null Linux- oder Windows-Knoten bereitstellen, ist die Ausgabe beim Ausführen von Get-AksHciCluster eine leere Zeichenfolge oder ein Nullwert.

Null ist eine erwartete Rückgabe für Nullknoten.

Wenn Sie einen Verwaltungs- oder Workloadcluster für länger als vier Tage herunterfahren, laufen die Zertifikate ab, und der Cluster ist nicht erreichbar. Die Zertifikate laufen ab, da sie aus Sicherheitsgründen alle drei bis vier Tage rotiert werden.

Um den Cluster neu zu starten, müssen Sie die Zertifikate manuell reparieren, bevor Sie Clustervorgänge ausführen können. Um die Zertifikate zu reparieren, führen Sie den folgenden Repair-AksHciClusterCerts-Befehl aus:

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Beim Aufskalieren eines Workloadclusters wurden die entsprechenden virtuellen Linux- und Windows-Computer als Workerknoten hinzugefügt, aber nicht als hochverfügbare virtuelle Computer konfiguriert. Beim Ausführen des Befehls Get-ClusterGroup wurde der neu erstellte virtuelle Linux-Computer nicht als Clustergruppe konfiguriert.

Dies ist ein bekanntes Problem. Nach einem Neustart können virtuelle Computer manchmal nicht mehr als hochverfügbar konfiguriert werden. Die aktuelle Problemumgehung besteht darin, auf jedem der lokalen Azure-Knoten neu zu starten wssdagent . Dies funktioniert nur für neue VMs, die durch Erstellen von Knotenpools beim Ausführen eines Skalierungsvorgangs oder beim Erstellen neuer Kubernetes-Cluster nach dem Neustart der wssdagent Knoten generiert werden. Sie müssen die vorhandenen virtuellen Computer jedoch manuell zum Failovercluster hinzufügen.

Wenn Sie einen Cluster herunterskalieren, befinden sich die Clusterressourcen mit hoher Verfügbarkeit in einem fehlerhaften Zustand, während die virtuellen Computer entfernt werden. Die Problemumgehung für dieses Problem besteht im manuellen Entfernen der fehlerhaften Ressourcen.

Ein in einer Azure-VM bereitgestellter AKS-Cluster funktionierte zuvor einwandfrei, aber nachdem der AKS-Host mehrere Tage lang deaktiviert wurde, funktionierte der Kubectl Befehl nicht. Nach Ausführen des Befehls Kubectl get nodes oder Kubectl get services wurde die folgende Fehlermeldung angezeigt: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Dieses Problem ist aufgetreten, weil der AKS-Host länger als vier Tage deaktiviert war. Dadurch sind die Zertifikate abgelaufen. Zertifikate werden häufig in einem Vier-Tage-Zyklus rotiert. Führen Sie Repair-AksHciClusterCerts aus, um das Zertifikatablaufproblem zu beheben.

In einem Workloadcluster mit statischen IP-Adressen und Windows-Knoten bleiben alle Pods in einem Knoten (einschließlich der daemonset Pods) in einem ContainerCreating-Zustand hängen. Beim Versuch, eine Verbindung mit diesem Knoten mithilfe von SSH herzustellen, schlägt die Verbindung mit einem Connection timed out Fehler fehl.

Um dieses Problem zu beheben, verwenden Sie Hyper-V-Manager oder Failovercluster-Manager, um den virtuellen Computer dieses Knotens zu deaktivieren. Nach 5 bis 10 Minuten sollte der Knoten neu erstellt worden sein, wobei alle Pods ausgeführt werden.

Wenn Kubelet unter Datenträgerdruck liegt, sammelt es nicht verwendete Containerimages, die Pausenimages enthalten können, und in diesem Fall kann ContainerD das Image nicht ziehen.

Führen Sie zum Beheben dieses Problems die folgende Schritte aus:

1. Stellen Sie eine Verbindung mit dem betroffenen Knoten mithilfe von SSH her, und führen Sie den folgenden Befehl aus:

sudo su

2. Führen Sie dann den folgenden Befehl aus, um das Image zu pullen:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Nächste Schritte

• Problembehandlung: Übersicht, Feedback und Support
• Netzwerkprobleme und -fehler
• Bekannte Speicherprobleme