应用存储和持久化数据卷:存储快照与拓扑调查(二)|学习笔记

简介: 快速学习应用存储和持久化数据卷:存储快照与拓扑调查(二)

开发者学堂课程【Kubernetes 入门应用存储和持久化数据卷:存储快照与拓扑调查(二)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/51/detail/1016


应用存储和持久化数据卷:存储快照与拓扑调查(二)


三、操作演示

限制 Dynamic Provisioning PV 拓扑示例

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

name: csi-disk

provisioner: diskplugin.csi.alibabacloud.com

parameters:

regionld: cn-hangzhou

fsType: ext4

type: cloud_ssd

volumeBindingMode: WaitForFirstConsumer

allowedTopologies:

- matchLabelExpressions:

#拓扑域限制:动态创建的PV只能在可用区 cn-hangzhou-d被使用

- key: topology.diskplugin.csi.alibabacloud.com/zone

values:

- cn-hangzhou-d

reclaimPolicy: Delete

#当该PVC对象被创建之后由于对应StorageClass的 BindingMode为

# WaitForFirstConsumer并不会马上动态生成PV对象,而是要等到使用

#该PVC对象的第一个Pod调度结果出来之后,而且kube-scheduler在调

#度Pod的时候会去选择满足StorageClass.allowedTopologies中指定的#拓扑限制的Nodes

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: disk-pvc

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 30Gi

storageClassName: csi-disk

 

四、处理流程

Kubernetes 对 Volume Snapshot/Restore 处理流程

image.png

主流程说明:

1.首先 PV Controller 对需要 Delay Binding(通过 StorageClass 设置)的 PVC 暂不做任何处理

2.Scheduler 根据 Pod PVCs 过滤 per Node 流程:

-找到一个 Pod 所有Bound的 PVCs 以及需要 Delay Binding 的

PVCs

- Bound 的 PVCs 要 check bound 的 PV NodeAffinity 与当前 Node 的拓扑是否匹配,不匹配就skip this Node

- Delay Binding 的 PVCs,先 check 存量的 PVs 能满足 PVC 的列表,并将它们的NodeAffinity 与当前 Node 拓扑做匹配,都不匹配进一步 check PVCs 对应的StorageClass.AllowedTopologies 是否与 Node 的拓扑匹配,不匹配就 skip this Node

3.更新经过预选( Predicates )和优选( Priorities )选中 Node 的 Pod 在 scheduler 中的 PVC&PV cache,为 step(4)做准备

4.触发相关组件对 Pod 使用的 UnBound PVCs 的 Binding 或 Dynamic Provisioning 流程真正执行

相关文章
|
6月前
|
消息中间件 存储 缓存
写入内容丢失,各种数据库或者存储系统如何处理?
写入内容丢失,各种数据库或者存储系统如何处理?
74 0
|
存储 算法
数据仓库数据模型之:极限存储--历史拉链表
摘要: 在数据仓库的数据模型设计过程中,经常会遇到文内所提到的这样的需求。而历史拉链表,既能满足对历史数据的需求,又能很大程度的节省存储资源。 在数据仓库的数据模型设计过程中,经常会遇到这样的需求:1. 数据量比较大;2. 表中的部分字段会被update,如用户的地址,产品的描述信息,订单的状态等等;3. 需要查看某一个时间点或者时间段的历史快照信息,比如,查看某一个订单在历史某一个时间点的
5573 0
|
5天前
|
存储 运维 数据挖掘
服务器数据恢复—华为OceanStor存储数据恢复案例
服务器存储数据恢复环境: 华为品牌型号为OceanStor S2600T的存储设备,存储上有一组由24块4T容量的机械硬盘组建的RAID5阵列,作为存储池使用。 图1 服务器存储故障&检测: 存储设备中raid5阵列上多块硬盘出现故障离线,raid5阵列失效,数据无法正常访问。 关机后将存储中所有硬盘标记&取出,硬件工程师对所有硬盘进行硬件故障检测。经过检测,没有发现存在物理故障的磁盘,都可以正常读取。
|
1月前
|
存储 消息中间件 大数据
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
大数据-70 Kafka 高级特性 物理存储 日志存储 日志清理: 日志删除与日志压缩
38 1
|
3月前
|
存储 SQL Cloud Native
揭秘!PolarDB-X存储引擎如何玩转“时间魔术”?Lizard多级闪回技术让你秒回数据“黄金时代”!
【8月更文挑战第25天】PolarDB-X是一款由阿里巴巴自主研发的云原生分布式数据库,以其高性能、高可用性和出色的可扩展性著称。其核心竞争力之一是Lizard存储引擎的多级闪回技术,能够提供高效的数据恢复与问题诊断能力。本文通过一个电商公司的案例展示了一级与二级闪回技术如何帮助快速恢复误删的大量订单数据,确保业务连续性不受影响。一级闪回通过维护最近时间段内历史数据版本链,支持任意时间点查询;而二级闪回则通过扩展数据保留时间并采用成本更低的存储方式,进一步增强了数据保护能力。多级闪回技术的应用显著提高了数据库的可靠性和灵活性,为企业数据安全保驾护航。
44 1
|
6月前
|
存储 Kubernetes 调度
K8S常见的持久化(存储)方案用法详解
K8S常见的持久化(存储)方案用法详解
565 3
|
6月前
|
消息中间件 存储 缓存
Kafka【基础知识 02】集群+副本机制+数据请求+物理存储+数据存储设计(图片来源于网络)
【2月更文挑战第20天】Kafka【基础知识 02】集群+副本机制+数据请求+物理存储+数据存储设计(图片来源于网络)
131 1
|
存储 Kubernetes 应用服务中间件
应用存储和持久化数据卷:核心知识(二)|学习笔记
快速学习应用存储和持久化数据卷:核心知识(二)
121 0
应用存储和持久化数据卷:核心知识(二)|学习笔记
|
存储 缓存 NoSQL
缓存(1) —— 总述:分级存储
缓存(1) —— 总述:分级存储
591 0
|
存储 算法 数据安全/隐私保护
带你读《存储漫谈:Ceph原理与实践》——3.2.4 元数据 / 数据布局
带你读《存储漫谈:Ceph原理与实践》——3.2.4 元数据 / 数据布局