Ez a cikk segítséget nyújt a tárterülettel kapcsolatos problémák elhárításában és megoldásában az AKS Arcban.
Az állandó kötetjogcímek konfigurálása a következő hibaüzenetet eredményezi: "Nem lehet inicializálni az ügynököt. Hiba: mkdir /var/log/agent: engedély megtagadva"
Ez az engedély megtagadva hiba azt jelzi, hogy az alapértelmezett tárolási osztály nem felel meg a számítási feladatoknak, és a Kubernetes 1.19.x-es vagy újabb verzióján futó Linux-számítási feladatokban fordul elő. A biztonsági ajánlott eljárásokat követve számos Linux-számítási feladat határozza meg a securityContext fsGroup
pod beállításait. A számítási feladatok nem indulnak el az AKS-en az Azure Stack HCI-n, mivel az alapértelmezett tárolási osztály nem adja meg a fstype (=ext4)
paramétert, így a Kubernetes nem tudja módosítani a fájlok és az állandó kötetek tulajdonjogát a fsGroup
számítási feladat kérése alapján.
A probléma megoldásához definiáljon egy egyéni tárolási osztályt , amellyel kiépítheti a PVC-ket.
Tárolótároló-adapter podja "ContainerCreating" állapotban elakadt
Új Kubernetes számítási feladatfürt jött létre a Kubernetes 1.16.10-es verziójával, majd az 1.16.15-ös verzióra frissült. A frissítés után a csi-msk8scsi-node-9x47m
pod elakadt a ContainerCreating állapotban, és a kube-proxy-qqnkr
pod leállási állapotban volt az alábbi kimenetben látható módon:
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
Mivel kubelet
végül rossz állapotban lett, és már nem tud beszélni az API-kiszolgálóval, az egyetlen megoldás a szolgáltatás újraindítása kubelet
. Az újraindítás után a fürt futó állapotba kerül.
Az összeomlási memóriakép naplóiból feltöltött lemeztároló
A lemeztároló feltölthető a létrehozott összeomlási memóriakép-naplókból. Ennek oka egy lejárt genfi ügynök ügyféltanúsítványa. A tünetek a következők lehetnek:
- A szolgáltatások nem indulnak el.
- A Kubernetes-podok, üzemelő példányok stb. nem indulnak el, mert nincs elegendő erőforrás.
Fontos
Ez a probléma a 2022. április 18. és 2023. március közötti kiadásokban létrehozott összes új Mariner-felügyeleti és célfürt-csomópontra hatással lehet. A problémát a 2023-05-09-es és újabb kiadásban javítottuk.
Ez a probléma hatással lehet minden olyan műveletre, amely lemezterület lefoglalásával vagy új fájlok írásával jár, ezért a "nincs elegendő lemezterület/erőforrás" hiba jó tipp. Annak ellenőrzéséhez, hogy ez a probléma jelen van-e egy adott csomóponton, futtassa a következő rendszerhéjparancsot:
clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/
Ez a parancs a diagnosztikai fájlok által felhasznált tárterületet jelenti.
Gyökérok
A Geneva-ügynök szolgáltatásvégpontra történő hitelesítéséhez használt ügyféltanúsítvány lejárata az ügynök összeomlását okozza, ami összeomlási memóriaképet eredményez. Az ügynök összeomlási/újrapróbálkozési ciklusa a kezdeti indításkor körülbelül 5 másodperc, és nincs időtúllépés. Ez azt jelenti, hogy néhány másodpercenként létrejön egy új fájl (körülbelül 330 MB) a csomópont fájlrendszerén, amely gyorsan felhasználhatja a lemezterületet.
Kockázatcsökkentés
Az előnyben részesített kockázatcsökkentés a legújabb, frissített tanúsítvánnyal rendelkező 1.10.18.10425-ös verzióra való frissítés. Ehhez az AKS-HCI-gazdagép frissítése előtt először frissítse manuálisan a számítási feladatfürtöket bármely támogatott alverzióra .
Az AKS Arc kiadásairól és az AKS-HCI legújabb híreiről az AKS kiadási oldalára feliratkozhat.
Ha a frissítés nem lehetőség, kikapcsolhatja az mdsd szolgáltatást. Minden Mariner-csomópont esetében:
Kapcsolja ki a Genfi ügynököt a következő rendszerhéj-parancsokkal:
sudo systemctl disable --now mdsd
Ellenőrizze, hogy a genfi ügynök sikeresen le lett-e tiltva:
sudo systemctl status mdsd
Törölje a halmozott fájlokat a következő paranccsal:
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
Indítsa újra a csomópontot:
sudo reboot
A tároló podja összeomlik, és a naplók szerint a createSubDir paraméter érvénytelen
Hiba akkor fordulhat elő, ha telepítve van egy SMB- vagy NFS CSI-illesztőprogram az üzemelő példányban, és egy régebbi verzióról frissít a májusi buildre. Az egyik nevű createSubDir
paraméter már nem fogadható el. Ha ez az üzemelő példányra vonatkozik, kövesse az alábbi utasításokat a tárolási osztály hibájának elhárításához.
Ha ezt a hibát tapasztalja, a tároló podja összeomlik, és a naplók azt jelzik, hogy a createSubDir
paraméter érvénytelen.
Hozza létre újra a tárosztályt.
Állandó kötet létrehozásakor a kötet csatlakoztatási kísérlete meghiúsul
Miután töröl egy állandó kötetet vagy egy állandó kötetkövetelményt egy AKS Arc-környezetben, létrejön egy új állandó kötet, amely ugyanahhoz a megosztáshoz lesz megfeleltetve. A kötet csatlakoztatásának megkísérlésekor azonban a csatlakoztatás sikertelen lesz, és a pod túllépi az időkorlátot a következő hibával: NewSmbGlobalMapping failed
.
Az új kötet csatlakoztatásának sikertelenségével kapcsolatos problémák megoldásához SSH-t használhat a Windows-csomópontra, és futtathatja Remove-SMBGlobalMapping
és megadhatja a kötetnek megfelelő megosztást. A parancs futtatása után a kötet csatlakoztatásának sikeresnek kell lennie.