Résoudre les problèmes connus et les erreurs lors de la gestion du stockage dans AKS Arc

Cette erreur d’autorisation refusée indique que la classe de stockage par défaut peut ne pas convenir à vos charges de travail, et se produit dans les charges de travail Linux exécutées sur Kubernetes version 1.19.x ou ultérieure. Conformément aux meilleures pratiques en matière de sécurité, de nombreuses charges de travail Linux spécifient le paramètre securityContext fsGroup pour un pod. Les charges de travail ne parviennent pas à démarrer sur AKS sur Azure Local, car la classe de stockage par défaut ne spécifie pas le fstype (=ext4) paramètre. Kubernetes ne parvient donc pas à modifier la propriété des fichiers et des volumes persistants en fonction de la fsGroup charge de travail demandée.

Pour résoudre ce problème, définissez une classe de stockage personnalisée que vous pouvez utiliser pour approvisionner des revendications de volume persistant.

Un nouveau cluster de charge de travail Kubernetes a été créé avec Kubernetes version 1.16.10, puis mis à jour vers la version 1.16.15. Après la mise à jour, le pod csi-msk8scsi-node-9x47m se bloque dans l’état ContainerCreating, et le pod kube-proxy-qqnkr dans l’état Terminating, comme illustré dans la sortie ci-dessous :

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  

Comme kubelet s’est arrêté dans un état incorrect et ne peut plus communiquer avec le serveur d’API, la seule solution est de redémarrer le service kubelet. Après redémarrage, le cluster passe à l’état running.

Le stockage sur disque peut être rempli à partir des journaux de vidage sur incident créés. Ce problème est dû à l’expiration du certificat du client de l’agent Geneva. Les symptômes peuvent être les suivants :

• Les services ne parviennent pas à démarrer.
• Les pods Kubernetes, les déploiements, etc. ne parviennent pas à démarrer en raison de ressources insuffisantes.

Ce problème peut avoir un impact sur toute opération impliquant l’allocation d’espace disque ou l’écriture de nouveaux fichiers. Toute erreur « espace disque/ressources insuffisant » est donc un bon indicateur. Pour vérifier si ce problème est présent sur un nœud donné, exécutez la commande shell suivante :

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

Cette commande signale l’espace de stockage consommé par les fichiers de diagnostic.

Origine

L’expiration du certificat client utilisé pour authentifier l’agent de Genève auprès du point de terminaison de service provoque le blocage de l’agent, ce qui entraîne un vidage sur incident. La boucle de blocage/nouvelle tentative de l’agent est d’environ 5 secondes au démarrage initial et il n’y a pas de délai d’expiration. Cela signifie qu’un nouveau fichier (environ 330 Mo) est créé sur le système de fichiers du nœud toutes les quelques secondes, ce qui peut consommer rapidement le stockage sur disque.

Limitation des risques

L’atténuation recommandée consiste à effectuer une mise à niveau vers la dernière version, version 1.10.18.10425, qui a un certificat mis à jour. Pour ce faire, commencez par mettre à niveau manuellement vos clusters de charge de travail vers n’importe quelle version mineure prise en charge avant de mettre à jour votre hôte local Azure.

Pour plus d’informations sur les versions d’AKS Arc et toutes les dernières actualités AKS sur Azure Local, abonnez-vous à la page des versions AKS.

Si la mise à niveau n’est pas une option, vous pouvez désactiver le service mdsd . Pour chaque nœud Mariner :

1. Désactivez l’agent de Genève avec les commandes shell suivantes :

   sudo systemctl disable --now mdsd
   

2. Vérifiez que l’agent de Genève a été correctement désactivé :

   sudo systemctl status mdsd
   

3. Supprimez les fichiers cumulés avec la commande suivante :

   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. Redémarrez le nœud :

   sudo reboot
   

Une erreur peut se produire si un pilote CSI SMB ou NFS est installé dans votre déploiement et que vous effectuez une mise à niveau vers la build mai à partir d’une version antérieure. L’un des paramètres, appelé createSubDir, n’est plus accepté. Si cela s’applique à votre déploiement, suivez les instructions ci-dessous pour résoudre l’échec de la classe de stockage.

Si vous rencontrez cette erreur, le pod de stockage se bloque et les journaux indiquent que le createSubDir paramètre n’est pas valide.

Recréez la classe de stockage.

Après la suppression d’un volume persistant ou d’une revendication de volume persistant dans un environnement AKS Arc, un nouveau volume persistant est créé pour être mappé au même partage. Toutefois, pendant la tentative de montage du volume, le montage échoue et le pod expire avec l’erreur NewSmbGlobalMapping failed.

Pour contourner le problème de montage du nouveau volume, vous pouvez vous connecter avec SSH au nœud Windows et exécuter Remove-SMBGlobalMapping, puis fournir le partage qui correspond au volume. Après l’exécution de cette commande, la tentative de montage du volume devrait aboutir.

Étapes suivantes

• Vue d’ensemble de la résolution des problèmes
• Problèmes connus dans Windows Admin Center