Skip to main content

Command Palette

Search for a command to run...

Kubernetes 中对持久卷进行扩容

Published
•2 min read•View as Markdown

原文:Resizing Persistent Volumes using Kubernetes

作者:Hemant Kumar

Kubernetes v1.11 中,持久卷扩容能力升级为 Beta 阶段。这个功能让用户可以轻松的通过编辑 PVC 对象的方式修改现有卷的容量。没有这一功能之前,要对卷容量进行修改,需要要和存储后端进行手工交互,或者对 PV 以及 PVC 进行删除重建操作。持久卷不支持缩容操作。

v1.8 中卷扩展功能就已经进入 Alpha 阶段,v1.11 之前需要在 feature gate 中开启 ExpandPersistentVolumes,以及 admission 控制器 PersistentVolumeClaimResize(防止在底层存储不支持扩容的情况下对 PVC 进行扩容)。在 Kubernetes v1.11 中,这两个项目都会被缺省激活。

虽然功能已经被激活,但是集群管理员还是需要进行操作,让用户能够对自己的卷进行扩容。Kubernetes 1.11 内置了对部分卷插件的扩容支持:AWS-EBS、GCE-PD、Azure Disk、Azure File、Glusterfs、Cinder、Portworx、以及 Ceph RBD。管理员确定底层存储能够支持卷扩展之后,就可以在 StorageClass 对象中设置 allowVolumeExpansion 为 true 来启用这一功能了。只有从 StorageClass 中创建的 PVC 才允许使用卷扩展:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
parameters:
  type: pd-standard
provisioner: kubernetes.io/gce-pd
allowVolumeExpansion: true
reclaimPolicy: Delete

任何从这一 StorageClass 中创建的 PVC 都能够通过编辑的方式来申请更多空间。Kubernetes 会处理 Storage 字段的变更,据此申请空间,触发卷的扩容。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi #更新这一字段,修改 PVC 容量

文件系统扩展

GCE-PD、AWS-EBS、Azure Disk、Cinder 以及 Ceph RBD 这些块存储卷通常需要首先进行文件系统的扩展,然后被扩展的卷的额外空间才能为 Pod 所用。引用这些卷的 Pod 重启时,Kubernetes 会自动完成这些任务。

网络挂载的文件系统,例如 Glusterfs 和 Azure File,因为不需要进行文件系统扩展,因此可以在不重启 Pod 的情况下直接进行扩展。

只有终止引用卷的 Pod,才会触发对应文件系统的扩展,更确切地说:

  • 编辑 PVC,申请更多空间。
  • 底层存储对底层卷进行了扩展之后,PV 对象就会响应这一变化,PVC 会进入 FileSystemResizePending 状态。

可以运行 kubectl get pvc <pvc_name> -o yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
  namespace: default
  uid: 02d4aa83-83cd-11e8-909d-42010af00004
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 14Gi
  storageClassName: standard
  volumeName: pvc-xxx
status:
  capacity:
    storage: 9G
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-07-11T14:51:10Z
    message: Waiting for user to (re-)start a pod to finish file system resize of
      volume on node.
    status: "True"
    type: FileSystemResizePending
  phase: Bound
  • PVC 进入 FileSystemResizePending 状态,引用 PVC 的 Pod 就可以重新启动来结束文件系统在 Node 上的扩展过程了。可以通过删除和重建 Pod 的方式进行重启,也可以通过对 Deployment 的伸缩来完成这一过程。
  • 文件系统的扩展操作完成之后,PVC 会自动更新,设置为新的容量。

文件系统扩展过程中遇到任何错误,都会在 Pod 中以 Event 的形式表现出来。

在线文件系统扩展

Kubernetes v1.11 还引入了一个 Alpha 功能,叫做在线文件系统扩展。这个功能可以对一个正在被 Pod 使用的卷进行文件系统的扩展。这个功能还处于 Alpha 阶段,因此需要通过 Feature gate 启用 ExpandInUsePersistentVolumes。目前支持的有 GCE-PD、AWS-EBS、Cinder 以及 Ceph RBD。当激活这个功能后,引用被扩展的卷的 Pod 无需重启。文件系统会随着卷扩展的步骤进行扩展。文件系统的扩展只有在 Pod 引用被扩展的卷的时候才会发生,所以如果没有 Pod 引用这个卷,那么就不会进行文件系统扩展。

More from this blog

AI Agent 的“莫兰迪时刻”

一个新范式真正走向大众,往往不是从所有人都正确理解它开始,而是从它开始被反复引用、简化、误读,甚至滥用开始。 今天的 AI Agent,可能正走到这样一个时刻。 这篇文章的念头,来自我最近收听《大内密谈》vol.1434《审美升级or消费主义?从莫兰迪在中国聊起》时的一些联想。节目从莫兰迪色在中国的走红,谈到作品价格、知识产权、商业流量与消费主义。[9] 我听着听着想到另一个熟悉的技术史问题:为

Oct 5, 20263 min read

FDE 是传统运维产品厂商的出路吗?

很多传统运维产品厂商,已经不缺产品了。 从 ITSM、CMDB、监控、自动化,到 IAM、数据中心管理和各类大屏,一个成熟厂商往往都能拿出一张很完整的产品地图。销售材料上看,客户运维部门的日常工作几乎都被覆盖了。 但项目一落地,味道就变了。 产品越多,集成越重;模块越全,边界越模糊;客户越大,定制越深。到了后期,项目成功本身也会变成麻烦:现场改出来的东西回不到主干,配置越来越像黑箱,谁都不敢轻易升

Jun 29, 20263 min read

绵里藏针才是 AIOps 的本质?

Agent 让运维编排变得柔性、可变、甚至自演进;但真正敢进入生产环境的 AIOps,仍然离不开坚实、受控、可审计、可回退的自动化底座。 从 Gartner 提出 AIOps 概念到现在,也大概有十年了。这么多年来,这个领域好像发生了很多变化,又好像没什么“本质”的变化。技术上,我们经历了传统机器学习、深度学习和神经网络、以及大模型和智能体这样“翻天覆地”的变化;业务上,我们面对的是更多品种、更大

May 31, 20263 min read

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

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

Mar 9, 20261 min read
【

【伪】架构师

346 posts