在K8S中，容器本身是非持久化的，当容器崩溃后，kubelet将以镜像的初始状态重新启动容器，但是此时之前容器的数据已经丢失，我们该如何保护好容器的数据呢？
在同一Pod中的容器往往需要共享一些数据，此时我们又该如何实现呢？
这个时候就需要存储来解决这两个问题。
ConfigMap功能在 Kubernetes1.2版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。 ConfigMap API给我们提供了向容器中注入配置信息的机制， ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON二进制大对象。
① 使用目录创建
[root@master configmap] apple=8.0 orange=3.5 [root@master configmap] beef=55.0 pork=28.0 [root@master configmap] configmap/shop-config created [root@master configmap] NAME DATA AGE shop-config 2 8s [root@master configmap] [root@master configmap]② 使用文件创建
[root@master configmap] tea=3.0 coffee=4.0 [root@master configmap] configmap/drink-config created [root@master configmap]③ 使用字面值创建
使用文字值创建，利用 --from-literal参数传递配置信息，该参数可以使用多次，格式如下：
[root@master configmap] configmap/snacks-config created [root@master configmap]使用 ConfigMap有三种方式，一种是通过环境变量的方式，直接传递 pod，另一种是通过在 pod的命令行下运行的方式，第三种是使用 volume的方式挂载入到 pod内。
① 使用 ConfigMap 来替代环境变量
[root@master configmap] apiVersion: v1 kind: ConfigMap metadata: name: animal-config namespace: default data: cat: cute dog: lovely [root@master configmap] configmap/animal-config created [root@master configmap] apiVersion: v1 kind: Pod metadata: name: use-configmap-pod spec: containers: - name: test-container image: hub.hc.com/library/myapp:v1 command: [ "/bin/sh", "-c", "env" ] env: - name: animal-config-cat valueFrom: configMapKeyRef: name: animal-config key: cat - name: animal-config-coffee valueFrom: configMapKeyRef: name: animal-config key: dog envFrom: - configMapRef: name: snacks-config restartPolicy: Never [root@master configmap] pod/use-configmap-pod created [root@master configmap]② 用 ConfigMap 设置命令行参数
apiVersion: v1 kind: Pod metadata: name: use--configmap-pod2 spec: containers: - name: test-container image: hub.hc.com/library/myapp:v1 command: [ "/bin/sh", "-c", "echo $(animal-config-cat) $(animal-config-dog)" ] env: - name: animal-config-cat valueFrom: configMapKeyRef: name: animal-config key: cat - name: animal-config-dog valueFrom: configMapKeyRef: name: animal-config key: dog restartPolicy: Never③ 通过数据卷插件使用 ConfigMap
在数据卷里面使用这个 ConfigMap，有不同的选项。最基本的就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容。
apiVersion: v1 kind: Pod metadata: name: use-configmap-pod3 spec: containers: - name: test-container image: hub.hc.com/library/myapp:v1 command: [ "/bin/sh", "-c", "ls /etc/config" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: animal-config restartPolicy: NeverSecret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec中。Secret 可以以 Volume 或者环境变量的方式使用
Secret有三种类型：
Service Account：用来访问 Kubernetes API，由 Kubernetes自动创建，并且会自动挂载到 Pod的 /run/secrets/kubernetes.io/serviceaccount目录中Opaque： base64编码格式的 Secert，用来存储密码、密钥等kubernetes.io/dockerconfigjson：用来存储私有 docker registry的认证信息Opaque类型的数据是一个 map类型，要求 value是 base64编码格式：
[root@master ~] YWRtaW4= [root@master ~] MWYyZDFlMmU2N2Rm创建 Opaque类型的 secret:
[root@master secert] apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm [root@master secert] secret/mysecret created [root@master secert] NAME TYPE DATA AGE mysecret Opaque 2 93s将 Secret 挂载到 Volume 中：
[root@master secert] apiVersion: v1 kind: Pod metadata: labels: name: secret-test name: secret-test spec: volumes: - name: secrets secret: secretName: mysecret containers: - image: hub.hc.com/library/myapp:v1 name: db volumeMounts: - name: secrets mountPath: /etc/config [root@master secert] pod/secret-test created [root@master secert] / /etc/config 1f2d1e2e67df admin将 Secret 导出到环境变量中：
[root@master secert] apiVersion: extensions/v1beta1 kind: Deployment metadata: name: pod-deployment spec: replicas: 2 template: metadata: labels: app: pod-deployment spec: containers: - name: pod-1 image: hub.hc.com/library/myapp:v1 command: [ "/bin/sh", "-c", "env" ] ports: - containerPort: 80 env: - name: TEST_USER valueFrom: secretKeyRef: name: mysecret key: username - name: TEST_PASSWORD valueFrom: secretKeyRef: name: mysecret key: password [root@master secert] deployment.extensions/pod-deployment created容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时， kubelet会重启它，但是容器中的文件将丢失，容器以干净的状态（镜像最初的状态）重新启动。其次，在 Pod中同时运行多个容器时，这些容器之间通常需要共享文件。 Kubernetes中的 Volume抽象就很好的解决了这些问题。
Kubernetes中的卷（ Volume）有明确的寿命，与封装它的 Pod相同。所f以，卷的生命比 Pod中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod不再存在时，卷也将不复存在。 Kubernetes支持多种类型的卷， Pod可以同时使用任意数量的卷。
当 Pod被分配给节点时，首先创建 emptyDir卷，并且只要该 Pod在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。 Pod中的容器可以读取和写入 emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod时， emptyDir中的数据将被永久删除。
emptyDir 的用法有：
暂存空间，例如用于基于磁盘的合并排序用作长时间计算崩溃恢复时的检查点Web服务器容器提供数据时，保存内容管理器容器提取的文件 [root@master volume] apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: hub.hc.com/library/myapp:v1 name: test-container volumeMounts: - mountPath: /cache name: cache-volume - image: busybox name: test-container2 imagePullPolicy: IfNotPresent command: ['/bin/sh','-c','sleep 3600'] volumeMounts: - mountPath: /test name: cache-volume volumes: - name: cache-volume emptyDir: {} [root@master volume] [root@master volume] 'NAME READY STATUS RESTARTS AGE test-pd 2/2 Running 0 8m32s [root@master volume] / /cache /cache Wed Aug 12 07:43:08 UTC 2020 [root@master ~] / /test Wed Aug 12 07:43:08 UTC 2020hostPath卷将主机节点的文件系统中的文件或目录挂载到集群中
hostPath 的用途如下：
运行需要访问 Docker内部的容器；使用 /var/lib/docker的 hostPath在容器中运行 cAdvisor；使用 /dev/cgroups的 hostPath除了所需的 path属性之外，用户还可以为 hostPath卷指定 type：
值行为空空字符串（默认）用于向后兼容，这意味着在挂载 hostPath 卷之前不会执行任何检查DirectoryOrCreate如果在给定的路径上没有任何东西存在，那么将根据需要在那里创建一个空目录，权限设置为0755，与Kubelet具有相同的组和所有权。Directory给定的路径下必须存在目录FileOrCreate如果在给定的路径上没有任何东西存在，那么会根据需要创建一个空文件，权限设置为0644，与Kubelet具有相同的组和所有权。File给定的路径下必须存在文件Socket给定的路径下必须存在UNIX套接字CharDevice给定的路径下必须存在字符设备BlockDevice给定的路径下必须存在块设备
使用这种卷类型时请注意：
由于每个节点上的文件都不同，具有相同配置（例如从 podTemplate创建的）的 pod在不同节点上的行为可能会有所不同当 Kubernetes按照计划添加资源感知调度时，将无法考虑 hostPath使用的资源在底层主机上创建的文件或目录只能由 root写入。您需要在特权容器中以 root身份运行进程，或修改主机上的文件权限以便写入 hostPath卷 [root@master volume] apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: hub.hc.com/library/myapp:v1 name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: path: /data type: Directory [root@master volume] [root@master volume] / /test-pd [root@worker1 data] [root@worker2 data] 2020年 08月 12日 星期三 17:52:43 CST① PersistentVolume（PV） 是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样， PV也是集群中的资源。 PV是 Volume之类的卷插件，但具有独立于使用 PV的 Pod的生命周期。此 API对象包含存储实现的细节，即 NFS、 iSCSI或特定于云供应商的存储系统
② PersistentVolumeClaim（PVC） 是用户存储的请求，它与 Pod相似。 Pod消耗节点资源， PVC消耗 PV资源。 Pod可以请求特定级别的资源（ CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）
③ 静态 pv 集群管理员创建一些 PV，它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API中，可用于消费
④ 动态 当管理员创建的静态 PV都不匹配用户的 PersistentVolumeClaim时，集群可能会尝试动态地为 PVC创建卷。此配置基于 StorageClasses： PVC必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该类为""可以有效地禁用其动态配置要启用基于存储级别的动态存储配置，集群管理员需要启用 API server上的 DefaultStorageClass[准入控制器]。例如，通过确保 DefaultStorageClass位于 API server组件的 --admission-control标志，使用逗号分隔的有序值列表中，可以完成此操作
⑤ 绑定 master中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC动态调配 PV，则该环路将始终将该 PV绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC绑定后， PersistentVolumeClaim绑定是排他性的，不管它们是如何绑定的。 PVC跟 PV绑定是一对一的映射
PVC的保护 PVC保护的目的是确保由 pod正在使用的 PVC不会从系统中移除，因为如果被移除的话可能会导致数据丢失当启用 PVC保护 alpha功能时，如果用户删除了一个 pod正在使用的 PVC，则该 PVC不会被立即删除。 PVC的删除将被推迟，直到 PVC不再被任何 pod使用
PV演示代码
apiVersion: v1 kind: PersistentVolumemeta data: name: pv0003 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 172.17.0.2PV类型 PV类型以插件形式实现。 K8S目前支持以下插件类型： PV访问模式 PV可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个 PV的访问模式都将被设置为该卷支持的特定模式。例如， NFS可以支持多个读/写客户端，但特定的 NFS PV可能以只读方式导出到服务器上。每个 PV都有一套自己的用来描述特定功能的访问模式：
ReadWriteOnce：该卷可以被单个节点以读/写模式挂载ReadOnlyMany：该卷可以被多个节点以只读模式挂载ReadWriteMany：该卷可以被多个节点以读/写模式挂载在命令行中，访问模式缩写为
RWO： ReadWriteOnceROX： ReadOnlyManyRWX： ReadWriteMany回收策略
Retain（保留）——手动回收Recycle（回收）——基本擦除（ rm -rf /thevolume/*）Delete（删除）——关联的存储资产（例如 AWS EBS、 GCE PD、 Azure Disk 和 OpenStack Cinder卷）将被删除当前，只有 NFS和 HostPath支持回收策略。 AWS EBS、 GCE PD、 Azure Disk和 Cinder卷支持删除策略
状态 卷可以处于以下的某种状态：
Available（可用）——一块空闲资源还没有被任何声明绑定Bound（已绑定）——卷已经被声明绑定Released（已释放）——声明被删除，但是资源还未被集群重新声明Failed（失败）——该卷的自动回收失败命令行会显示绑定到 PV的 PVC的名称
① 安装 NFS 服务器
[root@master ~] [root@master ~] [root@master ~] /nfs *(rw,no_root_squash,no_all_squash,sync) [root@master ~] [root@worker1 ~] [root@worker1 ~] Export list for 192.168.182.100: /nfs * [root@worker1 ~] [root@worker1 /]② 部署 PV
[root@master pv] apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: nfs nfs: path: /nfs server: 192.168.182.100 [root@master pv] persistentvolume/nfs-pv1 created [root@master pv] NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE nfs-pv1 1Gi RWO Retain Available nfs 5s③ 创建服务并使用 PVC
[root@master /] [root@master /] [root@master /] /nfs *(rw,no_root_squash,no_all_squash,sync) /nfs2 *(rw,no_root_squash,no_all_squash,sync) /nfs3 *(rw,no_root_squash,no_all_squash,sync) [root@master pv] [root@master pv] apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: nfs nfs: path: /nfs server: 192.168.182.100 --- apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv2 spec: capacity: storage: 5Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain storageClassName: nfs nfs: path: /nfs2 server: 192.168.182.100 --- apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv3 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: slow nfs: path: /nfs3 server: 192.168.182.100 [root@master pv] NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE nfs-pv1 1Gi RWO Retain Available nfs 23s nfs-pv2 5Gi ROX Retain Available nfs 23s nfs-pv3 1Gi RWX Retain Available slow 23s [root@master pv] apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: hub.hc.com/library/myapp:v1 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: ["ReadWriteOnce"] storageClassName: "nfs" resources: requests: storage: 1Gi [root@master pv] NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7s web-1 0/1 Pending 0 5s [root@master pv] NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE nfs-pv1 1Gi RWO Retain Bound default/www-web-0 nfs 4m40s nfs-pv2 5Gi ROX Retain Available nfs 4m40s nfs-pv3 1Gi RWO Retain Bound default/www-web-1 nfs 4m40s [root@master pv] NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 15m 10.244.2.84 worker2 <none> <none> web-1 1/1 Running 0 15m 10.244.1.58 worker1 <none> <none> [root@master pv] Hello PV [root@master pv] Hello PV [root@master pv] pod "web-0" deleted [root@master pv] NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 3s 10.244.2.85 worker2 <none> <none> web-1 1/1 Running 0 18m 10.244.1.58 worker1 <none> <none> [root@master pv] Hello PVStatefulset 的启停顺序：
有序部署：部署 StatefulSet时，如果有多个 Pod副本，它们会被顺序地创建（从 0到 N-1）并且，在下一个 Pod运行之前所有之前的 Pod必须都是 Running和 Ready状态有序删除：当 Pod被删除时，它们被终止的顺序是从 N-1到 0有序扩展：当对 Pod执行扩展操作时，与部署一样，它前面的 Pod必须都处于 Running和 Ready状态StatefulSet 使用场景：
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于 PVC来实现稳定的网络标识符，即 Pod重新调度后其 PodName和 HostName不变有序部署，有序扩展，基于 init containers来实现有序收缩 全栈小刘 认证博客专家 开源框架设计原理 JVM底层原理 JUC 我从不给自己退路