一、背景介绍

问题报错 level=error err="opening storage failed: lock DB directory: no locks available
首先说明，该问题应该是一个小众问题
在学习K8S过程中我使用位于esxi上的三台Ubuntu虚拟机和kubekey进行了集群的搭建，使用了另外一台TrueNAS虚拟机作为NFS服务器，作为集群的高可用搭建（假象：turenas挂了同样gg）。
我首先使用kk单独搭建了kubernetes，自定义了配置文件，加入了nas作为默认sc（StorageClass）的部分。
然后又使用在kubernetes上搭建kubesphere的方法搭建了最小化的kubesphere。
完成安装之后发现Statefullset prometheus-k8s 处于CrashLoopBackOff状态。（Pod 中的某个容器不断崩溃和重新启动。可能的原因包括应用程序错误、配置错误等）
查看相关pod的describe发现如下日志，重点在最后一句的报错

ts=2024-06-08T05:27:16.503Z caller=main.go:550 level=info fd_limits="(soft=1048576, hard=1048576)"
ts=2024-06-08T05:27:16.505Z caller=main.go:551 level=info vm_limits="(soft=unlimited, hard=unlimited)"
ts=2024-06-08T05:27:16.650Z caller=web.go:559 level=info component=web msg="Start listening for connections" address=0.0.0.0:9090
ts=2024-06-08T05:27:16.652Z caller=main.go:980 level=info msg="Starting TSDB ..."
ts=2024-06-08T05:27:16.653Z caller=dir_locker.go:77 level=warn component=tsdb msg="A lockfile from a previous execution already existed. It was replaced" file=/prometheus/lock
ts=2024-06-08T05:27:16.655Z caller=tls_config.go:231 level=info component=web msg="TLS is disabled." http2=false
ts=2024-06-08T05:27:27.154Z caller=main.go:839 level=info msg="Stopping scrape discovery manager..."
ts=2024-06-08T05:27:27.154Z caller=main.go:853 level=info msg="Stopping notify discovery manager..."
ts=2024-06-08T05:27:27.154Z caller=manager.go:957 level=info component="rule manager" msg="Stopping rule manager..."
ts=2024-06-08T05:27:27.154Z caller=manager.go:967 level=info component="rule manager" msg="Rule manager stopped"
ts=2024-06-08T05:27:27.154Z caller=main.go:890 level=info msg="Stopping scrape manager..."
ts=2024-06-08T05:27:27.154Z caller=main.go:849 level=info msg="Notify discovery manager stopped"
ts=2024-06-08T05:27:27.154Z caller=main.go:835 level=info msg="Scrape discovery manager stopped"
ts=2024-06-08T05:27:27.154Z caller=notifier.go:608 level=info component=notifier msg="Stopping notification manager..."
ts=2024-06-08T05:27:27.155Z caller=main.go:1110 level=info msg="Notifier manager stopped"
ts=2024-06-08T05:27:27.155Z caller=main.go:882 level=info msg="Scrape manager stopped"
ts=2024-06-08T05:27:27.155Z caller=manager.go:943 level=info component="rule manager" msg="Starting rule manager..."
ts=2024-06-08T05:27:27.155Z caller=main.go:1119 level=error err="opening storage failed: lock DB directory: no locks available"

二、解决过程

1、上网查改该报错疑似和NFS文件锁有关。阿里云中关于nfs的介绍
了解到nfs中的文件锁功能，NFS v2/v3版本需要rpc-bind、rpc-statd 等帮助实现该文件所的功能，而NFS v4中自身实现了文件锁功能。
2、而我的ture nas 中的NFS文件共享，使用了默认的版本（不是v4），接着在bash中执行systemctl status rpc-statd发现rpc-statd状态是未运行的，使用systemctl start rpc-statd 尝试开启发现报错，一番处理后未能处理报错，于是将NFS共享调整成了v4版本，然后在客户端重新挂载。
3、确认文件锁功能无误之后，在kubesphere后台中删除pvc（对应的pv会自动删除），等待pvc和pv重建，同时将出问题的Statefullset（prometheus-k8s）的pod删除，等待重建，发现重建之后问题恢复

三、操作支持

NFS文件锁功能验证

1. 确认 NFSv4 服务已启动
   首先确保你的 NFS 服务器配置为使用 NFSv4 并已启动相应服务。

2. 检查 NFS 服务器上的锁定服务
   使用 rpcinfo 命令检查 NFS 服务器上的锁定服务：

rpcinfo -p <nfs_server_ip>

你应该看到类似以下的输出，显示 NFSv4 服务和锁定管理器（nlockmgr）：

   program vers proto   port  service
    100003    4   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp  54847  nlockmgr
    100021    3   udp  54847  nlockmgr
    100021    4   udp  54847  nlockmgr
    100021    1   tcp  46209  nlockmgr
    100021    3   tcp  46209  nlockmgr
    100021    4   tcp  46209  nlockmgr

3. 挂载 NFSv4 共享
   在客户端上挂载 NFSv4 共享：

sudo mount -t nfs4 <nfs_server_ip>:/mnt/share/nfs /mnt/nfs

4. 验证文件锁定功能
   可以使用以下步骤来测试文件锁定功能：
   在客户端 A 上创建一个文件并获取一个锁：

echo "Test file" > /mnt/nfs/testfile
sudo flock /mnt/nfs/testfile -c "sleep 300"

在客户端 B 上尝试获取相同文件的锁：

sudo flock /mnt/nfs/testfile -c "echo 'Client B got the lock'"

在客户端 A 锁住文件时，客户端 B 会等待，直到客户端 A 释放锁。

5. 检查锁定状态
   在服务器上检查锁定状态，通常可以通过以下命令查看锁定信息：

sudo nfsstat -c