Kubernetes 中的 StorageClass 和动态卷供给
存储是容器运行环境的重要一环,Kubernetes 提供了一些用于存储管理的基础能力。动态卷供给是一个 Kubernetes 独有的功能,这一功能允许按需创建存储卷。在没有这种能力之前,集群管理员需要打电话给他们的云或者存储提供者来创建新的存储卷,成功以后再创建 PersistentVolume对象,才能够在 Kubernetes 中使用。动态卷供给能力让管理员不必进行预先创建存储卷,而是随用户需求进行创 建。这一特性在 1.2 版本中处于 α 阶段,在 版本 1.4 中提升为 β。这一版本提高了动态卷的弹性和可用性。
新特性
Alpha 版本的动态卷,一个集群同时只能允许单独的、被硬编码的提供者。也就是说,如果 Kubernetes 要提供动态卷的时候,即使集群中可以使用多个存储系统,Kubernetes 也只会使用同一个存储卷插件。存储提供者的选型是基于云环境类型决定的 —— AWS 的 EBS,Google Cloud 的 Persistent Disk 或者是 OpenStack 的 Cinder,以及 vSphere 的 vSphere Volume。另外只有容量参数可以配置。这就意味着,即使有其他参数可用,所有的动态卷除了尺寸大小,其他都是一样的。
因为只有容量是大家都有的吧。。。
虽说这一功能的 Alpha 版本实用性有限,这毕竟是迈出了一步,有助于确定今后的发展方向。
Kubernetes 1.4 中加入了一个 新的 API 对象 StorageClass,可以定义多个 StorageClass 对象,并可以分别指定存储插件、设置参数,用于提供不同的存储卷。这样的设计让集群管理员能够在同一个集群内,定义和提供不同类型的、不同参数的卷(相同或者不同的存储系统)。这样的设计还确保了最终用户在无需了解太多的情况下,有能力选择不同的存储选项。
如何使用
下面是一个例子,管理员提供了两种存储,用户可以选择其中一个使用。细节可以查看 手册 以及示例 文档。
管理员配置
集群管理员定义并发布了两个 StorageClass 对象
kind: StorageClass apiVersion: storage.k8s.io/v1beta1 metadata: name: slow provisioner: kubernetes.io/gce-pd parameters: type: pd-standard
这一段创建了一个名为 “slow” 的 StorageClass,用于提供标准的持久存储。
kind: StorageClass apiVersion: storage.k8s.io/v1beta1 metadata: name: fast provisioner: kubernetes.io/gce-pd parameters: type: pd-ssd
这一段创建了一个名为 “fast” 的 StorageClass,用于提供类似 SSD 的持久存储。
用户请求
用户在 PersistentVolumeClaim 中可以包含一个 StorageClass 申请动态提供存储。这一任务需要使用 volume.beta.kubernetes.io/storage-class 注解来完成。这一注解的值必须符合管理员配置的 StorageClass 名称。
要选择 “fast” 存储类,用户需要创建如下的 PVC:
{ "kind": "PersistentVolumeClaim", "apiVersion": "v1", "metadata": { "name": "claim1", "annotations": { "volume.beta.kubernetes.io/storage-class": "fast" } }, "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "30Gi" } } } }
上述报文会提供一个等效于 SSD 的持久盘,当这个 PVC 被删除,这个卷也随之销毁。
缺省行为
所有的 PVC 都可以在不使用 StorageClass 注解的情况下,直接使用某个动态存储。把一个StorageClass 对象标记为 “default” 就可以了。StorageClass 用注解storageclass.beta.kubernetes.io/is-default-class 就可以成为缺省存储。
有了缺省的 StorageClass,用户创建 PVC 就不用 storage-class 的注解了,1.4 中新加入的DefaultStorageClass 准入控制器会自动把这个标注指向缺省存储类。
我还能使用 Alpha 版本么?
Kubernetes 1.4 兼容 alpha 版本的动态卷特性,让用户能够平滑过渡到 beta 版本。用volume.alpha.kubernetes.io/storage-class 注解来标注 alpha 版本。
在未来版本中将会弃用 Alpha 版本。
下一步?
动态卷功能会持续发展,下面是一些要点。
标准云支持
如果 Kubernetes 集群部署在云服务商,我们 考虑 自动使用云的本地存储系统创建一个动态卷供给者。例如在 AWS 上的标准部署会得到一个 EBS 的动态卷供给,而 Google Cloud 的部署则会提供一个 GCE PD 动态卷供应者。我们还在讨论是否应该把这种卷作为缺省卷。
本文转自中文社区-Kubernetes 中的 StorageClass 和动态卷供给

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
kubernetes资源对象--ingress
Ingress在K8S1.1之前还没有。 概念 Ingress是一种HTTP方式的路由转发机制,为K8S服务配置HTTP负载均衡器,通常会将服务暴露给K8S群集 外的客户端。 Ingress是一个允许入站连接到达集群服务的规则集合。Ingress能把K8S service配置成外网可访问集群service的URL、负载均衡、SSL、基于名称的虚拟主机等。 单纯创建一个Ingress没有任何意义,需要部署一个Ingress Controller(Ingress控制器,下文简称IC)来实现Ingress。在GCE/GKE环境下,会自动在master节点上部署一个IC。在非GCE/GKE的环境中,必须部署和运行一个IC。 IC是通过轮询实时监听K8S apiserver监视Ingress资源的应用程序,一旦资源发生了变化(包括增加、删除和修改),将ingress资源存储到本地缓存,并通知HTTP代理服务器(例如nginx)进行实时更新转发规则。 这与其他类型的控制器不同,其他类型的控制器通常作为kube-controller-manager二进制文件的一部分运行,在集群启动时自动启动。而IC...
- 下一篇
kubernetes资源对象--ConfigMap
原理 很多生产环境中的应用程序配置较为复杂,可能需要多个config文件、命令行参数和环境变量的组合。使用容器部署时,把配置应该从应用程序镜像中解耦出来,以保证镜像的可移植性。尽管Secret允许类似于验证信息和秘钥等信息从应用中解耦出来,但在K8S1.2前并没有为了普通的或者非secret配置而存在的对象。在K8S1.2后引入ConfigMap来处理这种类型的配置数据。 ConfigMap是存储通用的配置变量的,类似于配置文件,使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理;而它与配置文件的区别在于它是存在集群的“环境”中的,并且支持K8S集群中所有通用的操作调用方式。 从数据角度来看,ConfigMap的类型只是键值组,用于存储被Pod或者其他资源对象(如RC)访问的信息。这与secret的设计理念有异曲同工之妙,主要区别在于ConfigMap通常不用于存储敏感信息,而只存储简单的文本信息。 ConfigMap可以保存环境变量的属性,也可以保存配置文件。 创建pod时,对configmap进行绑定,pod内的应用可以直接引用ConfigMap的配置。相当于con...
相关文章
文章评论
共有0条评论来说两句吧...