# 在 Kubernetes 中实现 NFS 动态存储供应：生产级实践指南

在 Kubernetes 环境中，持久化存储是支撑有状态应用的关键基础设施。NFS（Network File System）作为一种成熟、简单且广泛支持的共享文件系统，常被用于开发测试环境或对高可用性要求不极端苛刻的生产场景。然而，Kubernetes 原生并不支持 NFS 的动态供应（Dynamic Provisioning），这意味着管理员需要手动创建 `PersistentVolume`（PV）对象，这在大规模集群中是不可持续的。

本文将详细介绍如何利用社区项目 `nfs-subdir-external-provisioner`，在 Kubernetes 集群中实现 NFS 存储的动态供应，并提供一套完整的、可直接用于生产环境的 YAML 模板和最佳实践，同时涵盖**NFS 服务器部署**、**离线环境镜像管理**和**自建 Harbor 私有仓库**的集成方案。

## 一、NFS 服务器部署与配置

在开始 Kubernetes 集成之前，必须先准备一个稳定、安全的 NFS 服务器。以下是基于 Ubuntu 22.04 的详细部署步骤。

### 1.1 安装 NFS 服务端

在一台专用服务器（例如 `192.168.1.10`）上执行以下操作：

```bash
# 更新系统并安装 NFS 服务端
sudo apt update
sudo apt install -y nfs-kernel-server

# 创建用于 Kubernetes 的共享目录
sudo mkdir -p /data/k8s/monitor
sudo chown nobody:nogroup /data/k8s/monitor
sudo chmod 777 /data/k8s/monitor
```

### 1.2 配置共享目录

编辑 `/etc/exports` 文件，定义共享策略：

```bash
# /etc/exports
/data/k8s/monitor 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
```

**参数说明**：
- `192.168.1.0/24`：允许访问的客户端网段，请替换为你的 Kubernetes 集群节点所在网段。
- `rw`：读写权限。
- `sync`：同步写入磁盘，保证数据一致性，但性能略低。如需更高性能，可改为 `async`，但有数据丢失风险。
- `no_subtree_check`：禁用子树检查，提升性能。
- `no_root_squash`：允许 root 用户保留其权限。这是关键选项，因为容器内进程可能以 root 身份运行。

### 1.3 启动并验证 NFS 服务

```bash
# 重新加载 exports 配置
sudo exportfs -ra

# 重启 NFS 服务
sudo systemctl restart nfs-kernel-server

# 设置开机自启
sudo systemctl enable nfs-kernel-server

# 验证本地导出
sudo exportfs -v
```

### 1.4 配置防火墙

确保 NFS 相关端口对 Kubernetes 节点开放：

```bash
# Ubuntu (UFW)
sudo ufw allow from 192.168.1.0/24 to any port nfs

# 或者开放具体端口
sudo ufw allow 2049/tcp
sudo ufw allow 111/tcp
sudo ufw allow 111/udp
```

### 1.5 从 Kubernetes 节点验证连接

在任意一个 Kubernetes 工作节点上执行：

```bash
# 安装 NFS 客户端
sudo apt install -y nfs-common

# 测试挂载
sudo showmount -e 192.168.1.10
# 应输出: /data/k8s/monitor 192.168.1.0/24

# 手动挂载测试（可选）
sudo mkdir -p /mnt/test-nfs
sudo mount -t nfs 192.168.1.10:/data/k8s/monitor /mnt/test-nfs
echo "test" | sudo tee /mnt/test-nfs/test.txt
sudo umount /mnt/test-nfs
```

如果以上步骤均成功，说明 NFS 服务器已准备就绪。

## 二、核心概念与工作原理

### 2.1 为什么需要动态供应？

在 Kubernetes 中，用户通过 `PersistentVolumeClaim`（PVC）来申请存储资源。静态供应模式下，集群管理员必须预先创建好 PV，其大小、访问模式等属性必须与 PVC 请求精确匹配。这种方式在小型环境中可行，但在多租户、多应用的动态环境中，会带来巨大的管理负担。

动态供应通过 `StorageClass` 对象解耦了存储的定义与使用。用户只需在 PVC 中指定所需的 `storageClassName`，一个名为 **Provisioner** 的控制器便会自动创建底层存储（如云盘、NFS 子目录）并生成对应的 PV 对象，从而实现“按需分配”。

### 2.2 nfs-subdir-external-provisioner 是什么？

`nfs-subdir-external-provisioner` 是一个由 Kubernetes SIG Storage 维护的外部供应器（External Provisioner）。它本身**不提供 NFS 服务**，而是作为一个智能代理，利用你已有的 NFS 服务器来实现动态供应。

