Kubernetes之存储

存储卷概述

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了这些问题。在原docker环境中也有存储卷的概念，但docker环境的存储卷调度在宿主机上的目录，当docker重新创建的时候存储卷还会挂载统一宿主机上，但我们知道Kubernetes是分布式集群，当我们销毁一个pod的时候，可能pod会在其他节点上启动，但其他节点宿主机上并没有这个目录，这样就不会挂载到原来的数据了。为此Kubernetes不同类型的持久卷。

我们可以通过kubectl explain pods.spec.volumes来查看支持的存储卷：

• hostPath  主机目录
• emptyDir  空目录（pod销毁也随之销毁）

• rbd    分布式存储之ceph块存储

• local   卷表示挂载的本地存储设备，如磁盘、分区或目录

• cephfs   分布式存储之cephfs

• awsElasticBlockStore  aws云存储

• azureDisk   azure云存储

• azureFile   azure云存储

• glusterfs   分布式存储之glusterfs

• downwardAPI   卷用于使向下 API 数据（downward API data）对应用程序可用。它挂载一个目录，并将请求的数据写入纯文本文件。
• cinder   OpenStack 块存储
• configMap   配置中心
• fc  卷允许将现有的 fc 卷挂载到 pod 中。您可以使用卷配置中的 targetWWN 参数指定单个或多个目标全球通用名称（World Wide Name）。如果指定了多个 WWN，则 targetWWN 期望这些 WWN 来自多路径连接。
• flexVolume 抽象的存储服务，存储服务的管理软件
• flocker  是一款开源的集群容器数据卷管理器。它提供了由各种存储后端支持的数据卷的管理和编排。
• gcePersistentDisk   谷歌云上
• gitRepo  卷是一个可以演示卷插件功能的示例。它会挂载一个空目录并将 git 存储库克隆到您的容器中。
• iscsi  iscsi 卷允许将现有的 iSCSI卷挂载到容器中。不像 emptyDir，删除 Pod 时 iscsi 卷的内容将被保留，卷仅仅是被卸载。这意味着 iscsi 卷可以预先填充数据，并且这些数据可以在 pod 之间“切换”。
• nfs   nfs Nas存储
• persistentVolumeClaim 卷用于将 PersistentVolume 挂载到容器中。PersistentVolumes 是在用户不知道特定云环境的细节的情况下“声明”持久化存储（例如 GCE PersistentDisk 或 iSCSI 卷）的一种方式。
• photonPersistentDisk
• portworxVolume  是一个与 Kubernetes 一起，以超融合模式运行的弹性块存储层
• projected 卷将几个现有的卷源映射到同一个目录中
• quobyte  卷允许将现有的 Quobyte 卷挂载到容器中。
• scaleIO  ScaleIO 是一个基于软件的存储平台，可以使用现有的硬件来创建可扩展的共享块网络存储集群
• secret   加密文件
• storageos  动态存储
• vsphereVolume 配置了 vSphere Cloud Provider 的 Kubernetes

emptyDir

kubectl explain pod.spec.volumes.emptyDir  指定emptyDir存储卷

• medium   指定媒介类型   disk  Memory 两种
• sizeLimit  现在资源使用情况

kubectl explain pod.spec.containers.volumeMounts  指定挂载哪些存储卷

• mountPath   挂载那个路径
• name 指定挂载的volumes名称
• readOnly   是否只读挂载
• subPath   是否挂载子路径

下面实例为 一个pod中的两个容器共享同一个存储

apiVersion: v1
kind: Pod
metadata:
  name: my-demo
  namespace: default
  labels:
    name: myapp
    tier: appfront
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort:
    volumeMounts:
    - name: appindex
      mountPath: /usr/share/nginx/html/
  - name: busybox
    image: busybox
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: appindex
      mountPath: /data/
    command:
    - "/bin/sh"
    - "-c"
    - "while true; do echo $(date) >> /data/index.html; sleep 2; done"
  volumes:
  - name: appindex
    emptyDir: {}

验证

