K8S学习----存储PV-PVC/StatefulSet

本文详细介绍了Kubernetes中的持久化存储原理,包括PersistentVolume(PV)和PersistentVolumeClaim(PVC)的关系,以及它们如何在集群中为应用提供稳定存储。同时,讲解了StatefulSet的特性,如有序部署、持久化存储和网络标识,并通过实例展示了如何配置和使用NFS存储。此外,还提到了PVC的保护机制,防止意外删除导致数据丢失。

学习目标:

1、掌握PV和PVC的关系
2、掌握statefulset对象

学习内容:

概念

PV(PersistentVolume)

是由管理员设置的存储,它是集群的一部分,就像节点是集群的资源一样,PV也是集群中的资源。PV是Volume之类的卷插件,但具有独立于使用PV的Pod的生命周期。此API 对象包含有存储实现的细节,即NFS、iscsi或特定于云提供商的存储系统

PVC(PersistentVolumeClaim)

是用户存储的请求,它与pod相似,Pod消耗节点资源,PVC消耗PV资源。pod可以请求特定级别的资源(CPU和内存)。声明可以请求特定的大小和访问方式(例如,可以以读写一次或只读多次模式挂载)

静态PV

集群管理员创建一些PV,它们带有可供集群用户使用的实际存储的细节,它们存在于kubernetes API中,可用于消费

动态

当管理员创建的静态PV都不匹配用户的PVC时,集群可能会尝试动态的为PVC创建卷,此配置基于StorageClasses:PVC必须请求[存储类],并且管理员必须创建并配置该类才能动态创建,声明该类为***可以有效的禁用其动态配置
要启用基于存储级别的动态存储配置,集群管理员需要启用API Server上的DefaultStorageClass【准入控制器】。例如,通过确保defaultStorageClass位于API Server组件的--admission-control标志,使用逗号分隔的有序值列表中,可以完成此操作

绑定

master中的控制环路监视新的PVC,寻找匹配的PV(如果可能),并将它们绑定在一起,如果为新的PVC动态调配PV,则该环路将始终将该PV绑定到PVC,否则,用户总会得到它们所请求的存储,但是容量可能超出要求的数量,一旦PV和PVC绑定后,PersistentVolumeClaim绑定是排他性的,不管他们是如何绑定的,PVC跟PV绑定是一对一的映射

持久化卷声明的保护

PVC保护的目的是确保pod正在使用PVC不会从系统中移除,因为如果被移除的话可能会导致数据丢失
##注意:当pod的状态为pending并且pod已经分配给节点或pod为running状态时,PVC处于活动状态
当启用PVC保护alpha功能时,如果用户删除了一个pod正在使用的PVC,则该PVC不会被立即删除,PVC的数据删除将被推迟,直到PVC不再被任何pod使用

持久化卷类型

在这里插入图片描述
持久化演示代码

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:                             #访问模式
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle    #回收策略
  storageClassName: slow                    #存储类名称
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp           #nfs服务器的目录
    server: 172.17.0.2   #nfs服务器的ip

PV访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上,如下表所示,供应商具有不同的功能,每个PV的访问模式都将被设置为该卷支持的特定的模式,例如,NFS可以支持多个读/写客户端,但特定的NFS PV可能以只读方式导出到服务器上,每个PV都要一套自己的用来描述特定功能的访问模式

  • ReadWriteOnce------该卷可以被单个节点以读/写模式挂载
  • ReadOnlyMany-------该卷可以被多个节点以只读模式挂载
  • ReadWriteMany------该卷可以被多个节点以读/写模式挂载

在命令行中,访问模式缩写为:

  • RWO-----ReadWriteOnce
  • ROX------ReadOnlyMany
  • RWX-----ReadWriteMany
    ##一个卷一次只能使用一种访问模式挂载,即使它支持多种访问模式,例如GCEPersistentDisk可以由单个节点作为RWO模式挂载,或由多个节点ROX模式挂载,但不能同时挂载

回收策略

  • Retain(保留)—手动回收
  • Recyle(回收)—基本擦除(rm -rf *) #最新版本已经被废弃
  • Delete(删除)—关联的存储资产将被删除

状态

