Řešení potíží se správou Kubernetes a clusterem úloh v AKS Arc

Při spuštění příkazu Remove-ClusterNode se uzel vyřadí z clusteru s podporou převzetí služeb při selhání, ale pokud se poté nespustí rutina Remove-AksHciNode , uzel bude dál existovat v agentu CloudAgent.

Vzhledem k tomu, že uzel byl odebrán z clusteru, ale ne z agenta CloudAgent, pokud k vytvoření nového uzlu použijete virtuální pevný disk, zobrazí se chyba Soubor se nenašel. K tomuto problému dochází, protože virtuální pevný disk je ve sdíleném úložišti a odebraný uzel k němu nemá přístup.

Pokud chcete tento problém vyřešit, odeberte z clusteru fyzický uzel a pak postupujte takto:

1. Spuštěním příkazu Remove-AksHciNode zrušte registraci uzlu z agenta CloudAgent.
2. Provádět rutinní údržbu, jako je například opětovné zobrazení image počítače.
3. Přidejte uzel zpátky do clusteru.
4. Spuštěním příkazu Add-AksHciNode zaregistrujte uzel u agenta CloudAgent.

U velkých clusterů Get-AksHciLogs může příkaz vyvolat výjimku, nepodaří se vytvořit výčet uzlů nebo nevygeneruje c:\wssd\wssdlogs.zip výstupní soubor.

Důvodem je to, že příkaz PowerShellu pro komprimaci souboru Compress-Archive má limit velikosti výstupního souboru 2 GB.

Po upgradu nebo vertikálním navýšení kapacity clusteru úloh je teď pod obnovení certifikátu ve smyčce chybových ukončení, protože očekává certifikát tetování souboru YAML z umístění /etc/Kubernetes/pkisouboru .

Příčinou tohoto problému může být konfigurační soubor, který se nachází na virtuálních počítačích řídicí roviny, ale ne na virtuálních počítačích pracovního uzlu.

Pokud chcete tento problém vyřešit, ručně zkopírujte soubor YAML certifikátu pro tetování z uzlu řídicí roviny do všech pracovních uzlů.

