安装nfs-Provisioner,实现动态供应StorageClass、在创建PVC时,自动创建PV。


需要澄清一下概念

  • 误区:单纯通过 StorageClass ​无法自动创建 PV,需要配置 StorageClass ​动态供应器(Provisioner)​​                例:NFS Provisioner。
  • 结论:​不依赖动态供应器时,必须手动创建 PV;若想实现 PVC 直接引用 StorageClass 自动创建 PV,需先部署 NFS Provisioner。

分步说明

1. 动态供应与静态供应的区别
类型是否需要手动创建 PV是否需要 Provisioner适用场景
静态供应NFS 目录固定,PV 数量少
动态供应必须安装 Provisioner按需自动创建 PV

方案一:静态供应(需手动创建 PV)​

即PVC ​必须依赖预先存在的 PV


方案二:动态供应(需安装 NFS Provisioner)​

以下是 ​真正实现 PVC 自动创建 PV 的实例:

1. 部署 NFS Provisioner

使用社区工具:

helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=192.168.1.100 \
    --set nfs.path=/data/nfs/dynamic

​社区工具可能失败可以指定阿里云镜像

helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=192.168.1.100 \     # 替换为你的 NFS 服务器 IP
    --set nfs.path=/data/nfs/dynamic \   # 替换为你的 NFS 共享目录
    --set image.repository=registry.cn-hangzhou.aliyuncs.com/google_containers/sig-storage/nfs-subdir-external-provisioner \
    --set image.tag=v4.0.2              # 指定镜像版本
2. 创建 StorageClass(自动生成)​
kubectl get storageclass 
3. 创建 PVC​
# dynamic-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-nfs-pvc
spec:
  storageClassName: nfs-client  # 与 Provisioner 的 StorageClass 名称一致
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

应用配置

kubectl apply -f dynamic-pvc.yaml
4. 验证自动创建的 PV
kubectl get pvc dynamic-nfs-pvc  # 状态应为 Bound
kubectl get pv                   # 自动生成的 PV,名称类似 pvc-xxxx
5. 挂载 PVC 到 Pod
# pod-with-dynamic-pvc.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dynamic-pvc-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: nfs-storage
      mountPath: /usr/share/nginx/html
  volumes:
  - name: nfs-storage
    persistentVolumeClaim:
      claimName: dynamic-nfs-pvc

应用配置

kubectl apply -f pod-with-dynamic-pvc.yaml
6. 验证数据持久化

写入数据到容器挂载目录:

kubectl exec -it dynamic-pvc-pod -- touch /usr/share/nginx/html/test.txt

检查 NFS 服务器的 /data/nfs/dynamic 目录,会看到自动创建的子目录,其中包含 test.txt


关键区别说明