其工作原理如下：
1.  **监听事件**：Provisioner 以 Deployment 形式运行在集群中，监听所有 PVC 的创建事件。
2.  **匹配 StorageClass**：当发现 PVC 的 `storageClassName` 与自身管理的 `StorageClass` 匹配时，触发供应逻辑。
3.  **创建子目录**：Provisioner 在 NFS 服务器的根共享目录下，创建一个以 `{namespace}-{pvc-name}-{pv-name}` 命名的子目录。
4.  **注册 PV**：向 Kubernetes API Server 注册一个新的 PV 对象，其后端指向刚刚创建的 NFS 子目录。
5.  **绑定 PVC**：Kubernetes 的持久卷控制器将新创建的 PV 与原始 PVC 绑定。

整个过程对用户透明，用户只需像使用云原生存储一样声明 PVC 即可。

## 三、生产级部署模板

以下是一套经过验证的、可直接应用于生产环境的 YAML 模板。请根据你的实际环境（NFS 服务器地址、共享路径等）修改相应的值。

### 3.1 RBAC 权限配置 (`01-nfs-rbac.yaml`)

此文件定义了 Provisioner 运行所需的最小权限集，包括操作 PV/PVC、读取 StorageClass 以及进行 Leader 选举的能力。

```yaml
# File: nfs-on-k8s/01-nfs-rbac.yaml
# 创建专用的 ServiceAccount
apiVersion: v1
kind: ServiceAccount
meta
  name: nfs-client-provisioner
  namespace: nfs-provisioner
---
# 定义集群角色，授予操作持久化资源的权限
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
meta
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
# 将集群角色绑定到 ServiceAccount
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
meta
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: nfs-provisioner
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
# 定义命名空间内的角色，用于 Leader 选举
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
meta
  name: leader-locking-nfs-client-provisioner
  namespace: nfs-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
# 将角色绑定到 ServiceAccount
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
meta
  name: leader-locking-nfs-client-provisioner
  namespace: nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: nfs-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
```

### 3.2 Provisioner 控制器部署 (`02-nfs-deployment.yaml`)

这是核心组件。请特别注意 `NFS_SERVER` 和 `NFS_PATH` 的值，它们必须与你的 NFS 服务器配置完全一致。

```yaml
# File: nfs-on-k8s/02-nfs-deployment.yaml
apiVersion: apps/v1
kind: Deployment
meta
  name: nfs-client-provisioner
  namespace: nfs-provisioner
spec:
  replicas: 1
  # 使用 Recreate 策略确保任何时候只有一个实例在运行
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    meta
      labels:
        app: nfs-client-provisioner
    spec:
      # 使用前面创建的 ServiceAccount
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          # 【关键】在离线或私有仓库环境中，替换为你的镜像地址
          image: registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
          # 关键：在离线环境中必须设置为 IfNotPresent
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: nfs-root
              # Provisioner 将在此路径下创建子目录
              mountPath: /persistentvolumes
          env:
            # PROVISIONER_NAME 必须与 StorageClass 中的 provisioner 字段一致
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs
            - name: NFS_SERVER
              value: 192.168.1.10 # 替换为你的 NFS 服务器 IP
            - name: NFS_PATH
              value: /data/k8s/monitor # 替换为你的 NFS 共享路径
      volumes:
        - name: nfs-root
          nfs:
            server: 192.168.1.10 # 与上面的 NFS_SERVER 保持一致
            path: /data/k8s/monitor # 与上面的 NFS_PATH 保持一致
```

### 3.3 生产级 StorageClass 定义 (`03-nfs-storageclass.yaml`)

此文件定义了名为 `nfs-client-prod` 的存储类，包含了生产环境所需的关键参数。

```yaml
# File: nfs-on-k8s/03-nfs-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
meta
  name: nfs-client-prod
provisioner: k8s-sigs.io/nfs
parameters:
  # 【关键】数据保留策略：PVC删除时重命名目录而非直接删除
  archiveOnDelete: "true"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: false
mountOptions:
  - vers=4.1
  - noatime
  - nodiratime
  - hard
  - intr
  - nconnect=8
```

### 3.4 测试用例 (`test-pvc.yaml` 和 `test-pod.yaml`)

用于验证整个动态供应流程是否正常工作。

```yaml
# File: nfs-on-k8s/test-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
meta
  name: test-nfs-pvc
spec:
  # 引用我们创建的 StorageClass
  storageClassName: nfs-client-prod
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
```

