kubernetes 数据化持久方案

Kubernetes Volume 相关概念

​ 容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。 首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建。 其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题

​ 缺省情况下，一个运行中的容器对文件系统的写入都是发生在其分层文件系统的可写层。一旦容器运行结束，所有写入都会被丢弃。如果数据需要长期存储，那就需要对容器数据做持久化支持。

​ Kubernetes 和 Docker 类似，也是通过 Volume 的方式提供对存储的支持。Volume 被定义在 Pod 上，可以被 Pod 里的多个容器挂载到相同或不同的路径下。Kubernetes 中 Volume 的 概念与Docker 中的 Volume 类似，但不完全相同。具体区别如下：

• Kubernetes 中的 Volume 与 Pod 的生命周期相同，但与容器的生命周期不相关。当容器终止或重启时，Volume 中的数据也不会丢失。
• 当 Pod 被删除时，Volume 才会被清理。并且数据是否丢失取决于 Volume 的具体类型，比如：emptyDir 类型的 Volume 数据会丢失，而 PV 类型的数据则不会丢失。

Volume 的类型

​ Volume 的核心是目录，可以通过 Pod 中的容器来访问。该目录是如何形成的、支持该目录的介质以及其内容取决于所使用的特定卷类型。要使用 Volume，需要为 Pod 指定为 Volume(spec.volumes 字段) 以及将它挂载到容器的位置 (spec.containers.volumeMounts 字段)。Kubernetes 支持多种类型的卷，一个 Pod 可以同时使用多种类型的 Volume。

​ **注意：**容器中的进程看到的是由其 Docker 镜像和 Volume 组成的文件系统视图。 Docker 镜像位于文件系统层次结构的根目录，任何 Volume 都被挂载在镜像的指定路径中。Volume 无法挂载到其他 Volume 上或与其他 Volume 的硬连接。Pod 中的每个容器都必须独立指定每个 Volume 的挂载位置。

Kubernetes 支持下列类型的卷：

• awsElasticBlockStore
• azureDisk
• azureFile
• cephfs
• cinder
• configMap
• csi
• downwardAPI
• emptyDir
• fc (fibre channel)
• flexVolume
• flocker
• gcePersistentDisk
• gitRepo (deprecated)
• glusterfs
• hostPath
• iscsi
• local
• nfs
• persistentVolumeClaim
• projected
• portworxVolume
• quobyte
• rbd
• scaleIO
• secret
• storageos
• vsphereVolume

注意⚠️：这些 Volume 并非全部都是持久化的，比如: emptyDir、secret、gitRepo 等，就会随着 Pod 的消亡而消失。

kubernetes 常用持久化存储方式

kubernetes 非持久化存储方式

emptryDir

​ emptryDir，顾名思义是一个空目录，它的生命周期和所属的 Pod 是完全一致的。emptyDir 类型的 Volume 在 Pod 分配到 Node 上时会被创建，Kubernetes 会在 Node 上自动分配一个目录，因此无需指定 Node 宿主机上对应的目录文件。这个目录的初始内容为空，当 Pod 从 Node 上移除（Pod 被删除或者 Pod 发生迁移）时，emptyDir 中的数据会被永久删除。

​ emptyDir Volume 主要用于某些应用程序无需永久保存的临时目录，在多个容器之间共享数据等。缺省情况下，emptryDir 是使用主机磁盘进行存储的。你也可以使用其它介质作为存储，比如：网络存储、内存等。设置 emptyDir.medium 字段的值为 Memory 就可以使用内存进行存储，使用内存做为存储可以提高整体速度，但是要注意一旦机器重启，内容就会被清空，并且也会受到容器内存的限制。

apiVersion: v1
kind: Pod
metadata:
  name: pods
spec:
  containers:
  - image: gcr.io/