1. Zkopírujte soubor YAML z virtuálního počítače řídicí roviny v clusteru úloh 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` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Zkopírujte soubor YAML z hostitelského počítače do virtuálního počítače pracovního uzlu. Před kopírováním souboru musíte změnit název počítače v souboru YAML na název uzlu, do kterého kopírujete (to je název uzlu pro řídicí rovinu clusteru úloh).

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

3. Pokud informace o vlastníkovi a skupině v souboru YAML ještě nejsou nastavené na kořen, nastavte informace na kořen:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Opakujte kroky 2 a 3 pro všechny pracovní uzly.

Příkazy PowerShellu Aks-Hci neověřují dostupnou paměť na hostitelském serveru před vytvořením uzlů Kubernetes. Tento problém může vést k vyčerpání paměti a virtuálním počítačům, které se nespustí.

Tato chyba se v současné době nezpracuje bez odkladu a nasazení přestane reagovat bez jasné chybové zprávy. Pokud máte nasazení, které přestane reagovat, otevřete Prohlížeč událostí a vyhledejte chybovou zprávu související s Technologií Hyper-V, která indikuje, že není dostatek paměti ke spuštění virtuálního počítače.

Při spuštění rutiny Get-AksHciCluster k ověření stavu instalace služby AKS Arc v Windows Admin Center se ve výstupu zobrazí chyba: "Verze s verzí 1.0.3.10818 nebyla nalezena." Při spuštění rutiny Get-AksHciVersion se však zobrazila instalace stejné verze. Tato chyba značí, že vypršela platnost sestavení.

Pokud chcete tento problém vyřešit, spusťte příkaz Uninstall-AksHcia pak spusťte nové sestavení AKS Arc.

Při použití nástroje pro správu clusteru k přesunu virtuálního počítače z jednoho uzlu (uzel A) do jiného uzlu (Uzel B) v clusteru Azure Stack HCI se nemusí podařit spustit virtuální počítač na novém uzlu. Po přesunutí virtuálního počítače zpět do původního uzlu se ho tam také nepodaří spustit.

K tomuto problému dochází, protože logika pro vyčištění první migrace běží asynchronně. V důsledku toho logika Azure Kubernetes Service "aktualizovat umístění virtuálního počítače" najde virtuální počítač v původním Hyper-V v uzlu A a místo zrušení registrace ho odstraní.

Pokud chcete tento problém obejít, ujistěte se, že se virtuální počítač na novém uzlu úspěšně spustil, než ho přesunete zpět na původní uzel.

Při použití PowerShellu k vytvoření clusteru se statickými IP adresami a následném pokusu o zvýšení počtu pracovních uzlů v clusteru úloh se instalace zablokuje ve stavu Počet řídicí roviny na hodnotě 2, stále čeká na požadovaný stav: 3. Po určité době se zobrazí další chybová zpráva: Chyba: Časový limit vypršel při čekání na podmínku.

Při spuštění příkazu Get-AksHciCluster se ukázalo, že se uzly řídicí roviny vytvořily a zřídily a byly ve stavu Připraveno . Při kubectl get nodes spuštění se ale ukázalo, že se uzly řídicí roviny vytvořily, ale nezřídily a nebyly ve stavu Připraveno .

Pokud se zobrazí tato chyba, pomocí Správce technologie Hyper-V nebo PowerShellu ověřte, že se k vytvořeným uzlům přiřadily IP adresy:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Pak ověřte nastavení sítě a ujistěte se, že ve fondu zbývá dostatek IP adres pro vytvoření dalších virtuálních počítačů.

Příkazy jako Update-AksHci, Update-AksHciCertificates, Update-AksHciClusterCertificatesa všechny interakce s clusterem pro správu můžou vrátit chybu: Musíte být přihlášení k serveru (Neautorizováno).

K této chybě může dojít v případě, že vypršela platnost souboru kubeconfig . Pokud chcete zkontrolovat, jestli vypršela jeho platnost, spusťte následující skript:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Pokud tento skript zobrazí datum, které je dřívější než aktuální datum, pak vypršela platnost souboru kubeconfig .

Pokud chcete tento problém zmírnit, zkopírujte do hostitele HCI soubor admin.conf , který je uvnitř virtuálního počítače řídicí roviny správy:

• SSH k virtuálnímu počítači řídicí roviny správy:

  • Získejte IP adresu virtuálního počítače v řídicí rovině správy:

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

  • Připojit se k němu SSH:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Zkopírujte soubor do umístění clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Udělení přístupu ke clouduserovi:

  sudo chown clouduser:clouduser admin.conf
  

• [Volitelné] Vytvořte zálohu souboru kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Zkopírujte soubor:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Když zkontrolujete správce technologie Hyper-V, můžete vysoké požadavky na procesor a paměť pro cluster pro správu bezpečně ignorovat. Souvisí se špičkami ve využití výpočetních prostředků při zřizování clusterů úloh.

Zvýšení velikosti paměti nebo procesoru pro cluster pro správu nepřišlo k výraznému zlepšení a můžete ho bez obav ignorovat.

Tento problém se zobrazí, pokud budete postupovat podle těchto kroků:

1. Vytvořte cluster Kubernetes.
2. Škálujte cluster na více než dva uzly.
3. Odstraňte uzel spuštěním následujícího příkazu:

kubectl delete node <node-name>

4. Vraťte seznam uzlů spuštěním následujícího příkazu:

kubectl get nodes

Odebraný uzel není ve výstupu uvedený. 5. Otevřete okno PowerShellu s oprávněními správce a spusťte následující příkaz:

get-vm

Odebraný uzel je stále uvedený.

Toto selhání způsobí, že systém nerozpozná, že uzel chybí, a proto se nový uzel nespustí.

Pokud nepoužíváte cluster pro správu nebo cluster úloh déle než 60 dnů, platnost certifikátů vyprší a před upgradem služby AKS Arc je musíte obnovit. Pokud se cluster AKS neupgraduje do 60 dnů, platnost tokenu modulu plug-in Služby správy klíčů i certifikátů vyprší během 60 dnů. Cluster je stále funkční. Vzhledem k tomu, že je to déle než 60 dní, musíte kvůli upgradu zavolat podporu Microsoftu. Pokud se cluster po této době restartuje, zůstane v nefunkčním stavu.

Pokud chcete tento problém vyřešit, spusťte následující kroky:

1. Opravte certifikát clusteru pro správu ruční obměnou tokenem a pak restartujte modul plug-in a kontejner Služby správy klíčů.
2. Opravte mocctl certifikáty spuštěním příkazu Repair-MocLogin.
3. Opravte certifikáty clusteru úloh ruční obměnou tokenem a pak restartujte modul plug-in a kontejner Služby správy klíčů.

Cluster úloh se nemusí najít, pokud jsou fondy IP adres dvou nasazení AKS ve službě Azure Stack HCI stejné nebo se překrývají. Pokud nasadíte dva hostitele AKS a pro oba použijete stejnou AksHciNetworkSetting konfiguraci, PowerShell a Windows Admin Center cluster úloh pravděpodobně nenajdou, protože serveru rozhraní API se v obou clusterech přiřadí stejná IP adresa, což způsobí konflikt.

Chybová zpráva, která se zobrazí, bude vypadat podobně jako v následujícím příkladu.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

Po dvou hodinách může dojít k vypršení časového limitu nasazení velkého clusteru. Jedná se ale o statický časový limit.

Tento výskyt časového limitu můžete ignorovat, protože operace běží na pozadí. Pomocí příkazu kubectl get nodes získejte přístup ke clusteru a monitorujte průběh.

Při pokusu o vyvolání nasazení AKS ve službě Azure Stack HCI po několika dnech Kubectl nespustí žádný z jeho příkazů. Protokol modulu plug-in Služby správy klíčů (KMS) zobrazil chybovou zprávu rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates.

Pokud je server rozhraní API mimo provoz, rutina Repair-AksHciClusterCerts selže. Pokud se AKS v Azure Stack HCI neupgraduje 60 nebo více dnů, při pokusu o restartování modulu plug-in Služby správy klíčů se nespustí. Toto selhání také způsobí selhání serveru rozhraní API.

Pokud chcete tento problém vyřešit, musíte token ručně otočit a poté restartovat modul plug-in a kontejner Služby správy klíčů, abyste získali zálohu serveru ROZHRANÍ API. Provedete to následovně:

1. Obměňte token spuštěním následujícího příkazu:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Zkopírujte token do virtuálního počítače pomocí následujícího příkazu. Nastavení ip v následujícím příkazu odkazuje na IP adresu řídicí roviny hostitele AKS.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Restartujte modul plug-in Služby správy klíčů a kontejner.

   Pokud chcete získat ID kontejneru, spusťte následující příkaz:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   Výstup by se měl zobrazit s následujícími poli:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   Výstup by měl vypadat podobně jako v tomto příkladu:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Nakonec kontejner restartujte spuštěním následujícího příkazu:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

Při instalaci AKS ve službě Azure Stack HCI s rozšířením Windows Admin Center verze 1.82.0 se cluster pro správu nastavil pomocí PowerShellu a došlo k pokusu o nasazení clusteru úloh pomocí Windows Admin Center. Na jednom z počítačů byl nainstalovaný modul PowerShellu verze 1.0.2 a na jiných počítačích byl nainstalovaný modul PowerShellu 1.1.3. Pokus o nasazení clusteru úloh selhal s chybou "Nelze najít parametr, který odpovídá názvu parametru nodePoolName". K této chybě mohlo dojít kvůli neshodě verzí. Počínaje PowerShellem verze 1.1.0 -nodePoolName <String> se parametr přidal do rutiny New-AksHciCluster a tento parametr je teď záměrně povinný při použití rozšíření Windows Admin Center verze 1.82.0.

Problém můžete vyřešit jednou z těchto akcí:

• Pomocí PowerShellu ručně aktualizujte cluster úloh na verzi 1.1.0 nebo novější.
• Pomocí Windows Admin Center aktualizujte cluster na verzi 1.1.0 nebo na nejnovější verzi PowerShellu.

K tomuto problému nedochází, pokud je cluster pro správu nasazený pomocí Windows Admin Center, protože už má nainstalované nejnovější moduly PowerShellu.

Když nasadíte AKS ve službě Azure Stack HCI a pak spustíte kubectl get pods, pody ve stejném uzlu se zablokují v ukončovacím stavu. Počítač odmítá připojení SSH, protože u uzlu pravděpodobně dochází k vysoké poptávce po paměti. K tomuto problému dochází, protože uzly Windows jsou nadměrně zřízené a nejsou k dispozici žádné rezervy pro základní součásti.

Abyste se této situaci vyhnuli, přidejte do specifikace podu limity prostředků a požadavky na prostředky pro procesor a paměť, abyste zajistili, že uzly nebudou nadměrně zřízené. Uzly Windows nepodporují vyřazování na základě limitů prostředků, takže byste měli odhadnout, kolik budou kontejnery používat, a pak zajistit, aby uzly měly dostatečné množství procesoru a paměti. Další informace najdete v tématu Požadavky na systém.

Automatické škálování clusteru může selhat, pokud na clusteru pro správu hostitele AKS použijete následující zásady Azure: Clustery Kubernetes by neměly používat výchozí obor názvů. K tomu dochází proto, že zásada, která je implementovaná v clusteru pro správu hostitelů AKS, blokuje vytváření profilů automatického škálování ve výchozím oboru názvů. Pokud chcete tento problém vyřešit, zvolte jednu z následujících možností:

• Odinstalujte rozšíření Azure Policy v clusteru pro správu hostitelů AKS. Další informace o odinstalaci rozšíření Azure Policy najdete tady.
• Změňte rozsah zásad Azure tak, aby se vyloučily clustery pro správu hostitelů AKS. Další informace o rozsahech Azure Policy najdete tady.
• U clusteru pro správu hostitelů AKS nastavte režim vynucení zásad na Zakázáno. Další informace o režimu vynucení najdete tady.

Jedná se o známý problém s červencovou aktualizací AKS ve službě Azure Stack HCI (verze 1.0.2.10723). K této chybě dochází, protože během distribuce virtuálních počítačů mezi více sdílených svazků clusteru v systému vypršel časový limit služby CloudAgent.

Pokud chcete tento problém vyřešit, měli byste upgradovat na nejnovější verzi AKS ve službě Azure Stack HCI.

Pokud zřídíte cluster AKS ve službě Azure Stack HCI s nulovými uzly s Linuxem nebo Windows, při spuštění rutiny Get-AksHciCluster bude výstupem prázdný řetězec nebo hodnota null.

Hodnota Null je očekávaná hodnota pro nulové uzly.

Když vypnete cluster pro správu nebo úlohy na více než čtyři dny, platnost certifikátů vyprší a cluster bude nedostupný. Platnost certifikátů vyprší, protože se z bezpečnostních důvodů obměňují každé 3 až 4 dny.

Pokud chcete cluster restartovat, musíte certifikáty před provedením jakýchkoli operací clusteru opravit ručně. Pokud chcete certifikáty opravit, spusťte následující příkaz Repair-AksHciClusterCerts :

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Při horizontálním navýšení kapacity clusteru úloh se odpovídající virtuální počítače s Linuxem a Windows přidaly jako pracovní uzly, ale nenakonfigurovaly se jako virtuální počítače s vysokou dostupností. Při spuštění příkazu Get-ClusterGroup nebyl nově vytvořený virtuální počítač s Linuxem nakonfigurovaný jako skupina clusterů.

Jedná se o známý problém. Po restartování se někdy ztratí možnost nakonfigurovat virtuální počítače jako vysoce dostupné. Aktuálním alternativním řešením je restartování wssdagent na všech uzlech Azure Stack HCI. To funguje jenom pro nové virtuální počítače, které se generují vytvořením fondů uzlů při provádění operace škálování na více instancí nebo při vytváření nových clusterů Kubernetes po restartování wssdagent uzlů. Budete ale muset ručně přidat existující virtuální počítače do clusteru s podporou převzetí služeb při selhání.

Při vertikálním snížení kapacity clusteru jsou prostředky clusteru s vysokou dostupností během odebrání virtuálních počítačů ve stavu selhání. Alternativním řešením tohoto problému je ruční odebrání neúspěšných prostředků.

Cluster AKS nasazený na virtuálním počítači Azure dříve fungoval správně, ale po vypnutí hostitele AKS na několik dní Kubectl příkaz nefungoval. Po spuštění Kubectl get nodes příkazu nebo Kubectl get services se zobrazila tato chybová zpráva: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

K tomuto problému došlo, protože hostitel AKS byl vypnutý po dobu delší než čtyři dny, což způsobilo vypršení platnosti certifikátů. Certifikáty se často obměňují ve čtyřdenním cyklu. Spuštěním příkazu Repair-AksHciClusterCerts opravte problém s vypršením platnosti certifikátu.

V clusteru úloh se statickými IP adresami a uzly Windows jsou všechny pody v uzlu (včetně daemonset podů) zablokované ve stavu ContainerCreating . Při pokusu o připojení k uzlu pomocí SSH připojení selže s chybou Connection timed out .

Pokud chcete tento problém vyřešit, vypněte virtuální počítač tohoto uzlu pomocí Správce technologie Hyper-V nebo Správce clusteru s podporou převzetí služeb při selhání. Po 5 až 10 minutách by se měl uzel znovu vytvořit se spuštěnými pody.

Když je kubelet pod tlakem na disk, shromažďuje nepoužívané image kontejneru, což může zahrnovat pozastavení imagí, a když k tomu dojde, ContainerD nemůže image načíst.

Pokud chcete tento problém vyřešit, spusťte následující kroky:

1. Připojte se k ovlivněným uzlům pomocí SSH a spusťte následující příkaz:

sudo su

2. Pokud chcete image vyžádat, spusťte následující příkaz:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Další kroky

• Přehled řešení potíží
• Problémy se sítěmi a chyby
• známé problémy s úložištěm