k8s存储入门

Volume 核心概念

Volume(卷)是计算机存储领域中用于抽象和管理物理存储资源的重要概念,其核心是将存储设备或存储空间组织成独立的逻辑单元,为操作系统、应用程序或容器提供持久化、共享或灵活的数据存储能力。

操作系统与文件系统中的卷

在操作系统(如Windows、UNIX)和文件系统中,卷是文件系统驻留的逻辑单元,代表一个可独立管理的存储空间。一个卷至少包含一个分区(物理磁盘的逻辑划分),也可以跨越多个分区或磁盘。例如:

简单卷:存在于单个分区上的卷,如Windows系统中的C盘、D盘。

多分区卷:包含多个分区上数据的卷,如跨区卷、带区卷等,用于提高存储性能或实现数据冗余。

卷具有独立性,可进行安装(Mount)和卸下(Unmount)操作。当需要访问卷中的数据时,需将其安装到系统中;当不再需要时,可将其卸下以释放资源或保护数据。

容器化技术中的卷

在容器化技术(如Docker、Kubernetes)中,卷是解决容器数据持久化和共享问题的关键机制。容器中的文件系统默认是短暂的,当容器被删除时,其中的数据也会丢失。卷通过将容器中的数据与容器解耦,实现了数据的持久化存储和共享。

Docker中的卷:

管理卷(Volume):由Docker管理,默认映射到宿主机的特定目录(如/var/lib/docker/volumes)。管理卷适用于多容器共享数据、数据持久化等场景。

绑定卷(Bind Mount):将宿主机的本地文件系统中的某个目录直接与容器内部的文件系统上的某一目录建立绑定关系。绑定卷适用于需要直接访问主机文件系统或快速测试和开发的场景。

临时卷(tmpfs Mount):映射到宿主机的内存中,数据在容器停止运行时会被清除。临时卷适用于高性能的临时数据存储场景。

Kubernetes中的卷:

Kubernetes支持多种类型的卷,如emptyDir、hostPath、nfs、persistentVolumeClaim等。

emptyDir:用于Pod中不同容器共享数据,数据在Pod删除时会被清除。

hostPath:将主机节点的文件系统中的文件或目录挂载到Pod中,数据在Pod删除时不会被清除(除非主机上的文件或目录被删除)。

nfs:允许将现有的NFS(网络文件系统)挂载到容器中,实现数据的持久化和共享。

persistentVolumeClaim(PVC):对持久卷(PersistentVolume,PV)的申请,用于实现数据的持久化存储和动态分配。

数据库系统中的卷

在数据库系统(如ClickHouse)中,卷是存储策略的下一级逻辑单元,用于组织和管理数据库的数据文件。通过配置不同的卷和存储路径,可以实现数据的并行写入、负载均衡和故障恢复等功能。例如:

ClickHouse中的卷:

每个存储策略可以包含多个卷,每个卷又可以配置多块磁盘。

在数据写入时,配置了该卷对应的存储策略的表会将数据并行写入到卷下的多个磁盘中,提高IO效率。

Volume卷的类型

在 Kubernetes 中,Volume 是用于为 Pod 提供持久化存储或容器间数据共享的抽象资源。Volume 类型多样,涵盖临时存储、宿主机挂载、网络存储、云存储等场景。

基础存储类型

EmptyDir

特点:

Pod 创建时在节点上自动分配一个空目录,无需提前配置。

数据仅在 Pod 生命周期内持久化,Pod 删除后数据丢失。

默认存储介质为磁盘,可配置为内存(medium: Memory)提升 I/O 性能。

适用场景:

Pod 内多个容器共享临时数据(如日志、中间计算结果)。

HostPath

特点:

将宿主机文件或目录挂载到 Pod,直接访问主机资源。

数据持久化,但不可跨主机共享(每个节点需独立配置)。

存在安全和隔离风险,仅推荐在开发/测试环境使用。

适用场景:

需要访问宿主机设备或文件的场景(如 Docker 守护进程配置)。

网络存储类型

NFS (Network File System)

特点:

支持多节点读写共享存储,数据在 Pod 删除后保留。

需提前部署 NFS 服务器并配置共享目录。

适用场景:

需要跨节点共享数据的场景(如多个 Pod 访问同一配置文件)。

GlusterFS / CephFS

特点:

分布式文件系统,提供高可用和可扩展的存储。

需独立部署存储集群。

适用场景:

大规模分布式存储需求(如大数据分析、持久化数据库)。

云存储类型

AWS EBS / Azure Disk / GCP Persistent Disk

特点:

云厂商提供的块存储服务,支持动态扩容和快照。

通常与 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 结合使用。

适用场景:

生产环境持久化存储(如 MySQL、MongoDB 数据库)。

Azure File / GCP Filestore

特点:

云厂商提供的文件共享服务,支持 SMB/NFS 协议。

适用场景:

需要文件共享的场景(如 Windows 容器访问共享目录)。

配置与密钥管理

ConfigMap

特点:

