#使用 NFS 配置持久存储

Alauda Container Platform 集群支持使用 NFS 的持久存储。Persistent Volumes (PVs) 和 Persistent Volume Claims (PVCs) 为项目内存储卷的配置和使用提供了抽象层。虽然可以直接在 Pod 定义中嵌入 NFS 配置细节，但这种方式不会将卷创建为独立的、隔离的集群资源，增加了冲突的风险。

#前提条件

• 底层基础设施中必须先存在存储，才能在 Alauda Container Platform 中将其挂载为卷。
• 配置 NFS 卷只需提供 NFS 服务器列表和导出路径。

#操作步骤

cat << EOF | kubectl create -f -
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-example
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  nfs:
    path: /tmp
    server: 10.0.0.3
  persistentVolumeReclaimPolicy: Retain
EOF

kubectl get pv

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  volumeName: pv-nfs-example
  storageClassName: ""

kubectl get pvc

#通过分区导出实现磁盘配额

为了强制执行磁盘配额和大小限制，可以利用磁盘分区。将每个分区分配为专用导出点，每个导出对应一个独立的 PersistentVolume (PV)。

虽然 Alauda Container Platform 要求 PV 名称唯一，但确保每个导出的 NFS 卷的服务器和路径唯一性仍由管理员负责。

这种分区方式实现了精确的容量管理。开发者请求指定容量（例如 10Gi）的持久存储，ACP 会匹配至少满足该容量的分区/导出支持的 PV。请注意：配额限制适用于分配的分区/导出内的可用存储空间。

#NFS 卷安全性

本节介绍 NFS 卷的安全机制，重点是权限匹配。假设读者具备 POSIX 权限、进程 UID 和附加组的基础知识。

开发者通过以下方式请求 NFS 存储：

• 通过名称引用 PersistentVolumeClaim (PVC)，或
• 在 Pod 规格的 volumes 部分直接配置 NFS 卷插件。

在 NFS 服务器上，/etc/exports 文件定义了可访问目录的导出规则。每个导出目录保留其原生的 POSIX 所有者/组 ID。

Alauda Container Platform 的 NFS 插件关键行为：

1. 挂载卷到容器时，保留源目录的精确 POSIX 所有权和权限
2. 运行容器时不强制进程 UID 与挂载所有权匹配——这是有意的安全设计

例如，考虑以下 NFS 目录的服务器端属性：

ls -l /share/nfs -d

id nfsnobody

此时，容器必须以 UID 65534（nfsnobody 所有者）运行，或在其附加组中包含 5555，才能访问该目录。

#组 ID

推荐的 NFS 访问管理（当导出权限固定时） 当无法修改 NFS 导出的权限时，推荐通过附加组管理访问。

在 Alauda Container Platform 中，附加组是控制共享文件存储（如 NFS）访问的常用机制。

与块存储对比：块存储卷（如 iSCSI）的访问通常通过在 pod 的 securityContext 中设置 fsGroup 实现，该方法依赖挂载时文件系统组所有权的更改。

由于示例目标 NFS 目录的组 ID 为 5555，pod 可以在其 securityContext 的 supplementalGroups 中定义该组 ID。例如：

spec:
  containers:
    - name:
    ...
  securityContext:
    supplementalGroups: [5555] 

#用户 ID

用户 ID 可以在容器镜像中定义，也可以在 Pod 定义中指定。

在上述示例目标 NFS 目录中，容器需要将其 UID 设置为 65534（暂不考虑组 ID），因此可以在 Pod 定义中添加：

spec:
  containers:
  - name:
  ...
    securityContext:
      runAsUser: 65534

#导出设置

为了允许任意容器用户读写卷，NFS 服务器上的每个导出卷应满足以下条件：

• 每个导出必须使用如下格式导出：

  # 将 10.0.0.0/24 替换为可信的 CIDRs/主机
  /<example_fs> 10.0.0.0/24(rw,sync,root_squash,no_subtree_check)

• 防火墙必须配置为允许访问挂载点的流量。

  • 对于 NFSv4，配置默认端口 2049（nfs）。

    iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT
  • 对于 NFSv3，需要配置三个端口：2049（nfs）、20048（mountd）和 111（portmapper）。

    iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT
    iptables -I INPUT 1 -p tcp --dport 20048 -j ACCEPT
    iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPT

• NFS 导出和目录必须设置为目标 pod 可访问。要么将导出目录所有权设置为容器的主 UID，要么通过 supplementalGroups 提供 pod 组访问权限，如上文组 ID 所示。

#资源回收

NFS 实现了 Alauda Container Platform 的 Recyclable 插件接口。自动流程根据每个持久卷设置的策略处理回收任务。

默认情况下，PV 设置为 Retain。

当 PVC 的声明被删除，且 PV 被释放后，该 PV 对象不应被重复使用。应创建一个新的 PV，基本卷信息与原 PV 相同。

例如，管理员创建了名为 nfs1 的 PV：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs1
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

用户创建 PVC1，绑定到 nfs1。用户随后删除 PVC1，释放对 nfs1 的声明。此时 nfs1 状态变为 Released。如果管理员想继续使用相同的 NFS 共享，应创建一个新的 PV，使用相同的 NFS 服务器信息，但 PV 名称不同：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs2
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"

不建议删除原 PV 后用相同名称重新创建。尝试手动将 PV 状态从 Released 改为 Available 会导致错误和潜在数据丢失。