卷可以处于以下的某种状态:

  • Available(可用)---- 一块空闲资源还没有被任何声明绑定
  • Bound(已绑定)---- 卷已经被声明绑定
  • Released(已释放)---- 声明被删除,但是资源还未被集群重新声明
  • Failed(失败)----- 该卷的自动回收失败

命令行会显示绑定到PV的PVC的名称

持久化演示说明–NFS

  1. 安装NFS服务器
    在这里插入图片描述

  2. 部署PV

apiVerison: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /data/nfs       #nfs服务器的某个目录
    server: 10.66.66.10   #nfs服务器的ip
  1. 创建服务并使用PVC
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLables:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerport: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "RWO" ]
      storageClassName: "nfs"
      resources:
        requests:
          storage: 1Gi

关于StatefulSet

  1. 匹配Pod name(网络标识)的模式为:(StatefulSet名称)−(StatefulSet名称)-(StatefulSet名称)(序号),比如上面的示例:web-0,web-1,web-2
  2. StatefulSet为每个pod副本创建了一个DNS域名,这个域名的格式为:$(pod name).(headless server name),也就意味着服务间是通过Pod域名来通信而非Pod IP,因为当pod所在的node发生故障时,pod会被漂移到其他node上,pod ip会发生变化,但是pod域名不会有变化
  3. StatefulSet使用Headless服务来控制pod的域名,这个域名的FQDN为:(servicename).(namespace).svc.cluster.local,其中,"cluster.local"指的是集群的域名
  4. 根据volumeClaimTemplates,为每个pod创建一个PVC,pvc的命名规则匹配模式:(volumeClaimTemplates.name)-(pod_name),比如上面的volumeMounts.name=www,podname=web-[0-2],因此创建出来的pvc是www-web-0,www-web-1,www-web-2
  5. 删除pod不会删除其pvc,手动删除pvc将自动释放pv

StatefulSet的启停顺序

  1. 有序部署:部署StatefulSet时,如果有多个Pod副本,它们会被顺序的创建(从0到N-1)并且,在下一个pod运行之前所有之前的pod必须都是running和ready的状态
  2. 有序删除:当pod被删除时,它们被终止的顺序是从N-1到0
  3. 有序扩展:当对pod执行扩展操作时,与部署一样,它前面的pod必须都处于running和ready状态

StatefulSet使用场景

  1. 稳定的持久化存储。即pod重新调度后还是能访问到相同的持久化存储,基于PVC来实现
  2. 稳定的网络标识符,即pod重新调度后其podname和hostname不变
  3. 有序部署,有序扩展,基于initcontainers来实现
  4. 有序收缩
