Upravit

Sdílet prostřednictvím

Oprava známých problémů a chyb při správě úložiště ve službě AKS Arc

  • Časté otázky

Tento článek vám pomůže vyřešit problémy související s úložištěm ve službě AKS Arc.

Při konfiguraci trvalých deklarací identity svazku dojde k chybě: Nejde inicializovat agenta. Chyba: mkdir /var/log/agent: oprávnění odepřeno"

Tato chyba odepření oprávnění značí, že výchozí třída úložiště nemusí být vhodná pro vaše úlohy a dochází k nim v úlohách Linuxu spuštěných nad Kubernetes verze 1.19.x nebo novější. Podle osvědčených postupů zabezpečení určuje mnoho úloh Linuxu securityContext fsGroup nastavení podu. Úlohy se nespustí v AKS v Azure Local, protože výchozí třída úložiště nezadá fstype (=ext4) parametr, takže Kubernetes nezmění vlastnictví souborů a trvalých svazků na fsGroup základě požadované úlohy.

Pokud chcete tento problém vyřešit, definujte vlastní třídu úložiště, kterou můžete použít ke zřízení pvcs.

Pod rozhraní úložiště kontejnerů se zablokoval ve stavu ContainerCreating

Vytvořil se nový cluster úloh Kubernetes s Kubernetes verze 1.16.10 a pak se aktualizoval na 1.16.15. Po aktualizaci csi-msk8scsi-node-9x47m se pod zablokoval ve stavu ContainerCreating a kube-proxy-qqnkr pod se zasekl ve stavu Ukončení , jak je znázorněno v následujícím výstupu:

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m

Vzhledem k tomu, že kubelet skončil ve špatném stavu a už nemůže komunikovat se serverem rozhraní API, jediným řešením je restartovat kubelet službu. Po restartování cluster přejde do spuštěného stavu.

Diskové úložiště vyplněné z protokolů výpisu stavu systému

Diskové úložiště je možné vyplnit z vytvořených protokolů výpisu stavu systému. Důvodem je vypršení platnosti klientského certifikátu agenta Geneva. Příznaky mohou být následující:

  • Služby se nespustí.
  • Pody Kubernetes, nasazení atd. nejde spustit kvůli nedostatečným prostředkům.

Důležité

Tento problém může mít vliv na všechny nové uzly clusteru Mariner a cílové uzly clusteru vytvořené po 18. dubnu 2023 ve verzích od dubna 2022 do března 2023. Tento problém je opravený ve verzi 2023-05-09 a novější.

Tento problém může mít vliv na jakoukoli operaci, která zahrnuje přidělení místa na disku nebo zápis nových souborů, takže jakákoli chyba nedostatku místa na disku nebo prostředků je dobrou nápovědou. Pokud chcete zkontrolovat, jestli tento problém na daném uzlu existuje, spusťte následující příkaz prostředí:

clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/

Tento příkaz hlásí prostor úložiště spotřebovaný diagnostickými soubory.

Původní příčina

Vypršení platnosti klientského certifikátu použitého k ověření agenta Geneva v koncovém bodu služby způsobí chybové ukončení agenta, což vede k výpisu stavu systému. Smyčka selhání nebo opakování agenta je při počátečním spuštění přibližně 5 sekund a neexistuje žádný časový limit. To znamená, že se v systému souborů uzlu každých několik sekund vytvoří nový soubor (přibližně 330 MB), který dokáže rychle využívat diskové úložiště.

Zmírnění

Upřednostňovaným zmírněním rizik je upgrade na nejnovější verzi verze 1.10.18.10425 s aktualizovaným certifikátem. Uděláte to tak, že před aktualizací místního hostitele Azure nejprve ručně upgradujete clustery úloh na jakoukoli podporovanou podverzi .

Další informace o vydaných verzích AKS Arc a všech nejnovějších verzích AKS v místních novinkách Azure najdete na stránce vydaných verzí AKS.

Pokud upgrade není možné, můžete službu mdsd vypnout. Pro každý uzel Mariner:

  1. Vypněte agenta Geneva pomocí následujících příkazů prostředí:

    sudo systemctl disable --now mdsd

  2. Ověřte, že agent Geneva byl úspěšně zakázán:

    sudo systemctl status mdsd

  3. Odstraňte kumulované soubory pomocí následujícího příkazu:

    sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \;
sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete
sudo journalctl --rotate && sudo journalctl --vacuum-size=500M

  4. Restartujte uzel:

    sudo reboot

Pod úložiště se chybově ukončí a protokoly říkají, že parametr createSubDir je neplatný.

K chybě může dojít v případě, že máte v nasazení nainstalovaný ovladač CSI protokolu SMB nebo NFS a upgradujete na květnový build ze starší verze. Jeden z parametrů, který se nazývá createSubDir, již není přijat. Pokud se to týká vašeho nasazení, vyřešte selhání třídy úložiště podle následujících pokynů.

Pokud dojde k této chybě, pod úložiště se chybově ukončí a protokoly značí, že createSubDir parametr je neplatný.

Znovu vytvořte třídu úložiště.

Při vytváření trvalého svazku se pokus o připojení svazku nezdaří.

Po odstranění trvalého svazku nebo deklarace identity trvalého svazku v prostředí AKS Arc se vytvoří nový trvalý svazek, který se mapuje na stejnou sdílenou složku. Při pokusu o připojení svazku se však připojení nezdaří a pod vyprší s chybou . NewSmbGlobalMapping failed

Pokud chcete obejít selhání připojení nového svazku, můžete SSH připojit k uzlu Windows a spustit Remove-SMBGlobalMapping a poskytnout sdílenou složku, která odpovídá svazku. Po spuštění tohoto příkazu by pokus o připojení svazku měl proběhnout úspěšně.

Další kroky