Điểm:1

Kubernetes không thể gắn ổ đĩa NFS sau khi cập nhật và khởi động lại máy chủ NFS

lá cờ pk

Sau đó bản vá zypperĐang kết nối máy chủ NFS trên openSUSE Leap 15.2 lên phiên bản mới nhất và khởi động lại, các nút trong cụm kubernetes (Openshift 4.5) không thể gắn ổ đĩa NFS nữa.

Phiên bản máy chủ NFS: nfs-kernel-server-2.1.1-lp152.9.12.1.x86_64

/etc/exports chứa:

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

Các nhóm bị ảnh hưởng đang ở trạng thái Tạo vùng chứa

kubectl description pod/<pod_name> đưa ra một lỗi sau:

Cảnh báo FailedMount 31m kubelet MountVolume.SetUp fail for volume "volume" : mount fail: thoát trạng thái 32
Lệnh gắn kết: systemd-run
Đối số gắn kết: --description=Kubernetes tạm thời gắn kết cho /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
Đầu ra: Chạy phạm vi dưới dạng đơn vị: run-r83d4e7dba1b645aca1e4693a48f45191.scope
mount.nfs: Thao tác không được phép

Máy chủ chỉ chạy NFSv4, vì vậy rpcbind bị tắt và các lệnh showmount không hoạt động.

Gắn trực tiếp trên nút kubernetes dẫn đến lỗi sau:

sudo mount.nfs4 nfs.example.invalid:/core tmp/ -v; tiếng vang $?
mount.nfs4: thời gian chờ được đặt cho Thứ Tư ngày 21 tháng 7 12:16:49 năm 2021
mount.nfs4: thử các tùy chọn dựa trên văn bản 'vers=4.2,addr=192.168.11.2,clientaddr=192.168.11.3'
mount.nfs4: mount(2): Thao tác không được phép
mount.nfs4: Thao tác không được phép
32

quy tắc tường lửa trên máy chủ NFS:

  dịch vụ: ssh dhcpv6-client nfs mountd rpc-bind samba http tftp
  cổng: 2049/tcp 2049/udp

AppArmor đang hoạt động, việc tắt nó không thay đổi kết quả.

Trước khi cập nhật máy chủ NFS, mọi thứ đều hoạt động tốt và không có thay đổi cấu hình nào khác được thực hiện. Làm cách nào tôi có thể gỡ lỗi này thêm và làm cho các cổ phiếu có thể gắn kết lại được?

Điểm:3
lá cờ pk

Sau khi cố gắng gỡ lỗi vấn đề này với rpcdebug nhưng không có kết quả, tôi đã dùng đến việc kết xuất lưu lượng truy cập trên máy chủ nfs đến từ một trong các nút. Kết xuất này đã đưa ra một hướng dẫn thú vị:

Trả lời NFS xid 4168498669 trả lời ERR 20: Auth Bogus Credentials (con dấu bị hỏng)

Vì vậy, vấn đề chắc chắn không liên quan đến mạng hoặc apparmor.

Sau đó, tôi đã cố gắng thay đổi xuất khẩu đến

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

và mọi thứ đã hoạt động, xác nhận rằng vấn đề này nằm ở một số loại xuất khẩu cấu hình sai.

Viết lại quy tắc thành

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

đã khôi phục kết nối.

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

ký tự đại diện â Trường hợp * hoặc ? ký tự được sử dụng để tính đến một nhóm các tên miền đủ điều kiện khớp với một chuỗi ký tự cụ thể. Không nên sử dụng ký tự đại diện với địa chỉ IP; tuy nhiên, chúng có thể vô tình hoạt động nếu tra cứu DNS ngược không thành công.

Vì vậy, việc sử dụng * với địa chỉ IP rõ ràng là một cấu hình sai mà bằng cách nào đó đã hoạt động trong nhiều tháng và cuối cùng dẫn đến các lỗi được mô tả trong câu hỏi.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.