Bekende problemen en fouten oplossen bij het beheren van opslag in AKS Arc

Deze fout geeft aan dat de standaardopslagklasse mogelijk niet geschikt is voor uw workloads en optreedt in Linux-workloads die worden uitgevoerd boven op Kubernetes versie 1.19.x of hoger. Volgens best practices voor beveiliging geven veel Linux-workloads de securityContext fsGroup instelling voor een pod op. De workloads kunnen niet worden gestart op AKS in Azure Stack HCI omdat de standaardopslagklasse de fstype (=ext4) parameter niet opgeeft, waardoor Kubernetes het eigendom van bestanden en permanente volumes niet kan wijzigen op basis van de fsGroup aangevraagde workload.

U kunt dit probleem oplossen door een aangepaste opslagklasse te definiëren die u kunt gebruiken om HPC's in te richten.

Er is een nieuw Kubernetes-workloadcluster gemaakt met Kubernetes versie 1.16.10 en vervolgens bijgewerkt naar 1.16.15. Na de update is de csi-msk8scsi-node-9x47m pod vastgelopen in de status ContainerCreating en is de kube-proxy-qqnkr pod vastgelopen in de afsluitstatus , zoals wordt weergegeven in de onderstaande uitvoer:

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  

Omdat kubelet deze in een slechte status terecht is gekomen en niet meer kan communiceren met de API-server, is de enige oplossing het opnieuw starten van de kubelet service. Na het opnieuw opstarten wordt het cluster uitgevoerd .

Schijfopslag kan worden opgevuld vanuit crashdumplogboeken die worden gemaakt. Dit komt door een verlopen Geneva-agentclientcertificaat. De symptomen kunnen als volgt zijn:

• Services kunnen niet worden gestart.
• Kubernetes-pods, implementaties, enzovoort kunnen niet worden gestart vanwege onvoldoende resources.

Dit probleem kan van invloed zijn op elke bewerking waarbij schijfruimte wordt toegewezen of nieuwe bestanden worden geschreven, dus een eventuele fout 'onvoldoende schijfruimte/resources' is een goede hint. Voer de volgende shell-opdracht uit om te controleren of dit probleem aanwezig is op een bepaald knooppunt:

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

Met deze opdracht wordt de opslagruimte gerapporteerd die wordt verbruikt door de diagnostische bestanden.

Hoofdoorzaak

Het verlopen van het clientcertificaat dat wordt gebruikt om de Geneva-agent te verifiëren bij het service-eindpunt, zorgt ervoor dat de agent vastloopt, wat resulteert in een crashdump. De lus voor vastlopen/opnieuw proberen van de agent duurt ongeveer 5 seconden bij de eerste start en er is geen time-out. Dit betekent dat er elke paar seconden een nieuw bestand (ongeveer 330 MB) wordt gemaakt in het bestandssysteem van het knooppunt, dat snel schijfopslag kan verbruiken.

Oplossing

De voorkeursbeperking is om een upgrade uit te voeren naar de nieuwste versie, versie 1.10.18.10425, die een bijgewerkt certificaat heeft. Hiervoor moet u eerst uw workloadclusters handmatig upgraden naar een ondersteunde secundaire versie voordat u uw AKS-HCI-host bijwerkt.

Abonneer u op de pagina AKS-releases voor meer informatie over AKS Arc-releases en het laatste AKS-HCI-nieuws.

Als upgraden geen optie is, kunt u de mdsd-service uitschakelen. Voor elk Mariner-knooppunt:

1. Schakel de Geneva-agent uit met de volgende shell-opdrachten:

   sudo systemctl disable --now mdsd
   

2. Controleer of de Geneva-agent is uitgeschakeld:

   sudo systemctl status mdsd
   

3. Verwijder verzamelde bestanden met de volgende opdracht:

   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. Start het knooppunt opnieuw op:

   sudo reboot
   

Er kan een fout optreden als u een SMB- of NFS CSI-stuurprogramma hebt geïnstalleerd in uw implementatie en u een upgrade uitvoert naar de build van mei vanaf een oudere versie. Een van de parameters, genaamd createSubDir, wordt niet meer geaccepteerd. Als dit van toepassing is op uw implementatie, volgt u de onderstaande instructies om de fout met de opslagklasse op te lossen.

Als deze fout optreedt, loopt de opslagpod vast en geven de logboeken aan dat de createSubDir parameter ongeldig is.

Maak de opslagklasse opnieuw.

Na het verwijderen van een permanent volume of een permanente volumeclaim in een AKS Arc-omgeving, wordt een nieuw permanent volume gemaakt om aan dezelfde share toe te wijzen. Wanneer u echter probeert het volume te koppelen, mislukt de koppeling en treedt er een time-out op voor de pod met de fout NewSmbGlobalMapping failed.

Als u de fout bij het koppelen van het nieuwe volume wilt omzeilen, kunt u SSH uitvoeren in het Windows-knooppunt en Remove-SMBGlobalMapping de share opgeven die overeenkomt met het volume. Na het uitvoeren van deze opdracht moeten pogingen om het volume te koppelen slagen.

Volgende stappen

• Overzicht van probleemoplossing
• bekende problemen Windows Admin Center