k8s之存储

1、引入卷

需要使用到卷 [Volumes] 两个场景：

• 场景一：如果 pod 中的某一个容器在运行时异常退出，被 kubelet 重新拉起之后，如何保证之前容器产生的重要数据没有丢失？
• 场景二：如果同一个 pod 中的多个容器想要共享数据，应该如何去做？

我们知道默认情况下容器的数据都是非持久化的，在容器消亡以后数据也跟着丢失，所以 Docker 提供了 Volume 机制以便将数据持久化存储。类似的，Kubernetes 提供了更强大的 Volume 机制和丰富的插件，解决了容器数据持久化和容器间共享数据的问题。

与 Docker 不同，Kubernetes Volume 的生命周期与 Pod 绑定：

• 容器挂掉后 Kubelet 再次重启容器时，Volume 的数据依然还在
• 而 Pod 删除时，Volume 才会清理。数据是否丢失取决于具体的 Volume 类型，比如 emptyDir 的数据会丢失，而 PV 的数据则不会丢。

Volume 类型

Kubernetes 支持的 Volume 类型众多，举例如下：
1、本地存储，常用的有 emptydir/hostpath；
2、网络存储：网络存储当前的实现方式有两种，一种是 in-tree，它的实现的代码是放在 K8s 代码仓库中的，随着k8s对存储类型支持的增多，这种方式会给k8s本身的维护和发展带来很大的负担；而第二种实现方式是 out-of-tree，它的实现其实是给 K8s 本身解耦的，通过抽象接口将不同存储的driver实现从k8s代码仓库中剥离，因此out-of-tree 是后面社区主推的一种实现网络存储插件的方式；
3、Projected Volumes：它其实是将一些配置信息，如 secret/configmap 用卷的形式挂载在容器中，让容器中的程序可以通过POSIX接口来访问配置数据；

• emptyDir

如果 Pod 设置了 emptyDir 类型 Volume， Pod 被分配到 Node 上时候，会创建 emptyDir，只要 Pod 运行在 Node 上，emptyDir 都会存在（容器挂掉不会导致emptyDir 丢失数据），但是如果 Pod 从 Node 上被删除（Pod 被删除，或者 Pod 发生迁移），emptyDir 也会被删除，并且永久丢失。

• hostPath

hostPath 允许挂载 Node 上的文件系统到 Pod 里面去。如果 Pod 需要使用 Node 上的文件，可以使用 hostPath。 比如：

apiVersion: v1 
kind: Pod 
metadata: 
  name: test-pd 
spec: 
  containers: 
  - image: gcr.io/google_containers/test-webserver 
    name: test-container 
    volumeMounts: 
    - mountPath: /test-pd 
      name: test-volume 
  volumes: 
  - name: test-volume 
    hostPath: 
    path: /data 

• NFS

NFS 是 Network File System 的缩写，即网络文件系统。Kubernetes 中通过简单地配置 就可以挂载 NFS 到 Pod 中，而 NFS 中的数据是可以永久保存的，同时 NFS 支持同时 写操作。

• gcePersistentDisk

gcePersistentDisk 可以挂载 GCE 上的永久磁盘到容器，需要 Kubernetes 运行在 GCE 的 VM 中。

• awsElasticBlockStore

awsElasticBlockStore 可以挂载 AWS 上的 EBS 盘到容器，需要 Kubernetes 运行在 AWS 的 EC2 上。

• gitRepo

gitRepo volume 将 git 代码下拉到指定的容器路径中。

• subPath

Pod 的多个容器使用同一个 Volume 时，subPath 非常有用。

• Projected Volume

Projected volume 将多个 Volume 源映射到同一个目录中，支持 secret、downwardAPI 和 configMap。

2、引入PV

需要使用到PV的四个场景：

• 场景一：pod 重建销毁，如用 Deployment 管理的 pod，在做镜像升级的过程中，会产生新的 pod并且删除旧的 pod ，那新旧 pod 之间如何复用数据？
• 场景二：宿主机宕机的时候，要把上面的 pod 迁移，这个时候 StatefulSet 管理的 pod，其实已经实现了带卷迁移的语义。这时通过 Pod Volumes 显然是做不到的；
• 场景三：多个 pod 之间，如果想要共享数据，应该如何去声明呢？我们知道，同一个 pod 中多个容器想共享数据，可以借助 Pod Volumes 来解决；当多个 pod 想共享数据时，Pod Volumes 就很难去表达这种语义；
• 场景四：如果要想对数据卷做一些功能扩展性，如：snapshot、resize 这些功能，又应该如何去做呢？