将配置文件或环境变量注入 Pod,非持久化存储。

数据存储在 etcd 中,Pod 重启后配置保留。

适用场景:

存储应用配置(如 nginx.conf、环境变量)。

Secret

特点:

加密存储敏感信息(如密码、API 密钥),非持久化存储。

默认以 Base64 编码存储,建议结合 RBAC 控制访问权限。

适用场景:

存储数据库密码、TLS 证书等敏感数据。

高级存储类型

PersistentVolume (PV) + PersistentVolumeClaim (PVC)

特点:

PV:集群级持久化存储资源,由管理员预配置或动态创建。

PVC:用户对 PV 的请求,声明存储需求(容量、访问模式等)。

支持动态存储分配(通过 StorageClass)。

适用场景:

生产环境标准化存储管理(如数据库、状态ful 应用)。

StorageClass + Dynamic Provisioning

特点:

根据 PVC 请求自动创建 PV(如云存储卷)。

支持存储类(如 standard、ssd)和回收策略(Retain、Delete)。

适用场景:

自动化存储管理,减少手动操作。

其他特殊类型

Projected Volume

特点:

将多个存储源(如 ConfigMap、Secret)映射到同一目录。

适用场景:

需要合并多个配置文件的场景。

CSI (Container Storage Interface)

特点:

第三方存储插件标准,支持更多存储后端(如 Portworx、Rook-Ceph)。

适用场景:

扩展 Kubernetes 存储能力,集成专有存储系统。

各个卷的区别

类型 持久化 跨节点共享 适用场景

EmptyDir ❌ ❌ 临时数据共享

HostPath ✔️ ❌ 开发环境访问宿主机文件

NFS ✔️ ✔️ 多节点共享存储

Cloud Disk ✔️ ❌ 生产环境持久化存储(如数据库)

ConfigMap ❌ ❌ 注入配置文件

Secret ❌ ❌ 存储敏感信息

PV/PVC ✔️ 依赖类型 生产环境标准化存储管理

PersistentVolume(PV,持久卷)

PV(PersistentVolume)是 Kubernetes 中的一种持久化存储资源

PV 的核心概念

定义:PV 是集群中的一块存储,独立于 Pod 存在,用于持久化存储数据。它可以是云提供商的存储、NFS、iSCSI、本地存储等,由管理员预置或通过 StorageClass 动态配置。

生命周期:PV 的状态包括可用(Available)、绑定(Bound)、释放(Released)、回收(Retained)等。管理员负责创建、配置、更新和删除 PV,确保其可用性和数据持久性。

访问模式:

ReadWriteOnce(RWO):单节点读写。

ReadOnlyMany(ROX):多节点只读。

ReadWriteMany(RWX):多节点读写。

回收策略:

Retain(保留):手动回收,数据保留在 PV 中,需管理员手动清理。

