学习K8s:从PV到PVC

本文深入讲解Kubernetes中PersistentVolume(PV)、PersistentVolumeClaim(PVC)及StorageClass的概念与使用流程,涵盖静态与动态存储供应、绑定、使用、释放与回收的生命周期管理,以及PV的类型与状态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

初识PV、PVC、StorageClass

1.1 介绍

管理存储是管理计算的一个明显问题。该PersistentVolume子系统为用户和管理员提供了一个API,用于抽象如何根据消费方式提供存储的详细信息。为此,我们引入了两个新的API资源:PersistentVolume和PersistentVolumeClaim

PersistentVolume(PV)是集群中由管理员配置的一段网络存储。 它是集群中的资源,就像节点是集群资源一样。 PV是容量插件,如Volumes,但其生命周期独立于使用PV的任何单个pod。 此API对象捕获存储实现的详细信息,包括NFS,iSCSI或特定于云提供程序的存储系统。

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

虽然PersistentVolumeClaims允许用户使用抽象存储资源,但是PersistentVolumes对于不同的问题,用户通常需要具有不同属性(例如性能)。群集管理员需要能够提供各种PersistentVolumes不同的方式,而不仅仅是大小和访问模式,而不会让用户了解这些卷的实现方式。对于这些需求,有StorageClass 资源。

StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别,或备份策略,或者由群集管理员确定的任意策略。 Kubernetes本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”。

PVC和PV是一一对应的。

1.2 生命周期

PV是群集中的资源。PVC是对这些资源的请求,并且还充当对资源的检查。PV和PVC之间的相互作用遵循以下生命周期:

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

  • 供应准备Provisioning

    —通过集群外的存储系统或者云平台来提供存储持久化支持。

    • - 静态提供Static:集群管理员创建多个PV。 它们携带可供集群用户使用的真实存储的详细信息。 它们存在于Kubernetes API中,可用于消费
    • - 动态提供Dynamic:当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时,集群可能会尝试为PVC动态配置卷。 此配置基于StorageClasses:PVC必须请求一个类,并且管理员必须已创建并配置该类才能进行动态配置。 要求该类的声明有效地为自己禁用动态配置。
  • 绑定Binding—用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前,pvc会保持未绑定状态。

  • 使用Using—用户可在pod中像volume一样使用pvc。

  • 释放Releasing—用户删除pvc来回收存储资源,pv将变成“released”状态。由于还保留着之前的数据,这些数据需要根据不同的策略来处理,否则这些存储资源无法被其他pvc使用。

  • 回收Recycling

    —pv可以设置三种回收策略:保留(Retain),回收(Recycle)和删除(Delete)。

    • - 保留策略:允许人工处理保留的数据。
    • - 删除策略:将删除pv和外部关联的存储资源,需要插件支持。
    • - 回收策略:将执行清除操作,之后可以被新的pvc使用,需要插件支持。

注:目前只有NFS和HostPath类型卷支持回收策略,AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

1.3 PV类型

  • GCEPersistentDisk
  • AWSElasticBlockStore
  • AzureFile
  • AzureDisk
  • FC (Fibre Channel)
  • Flexvolume
  • Flocker
  • NFS
  • iSCSI
  • RBD (Ceph Block Device)
  • CephFS
  • Cinder (OpenStack block storage)
  • Glusterfs
  • VsphereVolume
  • Quobyte Volumes
  • HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
  • Portworx Volumes
  • ScaleIO Volumes
  • StorageOS

1.4 PV卷阶段状态

  • Available – 资源尚未被claim使用
  • Bound – 卷已经被绑定到claim了
  • Released – claim被删除,卷处于释放状态,但未被集群回收。
  • Failed – 卷自动回收失败

2、演示:创建PV

2.1 在master上创建PV

(1)编写yaml文件,并创建pv

创建5个pv,存储大小各不相同,是否可读也不相同

[root@master volumes]# vim pv-damo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: nfs
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 20Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 10Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: nfs
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 15Gi
[root@master volumes]# kubectl apply -f pv-damo.yaml
persistentvolume/pv001 created
persistentvolume/pv002 created
persistentvolume/pv003 created
persistentvolume/pv004 created
persistentvolume/pv005 created

(2)查询验证

