Řešení potíží se správou Kubernetes a clusterem úloh ve službě AKS Arc

Když spustíte příkaz Remove-ClusterNode , uzel se vyřadí z clusteru s podporou převzetí služeb při selhání, ale pokud příkaz Remove-AksHciNode není následně spuštěný, uzel bude stále existovat v CloudAgent.

Vzhledem k tomu, že uzel byl odebrán z clusteru, ale ne z CloudAgent, pokud k vytvoření nového uzlu použijete virtuální pevný disk, zobrazí se chyba Soubor nenalezen. 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 fyzický uzel z clusteru a pak postupujte takto:

1. Spuštěním zrušte Remove-AksHciNode registraci uzlu z CloudAgent.
2. Proveďte běžnou údržbu, jako je opětovné zobrazení počítače.
3. Přidejte uzel zpět do clusteru.
4. Spuštěním zaregistrujte Add-AksHciNode uzel v CloudAgent.

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

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

Po upgradu nebo vertikálním navýšení kapacity clusteru úloh je pod prodlužování certifikátů nyní ve stavu smyček chyb, protože pod očekává soubor YAML pro tetování certifikátu 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ích uzlů.

Pokud chcete tento problém vyřešit, zkopírujte ručně soubor YAML pro tetování certifikátu 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. Než soubor zkopírujete, musíte změnit název počítače v souboru YAML na název uzlu, do kterého kopírujete (jedná se o název uzlu řídicí roviny clusteru úloh).

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

3. Pokud informace vlastníka a skupiny v souboru YAML ještě nejsou nastavené na root, nastavte informace na kořenový adresář:

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 před vytvořením uzlů Kubernetes neověřují dostupnou paměť na hostitelském serveru. Tento problém může vést k vyčerpání paměti a virtuálním počítačům, které se nespustí.

Toto selhání se v současné době nezpracuje elegantně 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 pro spuštění virtuálního počítače není dostatek paměti.

Při spuštění rutiny Get-AksHciCluster pro ověření stavu instalace AKS Arc v Centru pro správu Windows se ve výstupu zobrazí chyba Verze 1.0.3.10818 nebyla nalezena. Při spuštění rutiny Get-AksHciVersion se však zobrazila stejná verze. Tato chyba značí, že platnost sestavení vypršela.

Pokud chcete tento problém vyřešit, spusťte Uninstall-AksHcia spusťte nový build AKS Arc.

Pokud pomocí nástroje pro správu clusteru přesunete virtuální počítač z jednoho uzlu (Node A) do jiného uzlu (Node B) v místním clusteru Azure, virtuální počítač se nemusí podařit spustit na novém uzlu. Po přesunutí virtuálního počítače zpět do původního uzlu se 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 "aktualizace umístění virtuálního počítače" ve službě Azure Kubernetes Service najde virtuální počítač na původním hyper-V na uzlu A a odstraní ho, místo aby ho nezaregistrovává.

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

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

Při spuštění 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 však ukázalo, že uzly řídicí roviny byly vytvořeny, ale nebyly zřízeny a nebyly ve stavu Připraveno .

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

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

Pak ověřte nastavení sítě, abyste měli jistotu, že ve fondu zbývá dostatek IP adres, aby se vytvořilo více virtuálních počítačů.

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

K této chybě může dojít při vypršení platnosti souboru kubeconfig . Pokud chcete zkontrolovat, jestli jeho platnost vypršela, 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, vypršela platnost souboru kubeconfig .

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

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

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

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

  • Připojte 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
  

Při kontrole správce Technologie Hyper-V je možné bezpečně ignorovat vysoké požadavky na procesor a paměť pro cluster pro správu. Souvisí se špičkami 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 nezobrazovalo významné zlepšení a dá se bezpečně ignorovat.

Tento problém se zobrazí, pokud budete postupovat následovně:

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. Spuštěním následujícího příkazu vraťte seznam uzlů:

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

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

Pokud cluster pro správu nebo úlohu nepoužíváte 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íčů a certifikátů vyprší během 60 dnů. Cluster je stále funkční. Vzhledem k tomu, že je to delší než 60 dnů, musíte zavolat na podporu Microsoftu a upgradovat. Pokud se cluster po tomto období 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 token a pak restartujte modul plug-in a kontejner Služby správy klíčů.
2. Opravte mocctl certifikáty spuštěním Repair-MocLoginpříkazu .
3. Opravte certifikáty clusteru úloh ruční obměnou token a restartujte modul plug-in a kontejner Služby správy klíčů.

Cluster úloh se nemusí najít, pokud jsou fondy IP adres dvou AKS v místních nasazeních Azure stejné nebo se překrývají. Pokud nasadíte dva hostitele AKS a použijete stejnou AksHciNetworkSetting konfiguraci pro oba, PowerShell i Centrum pro správu Windows pravděpodobně cluster úloh nenajde, protože server rozhraní API bude mít v obou clusterech přiřazenou stejnou IP adresu, což vede ke konfliktu.

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.

