Åtgärda kända problem och fel vid hantering av lagring i AKS Arc

Det här felet om nekad behörighet anger att standardlagringsklassen kanske inte är lämplig för dina arbetsbelastningar och inträffar i Linux-arbetsbelastningar som körs ovanpå Kubernetes version 1.19.x eller senare. Enligt metodtips för säkerhet anger många Linux-arbetsbelastningar inställningen securityContext fsGroup för en podd. Arbetsbelastningarna startar inte på AKS på Azure Local eftersom standardlagringsklassen inte anger parametern fstype (=ext4) , så Kubernetes kan inte ändra ägarskapet för filer och beständiga volymer baserat på den fsGroup begärda av arbetsbelastningen.

Lös problemet genom att definiera en anpassad lagringsklass som du kan använda för att etablera datorer.

Ett nytt Kubernetes-arbetsbelastningskluster skapades med Kubernetes version 1.16.10 och uppdaterades sedan till 1.16.15. Efter uppdateringen csi-msk8scsi-node-9x47m fastnade podden i containerskapningstillståndet kube-proxy-qqnkr och podden fastnade i tillståndet Avslutande enligt utdata nedan:

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  

Eftersom kubelet hamnade i ett felaktigt tillstånd och inte längre kan prata med API-servern är den enda lösningen att starta om kubelet tjänsten. När du har startat om hamnar klustret i ett körningstillstånd .

Disklagring kan fyllas i från kraschdumploggar som skapas. Detta beror på ett utgånget klientcertifikat för Geneva-agent. Symtomen kan vara följande:

• Det går inte att starta tjänsterna.
• Kubernetes-poddar, distributioner osv. startar inte på grund av otillräckliga resurser.

Det här problemet kan påverka alla åtgärder som innebär att diskutrymme allokeras eller nya filer skrivs, så eventuella "otillräckligt diskutrymme/resurser"-fel är ett bra tips. Kontrollera om det här problemet finns på en viss nod genom att köra följande gränssnittskommando:

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

Det här kommandot rapporterar det lagringsutrymme som förbrukas av diagnostikfilerna.

Rotorsak

Förfallodatumet för det klientcertifikat som används för att autentisera Genève-agenten till tjänstslutpunkten gör att agenten kraschar, vilket resulterar i en kraschdump. Agentens krasch-/återförsöksloop är cirka 5 sekunder vid den första starten och det finns ingen tidsgräns. Det innebär att en ny fil (cirka 330 MB) skapas i nodens filsystem med några sekunders mellanrum, vilket snabbt kan förbruka disklagring.

Riskreducering

Den bästa lösningen är att uppgradera till den senaste versionen, version 1.10.18.10425, som har ett uppdaterat certifikat. Det gör du genom att först manuellt uppgradera dina arbetsbelastningskluster till valfri delversion som stöds innan du uppdaterar din lokala Azure-värd.

Om du vill ha mer information om AKS Arc-versioner och alla de senaste AKS-nyheterna i Azure Local kan du prenumerera på sidan med AKS-versioner.

Om uppgradering inte är ett alternativ kan du inaktivera mdsd-tjänsten . För varje Mariner-nod:

1. Inaktivera Genève-agenten med följande gränssnittskommandon:

   sudo systemctl disable --now mdsd
   

2. Kontrollera att Genèveagenten har inaktiverats:

   sudo systemctl status mdsd
   

3. Ta bort ackumulerade filer med följande kommando:

   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. Starta om noden:

   sudo reboot
   

Ett fel kan inträffa om du har en SMB- eller NFS CSI-drivrutin installerad i distributionen och du uppgraderar till majversionen från en äldre version. En av parametrarna, som kallas createSubDir, accepteras inte längre. Om detta gäller för distributionen följer du anvisningarna nedan för att lösa problemet med lagringsklassen.

Om det här felet uppstår kraschar lagringspodden och loggarna anger att parametern createSubDir är ogiltig.

Återskapa lagringsklassen.

När du har raderat en beständig volym eller ett beständiga volymanspråk i en AKS Arc-miljö skapas en ny beständiga volym för mappning till samma resurs. Men när du försöker montera volymen misslyckas monteringen och podden överskrider tidsgränsen med felet . NewSmbGlobalMapping failed

Om du vill undvika misslyckandet med att montera den nya volymen kan du SSH till Windows-noden och köra Remove-SMBGlobalMapping och ange den resurs som motsvarar volymen. När du har kört det här kommandot bör försöken att montera volymen lyckas.

Nästa steg

• Felsökningsöversikt
• Kända problem med Windows Admin Center