零、文章目录
架构13-持久化存储
1、Kubernetes 存储设计
(1)存储设计考量
- **设计哲学:**Kubernetes 遵循用户通过资源和声明式 API 描述意图,Kubernetes 根据意图完成具体操作。
- **复杂性:**描述用户的存储意图本身并不容易,Kubernetes 的存储资源较为复杂和繁琐。
- **兼容性:**为了兼容多种存储技术,Kubernetes 预置了大量 In-Tree 插件,并支持 Out-of-Tree 插件(如 FlexVolume 和 CSI)。
- **工业级需求:**Kubernetes 是一个面向生产的容器编排系统,因此在新功能的实现上需要保持向后兼容,避免影响现有生产环境。
(2)存储相关概念
- Mount 和 Volume
- **Mount:**将外部存储挂载到系统中。
- **Volume:**物理存储的逻辑抽象,提供有弹性的分割方式。
- Docker 的挂载类型
- **Bind:**将宿主机目录挂载到容器中。
- **Volume:**Docker 管理的存储资源。
- **tmpfs:**内存中的临时存储,不适用于持久化存储。
- Kubernetes 存储类型
- **普通 Volume:**生命周期与 Pod 相同,不支持持久化存储。
- **PersistentVolume (PV):**独立于 Pod 存在,支持持久化存储。
- **PersistentVolumeClaim (PVC):**用户对存储的请求,与 PV 进行动态绑定。
(3)存储分配机制
- Static Provisioning
- **手动分配:**管理员预先分配 PV,用户通过 PVC 申请。
- **优点:**简单直观。
- **缺点:**难以自动化,不适合大规模集群。
- Dynamic Provisioning
- **自动分配:**通过 StorageClass 和 Provisioner 自动创建 PV。
- **优点:**自动化能力强,灵活度高。
- **缺点:**配置复杂,需要更多管理。
- **设计挑战:**平衡复杂性和兼容性,满足不同规模和需求的用户。
- **未来趋势:**Dynamic Provisioning 逐步替代 Static Provisioning,提高自动化和灵活性。
(4)存储回收策略
- **Retain:**保留数据,需要手动清理。
- **Recycle:**自动删除数据(已废弃)。
- **Delete:**自动删除存储资源。
2、Kubernetes 存储扩展架构
(1)存储设备的接入与移除
- **Provision(准备存储):**类似购买新的存储设备,确定存储的来源、容量、性能等。
- **Attach(附加存储):**将存储设备连接到系统,但尚未启用。
- **Mount(挂载存储):**将存储设备挂载到系统指定位置,使其可以被应用访问。
- **Unmount(卸载存储):**将存储设备从系统中卸载。
- **Detach(分离存储):**将存储设备从系统中分离。
- **Delete(移除存储):**删除存储设备。
(2)存储控制器与管理器
- PV 控制器(PersistentVolume Controller):
- **期望状态:**所有未绑定的 PersistentVolume 都处于可用状态;所有处于等待状态的 PersistentVolumeClaim 都能配对到与之绑定的 PersistentVolume。
- **核心逻辑:**ClaimWorker 和 VolumeWorker 分别跟踪两种期望状态。
- **职责:**实现 PersistentVolume 和 PersistentVolumeClaim 的生命周期管理,调用存储驱动插件的 Provision/Delete 操作。
- AD 控制器(Attach/Detach Controller):
- **期望状态:**所有被调度到准备新创建 Pod 的节点都附加好要使用的存储;当 Pod 被销毁后,原本运行 Pod 的节点都分离了不再被使用的存储。
- **职责:**调用存储驱动插件的 Attach/Detach 操作。
- Volume 管理器(Volume Manager):
- **职责:**支持本节点中 Volume 执行 Attach/Detach/Mount/Unmount 操作。
- **历史原因:**最初 Attach/Detach 由 kubelet 完成,现在默认由 AD 控制器完成,但可以通过
--enable-controller-attach-detach
参数切换。
(3)存储扩展机制
- FlexVolume:
- 特点:
- 早期版本(1.2 版开始提供,1.8 版达到 GA 状态)。
- 私有的存储扩展机制,已经冻结,不再发展新功能。
- 优势:
- 简单易用。
- 不足:
- 不支持 Dynamic Provisioning。
- 部署维护繁琐。
- 实现复杂交互相对繁琐。
- 特点:
- CSI(Container Storage Interface):
- 特点:
- 从 1.9 版本开始加入,1.13 版本达到 GA 状态。
- 公开的技术规范,适用于任何容器运行时和容器编排引擎。
- 优势:
- 功能完善,支持 Dynamic Provisioning。
- 易于安装和维护。
- 通过 gRPC 协议传递参数,更加严谨和可靠。
- 组件:
- **CSI Identity 接口:**描述插件基本信息,检查插件健康状态。
- **CSI Controller 接口:**管理存储资源,如 Provision、Delete、Attach、Detach、快照等。
- **CSI Node 接口:**操作集群节点上的存储资源,如分区、格式化、挂载、卸载等。
- 特点:
(4)In-Tree 到 Out-of-Tree 的迁移
- 背景:
- In-Tree 存储驱动内置在 Kubernetes 中,导致灵活性和安全性问题。
- 从 1.14 版本开始,启动 In-Tree 存储驱动的 CSI 外置迁移工作。
- 计划在 1.21 到 1.22 版本(2021 年中期)完成主要存储驱动的迁移。
- 兼容性设计:
- **CSIMigration:**Out-of-Tree 驱动自动伪装成 In-Tree 接口,确保旧功能的兼容性。
3、容器存储生态系统
- 随着 Kubernetes 的 CSI (Container Storage Interface) 规范成为容器业界统一的存储接入标准,各大云计算厂商纷纷支持自家的容器通过 CSI 规范接入外部存储。这一标准化使得容器存储生态逐渐成熟,存储插件种类繁多,涵盖了多种存储类型。
(1)主要存储类型及其特点
- 块存储
- **定义:**数据存储在固定长度的块中,通过特定协议(如 SCSI、SATA、SAS、FCP、FCoE、iSCSI)进行读写访问。
- 特点:
- 性能优秀(高吞吐量、低延迟)
- 接近底层硬件,无文件、目录等额外开销
- 排他性:一次只能被一个客户端挂载
- **应用场景:**适合高性能应用,如大型数据库(Oracle)等
- **示例:**Amazon Elastic Block Store (EBS)
- 文件存储
- **定义:**数据存储在长度不固定的文件中,提供文件操作接口(如新增、写入、追加、移动、复制、删除、重命名等)。
- 特点:
- 提供文件查找、目录管理、权限控制等高级功能
- 使用 POSIX 接口,成为事实标准
- 基于块存储实现,更易管理和使用
- 性能略逊于块存储,但支持多客户端共享
- **应用场景:**适合需要文件共享和管理的场景,如容器工作负载
- **示例:**Amazon Elastic File System (EFS)
- 对象存储
- **定义:**数据存储在对象中,每个对象包含元数据和逻辑数据块,通过全局唯一标识进行访问。
- 特点:
- 扁平化结构,易于共享和扩展
- 支持高吞吐量,但延迟较高
- 适合存储非结构化数据,如图片、音视频等
- **应用场景:**适合 CDN、静态资源存储等
- **示例:**Amazon Simple Storage Service (S3)
(2)选择合适的存储类型
- **块存储:**适合需要高性能、低延迟的应用,如大型数据库。
- **文件存储:**适合需要文件共享和管理的场景,如容器工作负载。
- **对象存储:**适合存储非结构化数据,如图片、音视频等,适合 CDN 和静态资源存储。
(3)亚马逊存储产品对比
- Amazon EBS:
- **类型:**块存储
- **特点:**高性能、低延迟,但不支持多客户端共享
- **适用场景:**系统引导卷、高性能应用
- Amazon EFS:
- **类型:**文件存储
- **特点:**支持多客户端共享,动态弹性,性能较高
- **适用场景:**容器工作负载、文件共享
- Amazon S3:
- **类型:**对象存储
- **特点:**简单易用,成本低,适合非结构化数据存储
- **适用场景:**备份、归档、静态页面托管、多媒体分发