```yaml
# File: nfs-on-k8s/test-pod.yaml
apiVersion: v1
kind: Pod
meta
  name: test-nfs-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.29.4
      imagePullPolicy: IfNotPresent
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      # 挂载前面创建的 PVC
      persistentVolumeClaim:
        claimName: test-nfs-pvc
```

## 四、生产环境 StorageClass 参数详解

在生产环境中，StorageClass 的配置需要优先考虑**数据安全**和**系统稳定性**。

- **`archiveOnDelete: "true"`**：这是最重要的数据保护机制。当 PVC 被删除时，NFS 子目录会被重命名为 `archived-*`，而不是直接删除，有效防止了因误操作导致的数据永久丢失。
- **`reclaimPolicy: Retain`**：将数据删除的最终控制权交给存储管理员。即使 PV 对象被删除，后端数据依然保留，为恢复操作提供了最后的机会。
- **`volumeBindingMode: WaitForFirstConsumer`**：延迟 PV 的绑定，直到使用该 PVC 的 Pod 被调度。这可以避免在集群初始化阶段就创建大量无用的 PV，优化了资源分配。
- **`allowVolumeExpansion: false`**：NFS 本身没有卷大小的概念，所谓的“扩容”只是修改了元数据，容易导致应用层和存储层的认知不一致。在没有完善的配额管理前，禁用此功能更为安全。
- **`mountOptions`**：
  - `vers=4.1`：使用更健壮的 NFS v4.1 协议。
  - `noatime, nodiratime`：禁止更新访问时间戳，提升 I/O 性能。
  - `hard, intr`：保证数据一致性的同时，允许请求被中断。
  - `nconnect=8`：建立多个 TCP 连接以并行传输数据，大幅提升吞吐量。

## 五、部署与验证流程

### 5.1 应用配置

按照顺序应用上述 YAML 文件：

```bash
# 1. 创建命名空间
kubectl create namespace nfs-provisioner

# 2. 应用 RBAC
kubectl apply -f nfs-on-k8s/01-nfs-rbac.yaml

# 3. 部署 Provisioner
kubectl apply -f nfs-on-k8s/02-nfs-deployment.yaml

# 4. 创建 StorageClass
kubectl apply -f nfs-on-k8s/03-nfs-storageclass.yaml
```

### 5.2 验证 Provisioner

确保 Provisioner Pod 处于 `Running` 状态：
```bash
kubectl get pods -n nfs-provisioner
```

### 5.3 执行测试

```bash
# 创建测试 PVC
kubectl apply -f nfs-on-k8s/test-pvc.yaml

# 创建测试 Pod
kubectl apply -f nfs-on-k8s/test-pod.yaml

# 验证
kubectl get pvc test-nfs-pvc # 应为 Bound
kubectl exec test-nfs-pod -- ls /usr/share/nginx/html
```

同时，登录你的 NFS 服务器，检查共享目录下是否生成了新的子目录。

## 六、离线与私有化环境的镜像管理策略

在企业内网、安全隔离或无外网访问的环境中，无法直接从 `registry.k8s.io` 等公共仓库拉取镜像。我们需要采用两种主要策略来解决这个问题：**本地预加载**和**自建私有仓库**。

### 6.1 策略一：本地预加载（适用于小规模或临时环境）

此方法将镜像直接导入到每个 Kubernetes 节点的容器运行时中。

**步骤 1：准备镜像**
在一个有网络的机器上，拉取并保存镜像：
```bash
docker pull registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
docker save registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2 -o nfs-provisioner.tar
```

**步骤 2：分发并导入**
将 `.tar` 文件复制到所有 Kubernetes 工作节点，并导入到 containerd：
```bash
# 导入到 k8s.io 命名空间
sudo ctr -n k8s.io images import nfs-provisioner.tar
```

**步骤 3：验证**
```bash
crictl images | grep nfs-subdir-external-provisioner
```

**优点**：简单直接，无需额外基础设施。
**缺点**：难以维护和扩展，每次更新镜像都需要手动同步到所有节点。

### 6.2 策略二：自建 Harbor 私有仓库（推荐用于生产环境）

Harbor 是一个开源的企业级 Docker Registry 项目，提供了权限管理、漏洞扫描、镜像复制等高级功能，是管理私有镜像的理想选择。

**步骤 1：部署 Harbor**
可以使用 Helm Chart 或 Docker Compose 在内网部署 Harbor。假设你的 Harbor 地址为 `harbor.local.com`。

**步骤 2：推送镜像到 Harbor**
```bash
# 重新打标签
docker tag registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2 harbor.local.com/library/nfs-subdir-external-provisioner:v4.0.2

# 登录并推送
docker login harbor.local.com
docker push harbor.local.com/library/nfs-subdir-external-provisioner:v4.0.2
```