curl 10.244.3.14
Mon Sep  :: UTC
Mon Sep  :: UTC
Mon Sep  :: UTC
Mon Sep  :: UTC
Mon Sep  :: UTC
Mon Sep  :: UTC 

hostPath

kubectl explain pod.spec.volumes.hostPath

• path  指定宿主机的路径
• type  DirectoryOrCreate  宿主机上不存在创建此目录  Directory 必须存在挂载目录  FileOrCreate 宿主机上不存在挂载文件就创建  File 必须存在文件

目录自动创建

apiVersion: v1
kind: Pod
metadata:
  name: my-demo
  namespace: default
  labels:
    name: myapp
    tier: appfront
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort:
    volumeMounts:
    - name: appindex
      mountPath: /usr/share/nginx/html/
  volumes:
  - name: appindex
    hostPath:
      path: /data/pod/myapp
      type: DirectoryOrCreate

NFS

kubectl explain pod.spec.volumes.nfs

• path 源目录
• readOnly  是否只读  默认false
• server  NFS服务地址

apiVersion: v1
kind: Pod
metadata:
  name: my-demo-nfs
  namespace: default
  labels:
    name: myapp
    tier: appfront
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort:
    volumeMounts:
    - name: appindex
      mountPath: /usr/share/nginx/html/
  volumes:
  - name: appindex
    nfs:
      server: 172.16.132.241
      path: /data

手动在/data目录下增加一个index.html

验证

kubectl get pods -o wide
NAME                          READY     STATUS    RESTARTS   AGE       IP            NODE
my-demo                       /       Running             3h        10.244.2.4    k8s-node02
my-demo-nfs                   /       Running             2m        10.244.3.15   k8s-node03

$ curl 10.244.3.15
nfs

PVC如何使用的

我们前面提到kubernetes提供那么多储存接口，但是首先kubernetes的各个Node节点能管理这些存储，但是各种存储参数也需要专业的存储工程师才能了解，由此我们的kubernetes管理变的更加复杂的。由此kubernetes提出了PV和PVC的概念，这样开发人员和使用者就不需要关注后端存储是什么，使用什么参数等问题。如下图：

当我们pod中定义volume的时候，我们只需要使用pvs存储卷就可以，pvc必须与对应的pv建立关系，pvc会根据定义去pv申请，而pv是由存储空间创建出来的。pv和pvc是kubernetes抽象出来的一种存储资源。

PV介绍：

PersistentVolume 是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。可根据上图看清他们之间的关系

PV有两种配置方式：动态和静态

静态：

集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。

动态：

当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。此配置基于 StorageClasses：PVC 必须请求存储类，并且管理员必须创建并配置该类才能进行动态创建。声明该类为 "" 可以有效地禁用其动态配置。

要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass 准入控制器。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作。

kubectl explain pv.spec

• accessModes   访问模式

1. ReadWriteOnce（RWO）  单节点读写
2. ReadOnlyMany（ROX）  多节点只读
3. ReadWriteMany（RWX）  多节点读写

• capacity  定义pv使用多少资源

定义一个nfs格式的pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv01
  labels:
    name: pv01
spec:
  nfs:
    path: /data/pv/
    server: 172.16.132.241
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv02
  labels:
    name: pv02
spec:
  nfs:
    path: /data/pv/
    server: 172.16.132.241
  accessModes: ["ReadOnlyMany","ReadWriteOnce"]
  capacity:
    storage: 5Gi

查看详细

kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
pv01      2Gi        RWO,RWX        Retain           Available                                      1m
pv02      5Gi        RWO,ROX        Retain           Available                                      1m

回收策略（RECLAIM POLICY）

当pod结束 volume 后可以回收资源对象删除PVC，而绑定关系就不存在了，当绑定关系不存在后这个PV需要怎么处理，而PersistentVolume 的回收策略告诉集群在存储卷声明释放后应如何处理该卷。目前，volume 的处理策略有保留、回收或删除。

保留：

此策略允许手动回收资源，当pvc被删除后，pv依然存在，volume 被视为“已释放”。但是由于前一个声明人的数据仍然存在，所以还不能马上进行其他声明。管理员可以通过以下步骤手动回收卷。

