Puncte:1

Kubernetes nu poate monta volume NFS după actualizarea și repornirea serverului NFS

drapel pk

După plasture zypperÎn timpul serverului NFS de pe openSUSE Leap 15.2 la cea mai recentă versiune și repornind, nodurile din clusterul kubernetes (Openshift 4.5) nu mai pot monta volume NFS.

Versiunea serverului NFS: nfs-kernel-server-2.1.1-lp152.9.12.1.x86_64

/etc/exports conține:

/nfs 192.168.11.*(rw,sync,no_wdelay,root_squash,nesecure,no_subtree_check,fsid=0)

Podurile afectate sunt în stare ContainerCreating

kubectl descrie pod/<pod_name> da urmatoarea eroare:

Avertisment FailedMount 31m kubelet MountVolume.SetUp failed for volume "volume": mount failed: exit status 32
Comanda de montare: systemd-run
Argumente de montare: --description=Montarea tranzitorie Kubernetes pentru /var/lib/kubelet/pods/c86dee2e-f533-43c9-9a1d-c4f00a1b8eef/volumes/kubernetes.io~nfs/smart-services-http-video-stream --scope -- mount -t nfs nfs.example.invalid:/nfs/volume /var/lib/kubelet/pods/c86dee2e-f533-43c9-9a1d-c4f00a1b8eef/volumes/kubernetes.io~nfs/pv-name
Ieșire: Rularea domeniului de aplicare ca unitate: run-r83d4e7dba1b645aca1e4693a48f45191.scope
mount.nfs: Operațiunea nu este permisă

Serverul rulează numai NFSv4, așa că rpcbind este dezactivat și comenzile showmount nu funcționează.

Montarea direct pe nodul kubernetes are ca rezultat următoarea eroare:

sudo mount.nfs4 nfs.example.invalid:/core tmp/ -v; eco $?
mount.nfs4: timeout stabilit pentru miercuri, 21 iulie 12:16:49 2021
mount.nfs4: încercarea de opțiuni bazate pe text „vers=4.2,addr=192.168.11.2,clientaddr=192.168.11.3”
mount.nfs4: mount(2): operațiunea nu este permisă
mount.nfs4: Operațiunea nu este permisă
32

reguli firewalld pe serverul NFS:

  servicii: ssh dhcpv6-client nfs mountd rpc-bind samba http tftp
  porturi: 2049/tcp 2049/udp

AppArmor funcționa, oprirea nu a schimbat rezultatul.

Înainte de a actualiza serverul NFS, totul funcționa bine și nu s-au făcut alte modificări de configurare. Cum pot depana acest lucru în continuare și pot face din nou acțiunile montabile?

Puncte:3
drapel pk

După ce am încercat să depanați această problemă cu rpcdebug fără niciun rezultat, am recurs la dumpingul de trafic pe serverul nfs care vine de la unul dintre noduri. Această groapă a dat un indiciu interesant:

Răspuns NFS xid 4168498669 răspuns ERR 20: Acreditări false de autorizare (sigiliu rupt)

Deci problema nu era legată cu siguranță de rețea sau de apariție.

Apoi am încercat să mă schimb exporturi la

/nfs *(rw,sync,no_wdelay,root_squash,nesecure,no_subtree_check,fsid=0)

și totul a funcționat, confirmând că această problemă constă într-un fel de exporturi configurație greșită.

Regula de rescriere la

/nfs 192.168.11.0/24(rw,sync,no_wdelay,root_squash,nesecure,no_subtree_check,fsid=0)

conectivitate restabilită.

Conform https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports

wildcards â Unde un * sau ? caracterul este folosit pentru a lua în considerare o grupare de nume de domenii complet calificate care se potrivesc cu un anumit șir de litere. Wildcard-urile nu trebuie folosite cu adrese IP; cu toate acestea, este posibil ca aceștia să funcționeze accidental dacă căutările DNS inverse eșuează.

Deci, folosirea * cu adresa IP a fost o configurație greșită clară care a funcționat cumva luni de zile și, în cele din urmă, a dus la erori descrise în cauză.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.