Perché la mia applicazione non riesce con un errore ID gruppo per le autorizzazioni di archiviazione file NFS ?

Risolvere i problemi relativi agli errori di autorizzazione relativi all'ID del gruppo di archiviazione dei file.

Infrastrutture classiche

Dopo aver aggiunto lo storage creare o aggiungere l'esistente NFS al cluster, la distribuzione dei container dell'applicazione non va a buon fine. Vengono visualizzati i messaggi di errore GID (group ID).

Quando crei un contenitore da una immagine che non specifica un utente e un ID utente (UID), tutte le istruzioni nel Dockerfile vengono eseguite dall'utente root (UID: 0) all'interno del contenitore per impostazione predefinita.

Tuttavia, quando vuoi montare una condivisione file NFS nel tuo contenitore, l'ID utente 0 all'interno del contenitore viene associato all'ID utente nobody nel sistema host NFS. Pertanto, il percorso di montaggio del volume è di proprietà dell'ID utente nobody e non di root. Questa funzione di sicurezza è nota anche come root squash. Lo squash root protegge i dati all'interno di NFS montando il contenitore senza concedere le autorizzazioni root dell'ID utente sul file system dell'host NFS effettivo.

Utilizzare un Kubernetes DaemonSet per abilitare i permessi di root al percorso di montaggio dello storage su tutti i nodi worker per le condivisioni di file NFSv4.

Per consentire l'autorizzazione root sul percorso di montaggio del volume, devi configurare una ConfigMap sul nodo di lavoro. La ConfigMap associa l'ID utente nobody dal sistema host NFS all'ID utente root 0 nel contenitore. Questo processo è anche indicato come nessuna zucca root. Un modo efficace per aggiornare tutti i tuoi nodi di lavoro è utilizzare una serie di daemon, che esegue un pod specificato su ogni nodo di lavoro nel tuo cluster. In questo caso, il pod controllato dalla serie di daemon aggiorna ciascun nodo di lavoro per abilitare l'autorizzazione root sul percorso di montaggio del volume.

La distribuzione è configurata per permettere al pod della serie di daemon di essere eseguito in modalità privilegiata, che è necessaria per accedere al file system dell'host. L'esecuzione di un pod in modalità privilegiata crea un rischio per la sicurezza, quindi utilizzare questa opzione con attenzione.

Mentre la serie di daemon è in esecuzione, i nuovi nodi di lavoro aggiunti al cluster vengono aggiornati automaticamente.

Prima di cominciare:

Completare la seguente procedura.

  1. Copiare il file YAML dell'installazione del demone norootsquash.

  2. Creare la distribuzione della serie di daemon norootsquash.

    oc apply -f norootsquash.yaml

  3. Ottieni il nome del pod su cui è montato il tuo volume di archiviazione. Questa capsula non è uguale a quella di norootsquash.

    oc get pods

  4. Accedi al pod.

    oc exec -it mypod /bin/bash

  5. Verificare che le autorizzazioni per il percorso di montaggio siano root.

    root@mypod:/# ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb  7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .

    Questo output mostra che l'UID nella prima riga è ora di proprietà di root (invece di nobody).

  6. Se l'UID è di proprietà di nobody, esci dal pod e riavvia i nodi di lavoro del tuo cluster. Attendere il riavvio dei nodi.

    ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2

  7. Ripetere i punti 4 e 5 per verificare le autorizzazioni.