教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载StorageClass是 Kubernetes 存储体系中的存储分类器它由管理员定义描述一类存储的特质如性能等级、回收策略、备份策略并绑定一个provisioner存储分配器负责按需动态创建PersistentVolume。本文基于本仓库 concepts/storageclass.md 展开结合仓库内的真实配置清单与实战文档NFS、Ceph RBD、Rook、OpenEBS 等带你完整掌握 StorageClass 的资源字段、内置/外部分配器选型、回收策略与挂载选项以及如何通过默认 StorageClass实现 PVC 的无感动态供给。读完本文你将能够独立设计并落地一套 Kubernetes 动态持久化存储方案。StorageClass 是什么为存储定义类StorageClass为管理员提供了一种描述存储 class类 的方法。不同的 class 可以映射到不同的服务质量等级、备份策略或由集群管理员确定的任意策略——Kubernetes 本身并不理解各个 class 具体代表什么含义这个概念在其他存储系统中有时被称为配置文件profile。Kubernetes 的持久化存储体系由 Persistent Volume持久卷 与 PersistentVolumeClaimPVC组成PV 是集群中的存储资源PVC 是用户对存储的请求。而StorageClass正是连接二者的催化剂——它让集群能够在没有静态 PV 匹配时依据用户 PVC 的请求动态地创建卷动态供给Dynamic Provisioning从而把如何提供存储的底层细节彻底抽象掉。StorageClass 资源与核心字段StorageClass中包含provisioner、parameters和reclaimPolicy字段当 class 需要动态分配PersistentVolume时都会用到。一个最典型的清单如下本仓库 concepts/storageclass.md 中的标准示例kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Retain mountOptions: - debug各字段职责如下字段是否必填作用metadata.name是StorageClass 对象名称用户通过该名称请求特定存储类创建后不可更新provisioner是决定使用哪个卷插件分配 PV必须显式指定parameters否描述属于该 class 卷的参数具体键值由 provisioner 决定reclaimPolicy否动态创建 PV 的回收策略Delete或Retain默认DeletemountOptions否动态创建的 PV 使用的挂载选项allowVolumeExpansion否是否允许该 class 的卷被扩容需配合特性开关volumeBindingMode否卷绑定模式如Immediate/WaitForFirstConsumerStorageClass 对象的名称非常重要——用户使用该类来请求一个特定的存储方法。创建StorageClass对象时管理员设置名称和其他参数对象一旦创建就不能再对其更新因此规划名称与参数需谨慎。另外管理员可以为没有申请绑定到特定 class 的 PVC指定一个默认的 StorageClass具体绑定逻辑下文默认 StorageClass 与 PVC 绑定一节详述。Provisioner存储分配器决定由谁创建 PVStorageClass 有一个provisioner分配器用来决定使用哪个卷插件分配 PV该字段必须指定。provisioner 分为两类内置分配器Internal Provisioner名称以kubernetes.io为前缀、随 Kubernetes 一起打包的分配器外部分配器External Provisioner独立运行的程序遵循 Kubernetes 定义的卷供给规范由社区或存储供应商维护。本仓库 concepts/storageclass.md 给出了一版完整的分配器对照表✓ 表示 Kubernetes 内置提供该分配器Volume PluginInternal ProvisionerConfig ExampleAWSElasticBlockStore✓AWSEBSAzureFile✓Azure FileAzureDisk✓Azure DiskCephFS--Cinder✓OpenStack CinderFC--FlexVolume--Flocker✓-GCEPersistentDisk✓GCEGlusterfs✓Glusterfs 持久化存储实践iSCSI--PhotonPersistentDisk✓-Quobyte✓QuobyteNFS-利用 NFS 动态提供存储卷RBD✓使用 Ceph 提供持久化存储VsphereVolume✓vSpherePortworxVolume✓Portworx VolumeScaleIO✓ScaleIOStorageOS✓StorageOS说明上表为原文档所载版本部分插件的内置支持状态会随 Kubernetes 版本演进而变化实践中应以目标集群版本官方文档为准。外部分配器与 CSI 生态你不限于使用上表所列的内置分配器。外部分配器是独立的程序遵循 Kubernetes 定义的卷供给规范外部供应商的作者完全可以自由决定代码存放位置、打包方式、运行方式及使用的卷插件包括 Flex 等。例如NFS 没有内置分配器但可以使用外部分配器如nfs-client-provisioner来获得动态供给能力详见仓库实践文档 利用 NFS 动态提供 Kubernetes 后端存储卷Ceph RBD既有内置的kubernetes.io/rbd也有外部的rbd-provisionerceph.com/rbd后者用于解决 kube-controller-manager 容器镜像缺少rbd命令导致动态供给失败的问题详见 使用 rbd-provisioner 提供 rbd 持久化存储。从发展趋势看外部分配器正逐步统一到CSI容器存储接口生态。仓库 concepts/csi.md 展示了如何为 CSI 驱动创建 StorageClass 以启用动态供给kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: fast-storage provisioner: com.example.team/csi-driver parameters: type: pd-ssd当用户创建一个引用fast-storage的 PVC 后Kubernetes 通过CreateVolume调用把参数type: pd-ssd传给 CSI 插件插件创建新卷并自动生成对应的 PV 对象绑定到 PVC。CSI 驱动的部署通常借助external-provisioner监听 PVC 并触发 CreateVolume/DeleteVolume、external-attacher处理卷挂载/卸载等 sidecar 容器完成存储供应商可用这些组件构建插件 Deployment而 CSI 驱动本身完全感知不到 Kubernetes 的存在。回收策略reclaimPolicy由 StorageClass 动态创建的 PersistentVolume 会在reclaimPolicy字段中指定回收策略取值与语义如下Delete删除 PV 时同时删除外部基础设施中的关联存储资产如 AWS EBS、GCE PD、Azure Disk、Cinder 卷。若创建 StorageClass 时未指定默认为DeleteRetainPVC 被删除后 PV 仍保留、卷被视为已释放Released但前一个声明人的数据仍然存在不能立即被再次声明需要管理员手动回收——删除 PV、清理存储资产数据、再以同名资产重建 PV详见 Persistent Volume持久卷 的回收章节。值得注意通过 StorageClass手动创建并管理的 PersistentVolume会使用它们被创建时指定的回收策略而不是 StorageClass 上的配置。动态供给场景下卷继承其 StorageClass 的回收策略默认为 Delete管理员应当根据用户预期显式配置reclaimPolicy否则只能在 PV 创建后编辑或修补。挂载选项mountOptions由 StorageClass 动态创建的 PersistentVolume 将使用 class 中mountOptions字段指定的挂载选项。例如- debug可传递给 EBS 卷。使用挂载选项时需注意两点concepts/storageclass.md如果卷插件不支持挂载选项却指定了该选项则分配操作失败挂载选项在 class 和 PV 上都不会做验证如果挂载选项无效那么这个 PV 就会挂载失败。参数parametersStorageClass 具有描述属于该 class 卷的parameters具体键值取决于分配器不同 provisioner 接受不同的参数。当参数被省略时会使用默认值。以文档中给出的 EBS 为例参数type的值io1和参数iopsPerGB特定于 EBS PV——type: io1表示预置 IOPS 卷iopsPerGB定义每 GiB 的 IOPS 配额。这类参数直接决定了动态创建卷的性能与成本特征这正是 StorageClass 能够表达不同服务质量等级的核心手段。仓库内的真实 StorageClass 参数实例本仓库manifests目录下提供了多个可直接参照的真实配置1. Ceph RBD内置分配器kubernetes.io/rbd—— manifests/mariadb-cluster/ceph-class.yamlapiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-web provisioner: kubernetes.io/rbd parameters: monitors: 172.28.7.98,172.28.7.99,172.28.7.100 adminId: admin adminSecretName: ceph-secret adminSecretNamespace: galera pool: rbd #此处默认是rbd池生产上建议自己创建存储池隔离 userId: admin userSecretName: ceph-secret各参数含义monitors指定 Ceph 监控节点地址逗号分隔adminId/adminSecretName/adminSecretNamespace指定拥有创建权限的 admin 账号及其 Secretpool指定 RBD 存储池userId/userSecretName指定实际挂载卷时使用的客户端账号。2. Rook外部分配器rook.io/block—— manifests/rook/rook-storageclass.yamlapiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-block provisioner: rook.io/block parameters: pool: replicapool clusterName: rook # 未指定时默认使用 rook 集群 # fstype: ext4 # 卷文件系统类型未指定时默认 ext43. OpenEBS外部分配器openebs.io/provisioner-iscsi—— manifests/openebs/openebs-storageclasses.yaml 中定义了openebs-standalone、openebs-jupyter、openebs-mongodb、openebs-kafka等一批 StorageClass每个都以openebs.io/jiva-replica-count控制副本数、openebs.io/storage-pool指定存储池、openebs.io/volume-monitor开启卷监控例如apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-standalone provisioner: openebs.io/provisioner-iscsi parameters: openebs.io/storage-pool: default openebs.io/jiva-replica-count: 1 openebs.io/volume-monitor: true openebs.io/capacity: 5G可以看到同一个存储后端可以通过不同参数组合声明出多个 StorageClass如副本数 1 的低成本类、副本数 2 的高可用类这正是 StorageClass 分类能力的直接体现。默认 StorageClass 与 PVC 绑定逻辑StorageClass 与 PVC 的绑定遵循以下规则详见 Persistent Volume持久卷 的类章节PVC 通过storageClassName属性请求特定类只有与 PVC 具有相同storageClassName的 PV 才能绑定storageClassName设置为的 PVC 只能绑定到没有类的 PV未设置storageClassName的 PVC 的行为取决于集群是否启用了DefaultStorageClass准入控制插件若启用管理员可通过在 StorageClass 对象上设置注解storageclass.kubernetes.io/is-default-class: true将其指定为默认类未声明类的 PVC 将自动绑定到该默认类若指定了多个默认类准入控制插件将禁止所有 PVC 创建若准入控制插件关闭则不存在默认 StorageClass 概念未设置storageClassName的 PVC 与设置为的处理方式相同。本仓库 利用 NFS 动态提供 Kubernetes 后端存储卷 演示了完整操作先部署nfs-client-provisioner外部分配器fuseim.pri/ifs再创建名为default的 StorageClass最后通过 patch 命令将其标记为集群默认$ kubectl patch storageclass default -p {metadata: {annotations:{storageclass.kubernetes.io/is-default-class:true}}} storageclass.storage.k8s.io default patched $ kubectl get sc NAME PROVISIONER AGE default (default) fuseim.pri/ifs 2d此后创建的、未指定storageClassName的 PVC 会自动获得动态供给的 NFS 卷。该实战文档还给出了验证步骤创建 PVC 后kubectl get pvc可见状态变为Bound并自动生成形如pvc-fe3cb938-3f15-11e8-b61d-08002795cb26的动态 PV随后运行一个在挂载目录 touchSUCCESS文件的测试 Pod去 NFS 共享目录下确认文件存在即证明动态供给链路完全打通。卷扩容allowVolumeExpansionStorageClass 还支持声明卷扩容能力。当集群启用PersistentVolumeClaimResize准入控制插件并开启相应特性开关后只有allowVolumeExpansion字段设置为true的 StorageClass 才允许其卷被调整大小。仓库 Persistent Volume持久卷 给出了一个 Glusterfs 的完整示例kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gluster-vol-default provisioner: kubernetes.io/glusterfs parameters: resturl: http://192.168.10.100:8080 restuser: secretNamespace: secretName: allowVolumeExpansion: true扩容时用户只需编辑 PVC 请求更大的容量Kubernetes 会尝试调整现有卷而非新建 PV。需要留意文件系统的 resize 只有在以 ReadWrite 模式启动新 Pod 时才会执行且仅支持 XFS、Ext3、Ext4 文件系统部分后端如 EBS扩容耗时较长且存在操作配额限制。实战PVC 触发动态供给的完整链路综合 PV/PVC 生命周期Persistent Volume持久卷一次完整的 StorageClass 动态供给流程如下定义管理员创建 StorageClass指定 provisioner、parameters、reclaimPolicy 等请求用户创建引用该 StorageClass 的 PVC声明访问模式、请求容量、storageClassName供给当静态 PV 均不匹配时provisioner 依据 parameters 在后端NFS 目录、Ceph RBD 镜像、云盘等创建真实存储资产并自动生成 PV 对象绑定控制环路将新 PV 绑定到 PVC一对一、排他未匹配到卷的 PVC 会无限期保持未绑定状态使用Pod 在 volume 中通过persistentVolumeClaim.claimName引用 PVC卷被挂载到容器回收用户删除 PVC 后依据 StorageClass 的reclaimPolicy默认 Delete执行保留或删除。NFS 动态供给要点参考 利用 NFS 动态提供 Kubernetes 后端存储卷前提是已安装 NFS 服务器且与集群节点网络连通nfs-client-provisioner本身不提供 NFS仅消费现有 NFS 共享Deployment 中通过环境变量NFS_SERVER、NFS_PATH指向实际共享目录PROVISIONER_NAME必须与 StorageClass 的provisioner完全一致动态 PV 在 NFS 服务器上以${namespace}-${pvcName}-${pvName}命名回收时更名为archived-${namespace}-${pvcName}-${pvName}集群启用 RBAC 时需要为 provisioner 创建 ServiceAccount、ClusterRole 与 ClusterRoleBinding 授权。Ceph RBD 动态供给要点参考 使用 rbd-provisioner 提供 rbd 持久化存储常规部署二进制方式、且节点安装ceph-common包直接使用内置kubernetes.io/rbd即可若 kube-controller-manager 以容器方式运行且镜像缺少rbd命令动态供给会报executable file not found in $PATH错误此时需部署外部分配器rbd-provisioner并把 StorageClass 的provisioner改为ceph.com/rbd参数层面建议关注imageFormat: 2与imageFeatures: layeringkubelet 节点ceph-common版本尽量与 Ceph 服务端保持一致该实战文档验证了从创建 PVC、Pod 挂载/dev/rbd0到删除后 PV/PVC 与 RBD 镜像全部自动清理的完整闭环也提醒生产环境中删除测试务必确认回收策略设置妥当。参考本仓库 concepts/storageclass.md本文核心来源本仓库 concepts/persistent-volume.mdPV/PVC 生命周期、默认类、卷扩容本仓库 concepts/csi.mdCSI 驱动的 StorageClass 动态供给本仓库 concepts/storage.mdKubernetes 存储对象总览本仓库实战清单manifests/rook/rook-storageclass.yaml、manifests/mariadb-cluster/ceph-class.yaml、manifests/openebs/openebs-storageclasses.yaml赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐容器持久化存储实战Kubernetes PVC与StorageClass完全指南容器持久化存储实战Kubernetes PVC与StorageClass完全指南 在Kubernetes容器编排环境中数据持久化是保障应用稳定性的核心环节。教程Valkey 集群从零到可用create-cluster 一键部署与运维手册Valkey 集群从零到可用create cluster 一键部署与运维手册 Valkey 是面向缓存优化的分布式键值数据库。本文用官方自带的 createKV存储缓存数据库ClickHouse Operator 存储指南PersistentVolume、StorageClass 与 PVC 的 Kubernetes 持久化实战ClickHouse Operator 存储指南PersistentVolume、StorageClass 与 PVC 的 Kubernetes 持久化实战云原生容器编排后端运维可观测性上一篇3步掌握Buzz完全离线的专业音频转录工具终极指南下一篇Watermill中的事件驱动架构可扩展性测试横向扩展验证创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考