K8s 使用 NFS 作为 SC 遇到的文件访问问题：.json 文件神秘失踪？

K8s 中使用 NFS 作为 SC 遇到的文件访问问题分析与解决

在 Kubernetes (K8s) 集群中，持久化存储是至关重要的组成部分。网络文件系统 (NFS) 是一种常见的选择，因为它易于设置和管理。然而，在某些情况下，使用 NFS 作为存储类 (SC) 可能会遇到一些意想不到的问题。本文将深入探讨一个具体的案例，即 Pod 中程序解压后无法找到所有预期 .json 文件的问题，并提供详细的分析和解决方案。

问题描述

某个 K8s 集群使用 NFS 作为 SC，Pod 挂载的配置如下：

rw, relatime, vers=4.1, rsize=1048576, wsize=1048576, namlen=255, hard, proto=tcp, timeo=600, retrans=2, sec=sys, clientaddr=10.***.***.***, local_lock=none, addr=10.***.***.***

应用程序在 Pod 中运行，其主要任务是解压文件并查找以 .json 为结尾的文件。然而，尽管解压后的目录中应该包含 20 多个 .json 文件，程序却只能找到其中的一部分，导致业务逻辑无法正常执行。经过初步排查，确认所有文件确实都已完整解压到 NFS 挂载的目录中。

问题分析与排查

这个问题看似简单，但其根本原因可能涉及多个层面。以下是一些可能的排查方向：

NFS 客户端缓存问题：

NFS 客户端通常会缓存文件和目录信息，以提高性能。然而，如果客户端的缓存与服务器上的实际文件系统状态不一致，就可能导致文件查找失败。这可能是由于客户端没有及时刷新缓存，或者 NFS 服务器上的文件系统更新没有及时传播到客户端。

为了验证这一点，可以尝试在 Pod 中手动刷新 NFS 客户端的缓存。具体方法取决于所使用的 Linux 发行版和 NFS 客户端版本。一个常用的方法是使用 fattr 命令强制刷新缓存：
```
fattr -v -n . -o flush_before /path/to/mounted/directory
```
其中 /path/to/mounted/directory 是 NFS 挂载的目录。
文件权限问题：

尽管文件已经解压到 NFS 目录中，但应用程序可能没有足够的权限访问这些文件。这可能是由于 NFS 服务器的导出配置不正确，或者文件本身的权限设置不当。需要仔细检查 NFS 服务器的 /etc/exports 文件，确保导出的目录具有适当的权限，并且允许 Pod 所在的 IP 地址或网络访问。

此外，还需要检查解压后的 .json 文件的权限，确保应用程序用户具有读取权限。可以使用 ls -l 命令查看文件权限，并使用 chmod 命令修改权限。
文件名大小写敏感问题：

在某些文件系统中，文件名是大小写敏感的。如果应用程序在查找文件时使用了错误的大小写，就可能导致文件查找失败。尽管通常 Linux 文件系统是区分大小写的，但 NFS 客户端的行为可能受到配置的影响。检查应用程序的代码，确保文件名的大小写与实际文件系统中的文件名完全一致。
文件系统元数据损坏：

虽然可能性较低，但文件系统元数据损坏也可能导致文件查找问题。如果文件系统元数据损坏，可能导致目录结构不正确，或者文件信息丢失。为了排除这种可能性，可以尝试在 NFS 服务器上运行文件系统检查工具，例如 fsck。
应用程序代码问题：

最后，还需要排除应用程序代码本身的问题。例如，应用程序可能在查找文件时使用了错误的路径，或者存在其他逻辑错误导致文件查找失败。仔细检查应用程序的代码，确保文件查找逻辑正确无误。
NFS 版本兼容性问题

案例中使用的 NFS 版本是 4.1。虽然 4.1 版本相对较新，但仍需考虑客户端和服务端对于该版本的支持程度和兼容性。不同版本之间可能存在细微的差异，导致某些操作行为不一致。

检查客户端和服务端的 NFS 版本配置，确保双方都完全支持并正确配置了 NFS 4.1。可以尝试显式指定 NFS 版本，避免自动协商可能导致的问题。

例如，在 mount 命令中明确指定版本：
```
mount -t nfs -o vers=4.1 <server_ip>:<export_path> <mount_point>
```
readdirplus 参数的影响

readdirplus 是 NFS 客户端的一个选项，用于在读取目录内容时同时获取文件属性，以提高性能。然而，在某些情况下，readdirplus 可能会导致一些奇怪的问题。可以尝试禁用 readdirplus 选项，看看是否能够解决文件查找问题。

在 mount 命令中禁用 readdirplus：
```
mount -t nfs -o noreaddirplus <server_ip>:<export_path> <mount_point>
```
SELinux 或 AppArmor 的干扰

如果集群启用了 SELinux 或 AppArmor 等安全模块，这些模块可能会限制 Pod 对 NFS 挂载目录的访问。检查相关的安全策略，确保 Pod 具有足够的权限访问 NFS 共享。

查看 SELinux 的审计日志：
```
ausearch -m avc -ts recent
```
如果发现有访问被拒绝的记录，需要修改 SELinux 策略以允许访问。

解决方案

针对上述可能的原因，可以采取以下解决方案：

刷新 NFS 客户端缓存：

如前所述，可以使用 fattr 命令强制刷新 NFS 客户端的缓存。
检查和修改文件权限：

确保 NFS 服务器的导出配置正确，并且应用程序用户具有读取 .json 文件的权限。可以使用 chmod 命令修改文件权限。
统一文件名大小写：

确保应用程序在查找文件时使用与实际文件系统中的文件名完全一致的大小写。
修复文件系统元数据：

如果怀疑文件系统元数据损坏，可以在 NFS 服务器上运行文件系统检查工具。
检查和修复应用程序代码：

仔细检查应用程序的代码，确保文件查找逻辑正确无误。
调整 NFS 客户端配置：

可以尝试调整 NFS 客户端的配置，例如修改 rsize 和 wsize 参数，或者禁用某些高级特性。
使用 NFSv4：

NFSv4 具有更好的安全性和性能，可以尝试使用 NFSv4 替代 NFSv3。
检查防火墙设置

确保防火墙允许 NFS 客户端和服务端之间的通信。NFS 使用的端口包括 111 (portmapper), 2049 (nfs), 和可能的其他端口 (mountd, rquotad, etc.)。根据 NFS 的配置，可能需要打开这些端口。
考虑使用其他的存储方案

如果上述方法都无法解决问题，可以考虑使用其他的存储方案，例如 GlusterFS、Ceph 或 Rook。这些方案通常具有更好的性能和可靠性。

案例总结

在 K8s 中使用 NFS 作为 SC 可能会遇到各种各样的问题。当遇到文件访问问题时，需要从多个层面进行分析和排查，包括 NFS 客户端缓存、文件权限、文件名大小写、文件系统元数据、应用程序代码以及网络配置等等。通过仔细的分析和排查，最终可以找到问题的根源，并采取相应的解决方案。

总结与建议

在 Kubernetes 环境中使用 NFS 作为存储类时，遇到“部分 .json 文件找不到”的问题，排查思路应全面。不仅要关注 NFS 本身的配置和缓存机制，还要深入到文件权限、应用程序代码逻辑、以及潜在的网络和安全策略影响。通过逐一排除可能因素，并结合实际案例进行分析，最终能够定位问题并提出有效的解决方案。

此外，对于生产环境，建议充分测试和监控 NFS 存储，以便及时发现和解决潜在问题。在条件允许的情况下，可以考虑采用更先进的分布式存储方案，如 Ceph 或 GlusterFS，以获得更高的性能和可靠性。