Upravit

Sdílet prostřednictvím


Řešení problémů při upgradu služby AKS Arc

Tento článek popisuje známé problémy a chyby, se kterými se můžete setkat při upgradu nasazení služby Azure Kubernetes Service (AKS) Arc na nejnovější verzi. Můžete také zkontrolovat známé problémy se službou Windows Admin Center a při instalaci AKS v Azure Stack HCI.

Po úspěšném upgradu se starší verze PowerShellu neodeberou.

Starší verze PowerShellu se neodeberou.

Tento problém můžete vyřešit spuštěním tohoto skriptu, který odinstaluje starší verze PowerShellu.

Pod prodlužování platnosti certifikátu je ve stavu smyčky chybového ukončení

Po upgradu nebo vertikálním škálování cílového clusteru se pod prodlužování platnosti certifikátů teď nachází ve stavu smyčky selhání. Očekává se, že certifikát tetování yaml soubor z cesty /etc/Kubernetes/pki. Konfigurační soubor se nachází na virtuálních počítačích uzlů řídicí roviny, ale ne na virtuálních počítačích pracovních uzlů.

Poznámka:

Tento problém je opravený po vydání z dubna 2022.

Pokud chcete tento problém vyřešit, zkopírujte ručně soubor tetování certifikátu z uzlu řídicí roviny do každého pracovního uzlu.

  1. Zkopírujte soubor z virtuálního počítače řídicí roviny do aktuálního adresáře hostitelského počítače.

    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. Zkopírujte soubor z hostitelského počítače do virtuálního počítače pracovního uzlu.

    scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml
    
  3. Informace o vlastníku a skupině tohoto souboru nastavte zpět do kořenového adresáře, pokud ještě není nastavená na root.

    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. Opakujte kroky 2 a 3 pro každý pracovní uzel.

Uzly při nemožnosti připojit se ke cloudagentu kvůli vypršení platnosti tokenu, když se cluster neupgradoval déle než 60 dnů

Pokud se cluster neupgradoval déle než 60 dní, agent uzlu se nespustí během restartování agenta uzlu kvůli vypršení platnosti tokenu. Toto selhání způsobí, že agenti budou v počáteční fázi. Průběžné pokusy o připojení ke cloudagentu můžou vyčerpat dodávky portů na hostiteli. Stav následujícího příkazu je Spuštěno.

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

Očekávané chování: Agent uzlu by měl být ve spouštěcí fázi, který se neustále snaží připojit cloudového agenta a vyčerpat porty.

Pokud chcete tento problém vyřešit, zastavte spuštění agenta wssdagent. Vzhledem k tomu, že je služba ve spouštěcí fázi, může vám bránit v zastavení služby. Pokud ano, ukončete proces před pokusem o zastavení služby.

  1. Ověřte, že je agent wssdagent ve počáteční fázi.

    Get-Service wssdagent | Select-Object -Property Name, Status
    
  2. Proces ukončete.

    kill -Name wssdagent -Force
    
  3. Zastavte službu.

    Stop-Service wssdagent -Force
    

Poznámka:

I po zastavení služby se zdá, že proces wssdagent se spustí během několika sekund po dobu několika sekund před zastavením. Než budete pokračovat k dalšímu kroku, ujistěte se, že následující příkaz vrátí chybu na všech uzlech.

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. Opakujte kroky 1, 2 a 3 v každém uzlu clusteru HCI, u kterého dochází k tomuto problému.

  2. Po potvrzení, že wssdagent není spuštěný, spusťte cloudagent, pokud není spuštěný.

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName
  1. Ověřte, že je cloudagent spuštěný a spuštěný.

    Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
    
  2. Spuštěním následujícího příkazu opravte agenta wssdagent:

    Repair-Moc
    
  3. Po dokončení tohoto příkazu by měl být agent wssdagent ve spuštěném stavu.

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

Agenti MOC se nespustí po selhání upgradu

Pokud se AKS-HCI nepodaří upgradovat z květnové verze na červenou verzi, očekává se, že se AKS-HCI vrátí k květnové verzi a bude dál fungovat. Agenty MOC ale zůstanou v zastaveném stavu a ruční pokusy o spuštění agenta je neaktivují.

Poznámka:

Tento problém je relevantní pouze při upgradu z květnové verze na červenou verzi.

Kroky pro reprodukci

  1. Nainstalujte modul PowerShellu AKS-HCI verze 1.1.36.
  2. Upgradujte AKS-HCI. Pokud upgrade selže, AKS-HCI se vrátí zpět do května, ale agenti MOC jsou mimo provoz.

Očekávané chování

Pokud se upgrade Aks-Hci nezdaří, očekává se, že se AksHci vrátí k předchozí verzi a dál funguje bez jakýchkoli problémů.

Příznaky

Neshoda mezi verzí Aks-Hci a verzí MOC

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