以上场景中，通过 Pod Volumes 很难准确地表达它的复用/共享语义，对它的扩展也比较困难。因此 K8s 中又引入了 Persistent Volumes 概念，它可以将存储和计算分离，通过不同的组件来管理存储资源和计算资源，然后解耦 pod 和 Volume 之间生命周期的关联。这样，当把 pod 删除之后，它使用的PV仍然存在，还可以被新建的 pod 复用。

PV状态流转

3、引入PVC

用户在使用 PV 时其实是通过 PVC，为什么有了 PV 又设计了 PVC 呢？主要原因是为了简化K8s用户对存储的使用方式，做到职责分离。通常用户在使用存储的时候，只用声明所需的存储大小以及访问模式。

访问模式是什么？其实就是：我要使用的存储是可以被多个node共享还是只能单node独占访问(注意是node level而不是pod level)？只读还是读写访问？用户只用关心这些东西，与存储相关的实现细节是不需要关心的。

通过 PVC 和 PV 的概念，将用户需求和实现细节解耦开，用户只用通过 PVC 声明自己的存储需求。PV是有集群管理员和存储相关团队来统一运维和管控，这样的话，就简化了用户使用存储的方式。可以看到，PV 和 PVC 的设计其实有点像面向对象的接口与实现的关系。用户在使用功能时，只需关心用户接口，不需关心它内部复杂的实现细节。

Static Volume Provisioning

静态 Provisioning：由集群管理员事先去规划这个集群中的用户会怎样使用存储，它会先预分配一些存储，也就是预先创建一些 PV；然后用户在提交自己的存储需求（也就是 PVC）的时候，K8s 内部相关组件会帮助它把 PVC 和 PV 做绑定；之后用户再通过 pod 去使用存储的时候，就可以通过 PVC 找到相应的 PV，它就可以使用了。

静态供给方式的缺点：首先需要集群管理员预分配，预分配其实是很难预测用户真实需求的。举一个最简单的例子：如果用户需要的是 20G，然而集群管理员在分配的时候可能有 80G 、100G 的，但没有 20G 的，这样就很难满足用户的真实需求，也会造成资源浪费。有没有更好的方式呢？

Dynamic Volume Provisioning

动态Provisioning就是说现在集群管理员不预分配 PV，只写一个模板文件，这个模板文件是用来表示创建某一类型存储（块存储，文件存储等）所需的一些参数，这些参数是用户不关心的，给存储本身实现有关的参数。用户只需要提交自身的存储需求，也就是PVC文件，并在 PVC 中指定使用的存储模板（StorageClass）。

K8s 集群中的管控组件，会结合 PVC 和 StorageClass 的信息动态，生成用户所需要的存储（PV），将 PVC 和 PV 进行绑定后，pod 就可以使用 PV 了。通过 StorageClass 配置生成存储所需要的存储模板，再结合用户的需求动态创建 PV 对象，做到按需分配，在没有增加用户使用难度的同时也解放了集群管理员的运维工作。

4、PV+PVC体系流程

K8s 中的 PV 和 PVC 体系的完整处理流程：

图中右下部分里面提到的 csi 全称是 container storage interface，它是K8s社区后面对存储插件实现(out of tree)的官方推荐方式。csi 的实现大体可以分为两部分：

• 第一部分是由k8s社区驱动实现的通用的部分，像我们这张图中的 csi-provisioner和 csi-attacher controller；
• 另外一种是由云存储厂商实践的，对接云存储厂商的 OpenApi，主要是实现真正的 create/delete/mount/unmount 存储的相关操作，对应到上图中的csi-controller-server和csi-node-server。

• 用户在提交 PVC的yaml 的时候，首先会在集群中生成一个 PVC 对象，然后 PVC 对象会被 csi-provisioner controller watch到，csi-provisioner 会结合 PVC 对象以及 PVC 对象中声明的 storageClass，通过 GRPC 调用 csi-controller-server，然后，到云存储服务这边去创建真正的存储，并最终创建出来 PV 对象。最后，由集群中的 PV controller 将 PVC 和 PV 对象做 bound 之后，这个 PV 就可以被使用了。
• 用户在提交 pod 之后，首先会被调度器调度选中某一个合适的node，之后该 node 上面的 kubelet 在创建 pod 流程中会通过首先 csi-node-server 将我们之前创建的 PV 挂载到我们 pod 可以使用的路径，然后 kubelet 开始 create && start pod 中的所有 container。

