当前位置: 首页 > article >正文

k8s-持久化存储之StorageClass(2)

1、概述

在前面这章 k8s-持久化存储PV与PVC(1) 中,熟悉了PV/PVC之后,简单回顾:PV 和 PVC 一一对应的,PV 是由运维人员事先负责提前创建好的,在 kubernetes 等待使用;PVC 通常由开发人员创建,假如开发人员想要申请一个为 1 GiB 大小的 PVC,创建完成后会向 kubernetes 申请资源,申请成功会将 PV 与 PVC 进行绑定。

但现在有一个比较棘手的问题,当大规模的 kubernetes 生产集群中,可能会有很多的 PVC,而且随着项目的增加,可能还需要不断创建新的 PV,不然可能为某个新的 Pod 因 PVC 绑定不到 PV 而创建失败。如果还是让运维人员去一个个创建 PV 的话,其实是个非常麻烦的,人工也无法做到,于是 kubernetes 提供可以自动创建 PV 的机制,核心是 StorageClass API对象。

2、如何持久化 Volume

首先,来了解持久化 Volume 的实现,想要持久化 Volume 大多数情况是需要依赖一个远程存储服务的,比如:远程文件存储(如:NFS)、远程块存储(如:公有云提供的远程磁盘)等。而 Kubernetes 需要使用这些存储服务,来为容器准备一个持久化的宿主机目录,以供将来进行绑定挂载时使用。

那么,准备 “持久化” 宿主机目录这个过程,可分为 Attach 和 Mount 两个阶段处理。

Attach 阶段:当一个 Pod 调度到一个 Node 之后,kubelet 会负责把帮这个 Pod 创建它的 Volume 目录。如果 Volume 类型是远程块存储比如:Google Cloud 的 Persistent Disk(GCE 提供的远程磁盘服务),那么 kubelet 就需要先调用 Goolge Cloud 的 API,将它所提供的 Persistent Disk 挂载到 Pod 所在的宿主机上。

Mount 阶段:为了能使用远程磁盘,kubelet 需要进行将这磁盘进行格式化并且挂载到 Volume 宿主机目录的操作。此时,这个 Volume 的宿主机目录就是一个 “持久化” 的目录了,当容器写入内容时,会保存到 Google Cloud 远程磁盘里头。

3、动态供应策略(Dynamic Provisioning)

通过人工创建 PV的方式叫作静态供应策略(Static Provisioning),这种会造成资源浪费。

Dynamic Provisioning 机制工作的核心,在于一个名叫 StorageClass 的 API 对象。而 StorageClass 对象的作用,其实就是创建 PV 的模板。

栗子:假如我们的 Volume 的类型是 GCE 的 Persistent Disk ,运维人员就需要定义一个如下所示的 StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: block-service-demo
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  • StorageClass 的 provisioner 字段的值是:kubernetes.io/gce-pd,这正是 Kubernetes 内置的 GCE PD 存储插件的名字。
  • StorageClass 的 parameters 字段:是 PV 参数。(type=pd-ssd,指的是这个 PV 的类型是“SSD 格式的 GCE 远程磁盘”)

开发者,只需要在 PVC 里指定要使用的 StorageClass 名字即可,如下所示:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: block-service-demo
  resources:
    requests:
      storage: 10Gi

可以看到这个 PVC 里添加了一个叫作 storageClassName 的字段,用于指定该 PVC 所要使用的 StorageClass 的名字是:block-service-demo。

上面以 Google Cloud 为例,当开发人员创建好 PVC 对象后,keubernetes 会去调用 Google Cloud 的 API,创建出一块 SSD 格式的 Persistent Disk。

总结

  1. 首先,集群管理员事先创建一个或多个存储类,并将其中一个标记为默认值;
  2. 开发者创建存储类的 PVC;
  3. Kubernetes 会去查找 StorageClass 和其中引用的配置器,并要求配置器根据 PVC 请求的访问模式和存储大小以及 StorageClass 中的参数配置新的 PV;
  4. 供应商提供实际存储,创建 PV,并将其绑定到 PVC;
  5. 最终用户创建一个带有卷的pod,通过名称引用 PVC 了;

http://www.kler.cn/a/429314.html

相关文章:

  • 软件设计大致步骤
  • MySQL SQL优化技巧与原理
  • 2.slf4j入口
  • 基于 STM32 的多功能时间管理器项目
  • 嵌入式系统Linux实时化(四)Xenomai应用开发测试
  • Qt/C++进程间通信:QSharedMemory 使用详解(附演示Demo)
  • 【算法练习】852. 山脉数组的峰顶索引
  • Python + OpenCV 系列:图像阈值处理
  • 【CC++】fatal error: curses.h: No such file or directory(Ubuntu 22.04)
  • 使用 ASP.NET Core HttpLoggingMiddleware 记录 http 请求/响应
  • 六、Prompt工程——进阶迭代
  • 现代C++16 pair
  • 美畅物联丨视频接入网关如何配置 HTTPS 证书
  • 大数据(Hadoop)学习案例—通过Shell脚本定时采集数据到HDFS
  • 信号与槽机制的使用
  • centos kafka单机离线安装kafka服务化kafka tool连接kafka
  • MacOS 下 pico/pico2 学习笔记
  • java+springboot+mysql党务(党员)管理系统
  • ros2人脸检测
  • 【中间件开发】Nginx中过滤器模块实现
  • MFC 自定义静态文本控件:增强型标签控件
  • 40分钟学 Go 语言高并发:负载均衡与服务治理
  • 【前端】全面解析 JavaScript 中的 this 指向规则
  • 二阶段nginx1.0
  • 一些好用的网站
  • 深入理解Linux进程管理机制