Recycle(回收):基本擦除(如 rm -rf /thevolume/*),仅 NFS 和 HostPath 支持。

Delete(删除):关联的存储资产(如 AWS EBS、GCE PD)被删除,云存储常用。

PV的配置方式

静态供给(Static Provisioning)

静态供给是管理员手动预先创建 PV,将其配置为集群中的持久化存储资源,供用户通过 PVC(PersistentVolumeClaim)申请使用。适用于存储资源需求明确且稳定的场景。

配置步骤

创建 PV 资源:

管理员根据存储类型(如 NFS、HostPath、云存储等)编写 PV 的 YAML 文件,定义存储容量、访问模式、回收策略等参数。

应用 PV 配置:

使用 kubectl apply -f pv.yaml 命令将 PV 部署到集群中。

用户创建 PVC:

用户根据业务需求创建 PVC,Kubernetes 会自动将 PVC 绑定到匹配的 PV。

Pod 使用 PVC:

在 Pod 的 YAML 文件中引用 PVC,实现数据持久化。

静态供给的优缺点

优点:

存储资源可控,管理员可以精确管理存储的分配和使用。

适用于存储需求固定的场景(如数据库、日志存储)。

缺点:

需要手动管理 PV 的生命周期,灵活性较低。

存储资源可能闲置或不足,需人工干预调整。

动态供给(Dynamic Provisioning)

动态供给是通过 StorageClass 自动创建 PV,无需管理员手动预置。当用户创建 PVC 时,Kubernetes 会根据 PVC 的请求自动生成对应的 PV。适用于存储需求动态变化的场景。

配置步骤

创建 StorageClass:

管理员定义 StorageClass,指定存储提供程序(如 nfs-client、aws-ebs、gce-pd 等)和参数(如存储类型、回收策略等)。

用户创建 PVC:

用户在 PVC 中指定 storageClassName,Kubernetes 会根据 StorageClass 自动创建 PV。

Pod 使用 PVC:

在 Pod 的 YAML 文件中引用 PVC,实现数据持久化。

动态供给的优缺点

优点:

自动化管理 PV 的生命周期,减少人工干预。

存储资源按需分配,提高资源利用率。

缺点:

需要依赖 StorageClass 和动态供给器(如 nfs-subdir-external-provisioner)。

某些存储类型(如本地存储)可能不支持动态供给。

PV 配置方式对比

配置方式 适用场景 灵活性 管理复杂度 资源利用率

静态供给 存储需求固定(如数据库) 低 高(需手动管理) 可能闲置或不足

动态供给 存储需求动态变化(如开发测试环境) 高 低(自动化管理) 按需分配,高效

PVC(PersistentVolumeClaim,持久卷声明)

PVC(PersistentVolumeClaim,持久卷声明) 是 Kubernetes 中用于申请持久化存储资源的对象,它作为用户与持久卷(PV)之间的桥梁,简化了存储的管理和使用。

PVC 的核心概念

定义

PVC 是用户对存储资源的请求,定义了所需的存储容量、访问模式、存储类型等参数。Kubernetes 会根据 PVC 的要求,自动匹配或动态创建合适的 PV(PersistentVolume),实现数据持久化。

与 PV 的关系

PV:集群中的实际存储资源(如磁盘、NFS 共享、云存储卷等),由管理员预置或通过 StorageClass 动态创建。

PVC:用户对 PV 的"申请单",声明需要的存储规格。

绑定机制:Kubernetes 会将 PVC 与符合条件的 PV 绑定,形成一对一关系。绑定后,PVC 即可被 Pod 使用。

生命周期

PVC 的生命周期包括:创建 → 绑定(Bound)→ 使用 → 释放(Released)→ 回收(根据回收策略处理数据)。

PVC 的核心配置参数

字段 说明

spec.accessModes 存储访问模式(如 ReadWriteOnce、ReadOnlyMany、ReadWriteMany)。

spec.resources.requests.storage 请求的存储容量(如 10Gi)。

spec.storageClassName 指定 StorageClass 名称(动态供给时使用,静态供给可省略)。

spec.selector 可选字段,通过标签选择器手动匹配特定 PV(通常用于静态供给的精确控制)。

PVC 的示例场景

数据库持久化存储

复制代码
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

多 Pod 共享数据

复制代码
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

动态存储分配

复制代码
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: "nfs-client"  # 引用动态供给的 StorageClass

PVC 的工作流程

用户创建 PVC

提交 PVC 定义文件到 Kubernetes 集群。

Kubernetes 匹配 PV

静态供给:检查集群中是否存在未绑定的 PV,且满足 PVC 的容量、访问模式等要求。

动态供给:若没有匹配的 PV,且 PVC 指定了 storageClassName,则触发 StorageClass 自动创建 PV。

绑定 PVC 与 PV

将符合条件的 PV 标记为 Bound 状态,并与 PVC 关联。

Pod 使用 PVC

在 Pod 的 volumes 字段中引用 PVC,实现数据持久化:

复制代码
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: data-volume
      mountPath: "/usr/share/nginx/html"
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: my-pvc  # 引用已绑定的 PVC

释放与回收

当 PVC 被删除时,PV 进入 Released 状态。

根据 PV 的 persistentVolumeReclaimPolicy(回收策略)处理数据:

Retain:保留数据,需手动清理。

Delete:删除 PV 及关联的存储资产(如云存储卷)。

Recycle:基本擦除数据(仅 NFS 和 HostPath 支持,已弃用)。

PVC 与 PV 的关键区别

特性 PVC(PersistentVolumeClaim) PV(PersistentVolume)

角色 用户对存储的请求 集群中的实际存储资源

创建者 用户(开发者) 管理员(或动态供给器)

生命周期 随用户需求创建/删除 独立于 PVC,可长期存在

配置复杂度 简单(只需声明需求) 复杂(需配置存储细节,如路径、服务器等)

相关推荐
运维-大白同学2 小时前
2025最全面开源devops运维平台功能介绍
linux·运维·kubernetes·开源·运维开发·devops
敲上瘾9 小时前
【探索实战】:Kurator分布式统一应用分发平台的全面解析与实践指南
分布式·容器·kubernetes·serverless
Connie145120 小时前
记一次K8s故障告警排查(Grafna告警排查)
云原生·容器·kubernetes·grafana
谷隐凡二1 天前
Kubernetes主从架构简单解析:基于Python的模拟实现
python·架构·kubernetes
陈陈CHENCHEN1 天前
SuperMap iManager for K8s 离线环境镜像仓库 Containerd 部署
kubernetes
会飞的小蛮猪1 天前
Ubuntu24.04 基于Containerd部署K8s1.34(私服部署)
docker·云原生·kubernetes
间彧2 天前
Kubernetes滚动发布详解
kubernetes
间彧2 天前
在实际生产环境中,Kubernetes声明式API如何实现蓝绿部署、金丝雀发布等高级部署策略?
kubernetes
间彧2 天前
Kubernetes声明式API相比传统命令式API在故障恢复场景下的具体优势有哪些?
kubernetes·github
间彧2 天前
为什么说Kubernetes的API设计是其成功的关键因素之一?
kubernetes