一、存储卷
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），…
[[email protected] ~]$ kubectl explain pod.spec.volumes # 查看支持的存储卷的类型
emptyDir示例：
gitRepo：本质上还是emptyDir
hostPath: 在宿主机上找一个目录与Pod建立关联关系。节点级持久。
[[email protected] ~]$ 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删除）
[[email protected] ~]$ kubectl explain pv.spec [[email protected] ~]$ kubectl explain pod.spec.volumes.persistentVolumeClaim
（2）、PV的属性
PV的访问模式（accessModes）：需要看底层存储设备是否支持。
ReadWriteOnce（RWO）：单节点读写
ReadOnlyMany（ROX）：多节点只读
ReadWriteMany（RWX）：多节点读写
PV的存储容量（capacity）：
[[email protected] ~]$ 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示例：
[[email protected] ~]$ kubectl explain pvc.spec
动态供给： 当用户申请PVC时才去创建符合用户请求的PV。
StorageClass：存储类，K8S的上的标准资源。
PVC在申请资源时，不向某个具体的pv申请，而是向存储类申请。
存储设备需要支持restful风格的接口。才能实现动态供给。
二、容器化应用配置的方式
- 自定义命令行参数 args
- 把配置文件直接放在镜像里，适用性窄。
- 环境变量，Cloud Native应用程序支持直接从环境变量加载配置；entrypoint脚本通过预处理环境变量为配置文件中的配置信息。
- 存储卷（特殊的configMap，secret存储卷）
三、Pod中容器获取环境变量的方式
[[email protected] ~]$ kubectl explain pod.spec.containers.env [[email protected] ~]$ kubectl explain pod.spec.containers.envFrom
四、ConfigMap：
K8S上的配置中心。明文存储数据。让配置信息与镜像文件解耦，从而增强应用的可移植性和可复用性。
特殊类型的存储卷，目的不是给pod提供存储空间，而是给用户提供从K8S集群外部向Pod内部的应用注入配置信息的方式。
[[email protected] ~]$ kubectl explain configmap
注入的方式有两种：
- 变量注入的方式：
使用环境变量注入时只在系统启动时有效，运行中更改了configmap的值，容器中环境变量不会对应改变。
[[email protected] ~]$ kubectl create configmap nginx-config --from-literal=port=80 --from-literal=server_name=magedu.com
2.存储卷挂载的形式：
使用存储卷传递配置时，可以实时更新。挂载为文件，以键为文件名，以value为文件内容。
示例1：
示例2：
[[email protected] configmap]$ kubectl create cm nginx-www --from-file=nginx-vhost.conf
通过存储卷挂载的形式也可以只挂载configMap的部分键值，而不是全部键值，详情查看：
[[email protected] configmap]$ kubectl explain pod.spec.volumes.configMap.items
创建configmap的方式：
命令行或配置清单
[[email protected] ~]$ 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：认证信息。私有镜像仓库的认证信息。
[[email protected] configmap]$ kubectl explain pod.spec.imagePullSecrets
generic：密码等通用加密信息。
tls：私钥和证书
示例：
[[email protected] configmap]$ kubectl create secret generic mysql-root-pwd --from-literal=password=123456
环境变量注入的方式：
Tips：
/etc/nginx/conf.d # nginx –T # 查看NGINX加载的配置内容
原文地址：https://www.cnblogs.com/cmxu/p/12097678.html