Neshoda mezi verzí Get-MocVersion a wssdcloudagent.exe

Get-MocVersion indikuje, že červnové sestavení je nainstalováno, zatímco verze wssdcloudagent.exe indikuje, že je nainstalován sestavení z května.

Cesta image služeb agenta MOC má parametr ID nasazení

Spuštěním následujícího příkazu zobrazte cestu k imagi cloudového agenta:

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

Příklad výstupu

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

Pomocí následujícího příkazu zobrazte cestu image pro agenta uzlu: dotaz reg "HKLM\System\CurrentControlSet\Services\wssdagent"

Příklad výstupu

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

Pokud chcete tento problém zmírnit, spusťte následující rutiny PowerShellu:

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'

Během upgradu dojde ke ztrátě taintů, rolí a popisků vlastních uzlů.

Při upgradu můžete ztratit všechny vlastní tainty, role a popisky, které jste přidali do pracovních uzlů. Vzhledem k tomu, že AKS je spravovaná služba, přidání vlastních taintů, popisků a rolí při provedení mimo poskytnuté rutiny PowerShellu nebo Windows Admin Center se nepodporuje.

Pokud chcete tento problém obejít, spusťte rutinu New-AksHciNodePool a správně vytvořte fond uzlů s tainty pro pracovní uzly.

Pokud se cluster úloh nevytvořil za 60 dnů, služba AKS Arc přestane fungovat.

Pokud jste vytvořili cluster pro správu, ale během prvních 60 dnů jste nenasadili cluster úloh, bude vám zablokováno jeho vytvoření, protože už není v zásadách. V takovém případě se při spuštění update-AksHci proces aktualizace zablokuje s chybou Čekání na nasazení Operátor fakturace AksHci. Pokud spustíte Sync-AksHciBilling, vrátí úspěšný výstup. Pokud však spustíte Get-AksHciBillingStatus, stav připojení je OutofPolicy.

Pokud jste cluster úloh nenasadili za 60 dnů, fakturace se ze zásad vyhne.

Jediným způsobem, jak tento problém vyřešit, je opětovné nasazení s čistou instalací.

VNIC po restartování počítače chybí

Poznámka:

Tento problém je opravený ve verzi z května 2022 a novější.

Pokud se uzly Azure Stack HCI restartují jeden po druhém, některé virtuální počítače k nim ztratí připojené virtuální síťové adaptéry. Tato ztráta virtuálních síťových adaptérů způsobí ztrátu síťového připojení virtuálních počítačů a cluster spadne do špatného stavu.

Reprodukování

  1. Restartujte jeden uzel Azure Stack HCI.
  2. Počkejte na dokončení restartování uzlu. Uzel musí být označen Up v clusteru s podporou převzetí služeb při selhání.
  3. Restartujte ostatní uzly.
  4. Opakujte.

Očekávané chování : Stav clusteru by měl být v pořádku. Všechny virtuální počítače by k nim měly mít připojené síťové karty.

K vyřešení problému použijte příkazy MOC k přidání vNIC do virtuálního počítače.

  1. Získejte název vNIC pro virtuální počítač.
(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

nebo

mocctl.exe compute vm get --name <vmname> --group <group>
  1. Připojte virtuální síť k virtuálnímu počítači.
Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

nebo

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>
  1. Pokud příkaz vNIC connect selže, zkuste se odpojit a znovu se připojit. Následuje příkaz pro odpojení vNIC.
Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

nebo

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

Při upgradu nasazení se některé pody můžou zaseknout na čekání na statické pody, aby měly připravenou podmínku.

Pody se zablokovaly při čekání na statické pody, aby měly připravenou podmínku.

Pokud chcete uvolnit pody a vyřešit tento problém, měli byste restartovat kubelet. Pokud chcete zobrazit uzel NotReady se statickými pody, spusťte následující příkaz:

kubectl get nodes -o wide

Další informace o chybném uzlu získáte spuštěním následujícího příkazu:

kubectl describe node <IP of the node>

Pomocí SSH se přihlaste k uzlu NotReady spuštěním následujícího příkazu:

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

Potom spusťte následující příkaz, který restartuje kubelet:

/etc/.../kubelet restart

Spuštění upgradu způsobí chybu: Došlo k chybě při načítání informací o upgradu platformy.

Při spuštění upgradu v Centru pro správu Systému Windows došlo k následující chybě:

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.

K této chybové zprávě obvykle dochází, když je služba AKS ve službě Azure Stack HCI nasazená v prostředí s nakonfigurovaným proxy serverem. Windows Admin Center v současné době nepodporuje instalaci modulů v prostředí proxy serveru.

Pokud chcete tuto chybu vyřešit, nastavte AKS ve službě Azure Stack HCI pomocí příkazu PowerShellu proxy.

Při upgradu clusteru Kubernetes pomocí agenta Open Policy se proces upgradu zablokuje.

Při upgradu clusterů Kubernetes pomocí agenta OPA (Open Policy Agent), jako je OPA GateKeeper, může proces přestat reagovat a nemůže se dokončit. K tomuto problému může dojít, protože agent zásad je nakonfigurovaný tak, aby zabránil vyžádání imagí kontejneru z privátních registrů.

Pokud chcete tento problém vyřešit, pokud upgradujete clustery nasazené s OPA, ujistěte se, že vaše zásady umožňují načíst image ze služby Azure Container Registry. V případě upgradu AKS ve službě Azure Stack HCI byste měli do seznamu zásad přidat následující koncový bod: ecpacr.azurecr.io.

Aktualizace hostitelského operačního systému HCI na HCIv2 přeruší instalaci AKS ve službě Azure Stack HCI: OutOfCapacity

Spuštění aktualizace operačního systému na hostiteli s nasazením AKS ve službě Azure Stack HCI může způsobit, že nasazení přejde do špatného stavu a selže den dvou operací. Služby MOC NodeAgent Services se nemusí spustit na aktualizovaných hostitelích. Všechna volání MOC uzlů selžou.

Poznámka:

K tomuto problému dochází jen občas.

Reprodukování: Při aktualizaci clusteru s existujícím nasazením AKS z HCI na HCIv2 může dojít k New-AksHciCluster selhání operace AKS. Chybová zpráva uvádí, že uzly MOC jsou OutOfCapacity. Příklad:

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]