[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv001     5Gi        RWO,RWX        Retain           Available                                      9s
pv002     5Gi        RWO            Retain           Available                                      9s
pv003     5Gi        RWO,RWX        Retain           Available                                      9s
pv004     10Gi       RWO,RWX        Retain           Available                                      9s
pv005     15Gi       RWO,RWX        Retain           Available                                      9s

3、创建PVC,绑定PV

(1)编写yaml文件,并创建pvc

创建一个pvc,需要6G存储;所以不会匹配pv001、pv002、pv003

[root@master volumes]# vim vol-pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
  namespace: default
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 6Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: vol-pvc
  namespace: default
spec:
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html/
[root@master volumes]# kubectl apply -f vol-pvc-demo.yaml
persistentvolumeclaim/mypvc created
pod/vol-pvc created

(2)查询验证:pvc已经绑定到pv004上

[root@master ~]# kubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mypvc     Bound     pv004     10Gi       RWO,RWX                       24s
[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM           STORAGECLASS   REASON    AGE
pv001     5Gi        RWO,RWX        Retain           Available                                            1m
pv002     5Gi        RWO            Retain           Available                                            1m
pv003     5Gi        RWO,RWX        Retain           Available                                            1m
pv004     10Gi       RWO,RWX        Retain           Bound       default/mypvc                            1m
pv005     15Gi       RWO,RWX        Retain           Available                                            1m

(3)查询业务验证

[root@master ~]# kubectl get pods -o wide
NAME      READY     STATUS    RESTARTS   AGE       IP             NODE
vol-pvc   1/1       Running   0          59s       10.244.2.117   node2
[root@master ~]# curl 10.244.2.117
<h1>NFS stor 04</h1>
<think>我们正在配置Kubernetes审计日志以记录PVPVC的所有操作。根据用户需求,我们需要在审计策略中捕获与PersistentVolume和PersistentVolumeClaim相关的所有操作(如create, update, delete, get, list等)。 根据之前的审计策略设计原则,我们可以通过修改审计策略文件(audit-policy.yaml)来实现。具体步骤包括: 1. 在审计策略中明确添加针对PersistentVolume(PV)和PersistentVolumeClaim(PVC)资源的规则。 2. 设置适当的日志级别(例如,对于写操作使用RequestResponse级别以记录请求和响应体,对于读操作可以使用Metadata级别)。 参考引用[1]和[2]中关于PVPVC的描述,我们知道: - PV属于核心API组(group为空字符串),资源名为"persistentvolumes" - PVC属于核心API组(group为空字符串),资源名为"persistentvolumeclaims" 因此,我们可以在审计策略中添加如下规则: ```yaml # 记录PVPVC的关键写操作(create, update, delete) - level: RequestResponse verbs: ["create", "update", "delete"] resources: - group: "" # 核心API组 resources: ["persistentvolumes", "persistentvolumeclaims"] # 记录PVPVC的读操作(get, list, watch) - level: Metadata verbs: ["get", "list", "watch"] resources: - group: "" # 核心API组 resources: ["persistentvolumes", "persistentvolumeclaims"] ``` 这样配置后,所有对PVPVC的操作都将被记录。其中,写操作会记录请求和响应体(包括具体的配置信息),读操作则记录元数据(包括用户、时间、资源标识等)。 完整示例策略文件(audit-policy.yaml)可能如下: ```yaml apiVersion: audit.k8s.io/v1 kind: Policy rules: # 规则1:记录PVPVC的写操作 - level: RequestResponse verbs: ["create", "update", "delete"] resources: - group: "" resources: ["persistentvolumes", "persistentvolumeclaims"] # 规则2:记录PVPVC的读操作 - level: Metadata verbs: ["get", "list", "watch"] resources: - group: "" resources: ["persistentvolumes", "persistentvolumeclaims"] # 其他规则...(如之前已有的规则,例如针对secrets, configmaps等) ``` 配置完成后,需要将此策略文件应用到kube-apiserver,并重启kube-apiserver(或使其重新加载配置)。具体步骤: 1. 将上述策略文件保存到kube-apiserver所在节点的路径,例如`/etc/kubernetes/audit-policy.yaml`。 2. 修改kube-apiserver的启动参数,添加: ```bash --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kubernetes/audit/audit.log # 或者使用webhook后端 ``` 如果使用webhook后端,则配置`--audit-webhook-config-file`。 3. 重启kube-apiserver。 验证配置: 1. 创建一个PVPVC,然后检查审计日志中是否有对应的记录。 2. 执行一个读取PVPVC的操作(如`kubectl get pv`),检查审计日志。 注意:由于审计日志可能会产生大量数据,特别是对于读操作(如list和watch),在生产环境中需要谨慎评估存储和性能影响。可以考虑对高频读操作进行采样(例如,只记录部分请求的元数据),但根据用户要求,这里需要记录所有操作。 另外,根据合规要求,确保审计日志的存储和加密符合企业策略。 相关问题: 1. 如何限制审计日志的大小以避免存储压力? 2. 如何加密Kubernetes审计日志以确保安全? 3. 如何将PVPVC的审计日志与其他资源日志分开存储? 4. 如何监控审计日志采集管道的健康状况?</think>### Kubernetes审计日志配置:记录PVPVC操作 以下是针对PersistentVolume(PV)和PersistentVolumeClaim(PVC)操作的审计日志配置方案,基于Kubernetes审计策略实现: #### 步骤1: 创建审计策略文件 (audit-policy.yaml) ```yaml apiVersion: audit.k8s.io/v1 kind: Policy rules: # 记录PV的所有操作(核心API组) - level: RequestResponse verbs: ["*"] # 捕获所有动词:create/update/delete/get/list等 resources: - group: "" # 核心API组 resources: ["persistentvolumes"] # 记录PVC的所有操作(核心API组) - level: RequestResponse verbs: ["*"] resources: - group: "" # 核心API组 resources: ["persistentvolumeclaims"] # 可选:记录StorageClass操作(存储类资源组) - level: Metadata verbs: ["*"] resources: - group: "storage.k8s.io" resources: ["storageclasses"] # 默认策略(其他资源采样记录) - level: Metadata omitStages: ["RequestReceived"] ``` #### 步骤2: 配置kube-apiserver 修改kube-apiserver启动参数(通常在/etc/kubernetes/manifests/kube-apiserver.yaml): ```yaml spec: containers: - command: - kube-apiserver - --audit-policy-file=/etc/kubernetes/audit-policy.yaml # 策略文件 - --audit-log-path=/var/log/kubernetes/audit/audit.log # 日志路径 - --audit-log-maxage=30 # 保留30天 - --audit-log-maxbackup=10 # 保留10个备份 volumeMounts: - mountPath: /etc/kubernetes/audit-policy.yaml name: audit readOnly: true - mountPath: /var/log/kubernetes/audit/ name: audit-log volumes: - name: audit hostPath: path: /etc/kubernetes/audit-policy.yaml type: File - name: audit-log hostPath: path: /var/log/kubernetes/audit type: DirectoryOrCreate ``` #### 步骤3: 验证配置 1. 重启kube-apiserver: ```bash # 检查pod名称后重启 kubectl get pods -n kube-system | grep apiserver kubectl delete pod <apiserver-pod-name> -n kube-system ``` 2. 测试PV/PVC操作: ```bash kubectl create -f persistent-volume.yaml # 创建PV kubectl get pv # 查询PV kubectl delete pv my-pv # 删除PV ``` 3. 检查审计日志: ```bash tail -f /var/log/kubernetes/audit/audit.log | grep persistentvolumes ``` #### 关键字段说明 审计日志中将包含以下关键信息: - `verb`: 操作类型(create/update/delete等) - `resource`: 资源类型(persistentvolumes/persistentvolumeclaims) - `user`: 操作者身份(用户或ServiceAccount) - `requestURI`: API路径(如`/api/v1/persistentvolumes/my-pv`) - `responseStatus.code`: HTTP状态码(200/201/403等) - `annotations`: 扩展信息(如StorageClass名称)[^1][^2] #### 日志分析示例 使用jq解析日志: ```bash cat audit.log | jq -c ' select(.objectRef.resource == "persistentvolumes") | {user: .user.username, action: .verb, pv: .objectRef.name, status: .responseStatus.code} ' ``` #### 性能优化建议 1. 高频操作采样(如List): ```yaml - level: Request verbs: ["list", "watch"] resources: ["persistentvolumeclaims"] omitStages: ["RequestReceived"] ``` 2. 存储分离: ```mermaid graph LR A[审计日志] --> B[热存储: ES/Loki] A --> C[冷存储: S3] ``` > **注意**:生产环境建议启用日志轮转和加密,敏感操作(如PV删除)应配置实时告警[^1][^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值