k8s-存储 11

一、configmapu存储

首先,确保集群正常,节点都处于就绪状态

k8s-存储 11_第1张图片

Configmap用于保存配置数据,以键值对形式存储。configMap资源提供了向 Pod 注入配置数据的方法,旨在让镜像和配置文件解耦,以便实现镜像的可移植性和可复用性。

典型的使用场景:

• 填充环境变量的值

• 设置容器内的命令行参数

• 填充卷的配置文件

创建ConfigMap的方式有4种:使用字面值创建;使用文件创建;使用目录创建;编写configmap的yaml文件创建。

字面值创建

k8s-存储 11_第2张图片

通过文件创建

通过目录创建(创建时,目录中的文件名为key,文件内容是value)

k8s-存储 11_第3张图片

通过yaml文件创建

k8s-存储 11_第4张图片k8s-存储 11_第5张图片

二、secret存储

k8s-存储 11_第6张图片

从文件中创建Secret

k8s-存储 11_第7张图片

编写yaml文件

k8s-存储 11_第8张图片k8s-存储 11_第9张图片

将Secret挂载到Volume中:

创建映射secret密钥

k8s-存储 11_第10张图片k8s-存储 11_第11张图片

向指定路径映射secret密钥

k8s-存储 11_第12张图片

将Secret设置为环境变量

k8s-存储 11_第13张图片k8s-存储 11_第14张图片

存储docker registry的认证信息

k8s-存储 11_第15张图片k8s-存储 11_第16张图片k8s-存储 11_第17张图片

将registrykey绑定到sa,这样yaml文件中就可以不用指定,会更加安全

k8s-存储 11_第18张图片k8s-存储 11_第19张图片

三、Volumes配置管理

容器中的文件在磁盘上是临时存放的,这给容器中运行的特殊应用程序带来一些问题。首先,当容器崩溃时,kubelet 将重新启动容器,容器中的文件将会丢失, 因为容器会以干净的状态重建。其次,当在一个 Pod 中同时运行多个容器时,常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题。

Kubernetes 卷具有明确的生命周期,与包裹它的 Pod 相同。因此,卷比 Pod 中 运行的任何容器的存活期都长,在容器重新启动时数据也会得到保留。当然,当 一个 Pod 不再存在时,卷也将不再存在。也许更重要的是,Kubernetes 可以支持许多类型的卷,Pod 也能同时使用任意数量的卷。

卷不能挂载到其他卷,也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。

emptyDir卷

当 Pod 指定到某个节点上时,首先创建的是一个 emptyDir 卷,并且只要 Pod 在该节点上运行,卷就一直存在。就像它的名称表示的那样,卷最初是空的。尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同,但是这些容器都可 以读写 emptyDir 卷中相同的文件。当 Pod 因为某些原因被从节点上删除时, emptyDir 卷中的数据也会永久删除。k8s-存储 11_第20张图片k8s-存储 11_第21张图片k8s-存储 11_第22张图片k8s-存储 11_第23张图片k8s-存储 11_第24张图片k8s-存储 11_第25张图片

emptydir缺点:

不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出,但是这个时间内,其实 对node还是有风险的;
影响kubernetes调度,因为empty dir并不涉及node的resources,这样会造成Pod“偷偷” 使用了node的内存,但是调度器并不知晓;

用户不能及时感知到内存不可用。


hostpath卷(适合做监控类)

hostPath 卷能将主机节点文件系统上的文件或目录挂载到您的Pod 中。虽然这不是大多数Pod 需要的,但是它为一些应用程序提供了强大的逃生舱。

hostPath的一些用法有:

运行一个需要访问Docker 引擎内部机制的容器,挂载 /var/lib/docker 路径。

在容器中运行 cAdvisor 时,以 hostPath 方式挂载 /sys。

允许 Pod 指定给定的 hostPath 在运行 Pod 之前是否应该存在,是否应该创建以及应该以 什么方式存在。

hostpath卷相较于empitydir卷是直接持久化到pod所在的节点,为应用程序提供了一个强大的逃生舱,不会因为Pod被删除之后数据就丢了;而empitydir卷是pod没了数据也就没了,不是持久到磁盘上。

k8s-存储 11_第26张图片k8s-存储 11_第27张图片k8s-存储 11_第28张图片k8s-存储 11_第29张图片k8s-存储 11_第30张图片

nfs卷

配置nfs-server

k8s-存储 11_第31张图片

创建nfspodk8s-存储 11_第32张图片

k8s-存储 11_第33张图片

需要在所有k8s节点上安装nfs-utils安装包

持久卷(和pod是相互独立的)

k8s-存储 11_第34张图片

使用

Pod使用PVC就像使用volume一样。集群检查PVC,查找绑定的PV,并映射PV给Pod。对 于支持多种访问模式的PV,用户可以指定想用的模式。一旦用户拥有了一个PVC,并且 PVC被绑定,那么只要用户还需要,PV就一直属于这个用户。用户调度Pod,通过在Pod的 volume块中包含PVC来访问PV。

释放

当用户使用PV完毕后,他们可以通过API来删除PVC对象。当PVC被删除后,对应的PV就 被认为是已经是“released”了,但还不能再给另外一个PVC使用。前一个PVC的属于还存 在于该PV中,必须根据策略来处理掉。

回收

PV的回收策略告诉集群,在PV被释放之后集群应该如何处理该PV。当前,PV可以被 Retained(保留)、Recycled(再利用)或者Deleted(删除)。保留允许手动地再次声明 资源。对于支持删除操作的PV卷,删除操作会从Kubernetes中移除PV对象,还有对应的外 部存储(如AWS EBS,GCE PD,Azure Disk,或者Cinder volume)。动态供给的卷总是 会被删除。

配置nfs输出目录

k8s-存储 11_第35张图片k8s-存储 11_第36张图片k8s-存储 11_第37张图片k8s-存储 11_第38张图片

创建pvc

k8s-存储 11_第39张图片k8s-存储 11_第40张图片

创建pod

k8s-存储 11_第41张图片k8s-存储 11_第42张图片k8s-存储 11_第43张图片

回收资源,需要按顺序回收:pod > pvc > pv

k8s-存储 11_第44张图片

回收pvc后,pv会被回收再利用

由于pv的回收需要拉取镜像,因此需要提前在node节点导入镜像:

docker pull registry.k8s.io/debian-base:v2.0.0

用于替代默认仓库,但需要科学上网

k8s-存储 11_第45张图片

strogeclass动态存储分配

k8s-存储 11_第46张图片

更多属性查看地址:存储类 | Kubernetes

官方配置文档:https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

k8s-存储 11_第47张图片

创建sa并授权

k8s-存储 11_第48张图片

在复制文件有#的情况下要进入到paste模式下

k8s-存储 11_第49张图片k8s-存储 11_第50张图片k8s-存储 11_第51张图片

部署应用

k8s-存储 11_第52张图片k8s-存储 11_第53张图片

创建存储类k8s-存储 11_第54张图片

创建pvc

k8s-存储 11_第55张图片

创建pod

k8s-存储 11_第56张图片

回收

k8s-存储 11_第57张图片

可以设置默认存储类(default),这样在创建pvc的时候就不用专门去指定storageClassName

k8s-存储 11_第58张图片k8s-存储 11_第59张图片

你可能感兴趣的:(kubernetes,linux,容器)