配置项静态供应动态供应
PV 创建方式手动预先创建由 Provisioner 自动创建
NFS 目录固定路径动态生成子目录(如 /data/nfs/dynamic/default-pvc-xxxx
适用场景存储路径需严格控制按需分配,避免手动管理 PV

总结一下

  • 若 ​不安装 Provisioner,PVC 直接引用 StorageClass ​无法自动创建 PV,必须手动创建 PV。
  • 若需 ​完全自动化,必须部署 NFS Provisioner 并正确配置 StorageClass

更详细过程请访问: 

​PVC 通过 NFS Provisioner 自动创建 PV 的流程及鉴权,超详细~~~-优快云博客https://blog.youkuaiyun.com/SAJDASD/article/details/146314407?sharetype=blogdetail&sharerId=146314407&sharerefer=PC&sharesource=SAJDASD&spm=1011.2480.3001.8118 

<think>我们正在分析用户提供的命令输出和问题。用户执行了 `kubectl apply -f provisioner.yaml`,输出显示: - ServiceAccount、ClusterRole、ClusterRoleBinding 和 Deployment 的状态都是 "unchanged",意味着这些资源已经存在且配置没有变化。 - 然后出现了一个关于 StorageClass 的警告和错误: ``` Warning: resource storageclasses/prom-data-sc is missing the kubectl.kubernetes.io/last-applied-configuration annotation ... The StorageClass "prom-data-sc" is invalid: reclaimPolicy: Forbidden: updates to reclaimPolicy are forbidden. ``` 关键点分析: 1. **注解缺失警告**:StorageClass `prom-data-sc` 缺少 `kubectl.kubernetes.io/last-applied-configuration` 注解。这个注解是 `kubectl apply` 命令用来做三方合并(three-way merge)的。如果资源最初不是通过 `kubectl apply` 创建的(比如用 `kubectl create` 或直接通过API创建),就会缺少这个注解,导致后续 `apply` 出现警告[^4]。 2. **回收策略更新错误**:错误信息明确指出,StorageClass 的 `reclaimPolicy` 字段一旦创建就不能更新。这是因为 StorageClass 的某些字段(包括 `reclaimPolicy`)是不可变的[^1][^4]。 结合用户提供的引用[^1][^4],我们可以看到 StorageClass 的 `reclaimPolicy` 通常设置为 `Delete` 或 `Retain`,且创建后不能更改。 解决方案: 1. **处理注解缺失问题**:我们可以通过以下方式之一解决: - 删除现有的 StorageClass 然后重新创建(通过 `kubectl apply` 创建自动添加注解)。 - 使用 `kubectl replace` 命令代替 `apply`,并加上 `--save-config` 选项来添加注解。 2. **处理回收策略更新问题**:由于 `reclaimPolicy` 不可更新,我们必须: - 确保 `provisioner.yaml` 中的 `reclaimPolicy` 与现有 StorageClass 相同,或者 - 删除现有的 StorageClass 然后重新应用(如果确实需要更改 `reclaimPolicy`)。 具体操作步骤: ### 步骤1:检查现有 StorageClass 的配置 ```bash kubectl get storageclass prom-data-sc -o yaml ``` 记录当前的 `reclaimPolicy` 值(比如是 `Delete` 还是 `Retain`)以及其他配置。 ### 步骤2:修正 provisioner.yaml 文件 确保 `provisioner.yaml` 中定义的 `prom-data-sc` StorageClass 的 `reclaimPolicy` 与现有值完全相同(如果不想改变回收策略)。如果确实需要修改回收策略,那么必须先删除现有的 StorageClass。 ### 步骤3:删除并重建 StorageClass(如果需要更改回收策略) ```bash # 删除现有的 StorageClass kubectl delete storageclass prom-data-sc # 然后重新应用 kubectl apply -f provisioner.yaml ``` 注意:删除 StorageClass 不会影响已经创建PV,因为这些 PV 已经独立存在。但是,后续新创建PVC 将使用新的 StorageClass 配置。 ### 步骤4:使用 replace 命令(如果不更改回收策略且仅修复注解) ```bash kubectl replace -f provisioner.yaml --save-config ``` `--save-config` 选项会添加所需的注解,这样后续的 `apply` 操作就不会再出现警告。 ### 含义总结 - **"unchanged"**:表示这些资源已经存在且配置与文件中一致,无需更新。 - **"created"**:表示 StorageClass 资源在集群中不存在,所以被创建(但根据错误,实际上它可能已经存在,只是以不同的方式创建?)。然而,在输出中我们看到的是错误,所以实际上可能并没有成功创建,而是尝试更新一个已存在的资源失败了。 根据错误信息,实际上 StorageClass 已经存在(可能是之前通过非 `apply` 方式创建的),并且尝试更新它的 `reclaimPolicy` 字段,而这被禁止了。 因此,正确的做法是: 1. 如果不需要更改回收策略,则忽略警告,并使用 `replace` 命令更新 StorageClass 并修复注解。 2. 如果需要更改回收策略,则删除现有 StorageClass 后重新创建。 注意:在删除 StorageClass 之前,确保没有重要的 PVC 依赖它,或者确保已有 PV 的回收策略已经单独设置(因为 PV 的回收策略一旦创建也不能更改,但可以在创建后单独修改 PV 的回收策略,而 StorageClass 的回收策略只影响新创建PV)。 ### 参考引用说明 - 引用[^1] 和 [^4] 说明了 StorageClass 的回收策略和动态供应的机制。 - 引用[^2] 和 [^3] 提供了创建 StorageClassPVC 的示例。 ### 相关问题 根据用户的要求,生成相关问题: §§相关问题§§ 1. Kubernetes 中哪些资源字段在创建后不可修改? 2. 如何安全地迁移使用旧 StorageClassPVC/PV? 3. `kubectl apply` 与 `kubectl replace` 在工作机制上有何本质区别? 4. 如何批量更新集群中所有资源的 `last-applied-configuration` 注解? 注意:上述问题是为了帮助用户深入理解 Kubernetes 资源管理和操作命令。 </think>### 执行 `kubectl apply -f provisioner.yaml` 的输出分析 #### 输出内容解析: ```bash serviceaccount/nfs-client-provisioner unchanged clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner unchanged clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner unchanged deployment.apps/nfs-client-provisioner unchanged Warning: resource storageclasses/prom-data-sc is missing... # 警告信息 The StorageClass "prom-data-sc" is invalid: reclaimPolicy: Forbidden: updates to reclaimPolicy are forbidden. # 错误信息 storageclass.storage.k8s.io/prom-data-sc created # 结果声明 ``` #### 各部分的含义: 1. **`unchanged` 资源(ServiceAccount/ClusterRole/ClusterRoleBinding/Deployment)** 表示这些资源已存在且配置未变化,Kubernetes 无需执行更新操作[^1][^4]。通常是因为: - 资源已通过先前的 `apply` 命令创建 - YAML 文件中的定义与集群中的实际状态完全一致 2. **`storageclass.storage.k8s.io/prom-data-sc created`** 表明 StorageClass 资源 `prom-data-sc` **首次创建成功**。这是动态存储配置的关键组件,用于定义: - 存储供应者(provisioner- 回收策略(reclaimPolicy) - 卷绑定模式等[^2][^4] 3. **警告信息分析** ```bash Warning: resource storageclasses/prom-data-sc is missing the kubectl.kubernetes.io/last-applied-configuration annotation... ``` - **根本原因**:该 StorageClass 可能曾通过 `kubectl create`(而非 `apply`)创建 - **影响**:缺失此注解会导致后续 `apply` 操作无法正确计算配置差异 - **解决方案**: ```bash kubectl annotate storageclass prom-data-sc \ kubectl.kubernetes.io/last-applied-configuration="$(kubectl get sc prom-data-sc -o yaml | yq eval -j | jq -Rs)" ``` 4. **错误信息分析** ```bash The StorageClass "prom-data-sc" is invalid: reclaimPolicy: Forbidden: updates to reclaimPolicy are forbidden. ``` - **核心问题**:StorageClass 的 `reclaimPolicy` 字段**不可更新**(创建后即固化)[^1][^4] - **根本原因**: - 用户可能在 YAML 文件中修改了 `reclaimPolicy` 值 - Kubernetes 阻止此变更以确保现有 PV 的稳定性 - **回收策略说明**: | 策略 | 效果 | 适用场景 | |-----------|------------------------------------|-------------------------| | `Delete` | 删除 PVC 自动删除 PV 和后端存储 | 临数据,节省存储空间[^1] | | `Retain` | 保留 PV 和后端存储 | 重要数据需手动清理[^1] | | `Recycle` | (已废弃) 清理数据后重新使用 PV | 不推荐使用 | #### 当前状态总结: 1. **NFS 供应者组件已就绪** Deployment/RBAC 等组件运行正常,准备提供存储服务[^4] 2. **StorageClass 创建成功但有隐患** - ✅ 新 StorageClass 已可用 - ️ 缺少 `last-applied-configuration` 注解 - ⚠️ `reclaimPolicy` 可能不符合预期(若尝试修改) #### 解决路径: ```mermaid graph TD A[检查当前 reclaimPolicy] -->|kubectl get sc prom-data-sc -o jsonpath='{.reclaimPolicy}'| B[结果是否为预期值?] -->|是| C[仅修复注解] B -->|否| D[删除并重建 StorageClass] C --> E[执行注解修复命令] D --> F[修改 YAML 后重新 apply] E & F --> G[验证配置 kubectl apply -f provisioner.yaml] ``` #### 操作建议: 1. **检查现有回收策略**: ```bash kubectl get storageclass prom-data-sc -o jsonpath='{.reclaimPolicy}' ``` 2. **若需更改回收策略**: ```bash # 1. 删除现有 StorageClass kubectl delete storageclass prom-data-sc # 2. 修改 provisioner.yaml 确保包含: # apiVersion: storage.k8s.io/v1 # kind: StorageClass # metadata: # name: prom-data-sc # reclaimPolicy: Retain # 或 Delete # provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # 3. 重新创建 kubectl apply -f provisioner.yaml ``` 3. **仅修复注解问题**: ```bash kubectl annotate storageclass prom-data-sc \ kubectl.kubernetes.io/last-applied-configuration="$(kubectl get sc prom-data-sc -o yaml | yq eval -j | jq -Rs)" \ --overwrite ``` > **关键提示**:StorageClass 的回收策略只会影响**后续创建**的 PV,已有 PV 需单独修改[^1]: > ```bash > kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' > ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值