Nasazení velkého clusteru může vypršovat po dvou hodinách. Jedná se ale o statický časový limit.

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

Při pokusu o vyvolání AKS v místním nasazení Azure po několika dnech Kubectl se nespustí žádný z jeho příkazů. V protokolu modulu plug-in Služba správy klíčů (KMS) se zobrazila chybová zpráva 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 Local neupgradovalo po dobu 60 nebo déle, 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 pak restartovat modul plug-in a kontejner Služby správy klíčů, abyste získali zálohu serveru API. Provedete to následovně:

1. Otoč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. Pomocí následujícího příkazu zkopírujte token do virtuálního počítače. 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.

   ID kontejneru získáte spuštěním následujícího příkazu:

   $ 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 restartujte kontejner spuštěním následujícího příkazu:

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

V místní instalaci AKS v Azure 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í centra Windows Admin Center. Jeden z počítačů měl nainstalovaný modul PowerShell verze 1.0.2 a ostatní počítače měly nainstalovaný modul PowerShell 1.1.3. Pokus o nasazení clusteru úloh selhal s chybou Parametr nejde najít, 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ď 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í Centra pro správu Windows 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í Centra pro správu Windows, protože už má nainstalované nejnovější moduly PowerShellu.

Když nasadíte AKS v Azure Local a pak spustíte kubectl get pods, pody ve stejném uzlu se zablokují ve stavu Ukončení . Počítač odmítne 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 Systému Windows jsou nadměrně zřízené a pro základní komponenty není žádná rezerva.

Pokud se chcete této situaci vyhnout, přidejte do specifikace podu limity prostředků a požadavky na prostředky pro procesor a paměť, abyste zajistili, že uzly nejsou nadměrně zřízené. Uzly Windows nepodporují vyřazení na základě limitů prostředků, takže byste měli odhadnout, kolik kontejnerů bude používat, a pak zajistit, aby uzly měly dostatek procesoru a paměti. Další informace najdete v požadavcích na systém.

Automatické škálování clusteru může selhat, když ve svém clusteru pro správu hostitelů 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 při implementaci 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 oborech služby Azure Policy najdete tady.
• Pro cluster 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 se službou AKS v místní červencové aktualizaci Azure (verze 1.0.2.10723). K této chybě dochází, protože během distribuce virtuálních počítačů napříč několika sdílenými svazky clusteru v systému vyprší časový limit služby CloudAgent.

Pokud chcete tento problém vyřešit, měli byste upgradovat na nejnovější verzi AKS v místní verzi Azure.

Pokud zřídíte cluster AKS v Azure Local s nulovým linuxovým nebo windows uzlem, při spuštění Get-AksHciCluster bude výstup prázdný řetězec nebo hodnota null.

Null je očekávaný návrat pro nulové uzly.

Když vypnete cluster správy nebo úloh déle než čtyři dny, platnost certifikátů vyprší a cluster je nedostupný. Platnost certifikátů vyprší, protože se z bezpečnostních důvodů obměňují každých 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 vysoce dostupné virtuální počítače. Při spuštění příkazu Get-ClusterGroup se nově vytvořený virtuální počítač s Linuxem nenakonfiguroval jako skupina clusteru.

Jedná se o známý problém. Po restartování se někdy ztratí možnost konfigurovat virtuální počítače jako vysoce dostupné. Aktuální alternativní řešení je restartovat wssdagent na všech místních uzlech Azure. To funguje pouze pro nové virtuální počítače, které jsou generovány vytvořením fondů uzlů při provádění operace horizontálního navýšení kapacity nebo při vytváření nových clusterů Kubernetes po restartování wssdagent uzlů. Existující virtuální počítače ale budete muset do clusteru s podporou převzetí služeb při selhání přidat ručně.

Při vertikálním snížení kapacity clusteru jsou prostředky clusteru s vysokou dostupností ve stavu selhání, když se virtuální počítače odeberou. Alternativním řešením tohoto problému je ruční odebrání prostředků, které selhaly.

Cluster AKS nasazený na virtuálním počítači Azure dříve fungoval správně, ale po vypnutí hostitele AKS několik dní Kubectl příkaz nefungoval. Po spuštění příkazu Kubectl get nodes nebo příkazu Kubectl get services se zobrazí 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ý déle než čtyři dny, což způsobilo vypršení platnosti certifikátů. Certifikáty se často obměňují ve čtyřdenním cyklu. Spusťte Repair-AksHciClusterCerts a opravte problém s vypršením platnosti certifikátu.

V clusteru úloh se statickými IP adresami a uzly Windows se všechny pody v uzlu (včetně daemonset podů) zablokují ve stavu ContainerCreating . Při pokusu o připojení k uzlu pomocí SSH se připojení nezdaří 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 všemi spuštěnými pody.

Když je kubelet pod tlakem disku, shromažďuje nepoužívané image kontejneru, které můžou zahrnovat pozastavení imagí, a když k tomu dojde, ContainerD nemůže image vyžádat.

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

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

sudo su

2. Pokud chcete načíst image, 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