Beheben von Problemen beim Upgrade von AKS Arc

Ältere Versionen von PowerShell werden nicht entfernt.

Um dieses Problem zu umgehen, können Sie dieses Skript ausführen, um ältere PowerShell-Versionen zu deinstallieren.

Nach dem Upgrade oder der Up-Scaling des Zielclusters befindet sich der Zertifikaterneuerungs-Pod jetzt in einem Absturzschleifenzustand. Es wird eine yaml-Datei mit einem Zertifikat-Tattoo aus dem Pfad /etc/Kubernetes/pki erwartet. Die Konfigurationsdatei ist in den VMs des Steuerebenenknotens vorhanden, aber nicht auf VMs des Arbeitsknotens.

Um dieses Problem zu beheben, kopieren Sie die Zertifikat-Tattoo-Datei manuell vom Steuerebenenknoten auf jeden der Arbeitsknoten.

1. Kopieren Sie die Datei vom virtuellen Computer der Steuerungsebene 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 works)
   scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
   

2. Kopieren Sie die Datei vom Hostcomputer auf die Workerknoten-VM.

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

3. Legen Sie die Besitzer- und Gruppeninformationen für diese Datei wieder auf „root“ fest, wenn sie nicht bereits auf root festgelegt wurden.

   ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
   sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the cert file to 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 jeden Arbeitsknoten.

Wenn ein Cluster seit mehr als 60 Tagen nicht aktualisiert wurde, kann der Knoten-Agent während eines Knoten-Agent-Neustarts aufgrund des Ablaufs des Tokens nicht gestartet werden. Dieser Fehler bewirkt, dass sich die Agents in der Startphase befindet. Kontinuierliche Versuche, dem Cloudagent beizutreten, können die Bereitstellung von Ports auf dem Host ausschöpfen. Der Status für den folgenden Befehl wird gestartet.

Get-Service wssdagent | Select-Object -Property Name, Status

Erwartetes Verhalten: Der Knoten-Agent sollte sich in der Startphase befinden, die ständig versucht, dem Cloud-Agent beizutreten und die Ports zu erschöpfen.

Um das Problem zu beheben, beenden Sie die Ausführung des wssdagent. Da sich der Dienst in der Startphase befindet, kann er verhindern, dass Sie den Dienst beenden. Wenn ja, beenden Sie den Prozess, bevor Sie versuchen, den Dienst zu beenden.

1. Vergewissern Sie sich, dass sich „wssdagent“ in der Startphase befindet.

   Get-Service wssdagent | Select-Object -Property Name, Status
   

2. Erzwingen Sie die Beendigung des Prozesses mithilfe von „kill“:

   kill -Name wssdagent -Force
   

3. Beenden Sie den Dienst.

   Stop-Service wssdagent -Force
   

Get-Process -Name wssdagent

PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand

1. Wiederholen Sie die Schritte 1, 2 und 3 auf jedem Knoten des lokalen Azure-Clusters, der dieses Problem aufweist.

2. Starten Sie nach der Bestätigung, dass der wssdagent nicht ausgeführt wird, den Cloudagent, wenn er nicht ausgeführt wird.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName

1. Vergewissern Sie sich, dass der Cloudagent aktiv ist.

   Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
   

2. Führen Sie den folgenden Befehl aus, um den wssdagent zu beheben:

   Repair-Moc
   

3. Nach Abschluss dieses Befehls sollte sich „wssdagent“ im Zustand „Wird ausgeführt“ befinden.

   Get-Service wssdagent | Select-Object -Property Name, Status
   

Wenn AKS auf Azure Local von der Mai-Version auf die Juni-Version nicht aktualisiert werden kann, wird erwartet, dass AKS auf Azure Local auf die Mai-Version zurückgesetzt und weiterhin funktioniert. Aber es lässt MOC-Agents in einem angehaltenen Zustand, und manuelle Versuche, den Agent zu starten, aktivieren sie nicht.

Schritte zum Reproduzieren

1. Installieren Sie AKS-HCI PowerShell-Modul, Version 1.1.36.
2. Upgrade von AKS auf Azure Local. Wenn das Upgrade fehlschlägt, fällt AKS auf Azure Local zurück auf Mai, aber MOC-Agents sind nicht mehr vorhanden.

