linuxea:kubernetes 介绍ConfigMap与Secret(23)


在之前的描述中,我们知道pv和pvc在使用中存在一种问题。pvc申请的的大小并不意味着就有符合pvc申请条件的pv。之前有意设定了符合pvc条件的pv,并成功的被pod绑定所使用。

I. StorageClass

k8s也考虑到这种情况,于是有意的设计了一种工作逻辑,能够让pvc在申请pv时候,借助存储类--->中间层(StorageClass)完成资源分配

首先,将众多存储归类,将相同的存储分为一个类别 ,这些被区分的存储类别分配后进行定义。定义成存储类(这类存储类是k8s标准资源)。这里资源定义完成后,k8s再去申请资源时候,将不会针对某个pv进行,而是针对存储类进行

  • 定义存储类:以存储类型或者性能,在或者某一种标识特性进行分别区分来定义的类,就是存储类

II. restful

存储设备必须支持restful,并且存储空间必须满足pvc申请的空间,至少大于等于。

以NFS为例,假设此时并没有提前创建空间,也没有手动创建PV。在前端定义一个restful 风格的接口。用户请求在磁盘划分一个符合pvc大小的分区,而后编辑NFS的配置文件将划分的分区挂载至本地的某个目录并且导出。动态创建一个pv并且绑定导出的空间。而后与pvc绑定。这个过程的动作都是动态生成的。如下:

也就是说事先并没有手动创建任何,只是输入了管理接口后远程创建,这类有ceph,Glusterfs等。

III. configMap与secret

secret与configMap也算是存储卷,但是secret与configMap存在的目的并不是为pod提供存储空间来用的,而是给用户提供从集群外部向pod内部应用注入配置信息的方式

引入:
在之前,一个容器内的应用配置文件,在起初制作image的时候已经配置在镜像内制作完成。顶多使用变量传递而修改一些配置参数。但是,倘若修改后的容器在运行了一段时间后,又需要修改配置。需要重新传递参数,这时候就需要重启容器内的进程,或者脚本。从而使配置生效。

并且,在之前的场景中,配置文件写死在镜像内,如果有不同的配置那可能以为这需要制作多个镜像。倘若使用不同的镜像标识来做配置的更新迭代,那么就会出现很多不同版本的镜像。这在之前的场景中是常见的。 但是,如果仅仅修改一个配置文件,就需要重构一个镜像,这样的方式代价无疑较大。在一些非容器化常见的场景中,可以使用配置中心来进行管理配置文件,如下:

配置文件存放在配置中心,tomcat在启动时候加载配置文件是从配置中心拉取的内容,而后启动tomcat进程。而后如果需要修改配置文件,只需要修改配置中心的集中配置文件,而后通知程序重新加载配置即可

IV. configMap

在kubernetes中引用一个新的标准资源,configMap来解决这个问题。configMap中存放的配置信息,启动一个pod的时候,可以共享configMap资源,资源对象可以作为存储卷或者环境变量。

configMap的作用在与可以与镜像解耦,配置信息通过configMap注入,一个配置文件可以应对多个pod容器,一个镜像也可以应付(配置)多个配置文件。这样一来便增强了应用的复用性和配置的一致性。一个configMap就是一系列配置数据的集合,而这些数据注入到pod对象容器中使用,注入方式有两种:
1,直接使用configMap作为存储卷
2,使用ENV FROM引用
并且支持动态修改:修改完成同步到其他容器

comfigMap的存储模式是键值对:key1:value1。每个value的长度可以是一个,也可以是一串,没有字符长短限制。
comfigMap存放的数据是明文的,而secret是base64

0 分享

您可以选择一种方式赞助本站

支付宝扫码赞助

支付宝扫码赞助

日期: 2018-10-27分类: kubernetes

标签: kubernetes

发表评论