Rozwiązywanie problemów podczas uaktualniania usługi AKS Arc

Starsze wersje programu PowerShell nie są usuwane.

Aby obejść ten problem, możesz uruchomić ten skrypt, aby odinstalować starsze wersje programu PowerShell.

Po uaktualnieniu lub przeskalowaniu klastra docelowego zasobnik odnawiania certyfikatu jest teraz w stanie pętli awaryjnej. Oczekuje się pliku tatuażu yaml certyfikatu ze ścieżki /etc/Kubernetes/pki. Plik konfiguracji znajduje się na maszynach wirtualnych węzła płaszczyzny sterowania, ale nie na maszynach wirtualnych węzła roboczego.

Aby rozwiązać ten problem, ręcznie skopiuj plik tatuażu certyfikatu z węzła płaszczyzny sterowania do każdego węzła procesu roboczego.

1. Skopiuj plik z maszyny wirtualnej płaszczyzny sterowania do bieżącego katalogu maszyny hosta.

   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. Skopiuj plik z maszyny hosta do maszyny wirtualnej węzła roboczego.

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

3. Ustaw informacje o właścicielu i grupie dla tego pliku z powrotem na katalog główny, jeśli nie został jeszcze ustawiony na katalog główny.

   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. Powtórz kroki 2 i 3 dla każdego węzła roboczego.

Jeśli klaster nie został uaktualniony przez ponad 60 dni, agent węzła nie może uruchomić się podczas ponownego uruchamiania agenta węzła z powodu wygaśnięcia tokenu. Ten błąd powoduje, że agenci są w fazie początkowej. Ciągłe próby dołączenia do usługi Cloudagent mogą wyczerpać dostawy portów na hoście. Stan następującego polecenia to Uruchamianie.

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

Oczekiwane zachowanie: agent węzła powinien znajdować się w fazie początkowej, która stale próbuje dołączyć do agenta w chmurze, wyczerpając porty.

Aby rozwiązać ten problem, zatrzymaj działanie programu wssdagent. Ponieważ usługa jest w fazie początkowej, może to uniemożliwić zatrzymanie usługi. Jeśli tak, zabij proces przed podjęciem próby zatrzymania usługi.

1. Upewnij się, że program wssdagent jest w fazie początkowej.

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

2. Zabij proces.

   kill -Name wssdagent -Force
   

3. Zatrzymaj usługę.

   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. Powtórz kroki 1, 2 i 3 w każdym węźle klastra lokalnego platformy Azure, który ma ten problem.

2. Po potwierdzeniu, że agent wssdagent nie jest uruchomiony, uruchom cloudagent, jeśli nie jest uruchomiony.

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

1. Upewnij się, że aplikacja cloudagent jest uruchomiona.

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

2. Uruchom następujące polecenie, aby naprawić moduł wssdagent:

   Repair-Moc
   

3. Po zakończeniu tego polecenia agent wssdagent powinien być w stanie uruchomienia.

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

Jeśli usługa AKS w środowisku lokalnym platformy Azure nie może przeprowadzić uaktualnienia z wersji z maja do wersji z czerwca, oczekuje się, że usługa AKS na platformie Azure Lokalna powinna powrócić do wersji z maja i nadal działać. Ale pozostawia agentów MOC w stanie zatrzymanym, a ręczne próby uruchomienia agenta nie aktywują ich.

Kroki odtwarzania

1. Zainstaluj moduł AKS-HCI programu PowerShell w wersji 1.1.36.
2. Uaktualnij usługę AKS na platformie Azure Lokalnie. Jeśli uaktualnienie zakończy się niepowodzeniem, usługa AKS w usłudze Azure Local powróci do maja, ale agenci MOC nie działają.

Oczekiwane zachowanie

Jeśli uaktualnienie lokalne usługi AKS na platformie Azure zakończy się niepowodzeniem, oczekuje się, że usługa AKS w usłudze Azure Local powróci do poprzedniej wersji i będzie nadal działać bez żadnych problemów.

Objawy

Niezgodność między wersją Aks-Hci i wersją MOC

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

Niezgodność między wersją Get-MocVersion i wssdcloudagent.exe

Get-MocVersion wskazuje, że kompilacja z czerwca jest zainstalowana, gdy wersja wssdcloudagent.exe wskazuje, że kompilacja z maja jest zainstalowana.

Ścieżka obrazu usług agenta MOC ma parametr identyfikatora wdrożenia

Uruchom następujące polecenie, aby wyświetlić ścieżkę obrazu agenta w chmurze:

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

Przykładowe dane wyjściowe

"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"

Użyj następującego polecenia, aby wyświetlić ścieżkę obrazu agenta węzła: reg query "HKLM\System\CurrentControlSet\Services\wssdagent"