Erwartetes Verhalten

Wenn das AKS bei einem lokalen Azure-Upgrade fehlschlägt, wird erwartet, dass AKS auf Azure Local auf die vorherige Version zurückgesetzt wird und ohne Probleme weiterhin funktioniert.

Problembeschreibung

Konflikt zwischen Aks-Hci-Version und MOC-Version

• Get-AksHciVersion: 1.0.10.10513
• Get-MocVersion: 1.0.11.10707

Konflikt zwischen Get-MocVersion und wssdcloudagent.exe Version

Get-MocVersion gibt an, dass der Juni-Build installiert ist, während die wssdcloudagent.exe Version angibt, dass der Mai-Build installiert ist.

MOC-Agent-Dienste-Imagepfad verfügt über den Bereitstellungs-ID-Parameter

Führen Sie den folgenden Befehl aus, um den Bildpfad für den Cloud-Agent anzuzeigen:

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

Beispielausgabe

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

Verwenden Sie den folgenden Befehl, um den Bildpfad für den Knoten-Agent anzuzeigen: reg query "HKLM\System\CurrentControlSet\Services\wssdagent"

Beispielausgabe

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

Führen Sie die folgenden PowerShell-Cmdlets aus, um das Problem zu beheben:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

Beim Upgrade verlieren Sie möglicherweise alle benutzerdefinierten Taints, Rollen und Bezeichnungen, die Sie Ihren Workerknoten hinzugefügt haben. Da AKS ein verwalteter Dienst ist, wird das Hinzufügen von benutzerdefiniertenTaints, Bezeichnungen und Rollen, wenn sie außerhalb der bereitgestellten PowerShell-Cmdlets oder des Windows Admin Centers ausgeführt werden, nicht unterstützt.

Um dieses Problem zu umgehen, führen Sie das Cmdlet New-AksHciNodePool aus, um für Ihre Workerknoten ordnungsgemäß einen Knotenpool mit Taints zu erstellen.

Wenn Sie einen Verwaltungscluster erstellt haben, aber in den ersten 60 Tagen keinen Workloadcluster bereitgestellt haben, werden Sie daran gehindert, einen Cluster zu erstellen, da es sich jetzt nicht mehr um eine Richtlinie handelt. In dieser Situation wird der Updatevorgang beim Ausführen von Update-AksHci mit der Fehlermeldung blockiert, dass darauf gewartet wird, dass die Bereitstellung der AksHci-Abrechnungsoperators bereit ist. Wenn Sie Sync-AksHciBilling ausführen, wird eine erfolgreiche Ausgabe zurückgegeben. Wenn Sie jedoch Get-AksHciBillingStatus ausführen, lautet der Verbindungsstatus "OutofPolicy".

Wenn Sie innerhalb von 60 Tagen keinen Workloadcluster bereitgestellt haben, ist die Abrechnung nicht mehr richtlinienkonform.

Die einzige Möglichkeit, dieses Problem zu beheben, ist die erneute Bereitstellung mit einer Neuinstallation.

Wenn Azure Local-Knoten nacheinander neu gestartet werden, verlieren einige der virtuellen Computer die an sie angefügten vNICs. Dieser Verlust von vNICs führt dazu, dass die VMs netzwerkkonnektivität verlieren und der Cluster in einen schlechten Zustand fällt.

Schritte zum Reproduzieren

1. Starten Sie einen lokalen Azure-Knoten neu.
2. Warten Sie, bis der Knoten den Neustart abgeschlossen hat. Der Knoten muss im Failovercluster markiert Up werden.
3. Starten Sie die anderen Knoten neu.
4. Repeat.

Erwartetes Verhalten Der Clusterzustand sollte fehlerfrei sein. Alle virtuellen Computer sollten NICs angefügt haben.

Um das Problem zu beheben, verwenden Sie die MOC-Befehle, um die vNIC zur VM hinzuzufügen.

1. Rufen Sie den vNIC-Namen für den virtuellen Computer ab.

