21、架构-持久化存储

2024-06-20 11:44
文章标签 21 架构 存储 持久

本文主要是介绍21、架构-持久化存储,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1、Kubernetes存储设计

Kubernetes在存储设计上秉承声明式API和资源抽象的理念,用户通过声明存储需求,Kubernetes负责调度和管理实际的存储资源。以下是Kubernetes存储设计中的核心概念和机制。

 Mount和Volume

在Kubernetes中,Volume和Mount是实现持久化存储的基础概念。

  • Mount:将存储设备挂载到容器的文件系统中,使得容器可以访问和使用该存储设备。Mount是容器访问外部存储的入口。

  • Volume:用于描述一个存储单元,可以是持久性的(PersistentVolume,PV)或临时性的(如emptyDir、configMap)。Volume在Kubernetes中被定义为一种抽象,使得不同类型的存储设备(如本地磁盘、NFS、云存储等)能够被统一管理。

    在Kubernetes中,每个Pod可以声明多个Volume,并将其挂载到容器内的指定路径。这些Volume在Pod生命周期内保持一致,即使Pod中的容器重启,Volume的数据也不会丢失 。

静态存储分配

静态存储分配模式下,管理员提前创建并配置存储资源,用户通过声明来请求这些预先分配的资源。

  • PersistentVolume(PV):PV是集群中的一块存储资源,独立于具体的Pod。管理员通过YAML文件定义PV的属性,包括存储容量、访问模式(如ReadWriteOnce、ReadOnlyMany、ReadWriteMany)和存储类型(如NFS、iSCSI、AWS EBS)。

  • PersistentVolumeClaim(PVC):PVC是用户对存储资源的请求,类似于Pod对计算资源的请求。用户通过PVC声明需要的存储容量和访问模式,Kubernetes根据PVC匹配合适的PV。如果找到匹配的PV,Kubernetes会将其绑定到PVC,用户的Pod可以通过PVC访问对应的存储资源 。

静态分配模式适用于小规模集群和预先确定的存储需求,但在大规模动态环境中,手工管理PV和PVC会变得复杂且低效。

动态存储分配

动态存储分配通过自动化机制为用户提供灵活的存储资源,适应大规模集群的需求。

  • StorageClass:StorageClass定义了存储资源的类别和属性,是动态分配PV的模板。管理员通过StorageClass指定存储类型、配置参数和Provisioner(负责实际创建存储的插件)。

  • 动态分配流程:当用户创建PVC时,可以指定StorageClass,Kubernetes根据PVC和StorageClass的配置自动创建PV并绑定PVC。这种方式减少了管理员的手工操作,提高了存储管理的效率和灵活性 。

动态分配使得Kubernetes能够根据需求自动调度和分配存储资源,满足应用的动态变化和扩展需求。

2、容器存储与生态

Kubernetes的存储生态系统支持多种存储插件和接口,提供灵活多样的存储解决方案,以满足不同应用场景的需求。以下是Kubernetes存储架构及其主要组件和扩展机制。

 Kubernetes存储架构

Kubernetes存储架构由多个组件协同工作,确保存储资源的高效管理和可靠访问。

  • PV控制器:负责监控和管理PV的生命周期,包括创建、绑定和删除。

  • PVC控制器:处理PVC的创建和绑定请求,确保PVC与合适的PV匹配。

  • Volume管理器:在节点上管理Volume的挂载和卸载操作,确保容器能够访问所需的存储设备 。

这些组件共同保证了Kubernetes存储的自动化管理和可靠性,使用户能够专注于应用本身而无需担心底层存储的细节。

FlexVolume与CSI

Kubernetes支持两种主要的存储扩展机制:FlexVolume和CSI(Container Storage Interface)。

  • FlexVolume:FlexVolume是一种Kubernetes早期的存储扩展机制,通过可执行文件实现存储操作。它支持多种存储后端,但由于实现方式较为简单,功能有限,FlexVolume逐渐被CSI所取代 。

  • CSI(Container Storage Interface):CSI是Kubernetes的标准存储接口,通过定义统一的API,使得任何存储供应商都可以为Kubernetes开发存储插件。CSI插件可以动态加载,支持更灵活的存储管理和扩展。CSI的引入使得Kubernetes的存储生态更加开放和多样化 。

从In-Tree到Out-of-Tree

最初,Kubernetes将存储驱动集成在核心代码中(In-Tree),以快速支持各种存储系统。然而,这种方式导致核心代码庞大且难以维护。为了提高灵活性和安全性,Kubernetes开始迁移到Out-of-Tree模式,通过CSI插件实现存储驱动的扩展。

  • In-Tree驱动:内置于Kubernetes核心代码中的存储驱动,直接由Kubernetes管理。
  • Out-of-Tree驱动:通过CSI接口实现的存储驱动,独立于Kubernetes核心代码,由外部插件管理和更新。

这种迁移使得Kubernetes能够更灵活地添加和修改存储驱动,减少了核心代码的复杂性,提高了系统的可靠性和安全性 。

 容器插件生态