Pokud chcete tento problém vyřešit, spusťte na ovlivněných uzlech službu wssdagent Moc NodeAgent Service. Tím se problém vyřeší a nasazení se vrátí do dobrého stavu. Spusťte následující příkaz:

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

Upgrade cílového clusteru se zasekne s jedním nebo více uzly ve staré verzi Kubernetes.

Po spuštění update-AksHciCluster proces upgradu zastaví.

Spuštěním následujícího příkazu zkontrolujte, jestli existuje počítač s odstraněním PHASE , na kterém běží předchozí verze Kubernetes, ze které upgradujete.

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

Pokud je počítač s odstraněním PHASE a VERSION shodným s předchozí verzí Kubernetes, pokračujte následujícími kroky.

K vyřešení tohoto problému potřebujete následující informace:

  1. Verze Kubernetes, na kterou upgradujete cluster úloh.
  2. IP adresa uzlu, který je zablokovaný.

Pokud chcete tyto informace najít, spusťte následující rutinu a příkaz. Ve výchozím nastavení rutina Get-AksHciCredential zapíše kubeconfig do ~/.kube/config. Pokud při volání Get-AksHciCredentialzadáte jiné umístění pro cluster úloh kubeconfig, budete muset toto umístění zadat kubectl jako jiný argument. Například kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig>.

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

Uzel, který je potřeba opravit, by se měl zobrazit STATUS Ready,SchedulingDisabled. Pokud se zobrazí uzel s tímto stavem, použijte INTERNAL-IP tento uzel jako hodnotu IP adresy v následujícím příkazu níže. Jako hodnotu verze použijte verzi Kubernetes, na kterou upgradujete. to by se mělo shodovat s VERSION hodnotou z uzlu s ROLES control-plane,master. Nezapomeňte zahrnout úplnou hodnotu pro verzi Kubernetes, například vv1.22.6.

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

Po spuštění tohoto příkazu ssh by se zbývající uzly se starou verzí Kubernetes měly odstranit a upgrade bude pokračovat.

Aktualizace hostitelského operačního systému HCI na HCIv2 přeruší instalaci AKS ve službě Azure Stack HCI: Cluster pro správu se nedá spojit

Spuštění aktualizace operačního systému na hostiteli s nasazením AKS v Azure Stack HCI může způsobit, že nasazení přejde do špatného stavu, což vykreslí nedostupný server rozhraní API clusteru pro správu a selže dva operace. Pod kube-vip nemůže použít konfiguraci VIRTUÁLNÍ IP adresy pro rozhraní a proto je virtuální IP adresa nedostupná.

Reprodukování: Aktualizujte cluster s existujícím nasazením AKS HCI z HCI na HCIv2. Potom zkuste spustit příkazy, které se pokusí připojit ke clusteru pro správu, například Get-AksHciCluster. Všechny operace, které se pokusí připojit ke clusteru pro správu, selžou s chybami, například:

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

Pokud chcete tento problém vyřešit, restartujte kube-vip kontejner, aby se nasazení vrátilo do dobrého stavu.

  1. Získejte ID kontejneru kube-vip :
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

Výstup by měl vypadat přibližně takto, přičemž ID kontejneru je první hodnota 4a49a5158a5f8. Příklad:

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55
  1. Restartujte kontejner Restartovat:
ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