Przykładowe dane wyjściowe

"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"

Aby rozwiązać ten problem, uruchom następujące polecenia cmdlet programu PowerShell:

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'

Podczas uaktualniania można utracić wszystkie niestandardowe defekty, role i etykiety dodane do węzłów procesu roboczego. Ponieważ usługa AKS jest usługą zarządzaną, dodawanie niestandardowych defektów, etykiet i ról w przypadku wykonywania poza podanymi poleceniami cmdlet programu PowerShell lub Centrum administracyjnym systemu Windows nie jest obsługiwane.

Aby obejść ten problem, uruchom polecenie cmdlet New-AksHciNodePool , aby poprawnie utworzyć pulę węzłów z defektami dla węzłów procesu roboczego.

Jeśli utworzono klaster zarządzania, ale nie wdrożono klastra obciążenia w ciągu pierwszych 60 dni, tworzenie klastra zostanie zablokowane, ponieważ jest to teraz nieaktualne zasady. W takiej sytuacji po uruchomieniu polecenia Update-AksHci proces aktualizacji jest blokowany z powodu błędu Oczekiwanie na wdrożenie "Operator rozliczeń usługi AksHci", aby było gotowe. Jeśli uruchomisz polecenie Sync-AksHciBilling, zwraca pomyślne dane wyjściowe. Jeśli jednak uruchomisz polecenie Get-AksHciBillingStatus, stan połączenia to OutofPolicy.

Jeśli klaster obciążenia nie został wdrożony w ciągu 60 dni, rozliczenia nie będą naliczane.

Jedynym sposobem rozwiązania tego problemu jest ponowne wdrożenie przy użyciu czystej instalacji.

Jeśli węzły lokalne platformy Azure zostaną ponownie uruchomione po drugim, niektóre maszyny wirtualne utracą dołączone do nich wirtualne karty sieciowe. Ta utrata wirtualnych kart sieciowych powoduje utratę łączności sieciowej przez maszyny wirtualne, a klaster znajduje się w złym stanie.

Aby odtworzyć

1. Uruchom ponownie jeden węzeł lokalny platformy Azure.
2. Poczekaj na zakończenie ponownego uruchomienia węzła. Węzeł musi być oznaczony Up w klastrze trybu failover.
3. Uruchom ponownie inne węzły.
4. I od nowa.

Oczekiwane zachowanie Stan klastra powinien być w dobrej kondycji. Wszystkie maszyny wirtualne powinny mieć dołączone do nich karty sieciowe.

Aby rozwiązać ten problem, użyj poleceń MOC, aby dodać wirtualnąnicę do maszyny wirtualnej.

1. Pobierz nazwę wirtualnej karty sieciowej dla maszyny wirtualnej.

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

lub

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

2. Łączenie wirtualnej karty sieciowej z maszyną wirtualną.

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

lub

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

3. Jeśli polecenie vNIC Connect zakończy się niepowodzeniem, spróbuj rozłączyć się i nawiązać połączenie ponownie. Poniżej przedstawiono polecenie rozłączania wirtualnej karty sieciowej.

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

lub

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

Zasobniki utknęły w oczekiwaniu na przygotowanie statycznych zasobników.

Aby zwolnić zasobniki i rozwiązać ten problem, należy ponownie uruchomić narzędzie kubelet. Aby wyświetlić węzeł NotReady ze statycznymi zasobnikami, uruchom następujące polecenie:

kubectl get nodes -o wide

Aby uzyskać więcej informacji na temat wadliwego węzła, uruchom następujące polecenie:

kubectl describe node <IP of the node>

Użyj protokołu SSH, aby zalogować się do węzła NotReady, uruchamiając następujące polecenie:

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

Następnie, aby ponownie uruchomić narzędzie kubelet, uruchom następujące polecenie:

/etc/.../kubelet restart

Podczas uaktualniania w centrum administracyjnym systemu Windows wystąpił następujący błąd:

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.

Ten komunikat o błędzie zwykle występuje, gdy usługa AKS na platformie Azure Lokalna jest wdrażana w środowisku ze skonfigurowanym serwerem proxy. Obecnie program Windows Admin Center nie obsługuje instalowania modułów w środowisku proxy.

Aby rozwiązać ten błąd, skonfiguruj usługę AKS w usłudze Azure Local przy użyciu polecenia serwera proxy programu PowerShell.

Podczas uaktualniania klastrów Kubernetes za pomocą agenta open policy (OPA), takiego jak OPA GateKeeper, proces może się zawieszać i nie można go ukończyć. Ten problem może wystąpić, ponieważ agent zasad jest skonfigurowany tak, aby zapobiec ściąganiu obrazów kontenerów z prywatnych rejestrów.

