Risolvere i problemi noti e gli errori durante la gestione dell'archiviazione in Azure Kubernetes Arc

Questo errore di autorizzazione negata indica che la classe di archiviazione predefinita potrebbe non essere adatta per i carichi di lavoro e si verifica nei carichi di lavoro Linux in esecuzione nella versione 1.19.x o successiva di Kubernetes. Seguendo le procedure consigliate per la sicurezza, molti carichi di lavoro Linux specificano l'impostazione securityContext fsGroup per un pod. Non è possibile avviare i carichi di lavoro nel servizio Azure Kubernetes in Locale di Azure perché la classe di archiviazione predefinita non specifica il fstype (=ext4) parametro, pertanto Kubernetes non riesce a modificare la proprietà dei file e dei volumi permanenti in base all'oggetto fsGroup richiesto dal carico di lavoro.

Per risolvere questo problema, definire una classe di archiviazione personalizzata che è possibile usare per effettuare il provisioning dei pvC.

Un nuovo cluster del carico di lavoro Kubernetes è stato creato con Kubernetes versione 1.16.10 e quindi aggiornato alla versione 1.16.15. Dopo l'aggiornamento, il csi-msk8scsi-node-9x47m pod è rimasto bloccato nello stato ContainerCreating e il kube-proxy-qqnkr pod è rimasto bloccato nello stato terminazione , come illustrato nell'output seguente:

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  

Poiché kubelet è finito in uno stato non valido e non può più comunicare con il server API, l'unica soluzione consiste nel riavviare il kubelet servizio. Dopo il riavvio, il cluster entra in uno stato di esecuzione .

L'archiviazione su disco può essere riempita dai log di dump di arresto anomalo del sistema creati. Questo è dovuto a un certificato client dell'agente Geneva scaduto. I sintomi possono essere i seguenti:

• L'avvio dei servizi non riesce.
• I pod Kubernetes, le distribuzioni e così via non vengono avviati a causa di risorse insufficienti.

Questo problema può influire su qualsiasi operazione che comporta l'allocazione dello spazio su disco o la scrittura di nuovi file, pertanto qualsiasi errore di "spazio su disco/risorse insufficiente" è un buon suggerimento. Per verificare se questo problema è presente in un determinato nodo, eseguire il comando shell seguente:

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

Questo comando segnala lo spazio di archiviazione utilizzato dai file di diagnostica.

Causa principale

La scadenza del certificato client usato per autenticare l'agente di Ginevra nell'endpoint di servizio causa l'arresto anomalo dell'agente, causando un dump di arresto anomalo del sistema. Il ciclo di arresto anomalo/ripetizione dell'agente è di circa 5 secondi all'avvio iniziale e non è presente alcun timeout. Ciò significa che un nuovo file (circa 330 MB) viene creato nel file system del nodo ogni pochi secondi, che può usare rapidamente l'archiviazione su disco.

Strategia di riduzione del rischio

La mitigazione preferita consiste nell'eseguire l'aggiornamento alla versione più recente, la versione 1.10.18.10425, con un certificato aggiornato. A tale scopo, aggiornare manualmente i cluster del carico di lavoro a qualsiasi versione secondaria supportata prima di aggiornare l'host locale di Azure.

Per altre informazioni sulle versioni di Azure Kubernetes Arc e su tutte le novità più recenti del servizio Azure Kubernetes in Locale, sottoscrivere la pagina delle versioni del servizio Azure Kubernetes.

Se l'aggiornamento non è un'opzione, è possibile disattivare il servizio mdsd . Per ogni nodo Mariner:

1. Disattivare l'agente Di Ginevra con i comandi della shell seguenti:

   sudo systemctl disable --now mdsd
   

2. Verificare che l'agente di Ginevra sia stato disabilitato correttamente:

   sudo systemctl status mdsd
   

3. Eliminare i file accumulati con il comando seguente:

   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. Riavviare il nodo:

   sudo reboot
   

Un errore può verificarsi se nella distribuzione è installato un driver SMB o CSI NFS e si esegue l'aggiornamento alla build di maggio da una versione precedente. Uno dei parametri, denominato createSubDir, non è più accettato. Se si applica alla distribuzione, seguire le istruzioni riportate di seguito per risolvere l'errore della classe di archiviazione.

Se si verifica questo errore, il pod di archiviazione si arresta in modo anomalo e i log indicano che il createSubDir parametro non è valido.

Ricreare la classe di archiviazione.

Dopo aver eliminato un volume permanente o un'attestazione di volume permanente in un ambiente Arc del servizio Azure Kubernetes, viene creato un nuovo volume permanente per eseguire il mapping alla stessa condivisione. Tuttavia, quando si tenta di montare il volume, il montaggio ha esito negativo e il pod raggiunge il timeout con l'errore . NewSmbGlobalMapping failed

Per risolvere l'errore di montaggio del nuovo volume, è possibile connettersi tramite SSH al nodo Windows ed eseguire Remove-SMBGlobalMapping e fornire la condivisione corrispondente al volume. Dopo aver eseguito questo comando, i tentativi di montaggio del volume dovrebbero avere esito positivo.

Passaggi successivi

• Panoramica della risoluzione dei problemi
• Problemi noti di Windows Admin Center