Při spuštění update-AksHci se proces aktualizace zablokoval v části Čeká se na nasazení AksHci Billing Operator( Operátor fakturace AksHci).

Tato stavová zpráva se zobrazí při spuštění rutiny PowerShellu Update-AksHci .

Pokud chcete tento problém vyřešit, projděte si následující hlavní příčiny:

  • Důvod jedna: Během aktualizace fakturačního operátora AksHci se operátor nesprávně označil jako mimo zásady. Pokud chcete tento problém vyřešit, otevřete nové okno PowerShellu a spusťte Sync-AksHciBilling. Během dalších 20 až 30 minut by se měla zobrazit operace fakturace.

  • Důvod 2: Virtuální počítač clusteru pro správu může být nedostatek paměti, což způsobí nedostupný server rozhraní API a vyprší časový limit všech příkazů z Get-AksHciCluster, fakturace a aktualizace. Jako alternativní řešení nastavte virtuální počítač clusteru pro správu na 32 GB v Hyper-V a restartujte ho.

  • Důvod 3: Fakturační operátor AksHci může být mimo prostor úložiště, což je způsobeno chybou v nastavení konfigurace Microsoft SQL. Nedostatek úložného prostoru může způsobit, že upgrade přestane reagovat. Pokud chcete tento problém vyřešit, změňte velikost fakturačního podu pvc ručně pomocí následujícího postupu.

    1. Spuštěním následujícího příkazu upravte nastavení podu:

      kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
      
    2. Když se otevře Poznámkový blok nebo jiný editor se souborem YAML, upravte řádek úložiště z 100Mi na 5Gi:

      spec:
        resources:
          requests:
            **storage: 5Gi**
      
    3. Pomocí následujícího příkazu zkontrolujte stav nasazení fakturace:

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

Při upgradu AKS v Azure Stack HCI z aktualizace z února 2022 na aktualizaci z dubna 2022 zmizí nasazení CSI a způsobí zastavení upgradu.

Když upgradujete clustery z AKS v aktualizaci Azure Stack HCI z února 2022 na aktualizaci z dubna 2022, aktualizace se může po neomezenou dobu zaseknout. Ve stavu nebo CrashLoopBackoff ve stavu můžou být zablokované Terminating pody.

Možná uvidíte, že chybí některé prostředky doplňku CSI AksHci. Tyto pody prostředků nasazené pomocí démona csi-akshcicsi-controller csi-akshcicsi-node nebo z démona.

Doplněk AksHci CSI v aktualizaci z února 2022 obsahoval změnu specifikace ovladače CSI, která může někdy během upgradu opustit prostředky doplňku v nereagujícím stavu. Ovladač .spec.fsGroupPolicy CSI byl nastaven na novou hodnotu, i když se jedná o neměnné pole. Vzhledem k tomu, že pole je neměnné, specifikace ovladače se neaktualizuje. Následkem toho je, že ostatní prostředky doplňku CSI AksHci nemusí být plně odsouhlasené. Všechny prostředky CSI by se znovu vytvořily.

Pokud chcete tento problém vyřešit ručně, můžete ovladač CSI odstranit ručně. Jakmile ho odeberete, operátor cloudu odsouhlasí doplněk AksHci CSI během 10 minut a znovu vytvoří ovladač spolu se zbývajícími chybějícími prostředky doplňku.

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

Řídicí panel aktualizace Windows Admin Center se po úspěšných aktualizacích neaktualizuje

Po úspěšném upgradu se na řídicím panelu aktualizace Windows Admin Center stále zobrazuje předchozí verze.

Názvy síťových polí nejsou na portálu WAC konzistentní.

Pokud chcete tento problém vyřešit, aktualizujte prohlížeč.

Při upgradu pomocí PowerShellu se v clusteru vytvoří nadbytečný počet tajných kódů konfigurace Kubernetes.

Sestavení AKS v Azure Stack HCI z června 1.0.1.10628 vytvoří v clusteru nadbytečný počet tajných kódů konfigurace Kubernetes. Cesta upgradu z verze vydaná 1.0.1.10628 na verzi z července 1.0.2.10723 byla vylepšena, aby se vyčistily další tajné kódy Kubernetes. V některých případech však během upgradu se tajné kódy stále nevyčistily, a proto proces upgradu selže.

Pokud k tomuto problému dochází, spusťte následující kroky:

  1. Uložte následující skript jako soubor s názvem 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. Potom spusťte následující příkaz pomocí souboru fix_secret_leak.ps1 , který jste uložili:

       .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
    
  3. Nakonec pomocí následujícího příkazu PowerShellu zopakujte proces upgradu:

       Update-AksHci
    

Další kroky

Pokud při používání služby AKS Arc stále dochází k problémům, můžete chyby zasdílit prostřednictvím GitHubu.