Correction des problèmes et erreurs connus 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 démarrent pas sur AKS sur Azure Stack HCI, 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 demande de la charge de travail.

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. Cela est dû à un certificat client de l’agent Geneva expiré. Les symptômes peuvent être les suivants :

• Les services ne démarrent pas.
• 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 n’importe quelle opération qui implique l’allocation d’espace disque ou l’écriture de nouveaux fichiers. Par conséquent, toute erreur « espace disque/ressources insuffisants » est une bonne indication. Pour case activée 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.

Cause racine

L’expiration du certificat client utilisé pour authentifier l’agent Geneva auprès du point de terminaison de service provoque le blocage de l’agent, ce qui entraîne un vidage sur incident. La boucle d’incident/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 rapidement consommer du stockage sur disque.

Limitation des risques

L’atténuation par défaut consiste à mettre à niveau vers la dernière version, la 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 AKS-HCI.

Pour plus d’informations sur les versions d’AKS Arc et toutes les dernières actualités d’AKS-HCI, abonnez-vous à la page des versions d’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 Geneva avec les commandes d’interpréteur de commandes suivantes :

   sudo systemctl disable --now mdsd
   

2. Vérifiez que l’agent Geneva a été correctement désactivé :

   sudo systemctl status mdsd
   

3. Supprimez les fichiers accumulé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 vous avez installé un pilote CSI SMB ou NFS 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éer 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 mapper 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