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

Starší verze PowerShellu se neodeberou.

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

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ů.

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.

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
   

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 místního clusteru Azure, 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
   

Když se AKS v Azure Local nepodaří upgradovat z květnové verze na červenou verzi, očekává se, že se AKS v Azure Local 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í.

Kroky pro reprodukci

1. Nainstalujte modul PowerShellu AKS-HCI verze 1.1.36.
2. Upgradujte AKS v Azure Local. Pokud se upgrade nezdaří, AKS v místním Prostředí Azure se vrátí zpět do května, ale agenti MOC jsou v výpadku.

Očekávané chování

Pokud se místní upgrade AKS v Azure nezdaří, očekává se, že se AKS v Azure Local 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'

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 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í.

Pokud se místní uzly Azure restartují po druhém, některé virtuální počítače 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 místní uzel Azure.
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>

2. 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>

3. 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>

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

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í v případě, že je služba AKS v místním prostředí 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 v Azure Local pomocí příkazu PowerShellu proxy.

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ě místního upgradu AKS v Azure byste měli do seznamu zásad přidat následující koncový bod: ecpacr.azurecr.io.

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

Reprodukování: Při aktualizaci clusteru s existujícím nasazením AKS z HCI na operační systém 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 } }

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.

Spuštění aktualizace operačního systému na hostiteli s místním nasazením AKS v Azure 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 operačního systému 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>"

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
     

Když upgradujete clustery z AKS v místní aktualizaci Azure 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`

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

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

Build AKS v Azure Local 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

• Přehled řešení potíží
• Problémy s instalací a chyby
• Známé problémy v Centru pro správu Windows

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.