**步骤 3：配置 Kubernetes 节点信任 Harbor（如果使用 HTTPS 自签名证书）**
将 Harbor 的 CA 证书添加到所有 Kubernetes 节点的信任库中。

**步骤 4：修改 Deployment 配置**
将 `02-nfs-deployment.yaml` 中的镜像地址指向你的私有仓库，并移除 `imagePullPolicy: IfNotPresent`（因为现在可以从私有仓库动态拉取）：
```yaml
containers:
  - name: nfs-client-provisioner
    image: harbor.local.com/library/nfs-subdir-external-provisioner:v4.0.2
    # imagePullPolicy: IfNotPresent # 可注释掉，使用默认策略
```

**步骤 5：配置 ImagePullSecrets（如果 Harbor 需要认证）**
```bash
# 创建 Secret
kubectl create secret docker-registry harbor-secret \
  --docker-server=harbor.local.com \
  --docker-username=admin \
  --docker-password=yourpassword \
  -n nfs-provisioner

# 在 Deployment 的 spec.template.spec 下添加
imagePullSecrets:
  - name: harbor-secret
```

**优点**：
- **集中管理**：所有镜像统一存储，便于版本控制和审计。
- **自动化**：CI/CD 流水线可以直接推送和拉取镜像。
- **安全性**：支持基于角色的访问控制（RBAC）和内容信任。
- **可扩展**：支持跨数据中心的镜像复制。

## 七、总结与注意事项

通过 `nfs-subdir-external-provisioner`，我们可以轻松地为 Kubernetes 集群赋予 NFS 动态供应能力。对于镜像管理，**自建 Harbor 私有仓库是生产环境的最佳选择**，它提供了集中化、安全且可扩展的解决方案。

然而，在生产环境中使用 NFS 仍需谨慎：
-   **单点故障**：NFS 服务器本身是一个单点。对于关键业务，应考虑部署高可用的 NFS 集群（例如使用 DRBD + Pacemaker 或 NFS-Ganesha）。
-   **性能瓶颈**：NFS 的性能受限于网络带宽和服务器 I/O 能力，不适合高吞吐或低延迟的应用场景。
-   **权限管理**：需要仔细规划 NFS 导出选项（如 `no_root_squash`）和容器内的用户 ID（UID），以避免权限问题。
-   **备份策略**：务必为 NFS 服务器上的数据制定定期备份计划。

尽管如此，对于日志收集、配置共享、开发测试等场景，NFS 动态供应仍然是一个高效、经济的解决方案。

## 七、参考资源
[nfs-subdir-external-provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git)

### 文章分类标签
Kubernetes, DevOps, SRE, 存储, NFS, 容器化, 运维自动化, 云原生, Harbor, 镜像仓库

在 Kubernetes 环境中，持久化存储是支撑有状态应用的关键基础设施。NFS（Network File System）作为一种成熟、简单且广泛支持的共享文件系统，常被用于开发测试环境或对高可用性要求不极端苛刻的生产场景。然而，Kubernetes 原生并不支持 NFS 的动态供应（Dynamic Provisioning），这意味着管理员需要手动创建 PersistentVolume（PV）对象，这在大规模集群中是不可持续的。

在 Kubernetes 中实现 NFS 动态存储供应：生产级实践指南

本文将详细介绍如何利用社区项目 `nfs-subdir-external-provisioner`，在 Kubernetes 集群中实现 NFS 存储的动态供应，并提供一套完整的、可直接用于生产环境的 YAML 模板和最佳实践，同时涵盖**NFS 服务器部署**、**离线环境镜像管理**和**自建 Harbor 私有仓库**的集成方案。

编程语言

前端

Kubernetes生产环境NFS动态存储供应实战指南，详解nfs-subdir-external-provisioner部署流程，包含NFS服务器配置、RBAC权限设置、StorageClass参数优化及私有镜像仓库集成方案，提供完整YAML模板和性能调优建议，助力企业实现高效持久化存储管理。

数据一致性

数据丢失

文件系统

存储管理

数据中心

数据保护

漏洞扫描

数据安全

Kubernetes

云原生

防火墙

服务器

DevOps

Docker

容器

Ubuntu

dsgc

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在 Kubernetes 中实现 NFS 动态存储供应：生产级实践指南-腾讯云开发者社区-腾讯云

在 Kubernetes 中实现 NFS 动态存储供应：生产级实践指南

在 Kubernetes 中实现 NFS 动态存储供应：生产级实践指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