Aby rozwiązać ten problem, jeśli uaktualnisz klastry wdrożone za pomocą OPA, upewnij się, że zasady umożliwiają ściąganie obrazów z usługi Azure Container Registry. W przypadku uaktualnienia lokalnego usługi AKS na platformie Azure należy dodać następujący punkt końcowy na liście zasad: ecpacr.azurecr.io.

Uruchomienie aktualizacji systemu operacyjnego na hoście z usługą AKS w lokalnym wdrożeniu platformy Azure może spowodować wprowadzenie nieprawidłowego stanu wdrożenia i niepowodzenie dwóch operacji. Uruchomienie usług MOC NodeAgent na zaktualizowanych hostach może zakończyć się niepowodzeniem. Wszystkie wywołania MOC do węzłów kończą się niepowodzeniem.

Aby odtworzyć: podczas aktualizowania klastra przy użyciu istniejącego wdrożenia usługi AKS z rozwiązania HCI do systemu operacyjnego HCIv2 operacja usługi AKS, taka jak New-AksHciCluster może zakończyć się niepowodzeniem. Komunikat o błędzie wskazuje, że węzły MOC to OutOfCapacity. Na przykład:

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]

Aby rozwiązać ten problem, uruchom usługę wssdagent Moc NodeAgent w węzłach, których dotyczy problem. Spowoduje to rozwiązanie problemu i przywrócenie wdrożenia do dobrego stanu. Uruchom następujące polecenie:

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

Po uruchomieniu polecenia Update-AksHciCluster proces uaktualniania zostanie zatrzymany.

Uruchom następujące polecenie, aby sprawdzić, czy maszyna ma maszynę z PHASE uruchomioną poprzednią wersją platformy Kubernetes, z której korzystasz.

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

Jeśli istnieje maszyna z PHASE usuwaniem i VERSION dopasowywaniem poprzedniej wersji rozwiązania Kubernetes, wykonaj następujące kroki.

Aby rozwiązać ten problem, potrzebne są następujące informacje:

1. Wersja rozwiązania Kubernetes, do której uaktualniasz klaster obciążenia.
2. Adres IP węzła, który jest zablokowany.

Aby znaleźć te informacje, uruchom następujące polecenie cmdlet i polecenie. Domyślnie polecenie cmdlet Get-AksHciCredential zapisuje plik kubeconfig na .~/.kube/config W przypadku określenia innej lokalizacji dla klastra obciążenia kubeconfig podczas wywoływania Get-AksHciCredentialpolecenia należy podać lokalizację kubectl jako inny argument. Na przykład kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Węzeł, który należy naprawić, powinien zawierać wartość STATUS Ready,SchedulingDisabled. Jeśli zostanie wyświetlony węzeł o tym stanie, użyj INTERNAL-IP wartości tego węzła jako wartości adresu IP w poniższym poleceniu. Użyj wersji platformy Kubernetes, do której uaktualniasz wersję jako wartość wersji; ta wartość powinna być zgodna VERSION z wartością z węzła za pomocą ROLES control-plane,masterpolecenia . Pamiętaj, aby uwzględnić pełną wartość dla wersji kubernetes, w tym v, na przykład v1.22.6.

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

Po uruchomieniu tego polecenia SSH pozostałe węzły ze starą wersją platformy Kubernetes powinny zostać usunięte, a uaktualnienie będzie kontynuowane.

Uruchomienie aktualizacji systemu operacyjnego na hoście z usługą AKS w lokalnym wdrożeniu platformy Azure może spowodować wprowadzenie nieprawidłowego stanu wdrożenia, co powoduje, że serwer interfejsu API klastra zarządzania jest nieosiągalny i kończy się niepowodzeniem w ciągu dwóch dni. Zasobnik kube-vip nie może zastosować konfiguracji adresu VIP do interfejsu, a w związku z tym adres VIP jest niemożliwy do osiągnięcia.

Aby odtworzyć: zaktualizuj klaster przy użyciu istniejącego wdrożenia systemu operacyjnego AKS HCI z HCI do HCIv2. Następnie spróbuj uruchomić polecenia, które próbują uzyskać dostęp do klastra zarządzania, takiego jak Get-AksHciCluster. Wszystkie operacje, które próbują uzyskać dostęp do klastra zarządzania, kończą się niepowodzeniem z błędami, takimi jak:

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)]

Aby rozwiązać ten problem: uruchom ponownie kontener, kube-vip aby przywrócić stan wdrożenia.

1. Pobierz identyfikator kontenera kube-vip :

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

Dane wyjściowe powinny wyglądać mniej więcej tak, a identyfikator kontenera jest pierwszą wartością 4a49a5158a5f8. Na przykład:

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

1. Uruchom ponownie kontener:

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

