发生了什么？
删除有状态集时，Pod会卡在"terminating"状态。Pod被调度的节点产生高iowait时间。如果该节点上的另一个Pod无法终止，则iowait会随着多个卡住的NFS挂载而增加。无法清除iowait,必须重启节点。kubectl delete pods podname --force -n namespace确实会从k8s中删除Pod,但不会修复卡住的NFS挂载。如果我不强制删除Pod,那么Pod无法重启。
你期望会发生什么？
当Pod被删除时，节点应该能够卸载NFS挂载。
我们如何尽可能精确地重现它？
我无法重现错误。我有很多创建和删除的有状态集，其中随机Pod会卡住。
我们需要了解其他信息吗？
我正在从外部NFS服务器挂载一个NFS卷。我没有使用NFS provisioner。
spec:
volumes:
- name: data
nfs:
server: nfs1.storage.server.com
path: /home/brad节点上的nfs客户端配置
[ NFSMount_Global_Options ]
#rsize=1048576
#wsize=1048576
soft
timeo=50
nfsvers=4.1
retry=5nfs服务器导出
/home 10.10.30.0/24(rw,sync,no_wdelay,no_root_squash,no_subtree_check,insecure)Kubernetes版本
$ kubectl version
#Client Version: v1.28.7
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.2云提供商
裸金属
OS版本
# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
$ uname -a
Linux adm-wk1 5.15.0-1051-kvm #56-Ubuntu SMP Thu Feb 8 23:30:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here安装工具
kubeadm
容器运行时(CRI)和版本(如适用)
containerd 1.7.2
相关插件(CNI,CSI等)和版本(如适用)
cni - flannel csi - none
6条答案
按热度按时间ktca8awb1#
这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题，他们将通过应用
triage/accepted标签并提供进一步的指导来接受它。组织成员可以通过在评论中写入
/triage accepted来添加triage/accepted标签。有关使用PR评论与我互动的说明，请查看here。如果您对我的行为有任何问题或建议，请针对kubernetes/test-infra仓库提出一个问题。
8yoxcaq72#
/sig storage
h6my8fg23#
我能够添加更多的研究，我尝试使用umount -l /mnt/point命令，但这并没有关闭连接。然而，使用umount.nfs4 -f /mnt/point确实可以关闭卡住的挂载点。不知道为什么有区别，但它确实有效。
n3schb8v4#
我遇到过类似的问题。
你能检查一下服务器上的nfsd是否陷入了死循环，导致nfs客户端挂起吗？
tag5nh1u5#
不确定我该如何做到这一点？
f3temu5u6#
有一个常见的问题，即通信错误或类似的nfsd服务中断导致客户端在iowait上阻塞。这是在大多数内核上的nfs客户端的默认设计。在VMs-are-pets模型中，您应该挂载
umount -l -f,或者使用intr客户端挂载选项允许通过SIGKILL中断。然而，根据手册：自2008年进行此更改以来，对于遇到此问题的人来说，现实情况是SIGKILL是唯一的选择。K8s在宽限期后向容器发送SIGKILL,因此理论上我期望受影响的pods在默认的30秒后结束...但这似乎不是这样工作的。
既然这是一个常见问题，Kubernetes是否可以改进优雅期终止行为？如果有挂起的挂载点，不能保证SIGKILL实际上会结束它们。但是，懒惰的强制卸载几乎总是可以的(
umount -l -f)。到那时，我们已经处于异常强制删除状态，所以文档已经警告了潜在的数据丢失(据我所知，这是nfs默认阻塞行为背后的原因)。