一、存储卷
Pod自己是有生命周期的,如果将数据放到容器内的自有名称空间当中,则Pod的生命周期结束,数据也就消失了。
节点上提供存储集是不能解决K8S的数据存储问题,因为集群是调度的。并且节点挂掉,数据也就丢了。
集群应该使用脱离节点而存在的共享存储设备。K8S提供各种类型的存储卷来使用。对K8S来说,存储卷属于Pod,而不是容器。
持久存储卷(PersistentVolume -- pv)
持久存储卷请求(PersistentVolumeClaim -- pvc)
Pv的动态供给,需要定义好存储类。
1、存储卷(PV)类型
emptyDir:只在节点本地使用的,Pod被删,数据也会被清掉的存储卷,临时使用,或缓存(内存),没有任何持久性。
gitRepo:
hostPath:在宿主机上找一个目录与Pod建立关联关系。
传统意义上的存储设备:
SAN(存储区域网络):iSCSI …
NAS(网络附加存储):nfs,cifs,http
分布式存储:glusterfs,ceph(rbd),cephfs…
云存储:EBS(Amazon),Azure Disk(microsoft),…
[kubelet@master ~]$ kubectl explain pod.spec.volumes # 查看支持的存储卷的类型
emptyDir示例:
gitRepo:本质上还是emptyDir
hostPath: 在宿主机上找一个目录与Pod建立关联关系。节点级持久。
[kubelet@master ~]$ kubectl explain pod.spec.volumes.hostPath
nfs:
2、Pv and Pvc
持久存储卷(PersistentVolume -- pv):PV是集群级别的资源,不属于名称空间级别的,不能定义命名空间。
持久存储卷请求(PersistentVolumeClaim -- pvc):PVC是属于名称空间级别的资源。
Pvc消耗PV的资源,PVC可以向pv申请指定大小的存储资源,并设置访问模式;只有pv的存储空间大于等于PVC申请的存储大小,才能被分配给该PVC。
二者都是标准的K8S资源,Pv和PVC是一一对应的关系,但一个PVC可以被多个Pod访问(访问模式控制)。
(1)、PV和PVC的生命周期
供应准备 => 绑定 => 使用 => 释放 => 回收(Retain保留,Recycle回收,Delete删除)
[kubelet@master ~]$ kubectl explain pv.spec
[kubelet@master ~]$ kubectl explain pod.spec.volumes.persistentVolumeClaim
(2)、PV的属性
PV的访问模式(accessModes):需要看底层存储设备是否支持。
ReadWriteOnce(RWO):单节点读写
ReadOnlyMany(ROX):多节点只读
ReadWriteMany(RWX):多节点读写
PV的存储容量(capacity):
[kubelet@master ~]$ kubectl explain pv.spec.capacity
Pv的回收策略(RECLAIM POLICY):
Retain:保留
Recycle:回收
Delete:删除
PV的生命周期阶段:
Available,Bound,Released,Failed=>自动回收失败
PV定义示例:
(3)、PVC的属性
访问模式(accessModes):与pv语义相同,PVC的访问模式一定是pv的子集。
资源(resources):申请的存储资源数量
requests:
storage:3Gi
PVC示例:
[kubelet@master ~]$ kubectl explain pvc.spec
动态供给: 当用户申请PVC时才去创建符合用户请求的PV。
StorageClass:存储类,K8S的上的标准资源。
PVC在申请资源时,不向某个具体的pv申请,而是向存储类申请。
存储设备需要支持restful风格的接口。才能实现动态供给。
二、容器化应用配置的方式
- 自定义命令行参数 args
- 把配置文件直接放在镜像里,适用性窄。
- 环境变量,Cloud Native应用程序支持直接从环境变量加载配置;entrypoint脚本通过预处理环境变量为配置文件中的配置信息。
- 存储卷(特殊的configMap,secret存储卷)
三、Pod中容器获取环境变量的方式
[kubelet@master ~]$ kubectl explain pod.spec.containers.env [kubelet@master ~]$ kubectl explain pod.spec.containers.envFrom
四、ConfigMap:
K8S上的配置中心。明文存储数据。让配置信息与镜像文件解耦,从而增强应用的可移植性和可复用性。
特殊类型的存储卷,目的不是给pod提供存储空间,而是给用户提供从K8S集群外部向Pod内部的应用注入配置信息的方式。
[kubelet@master ~]$ kubectl explain configmap
注入的方式有两种:
- 变量注入的方式:
使用环境变量注入时只在系统启动时有效,运行中更改了configmap的值,容器中环境变量不会对应改变。
[kubelet@master ~]$ kubectl create configmap nginx-config --from-literal=port=80 --from-literal=server_name=magedu.com
2.存储卷挂载的形式:
使用存储卷传递配置时,可以实时更新。挂载为文件,以键为文件名,以value为文件内容。
示例1:
示例2:
[kubelet@master configmap]$ kubectl create cm nginx-www --from-file=nginx-vhost.conf
通过存储卷挂载的形式也可以只挂载configMap的部分键值,而不是全部键值,详情查看:
[kubelet@master configmap]$ kubectl explain pod.spec.volumes.configMap.items
创建configmap的方式:
命令行或配置清单
[kubelet@master ~]$ kubectl create configmap –help # kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2 # kubectl create configmap my-config --from-file=path/to/bar
等等
五、Secret:
功能同ConfigMap,不是明文存储,而是编码存储数据(base64编码)。
特殊类型的存储卷,目的不是给pod提供存储空间,而是给用户提供从K8S集群外部向Pod内部的应用注入配置信息的方式。
Secret的几种类型:
docker-registry:认证信息。私有镜像仓库的认证信息。
[kubelet@master configmap]$ kubectl explain pod.spec.imagePullSecrets
generic:密码等通用加密信息。
tls:私钥和证书
示例:
[kubelet@master configmap]$ kubectl create secret generic mysql-root-pwd --from-literal=password=123456
环境变量注入的方式:
Tips:
/etc/nginx/conf.d # nginx –T # 查看NGINX加载的配置内容