Kubernetes的容器存储生态系统已经形成了丰富的插件环境,支持多种存储类型和实现。

  • 块存储:适用于高性能、低延迟的应用场景,如数据库和虚拟机磁盘。常见插件包括AWS EBS、GCE PD、vSphere等。

  • 文件存储:适用于需要共享访问的场景,如日志和配置文件。常见插件包括NFS、GlusterFS、CephFS等。

  • 对象存储:适用于大规模、非结构化数据存储,如备份和媒体文件。常见插件包括Amazon S3、OpenStack Swift、MinIO等 。

这些插件通过CSI接口实现,用户可以根据实际需求选择合适的存储方案,构建高效可靠的容器存储系统。

总结

持久化存储是容器化应用的重要组成部分。Kubernetes通过静态和动态存储分配机制、丰富的存储插件生态系统,提供了强大的持久化存储支持。无论是块存储、文件存储还是对象存储,Kubernetes都能通过灵活的存储架构和扩展机制,满足不同应用场景的需求,确保数据的可靠性和持久性。Kubernetes的存储设计不仅提升了存储管理的效率和灵活性,还为云原生应用的发展提供了坚实的基础。

这篇关于21、架构-持久化存储的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1078043

相关文章

持久层 技术选型如何决策?JPA,Hibernate,ibatis(mybatis)

转自:http://t.51jdy.cn/thread-259-1-1.html 持久层 是一个项目 后台 最重要的部分。他直接 决定了 数据读写的性能,业务编写的复杂度,数据结构(对象结构)等问题。 因此 架构师在考虑 使用那个持久层框架的时候 要考虑清楚。 选择的 标准: 1,项目的场景。 2,团队的技能掌握情况。 3,开发周期(开发效率)。 传统的 业务系统,通常业

21.手绘Spring IOC运行时序图

1.再谈IOC与 DI IOC(lnversion of Control)控制反转:所谓控制反转,就是把原先我们代码里面需要实现的对象创 建、依赖的代码,反转给容器来帮忙实现。那么必然的我们需要创建一个容器,同时需要一种描述来让 容器知道需要创建的对象与对象的关系。这个描述最具体表现就是我们所看到的配置文件。 DI(Dependency Injection)依赖注入:就是指对象是被动接受依赖类

通信系统网络架构_2.广域网网络架构

1.概述          通俗来讲,广域网是将分布于相比局域网络更广区域的计算机设备联接起来的网络。广域网由通信子网于资源子网组成。通信子网可以利用公用分组交换网、卫星通信网和无线分组交换网构建,将分布在不同地区的局域网或计算机系统互连起来,实现资源子网的共享。 2.网络组成          广域网属于多级网络,通常由骨干网、分布网、接入网组成。在网络规模较小时,可仅由骨干网和接入网组成

【服务器运维】MySQL数据存储至数据盘

查看磁盘及分区 [root@MySQL tmp]# fdisk -lDisk /dev/sda: 21.5 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesSector size (logical/physical)

响应式架构

介绍 响应式架构(Reactive Architecture)是一种面向服务和事件的系统设计方法,旨在提高系统的可扩展性、弹性和容错能力。它适用于构建分布式系统,特别是在云环境和微服务架构中。响应式架构的核心理念是通过事件驱动和数据流来实现各个组件之间的解耦,从而提高整个系统的响应能力和可靠性。 响应式架构的主要特点包括: 响应性:系统能够快速响应外部事件和内部变化,确保在各种负载和故障情

mysql中存储过过程和游标的联合使用

1.SQL如下: DELIMITER //DROP PROCEDURE IF EXISTS PrintAllEmployeeNames5;CREATE PROCEDURE PrintAllEmployeeNames5()BEGINDECLARE error_count INT DEFAULT 0;DECLARE num INT ;DECLARE done INT DEFAULT

大型网站架构演化(六)——使用反向代理和CDN加速网站响应

随着网站业务不断发展,用户规模越来越大,由于中国复杂的网络环境,不同地区的用户访问网站时,速度差别也极大。有研究表明,网站访问延迟和用户流失率正相关,网站访问越慢,用户越容易失去耐心而离开。为了提供更好的用户体验,留住用户,网站需要加速网站访问速度。      主要手段:使用CDN和反向代理。如图。     使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速

大型网站架构演化(五)——数据库读写分离

网站在使用缓存后,使绝大部分数据读操作访问都可以不通过数据库就能完成,但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库,在网站的用户达到一定规模后,数据库因为负载压力过大而成为网站的瓶颈。      目前豆粉的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能,

大型网站架构演化(四)——使用应用服务器集群改善网站的并发能力

使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,不要企图去更换更强大的服务器,对大型服务器而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。 对网站架构而言,只要能通过增加一台服务器的方式改善负载压力,就可以以同样的方式持续增加服务器不断改善系统性能,从而实现系统

大型网站架构演化(二)——应用服务和数据服务分离

随着网站业务的发展,一台服务器逐渐不能满足需求:越来越多的用户访问导致性能越来越差,越来越多的数据导致存储空间不足。这时就需要将应用和数据分离。应用和数据分离后整个网站使用三台服务器:应用服务器、文件服务器和数据库服务器,如图。              这三台服务器对硬件资源的要求各不相同: 应用服务器需要处理大量的业务逻辑,因此需要更快更强大的CPU;