标签：需要   dash   ssm   处理   kubectl   也会   主机   传统   docke   

一、存储卷

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风格的接口。才能实现动态供给。

二、容器化应用配置的方式

1. 自定义命令行参数 args
2. 把配置文件直接放在镜像里，适用性窄。
3. 环境变量，Cloud Native应用程序支持直接从环境变量加载配置；entrypoint脚本通过预处理环境变量为配置文件中的配置信息。
4. 存储卷（特殊的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

注入的方式有两种：

1. 变量注入的方式：

使用环境变量注入时只在系统启动时有效，运行中更改了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加载的配置内容

7.存储卷（Volume）

标签：需要   dash   ssm   处理   kubectl   也会   主机   传统   docke   

原文地址：https://www.cnblogs.com/cmxu/p/12097678.html