Ten komunikat o stanie jest wyświetlany podczas uruchamiania polecenia cmdlet Update-AksHci programu PowerShell.

Zapoznaj się z następującymi głównymi przyczynami rozwiązania problemu:

• Przyczyna pierwsza: Podczas aktualizacji operatora rozliczeniowego AksHci operator niepoprawnie oznaczył się jako poza zasadami. Aby rozwiązać ten problem, otwórz nowe okno programu PowerShell i uruchom polecenie Sync-AksHciBilling. W ciągu najbliższych 20–30 minut powinna być widoczna operacja rozliczeń.

• Przyczyna druga: Maszyna wirtualna klastra zarządzania może nie mieć pamięci, co powoduje, że serwer interfejsu API jest niedostępny i powoduje przekroczenie limitu czasu wszystkich poleceń z polecenia Get-AksHciCluster, rozliczeń i aktualizacji. Aby obejść ten problem, ustaw maszynę wirtualną klastra zarządzania na 32 GB w funkcji Hyper-V i uruchom ją ponownie.

• Przyczyna trzecia: Operator rozliczeń usługi AksHci może nie zawierać miejsca do magazynowania, co jest spowodowane usterką w ustawieniach konfiguracji programu Microsoft SQL. Brak miejsca do magazynowania może spowodować, że uaktualnienie przestanie odpowiadać. Aby obejść ten problem, ręcznie zmień rozmiar zasobnika pvc rozliczeniowego, wykonując następujące kroki.

  1. Uruchom następujące polecenie, aby edytować ustawienia zasobnika:

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

  2. Po otwarciu Notatnika lub innego edytora z plikiem YAML edytuj wiersz dla magazynu z 100Mi do 5Gi:

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

  3. Sprawdź stan wdrożenia rozliczeniowego przy użyciu następującego polecenia:

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

Podczas uaktualniania klastrów z usługi AKS w lokalnej aktualizacji z lutego 2022 r. do aktualizacji z kwietnia 2022 r. aktualizacja może zostać zablokowana przez nieokreślony czas. Mogą istnieć zasobniki zablokowane w stanie Terminating lub CrashLoopBackoff .

Może się okazać, że brakuje niektórych zasobów dodatku AksHci CSI. Te zasobniki zasobów wdrożone przy użyciu csi-akshcicsi-controller elementu lub z demona csi-akshcicsi-node .

Dodatek AksHci CSI w aktualizacji z lutego 2022 r. zawierał zmianę specyfikacji sterownika CSI, która czasami może pozostawić zasoby dodatku w stanie nieodpowiadania podczas uaktualniania. Sterownik .spec.fsGroupPolicy CSI został ustawiony na nową wartość, mimo że jest to niezmienne pole. Ponieważ pole jest niezmienne, specyfikacja sterownika nie jest aktualizowana. Konsekwencją tego jest to, że inne zasoby dodatku AksHci CSI mogą nie zostać w pełni uzgodnione. Wszystkie zasoby CSI zostaną ponownie stworzone.

Aby ręcznie rozwiązać ten problem, sterownik CSI można usunąć ręcznie. Po jego usunięciu operator chmury uzgadnia dodatek AksHci CSI w ciągu 10 minut i ponownie utworzy sterownik wraz z resztą brakujących zasobów dodatku.

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

Po pomyślnym uaktualnieniu pulpit nawigacyjny aktualizacji programu Windows Admin Center nadal wyświetla poprzednią wersję.

Odśwież przeglądarkę, aby rozwiązać ten problem.

Kompilacja usługi AKS w wersji 1.0.1.10628 z czerwca 10628 w usłudze Azure Local tworzy nadmiarową liczbę wpisów tajnych konfiguracji platformy Kubernetes w klastrze. Ścieżka uaktualnienia z wersji 1.0.1.10628 z lipca 1.0.2.10723 została ulepszona w celu oczyszczenia dodatkowych wpisów tajnych kubernetes. Jednak w niektórych przypadkach podczas uaktualniania wpisy tajne nie zostały wyczyszczone i dlatego proces uaktualniania kończy się niepowodzeniem.

Jeśli wystąpi ten problem, uruchom następujące kroki:

1. Zapisz poniższy skrypt jako plik o nazwie 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. Następnie uruchom następujące polecenie przy użyciu zapisanego pliku fix_secret_leak.ps1 :

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

3. Na koniec użyj następującego polecenia programu PowerShell, aby powtórzyć proces uaktualniania:

      Update-AksHci
   

Następne kroki

• Omówienie rozwiązywania problemów
• Problemy z instalacją i błędy
• Znane problemy z programem Windows Admin Center

Jeśli nadal występują problemy podczas korzystania z usługi AKS Arc, możesz zgłosić błędy za pośrednictwem usługi GitHub.