<think> 嗯,用户的问题是关于K8S挂载accessModes为ReadWriteMany的使用指南和注意事项。首先,我需要回顾之前的引用内容,看看有哪些相关信息。引用[1]提到数据卷的基础概念,包括Pod直接挂载各种类型如emptyDir、hostPath、nfs,以及通过PV/PVC挂载localPath和nfs。引用[2]强调了StatefulSet在持久化存储和配置一致性上的优势,可能涉及ReadWriteMany的场景。引用[4]详细讨论了Ceph存储的三种类型,特别是文件存储(CephFS)和对象存储支持ReadWriteMany,而块存储(RBD)不支持共享存储(ReadWriteOnce)。这些信息是关键。 接下来,用户明确询问的是ReadWriteMany的配置方法和注意事项。根据引用[4],CephFS和对象存储都支持RWX模式,而块存储(RBD)不行。因此,存储后端的选择是首要考虑点。用户可能需要知道如何选择合适的存储类型,比如NFS、CephFS、GlusterFS等。 然后,配置步骤方面,引用[1]中的pv/pvc挂载部分,特别是nfs的例子,应该作为范例。需要说明PV中accessModes设置为ReadWriteMany,并在PVC中匹配该模式。同时,StorageClass的配置也很重要,如引用[4]中的CephBlockPool和StorageClass创建步骤,但需注意块存储不支持RWX,因此这里应转向支持共享的存储类型。 注意事项部分,引用[1]提到挂载nfs时的版本和权限问题,引用[4]则指出性能差异,如文件存储速度较慢但支持共享。此外,StatefulSet的使用场景(引用[2])可能需要考虑,但StatefulSet通常用于有状态服务,可能涉及ReadWriteOnce,不过用户的问题集中在RWX,所以需要明确适用场景,比如多Pod并行写入的场景。 另外,用户可能遇到的坑点包括:存储后端的兼容性、权限设置(如NFS的no_root_squash)、网络策略(如引用[3]中的allowedCIDRs影响网络存储访问)、性能优化方法(引用[2]中的配置优化技巧)。还要注意PVC绑定模式,比如WaitForFirstConsumer是否适用,但RWX可能需要立即绑定,避免调度问题。 最后,总结关键点:存储选择、正确配置PV/PVC的accessModes、权限和网络设置,以及性能调优。确保用户了解不同存储后端的特点,避免错误配置导致挂载失败。 </think> 以下是Kubernetes中挂载`accessModes: ReadWriteMany`存储的使用指南和注意事项,结合引用内容的关键点整理: --- ### **一、核心概念** 1. **`ReadWriteMany`(RWX)特性** 允许多个Pod**同时读写**同一存储卷,适用于需要共享数据的场景(如媒体库、配置文件同步)[^4]。 ```yaml accessModes: - ReadWriteMany # 关键配置 ``` 2. **支持的存储类型**(引用[1][^1][^4]) | 存储类型 | 是否支持RWX | 典型用例 | |----------------|-------------|---------------------------| | NFS | ✅ | 媒体库、共享配置(nas-tools)[^2] | | CephFS | ✅ | 文件共享、持久化应用数据 | | GlusterFS | ✅ | 分布式文件存储 | | 对象存储(OSS)| ✅ | 图片/视频存储[^4] | | HostPath | ❌ | 单节点调试(非生产) | | Local PV | ❌ | 本地磁盘(仅单Pod访问) | --- ### **二、配置步骤** #### 1. **创建支持RWX的PV/PVC**(以NFS为例) ```yaml # PV定义(引用[1][^1]) apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 100Gi accessModes: - ReadWriteMany # 关键声明 nfs: path: /data/nfs_share server: 192.168.1.10 --- # PVC绑定(引用[1][^1]) kind: PersistentVolumeClaim apiVersion: v1 metadata: name: rwx-pvc spec: accessModes: - ReadWriteMany # 必须与PV匹配 resources: requests: storage: 100Gi ``` #### 2. **Pod挂载PVC** ```yaml apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: app volumeMounts: - name: shared-data mountPath: /app/data volumes: - name: shared-data persistentVolumeClaim: claimName: rwx-pvc # 引用已创建的PVC ``` --- ### **三、关键注意事项** 1. **存储后端兼容性** - **RWX依赖存储系统能力**:例如Ceph RBD块存储**不支持RWX**,需改用CephFS或NFS[^4]。 - 云服务商限制:部分云存储(如AWS EBS)默认不支持RWX。 2. **文件锁与并发冲突** - 多Pod同时写同一文件可能导致数据损坏(如数据库SQLite),需应用层处理并发(nas-tools需分离写入路径)[^2]。 3. **性能优化** - **NFS调参**:调整`rsize/wsize`(如`mountOptions: ["rsize=65536","wsize=65536"]`)。 - **CephFS**:启用内核客户端提升性能(`fuse: false`)[^4]。 4. **权限与安全** - NFS服务端需配置`no_root_squash`(或Pod指定非root用户)。 - 网络策略限制:仅允许特定CIDR访问存储(引用[3]中的`allowedCIDRs`)[^3]。 5. **StatefulSet特殊场景** - 若需为每个Pod提供独立存储(如数据库),使用`ReadWriteOnce` + 动态卷(非RWX)[^2]。 --- ### **四、故障排查方向** 1. **PVC处于Pending状态** - 检查StorageClass是否支持RWX - 确认存储后端资源充足 2. **Pod挂载失败** - 验证NFS/CephFS服务可达性 - 检查服务端导出路径权限(如NFS的`/etc/exports`) 3. **读写性能低下** - 监控存储服务器负载(iowait、网络流量) - 调整Pod与存储的亲和性(避免跨节点访问) --- > **附:适用场景参考**[^2][^4] > - ✅ 媒体库(如nas-tools的刮削结果共享) > - ✅ CI/CD共享构建缓存 > - ✅ 多实例日志聚合(需文件锁控制) > - ❌ 数据库主节点(单写场景推荐`ReadWriteOnce`)
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值