利用Kubernetes实现容器的持久化存储
|
【技术】可以说，容器化彻底改变了我们对应用程序开发的思考方式，它带来很多好处:开发和生产之间的一致环境、使用共享的资源但容器之间相互隔离、云环境之间的可移植性、快速部署……等等不胜枚举。容器所固有的短暂性是它之所以伟大的核心原因：不可变的、相同的容器，可以在一瞬间快速启动。但容器的短暂性也有不利的一面：缺乏持久化存储。 引入Kubernetes 持久状态(Persistent state)通常数量较大且难以移动，这一概念与容器这种快速、轻量级且易于随时部署到任何地方的概念有很大的不同。正是由于这个原因，容器规范有意将持久状态排除在外，转而选择存储插件，将管理持久状态的责任转移给另一方。 开源容器编排工具Kubernetes已经开始着手解决这个问题。在这篇文章中，笔者将向您介绍Kubernetes中的几个组件，它们有助于解决在容器环境中持久化状态的问题。 有状态性 管理持久状态的最大问题是决定它应该存留在何处。在决定持久化存储应该放在何处时，有三种选择，每种方法各有其优点: ·持久化存储保存在容器中。如果数据是可复制的，而且不是关键数据，那么这中方法是非常有效的，但是当容器重新启动时，您将丢失这些数据。 ·持久化存储保存在主机节点上。这种方法绕过了容器的短暂性问题，但是您可能会因为主机节点的易受攻击性而遇到类似的问题。 ·持久化存储保存在远程存储中。这消除了容器和主机存储的不可靠性，但是需要仔细考虑如何提供/管理远程存储。 什么时候需要考虑状态? 应用程序有两个需要持久状态的关键特性：1、需要在应用程序中断和重启之前持久保存数据;2、需要跨相同的中断和重启，来管理应用程序状态。此类应用程序的典型例子有数据库及其副本、某种日志记录应用程序，或者需要远程存储的分布式应用程序。 但是，此类应用程序对持久性的需求并不是相同程度的，因为对于不同的应用程序，其关键程度显然是不同的。由于这个原因，笔者在设计有状态的应用程序时，常常会问自己几个问题: ·我们要管理多少数据? ·从最新的快照开始就可以吗?还是需要绝对最新的可用数据? ·从快照重新启动是否花费了太长时间，或者对这个应用程序而言已经足够了? ·数据的复制有多容易? ·这些数据对任务有多重要?能否在容器或主机终止时“存活”，还是需要远程存储? ·这个应用程序中的不同Pods是可互换的吗? 存储解决方案 许多应用程序要求数据能够跨容器和主机重启实现持久化，这就需要远程存储。幸运的是，Kubernetes已经意识到这种需求，并提供了一种Pod与远程存储交互的方式:卷(Volumes)。 Kubernetes卷 Kubernetes卷提供了一种与远程(或本地)存储交互的方法。可以将这些卷视为挂载的存储，这些存储将持续存留到封闭Pod的生存期。卷比在该Pod中spin up/down的任何容器的寿命都长，这为容器的短暂性提供了一个很好的解决方案。下面是一个利用卷的Pod定义示例。 apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: — name: test-container image: nginx volumeMounts: — mountPath: /data name: testvolume volumes: — name: testvolume # This AWS EBS Volume must already exist. awsElasticBlockStore: volumeID: <volume-id> fsType: ext4 正如我们从上面Pod定义中看到的，spec下的volumes部分指定了卷的名称和已经创建的存储的ID(在本例中是EBS卷)。要使用此卷，容器定义必须在spec下的containers volumeMounts字段中指定要挂载的卷。 在利用卷时要记住的一些关键点: ·Kubernetes提供许多类型的卷，一个Pod可以同时使用任意数量的卷。 ·卷仅能持续与封闭的Pod一样长的时间。当Pod停止存在时，卷也将停止。 ·持久存储的供应不是由卷或Pod本身处理的，卷后的持久存储需要以其他方式提供。 虽然卷解决了容器化应用程序的一个巨大问题，但某些应用程序要求附加卷的生存期超过Pod的生存期。对于这个用例，持久卷和持久卷声明将非常有用。 Kubernetes持久卷和持久卷声明 Kubernetes持久卷和持久卷声明提供了一种方法，以便从存储的使用方式中提取关于如何提供存储的细节。持久卷(PV，Persistent Volume)是一个集群中由管理员提供的可用持久存储，它们作为集群资源存在，就像节点一样，它们的生命周期独立于任何单独的Pod。持久卷声明(PVC，Persistent Volume Claim)是用户对存储的请求，与Pod消耗内存和CPU等节点资源的方式类似，PVC也消耗存储等PV资源。 PV的生命周期由四个阶段组成:供应(provisioning)、绑定(binding)、使用(using)和回收(reclaiming)。 供应——PV的供应可以通过两种方式完成:静态或动态。 ·静态供应需要集群管理员手动创建大量要使用的PV。 ·动态供应可以在PVC请求PV时发生，而不需要集群管理员进行任何手动干预。 ·动态供应需要以存储类(Storage Classes)的形式进行一些预先供应(我们稍后将对此进行讨论)。 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