(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

or

mocctl.exe compute vm get --name <vmname> --group <group>

2. Verbinden Sie die vNIC mit der VM.

Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

or

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>

3. Wenn der vNIC-Verbindungsbefehl fehlschlägt, versuchen Sie erneut, die Verbindung zu trennen und eine Verbindung herzustellen. Nachfolgend sehen Sie den Befehl für die vNIC-Verbindung.

Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

or

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

Pods bleiben hängen, um auf statische Pods zu warten, um eine fertige Bedingung zu haben.

Um die Pods freizugeben und dieses Problem zu beheben, sollten Sie kubelet neu starten. Führen Sie den folgenden Befehl aus, um den Knoten „NotReady“ mit den statischen Pods anzuzeigen:

kubectl get nodes -o wide

Führen Sie den folgenden Befehl aus, um weitere Informationen zum fehlerhaften Knoten zu erhalten:

kubectl describe node <IP of the node>

Führen Sie den folgenden Befehl aus, um SSH für die Anmeldung beim Knoten „NotReady“ zu verwenden:

ssh -i <path of the private key file> administrator@<IP of the node>

Führen Sie dann den folgenden Befehl aus, um kubelet neu zu starten:

/etc/.../kubelet restart

Beim Ausführen eines Upgrades in Windows Admin Center ist der folgende Fehler aufgetreten:

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

Diese Fehlermeldung tritt in der Regel auf, wenn AKS auf Azure Local in einer Umgebung bereitgestellt wird, die einen Proxy konfiguriert hat. Derzeit bietet Windows Admin Center keine Unterstützung für die Installation von Modulen in einer Proxyumgebung.

Um diesen Fehler zu beheben, richten Sie AKS auf Azure Local mithilfe des Proxy-PowerShell-Befehls ein.

Beim Upgrade von Kubernetes-Clustern mit einem Open Policy Agent (OPA), z. B. OPA GateKeeper, kann der Prozess hängen und nicht abgeschlossen werden. Dieses Problem kann auftreten, weil der Richtlinien-Agent so konfiguriert ist, dass das Pullen von Containerimages aus privaten Registrierungen verhindert wird.

Um dieses Problem beim Upgrade von Clustern, die mit einem OPA bereitgestellt wurden, zu vermeiden, müssen Sie sicherstellen, dass Ihre Richtlinien das Pullen von Images aus Azure Container Registry zulassen. Für ein AKS auf dem lokalen Azure-Upgrade sollten Sie den folgenden Endpunkt in der Liste Ihrer Richtlinie hinzufügen: ecpacr.azurecr.io.

Das Ausführen eines Betriebssystemupdates auf einem Host mit einer AKS auf der lokalen Azure-Bereitstellung kann dazu führen, dass die Bereitstellung in einen fehlerhaften Zustand wechselt und tag zwei Vorgänge fehlschlägt. Die MOC-NodeAgent-Dienste können auf aktualisierten Hosts möglicherweise nicht gestartet werden. Alle MOC-Aufrufe an die Knoten schlagen fehl.

So reproduzieren Sie: Wenn Sie einen Cluster mit einer vorhandenen AKS-Bereitstellung von HCI auf HCIv2 OS aktualisieren, kann ein AKS-Vorgang fehlschlagen New-AksHciCluster . Die Fehlermeldung gibt an, dass die MOC-Knoten OutOfCapacity sind. Zum Beispiel:

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

Um dieses Problem zu beheben, starten Sie den MOC-NodeAgent-Dienst „wssdagent“ auf den betroffenen Knoten. Dadurch wird das Problem behoben, und die Bereitstellung geht wieder in einen fehlerfreien Zustand über. Führen Sie den folgenden Befehl aus:

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

Nach dem Ausführen von Update-AksHciCluster wird der Upgradeprozess angehalten.

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob ein Computer mit PHASE dem Löschen vorhanden ist, auf dem die vorherige Kubernetes-Version ausgeführt wird, von der Sie upgraden.

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

Wenn ein Computer mit PHASE dem Löschen und VERSION Abgleichen der vorherigen Kubernetes-Version vorhanden ist, fahren Sie mit den folgenden Schritten fort.

Um dieses Problem zu beheben, benötigen Sie die folgenden Informationen:

1. Kubernetes-Version, auf die Sie Ihren Workloadcluster aktualisieren.
2. IP-Adresse des Knotens, der hängen bleibt.

Führen Sie das folgende Cmdlet und den folgenden Befehl aus, um diese Informationen zu finden. Standardmäßig schreibt das Cmdlet Get-AksHciCredential die Kubeconfig in ~/.kube/config. Wenn Sie beim Aufrufen Get-AksHciCredentialeinen anderen Speicherort für ihren Workloadcluster kubeconfig angeben, müssen Sie diesen Speicherort als ein anderes Argument angeben. Beispiel: kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

Der Knoten, der behoben werden muss, sollte angezeigt STATUS Ready,SchedulingDisabledwerden. Wenn ein Knoten mit diesem Status angezeigt wird, verwenden Sie den INTERNAL-IP Knoten als IP-Adresswert im folgenden Befehl unten. Verwenden Sie die Kubernetes-Version, auf die Sie als Versionswert aktualisieren; dies sollte mit dem VERSION Wert aus dem Knoten übereinstimmen mit ROLES control-plane,master. Achten Sie darauf, den vollständigen Wert für die Kubernetes-Version einzuschließen, z. Bv1.22.6. die v.

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Nach dem Ausführen dieses SSH-Befehls sollten die verbleibenden Knoten mit der alten Kubernetes-Version gelöscht werden, und das Upgrade wird fortgesetzt.

Das Ausführen eines Betriebssystemupdates auf einem Host mit einer AKS auf der lokalen Azure-Bereitstellung kann dazu führen, dass die Bereitstellung in einen ungültigen Zustand versetzt wird, wodurch der API-Server des Verwaltungsclusters nicht erreichbar ist und tag zwei Vorgänge fehlschlägt. Der kube-vip Pod kann die VIP-Konfiguration nicht auf die Schnittstelle anwenden, und daher ist die VIP nicht erreichbar.

So reproduzieren Sie einen Cluster mit einer vorhandenen AKS HCI OS-Bereitstellung von HCI zu HCIv2. Versuchen Sie dann, Befehle auszuführen, die versuchen, den Verwaltungscluster zu erreichen, z Get-AksHciCluster. B. . Alle Vorgänge, die versuchen, den Verwaltungscluster zu erreichen, schlägt mit Fehlern fehl, z. B.:

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

Um dieses Problem zu beheben, starten Sie den Container kube-vip neu, um die Bereitstellung wieder in einen fehlerfreien Zustand zu bringen.

1. Abrufen der kube-vip-Container-ID:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

Die Ausgabe sollte in etwa so aussehen, und die Container-ID ist der erste Wert 4a49a5158a5f8. Zum Beispiel:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55

1. Neustarten des Containers:

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Diese Statusmeldung wird beim Ausführen des PowerShell-Cmdlets Update-AksHci gezeigt.

Überprüfen Sie die folgenden Grundursachen, um das Problem zu beheben:

• Grund 1: Während der Aktualisierung des AksHci Abrechnungsanbieters hat sich der Betreiber fälschlicherweise als außerhalb der Richtlinie gekennzeichnet. Um dieses Problem zu beheben, öffnen Sie ein neues PowerShell-Fenster, und führen Sie Sync-AksHciBilling aus. Der Abrechnungsvorgang sollte dann innerhalb der nächsten 20 bis 30 Minuten fortgesetzt werden.

• Gründe für zwei: Die Verwaltungscluster-VM ist möglicherweise nicht mehr verfügbar, was dazu führt, dass der API-Server nicht erreichbar ist und alle Befehle aus Get-AksHciCluster, Abrechnung und Update, Timeout macht. Legen Sie als Problemumgehung die Verwaltungscluster-VM in Hyper-V auf 32 GB fest, und starten Sie ihn neu.

• Ursache 3: DemAksHci-Abrechnungsoperator steht möglicherweise nicht mehr genügend Speicherplatz zur Verfügung, was auf einen Fehler in den Microsoft SQL-Konfigurationseinstellungen zurückzuführen ist. Unzureichender Speicherplatz kann dazu führen, dass das Upgrade nicht mehr reagiert. Ändern Sie zur Umgehung dieses Problems die Größe des Abrechnungs-Pods pvc manuell mithilfe der folgenden Schritte.

  1. Führen Sie den folgenden Befehl aus, um die Podeinstellungen zu bearbeiten:

     kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

  2. Wenn ein Editor mit einer YAML-Datei geöffnet wird, ändern Sie die Zeile für den Speicher von „100Mi“ in „5Gi“:

     spec:
       resources:
         requests:
           **storage: 5Gi**
     

  3. Überprüfen Sie den Status der Abrechnungsbereitstellung mithilfe des folgenden Befehls:

     kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

Wenn Sie Cluster von der AKS im lokalen Azure Februar 2022-Update auf das Update vom April 2022 aktualisieren, bleibt das Update möglicherweise für einen unbegrenzten Zeitraum hängen. Es gibt möglicherweise Pods, die Terminating entweder im Zustand oder CrashLoopBackoff im Zustand hängen bleiben.

Möglicherweise sehen Sie, dass einige der AksHci CSI-Add-On-Ressourcen fehlen. Diese Ressourcen-Pods werden mithilfe des csi-akshcicsi-controller Daemonsets oder aus dem csi-akshcicsi-node Daemonset bereitgestellt.

Das AksHci CSI-Addon im Februar 2022-Update enthielt eine Änderung der CSI-Treiberspezifikation, die manchmal die Ressourcen des Addons während des Upgrades in einem nicht reagierenden Zustand belassen kann. Der CSI-Treiber .spec.fsGroupPolicy wurde auf einen neuen Wert festgelegt, obwohl es sich um ein unveränderliches Feld handelt. Da das Feld unveränderlich ist, wird die Treiberspezifikation nicht aktualisiert. Dies hat zur Folge, dass die anderen Add-On-Ressourcen von AksHci CSI möglicherweise nicht vollständig in Einklang gebracht werden. Alle CSI-Ressourcen würden neu erstellt.

Um das Problem manuell zu beheben, kann der CSI-Treiber manuell gelöscht werden. Nachdem Sie es entfernt haben, versöhnt der Cloudoperator das AksHci CSI-Addon innerhalb der 10 Minuten und erstellt den Treiber zusammen mit den restlichen addon-Ressourcen neu.

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

Nach einem erfolgreichen Upgrade zeigt das Windows Admin Center-Updatedashboard weiterhin die vorherige Version an.

Aktualisieren Sie den Browser, um dieses Problem zu beheben.

Der Build von AKS auf Azure Local vom 1.0.1.1.10628 erstellt eine übermäßige Anzahl von Kubernetes-Konfigurationsschlüsseln im Cluster. Der Upgradepfad des Release 1.0.1.10628 aus dem Juni zum Release 1.0.2.10723 aus dem Juli wurde verbessert, um die zusätzlichen Kubernetes-Geheimnisse zu bereinigen. In einigen Fällen wurden die Geheimnisse während des Upgrades jedoch immer noch nicht bereinigt, daher ist der Upgradevorgang nicht erfolgreich.

Führen Sie bei diesem Problem die folgenden Schritte aus:

1. Speichern Sie das folgende Skript als Datei mit dem Namen fix_leaked_secrets.ps1:

   upgparam (
   [Parameter(Mandatory=$true)]
   [string] $ClusterName,
   [Parameter(Mandatory=$true)]
   [string] $ManagementKubeConfigPath
   )
   
   $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
   "Hostname is: $ControlPlaneHostName"
   
   $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
   $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
   $leakedSecretPath3 = "$ClusterName-kube-vip"
   $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
   $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
   $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
   
   $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
   $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
   
   foreach ($leakedSecretName in $leakedSecretNameList)
   {
   "Deleting secrets with the prefix $leakedSecretName"
   $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
   "Deleted: $output"
   }
   

2. Führen Sie als Nächstes den folgenden Befehl mithilfe der gespeicherten Datei fix_secret_leak.ps1 aus:

      .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
   

3. Verwenden Sie abschließend den folgenden PowerShell-Befehl, um den Upgradevorgang zu wiederholen:

      Update-AksHci
   

Nächste Schritte

• Problembehandlung: Übersicht, Feedback und Support
• Installationsprobleme und Fehler
• Bekannte Probleme mit Windows Admin Center

Wenn weiterhin Probleme auftreten, wenn Sie AKS Arc verwenden, können Sie Fehler über GitHub ablegen.