Behandeln von Problemen mit Kubernetes-Verwaltung und Workloadclustern 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, aber nicht aus CloudAgent entfernt wurde, wird der Fehler "Datei nicht gefunden" angezeigt, wenn Sie die VHD zum Erstellen eines neuen Knotens verwenden. Dieses Problem tritt auf, weil 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 erneut 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 Zippen einer Datei, "Compress-Archive", eine Begrenzung der Ausgabedateigröße 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 die status einer AKS Arc-Installation in Windows Admin Center zu überprüfen, zeigt die Ausgabe einen Fehler an: "Ein Release 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.

Um dieses Problem zu beheben, führen Sie Uninstall-AksHciaus, und führen Sie dann einen neuen AKS Arc-Build aus.

Wenn Sie das Clusterverwaltungstool verwenden, um eine VM von einem Knoten (Knoten A) auf einen anderen Knoten (Knoten B) im Azure Stack HCI-Cluster zu verschieben, kann die VM möglicherweise nicht auf dem neuen Knoten 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 verwenden, um einen Cluster mit statischen IP-Adressen zu erstellen und dann versuchen, die Anzahl der Workerknoten im Workloadcluster zu erhöhen, bleibt die Installation bei "Anzahl der Steuerungsebenen bei 2, wartet immer noch auf den gewünschten Zustand: 3". Nach einem bestimmten Zeitraum wird eine weitere Fehlermeldung angezeigt: "Fehler: Timedout wartet auf die Bedingung."

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, Update-AksHciClusterCertificatesund alle Interaktionen mit dem Verwaltungscluster können "Fehler: Sie müssen beim Server angemeldet sein (nicht autorisiert)" zurückgeben.

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 in diesem Skript ein Datum angezeigt wird, das vor dem aktuellen Datum liegt, ist die kubeconfig-Datei abgelaufen.

Um das Problem zu beheben, kopieren Sie die Datei admin.conf , die sich innerhalb der VERWALTUNGSsteuerungsebene befindet, auf den HCI-Host:

• SSH zur VM der Verwaltungssteuerungsebene:

  • Rufen Sie die IP-Adresse der VM-Verwaltungssteuerungsebene ab:

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

  • SSH in ihn ein:

    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
  

• Gewähren Des Zugriffs auf clouduser:

  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 länger als 60 Tage nicht verwenden, laufen die Zertifikate ab, und Sie müssen sie verlängern, bevor Sie ein Upgrade von AKS Arc durchführen können. Wenn ein AKS-Cluster nicht innerhalb von 60 Tagen 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 mehr als 60 Tage dauert, müssen Sie den Microsoft-Support anrufen, um ein Upgrade durchzuführen. Wenn der Cluster nach diesem Zeitraum neu gestartet wird, bleibt er in einem nicht funktionalen Zustand.

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

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

Der Workloadcluster wird möglicherweise nicht gefunden, wenn die IP-Adresspools von zwei AKS-Instanzen auf Azure Stack HCI-Bereitstellungen identisch sind oder sich ü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.

Bei der Bereitstellung eines großen Clusters kann nach zwei Stunden ein Timeout auftreten. Dies ist jedoch ein statisches Timeout.

Sie können dieses Timeoutereignis 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 Bereitstellung von AKS in Azure Stack HCI nach einigen Tagen zu aktivieren, wurden von Kubectl keine 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 in Azure Stack HCI mindestens 60 Tage lang nicht aktualisiert wurde, wird das KMS-Plug-In bei einem Neustartversuch nicht gestartet. 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 in Azure Stack HCI-Installation mit Version 1.82.0 der Windows Admin Center-Erweiterung wurde der Verwaltungscluster mithilfe von PowerShell eingerichtet, und es wurde versucht, einen Workloadcluster mithilfe von 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. Der Versuch, den Workloadcluster bereitzustellen, ist mit der Fehlermeldung "Ein Parameter wurde nicht gefunden, der dem Parameternamen 'nodePoolName' entspricht" fehlgeschlagen. Dieser Fehler ist möglicherweise aufgrund eines Versionskonflikts aufgetreten. In der PowerShell-Version 1.1.0 wurde der Parameter -nodePoolName <String> dem Cmdlet -nodePoolName <String> 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 in Azure Stack HCI 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 einen hohen Arbeitsspeicherbedarf aufweist. 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, weil die Richtlinie bei Implementierung im AKS-Hostverwaltungscluster 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 Policy-Erweiterung auf dem AKS-Hostverwaltungscluster. Weitere Informationen zum Deinstallieren Azure Policy Erweiterungen finden Sie hier.
• Ändern Sie den Bereich der Azure Policy so, dass AKS-Hostverwaltungscluster ausgeschlossen werden. Weitere Informationen zu Azure Policy Bereichen finden Sie hier.
• Legen Sie den Richtlinienerzwingungsmodus für den AKS-Hostverwaltungscluster auf "Deaktiviert" fest. Weitere Informationen zum Erzwingungsmodus finden Sie hier.

Das ist ein bekanntes Problem mit dem Juli Update auf AKS in Azure Stack HCI (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-Version in Azure Stack HCI durchführen.

Wenn Sie einen AKS-Cluster in Azure Stack HCI mit null Linux- oder Windows-Knoten bereitstellen, ist die Ausgabe beim Ausführen von Get-AksHciCluster eine leere Zeichenfolge oder ein NULL-Wert.

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.

Dieses Problem ist bekannt. Nach einem Neustart können virtuelle Computer manchmal nicht mehr als hochverfügbar konfiguriert werden. Die aktuelle Problemumgehung besteht im Neustart von wssdagent auf jedem Azure Stack HCI-Knoten. Dies funktioniert nur für neue VMs, die durch das Erstellen von Knotenpools beim Ausführen eines Horizontalskalierungsvorgangs oder beim Erstellen neuer Kubernetes-Cluster nach dem Neustart von wssdagent auf den Knoten generiert werden. Sie müssen die vorhandenen virtuellen Computer jedoch manuell zum Failovercluster hinzufügen.

Wenn Sie einen Cluster herunterskalieren, befinden sich die Hochverfügbarkeitsclusterressourcen in einem fehlerbehafteten Zustand, während die VMs entfernt werden. Die Problemumgehung für dieses Problem besteht im manuellen Entfernen der fehlerhaften Ressourcen.

Ein auf einer Azure-VM bereitgestellter AKS-Cluster funktionierte zuvor einwandfrei, aber nachdem der AKS-Host mehrere Tage 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) im ContainerCreating-Zustand hängen. Beim Versuch, eine Verbindung mit diesem Knoten mithilfe von SSH herzustellen, schlägt die Verbindung mit einem Fehler fehl Connection timed out .

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 werden, wobei alle Pods ausgeführt werden.

Wenn Kubelet unter Datenträgerdruck steht, werden nicht verwendete Containerimages erfasst, die möglicherweise Pausenimages enthalten können, und wenn dies geschieht, kann ContainerD das Image nicht pullen.

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

1. Stellen Sie mithilfe von SSH eine Verbindung mit dem betroffenen Knoten 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