• 删除 PV。在删除 PV 后，外部基础架构中的关联存储空间（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）仍然存在。
• 手动清理相关存储空间上的数据
• 手动删除关联的存储空间，或者如果要重新使用相同的存储空间，请使用存储空间定义创建新的 PersistentVolume。

回收：

在 volume上执行情况数据（rm -rf /thevolume/*），可以再次被其他pvc调度

删除：

对于支持删除回收策略的卷插件，删除操作将从 Kubernetes 中删除 PV 对象，并删除外部基础架构（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中的关联存储空间。动态配置的卷继承其 StorageClass 的回收策略，默认为 Delete。管理员应该根据用户的期望来配置 StorageClass，否则就必须要在 PV 创建后进行编辑或修补。

PVC介绍：

PersistentVolumeClaim 是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或 只读多次模式挂载）。

虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但用户需要具有不同性质（例如性能）的 PersistentVolume 来解决不同的问题。集群管理员需要能够提供各种各样的 PersistentVolume，这些PersistentVolume 的大小和访问模式可以各有不同，但不需要向用户公开实现这些卷的细节。对于这些需求，StorageClass 资源可以实现。可根据上图看清他们之间的关系

kubectl  explain pvc.spec

• accessModes 访问模式  是递延pv的accessModes的子集，例如：pv中accessModes 定义["ReadWriteMany","ReadWriteOnce"]，pvc中的也只能定义["ReadWriteMany","ReadWriteOnce"] 或其中的一个。
• resources  资源限制
• selector 　标签选择器
• storageClassName  动态存储名称
• volumeMode  后端存储卷的模式
• volumeName  指定卷(pv)的名称

定义pvc资源对象

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
  namespace: default
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: my-demo-pvc
  namespace: default
  labels:
    name: myapp
    tier: appfront
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort:
    volumeMounts:
    - name: appindex
      mountPath: /usr/share/nginx/html/
  volumes:
  - name: appindex
    persistentVolumeClaim:
      claimName: mypvc

查看

$ kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM           STORAGECLASS   REASON    AGE
pv02      5Gi        RWO,ROX        Retain           Bound     default/mypvc                            1h
$ kubectl describe pod my-demo-pvc
Name:               my-demo-pvc
Namespace:          default
Priority:
PriorityClassName:  <none>
Node:               k8s-node02/172.16.138.42
Start Time:         Thu,  Sep  :: -
Labels:             name=myapp
                    tier=appfront
Annotations:        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"myapp","tier":"appfront"},"name":"my-demo-pvc","namespace":"default"},"s...
Status:             Running
IP:                 10.244.2.6
Containers:
  myapp:
    Container ID:   docker://6727e1b45fba703f98d7a11f16a60706b8f5c2925026707b412c13ef80f5ac52
    Image:          ikubernetes/myapp:v1
    Image ID:       docker-pullable://ikubernetes/myapp@sha256:9c3dc30b5219788b2b8a4b065f548b922a34479577befb54b03330999d30d513
    Port:           /TCP
    Host Port:      /TCP
    State:          Running
      Started:      Thu,  Sep  :: -
    Ready:          True
    Restart Count:
    Environment:    <none>
    Mounts:
      /usr/share/nginx/html/ from appindex (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-lplp6 (ro)
......

StorageClass介绍

当pvc申请的时候不一定有满足pvc要求的pv，那怎么办呢？kubernetes为 为管理员提供了描述存储 "class（类）" 的方法（StorageClass）。例如存储工程给划分一个1TB的存储空间供kubernetes使用，当用户需要一个10G的pvc的时候会立即通过restful的请求到存储空间创建一个10G的images,之后在我们的集群中定义成10G的pv给当前pvc作为挂载使用。如下图：

ConfigMap

configmap是让配置文件从镜像中解耦，让镜像的可移植性和可复制性。许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与docker image解耦，你总不能每修改一个配置就重做一个image吧？ConfigMap API给我们提供了向容器中注入配置信息的机制，ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制大对象。

ConfigMap API资源用来保存key-value pair配置数据，这个数据可以在pods里使用，或者被用来为像controller一样的系统组件存储配置数据。虽然ConfigMap跟Secrets类似，但是ConfigMap更方便的处理不含敏感信息的字符串。

注意：ConfigMaps不是属性配置文件的替代品。ConfigMaps只是作为多个properties文件的引用。你可以把它理解为Linux系统中的/etc目录，专门用来存储配置文件的目录。下面举个例子，使用ConfigMap配置来创建Kuberntes Volumes，ConfigMap中的每个data项都会成为一个新文件。

详解

kubectl explain cm

• data    传递数据
• binaryData  使用二进制传递数据

如果临时使用可以使用命令行创建  kubectl create cm --help

$ kubectl create cm nginx-conf  --from-literal=nginx_port= --from-literal=server_name=myapp.jaxzhai.com
configmap/nginx-conf created
$ kubectl get cm 
NAME         DATA      AGE
nginx-conf   2         31

通过配置文件创建

$ kubectl create cm nginx-jax --from-file=./jax.conf
configmap/nginx-jax created

引用configmap

kubectl explain pod.spec.containers.env.valueFrom.configMapKeyRef

• key    引用那个confmap中的key
• name  引用那个confmap
• optional  如果没有这个key就可以忽略

apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-
  namespace: default
  labels:
    app: myapp
    tier: test
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort:
    env:
    - name: NGINX_SERVER_PORT
      valueFrom:
        configMapKeyRef:
          name: nginx-conf
          key: nginx_port
    - name: NGINX_SERVER_NAME
      valueFrom:
        configMapKeyRef:
           name: nginx-conf
           key: server_name

查看

kubectl exec -it pod-cm- -- /bin/sh
/ # printenv
MYAPP_SVC_PORT_80_TCP_ADDR=10.98.57.156
KUBERNETES_SERVICE_PORT=
MYAPP_SERVICE_PORT_HTTP=
KUBERNETES_PORT=tcp://10.96.0.1:443
MYAPP_SVC_PORT_80_TCP_PORT=
HOSTNAME=pod-cm-
SHLVL=
MYAPP_SVC_PORT_80_TCP_PROTO=tcp
HOME=/root
MYAPP_SERVICE_HOST=10.100.51.12
NGINX_SERVER_PORT=
NGINX_SERVER_NAME=myapp.jaxzhai.com
.....

存储卷挂载的方式

apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-
  namespace: default
  labels:
    app: myapp
    tier: test
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort:
    volumeMounts:
    - name: nginxconfig
      mountPath: /etc/nginx/config.d/
      readOnly: true
  volumes:
  - name: nginxconfig
    configMap:
      name: nginx-conf

Secret

Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。

Secret有三种类型：

• Service Account ：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
• Opaque ：base64编码格式的Secret，用来存储密码、密钥等；
• kubernetes.io/dockerconfigjson ：用来存储私有docker registry的认证信息。

创建密钥有三种方式：

• docker-registry：创建仓库登录密钥
• generic： 通用的创建方式
• tls： 创建加密证书的方式

创建一个通用类型密钥

用法：
kubectl create secret generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run]
创建一个mysql的root密码：
$ kubectl create secret generic mysql-root-password --from-literal=password=
secret/mysql-root-password created
查看
$ kubectl get secret
NAME                         TYPE                                  DATA     AGE
mysql-root-password   Opaque                                         30s
$ kubectl describe secret mysql-root-password
Name:         mysql-root-password
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:   bytes   #我们看到这里只显示6个字节

怎样解密
首先获得解密信息
$ kubectl get secret mysql-root-password -o yaml
apiVersion: v1
data:
  password: MTIzNDU2
kind: Secret
metadata:
  creationTimestamp: --29T09::02Z
  name: mysql-root-password
  namespace: default
  resourceVersion: ""
  selfLink: /api/v1/namespaces/default/secrets/mysql-root-password
  uid: ffccb84d-db59-11e8-b8c9-
type: Opaque

通过base64解码
$ echo MTIzNDU2 | base64 -d