主要分为三个阶段：

• 第一个阶段(Create阶段)是用户提交完 PVC，由 csi-provisioner 创建存储，并生成 PV 对象，之后 PV controller 将 PVC 及生成的 PV 对象做 bound，bound 之后，create 阶段就完成了；
• 第二个阶段（attach阶段），用户在提交 pod yaml 的时候，首先会被调度选中某一个 合适的node，等 pod 的运行 node 被选出来之后，会被 AD Controller watch 到 pod 选中的 node，它会去查找 pod 中使用了哪些 PV。然后它会生成一个内部的对象叫 VolumeAttachment 对象，从而去触发 csi-attacher去调用csi-controller-server 去做真正的 attache 操作，attach操作调到云存储厂商OpenAPI。这个 attach 操作就是将存储 attach到 pod 将会运行的 node 上面。第二个阶段 —— attach阶段完成；
• 第三个阶段（mount 阶段）发生在kubelet 创建 pod的过程中，它在创建 pod 的过程中，首先要去做一个 mount，这里的 mount 操作是为了将已经attach到这个 node 上面那块盘，进一步 mount 到 pod 可以使用的一个具体路径，之后 kubelet 才开始创建并启动容器。

本地存储限额

v1.7 + 支持对基于本地存储（如 hostPath, emptyDir, gitRepo 等）的容量进行调度限额，可以通过 --feature-gates=LocalStorageCapacityIsolation=true 来开启这个特性。

Kubernetes 根据 storage.kubernetes.io/scratch 的大小来调度本地存储空间，而根据 storage.kubernetes.io/overlay 来调度容器的存储。比如：

apiVersion: v1 
kind: Pod 
metadata: 
  name: ls1 
spec: 
  restartPolicy: Never 
  containers: 
  - name: hello 
    image: busybox 
    command: ["df"] 
    resources: 
      requests: 
        storage.kubernetes.io/overlay: 64Mi   # 为容器请求 64MB 的可写层存储空间。
---
apiVersion: v1 
kind: Pod 
metadata: 
  name: ls2
spec: 
  restartPolicy: Never 
  containers: 
  - name: hello 
    image: busybox 
    command: ["df"] 
    volumeMounts: 
    - name: data 
      mountPath: /data 
  volumes: 
  - name: data 
    emptyDir: 
       sizeLimit: 64Mi       #  为 empty 请求 64MB 的存储空间

Mount 传递

在 Kubernetes 中，Volume Mount 默认是 私有的，但从 v1.8 开始，Kubernetes 支持配置 Mount 传递（mountPropagation）。它支持两种选项：

• HostToContainer：这是开启 MountPropagation=true 时的默认模式，等效于rslave 模式，即容器可以看到 Host 上面在该 volume 内的任何新 Mount 操作。

• Bidirectional：等效于 rshared 模式，即 Host 和容器都可以看到对方在该Volume 内的任何新 Mount 操作。该模式要求容器必须运行在特权模式（即securityContext.privileged=true ）

注意：

使用 Mount 传递需要开启 --feature-gates=MountPropagation=true

挂载传播

挂载传播（MountPropagation）是 v1.9 引入的新功能，并在 v1.10 中升级为 Beta 版 本。挂载传播用来解决同一个 Volume 在不同的容器甚至是 Pod 之间挂载的问题。通过 设置Container.volumeMounts.mountPropagation，可以为该存储卷设置不同的传播类型。

支持三种选项：

• None：即私有挂载（private）

• HostToContainer：即 Host 内在该目录中的新挂载都可以在容器中看到，等价于Linux 内核的 rslave。

• Bidirectional：即 Host 内在该目录中的新挂载都可以在容器中看到，同样容器内在该目录中的任何新挂载也都可以在 Host 中看到，等价于 Linux 内核的 rshared。仅特权容器（privileged）可以使用 Bidirectional 类型。

• 该模式要求容器必须运行在特权模式（即securityContext.privileged=true）

注意：

• 使用前需要开启 MountPropagation 特性。

• 如未设置，则 v1.9 和 v1.10 中默认为私有挂载（ None ），而 v1.11 中默认为HostToContainer。

• Docker 服务的 systemd 配置文件中需要设置 MountFlags=shared。