Skip to main content

Command Palette

Search for a command to run...

Kubernetes 中的 StorageClass 和动态卷供给

Updated
2 min read

原文:Dynamic Provisioning and Storage Classes in Kubernetes

存储是容器运行环境的重要一环,Kubernetes 提供了一些用于存储管理的基础能力。动态卷供给是一个 Kubernetes 独有的功能,这一功能允许按需创建存储卷。在没有这种能力之前,集群管理员需要打电话给他们的云或者存储提供者来创建新的存储卷,成功以后再创建 PersistentVolume 对象,才能够在 Kubernetes 中使用。动态卷供给能力让管理员不必进行预先创建存储卷,而是随用户需求进行创建。这一特性在 1.2 版本中处于 α 阶段,在 版本 1.4 中提升为 β。这一版本提高了动态卷的弹性和可用性。

新特性

Alpha 版本的动态卷,一个集群同时只能允许单独的、被硬编码的提供者。也就是说,如果 Kubernetes 要提供动态卷的时候,即使集群中可以使用多个存储系统,Kubernetes 也只会使用同一个存储卷插件。存储提供者的选型是基于云环境类型决定的 —— AWS 的 EBS,Google Cloud 的 Persistent Disk 或者是 OpenStack 的 Cinder,以及 vSphere 的 vSphere Volume。另外只有容量参数可以配置。这就意味着,即使有其他参数可用,所有的动态卷除了尺寸大小,其他都是一样的。

因为只有容量是大家都有的吧。。。

虽说这一功能的 Alpha 版本实用性有限,这毕竟是迈出了一步,有助于确定今后的发展方向。

Kubernetes 1.4 中中加入了一个 新的 API 对象 StorageClass,可以定义多个 StorageClass 对象,并可以分别指定存储插件、设置参数,用于提供不同的存储卷。这样的设计让集群管理员能够在同一个集群内,定义和提供不同类型的、不同参数的卷(相同或者不同的存储系统)。这样的设计还确保了最终用户在无需了解太多的情况下,有能力选择不同的存储选项。

如何使用

下面是一个例子,管理员提供了两种存储,用户可以选择其中一个使用。细节可以查看 手册 以及 示例 文档。

管理员配置

集群管理员定义并发布了两个 StorageClass 对象

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard

这一段创建了一个名为 "slow" 的 StorageClass,用于提供标准的持久存储。

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

这一段创建了一个名为 "fast" 的 StorageClass,用于提供类似 SSD 的持久存储。

用户请求

用户在 PersistentVolumeClaim 中可以包含一个 StorageClass 申请动态提供存储。这一任务需要使用 volume.beta.kubernetes.io/storage-class 注解来完成。这一注解的值必须符合管理员配置的 StorageClass 名称。

要选择 "fast" 存储类,用户需要创建如下的 PVC:

 {
  "kind": "PersistentVolumeClaim",
  "apiVersion": "v1",
  "metadata": {
    "name": "claim1",
    "annotations": {
        "volume.beta.kubernetes.io/storage-class": "fast"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "30Gi"
      }
    }
  }
}

上述报文会提供一个等效于 SSD 的持久盘,当这个 PVC 被删除,这个卷也随之销毁。

缺省行为

所有的 PVC 都可以在不使用 StorageClass 注解的情况下,直接使用某个动态存储。把一个 StorageClass 对象标记为 "default" 就可以了。StorageClass 用注解 storageclass.beta.kubernetes.io/is-default-class 就可以成为缺省存储。

有了缺省的 StorageClass,用户创建 PVC 就不用 storage-class 的注解了,1.4 中新加入的 DefaultStorageClass 准入控制器会自动把这个标注指向缺省存储类。

我还能使用 Alpha 版本么?

Kubernetes 1.4 兼容 alpha 版本的动态卷特性,让用户能够平滑过渡到 beta 版本。用 volume.alpha.kubernetes.io/storage-class 注解来标注 alpha 版本。

在未来版本中将会弃用 Alpha 版本。

下一步?

动态卷功能会持续发展,下面是一些要点。

标准云支持

如果 Kubernetes 集群部署在云服务商,我们 考虑 自动使用云的本地存储系统创建一个动态卷供给者。例如在 AWS 上的标准部署会得到一个 EBS 的动态卷供给,而 Google Cloud 的部署则会提供一个 GCE PD 动态卷供应者。我们还在讨论是否应该把这种卷作为缺省卷。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts