【K8S】整体原理-K8S的存储

存储设计理念

K8S存储设计理念就是将所有的存储资源统一封装起来，比如用到的NAS，或者物理机本地磁盘，或者是云厂商的对象存储。K8S就是把他们整合起来，抽象出存储卷的（Volume）的逻辑，容器挂载他们就可以直接使用存储空间。跟Docker里的挂载文件相似，Volume独立于Pod与Pod具有相同生命周期的对象。

Volume来源

1.以Volume形式挂载到容器的对象包括：

• ConfigMap：明文配置文件

• Secrett：密文配置文件

• Downward API：将Pod 容器 的元数据信息以文件形式挂载到容器中使用

• Projected Volume：用于解决将多个资源挂载到同一目录的问题

volumes:
- name: all-in-one
  projected:  #多个资源挂载到同一目录的问题，例子为 downwardAPI和 configMap一同挂载同一个目录
    sources:
    - secret:
      name: mysecret
      items:
        - key: username
          path: group/username
    - downwardAPI:
      items:
        - path: "labels"
        fieldRef:
          fieldPath: metadata.labels
    - configMap:
      name: mycm
      items:
        - key: config
          path: group/config

• ServiceAccountToken：就是serviceaccount的Token数据

  这是应用在调用API-Sever所要用到的Token，在K8S认证的部分，会先创建一个ServiceAccount这样的对象，这个对象会转化成Token的文件挂载到容器里。这样当容器想跟API-Server通信的时候，API-Server就能分辨出跟他（API-Server）通信的是谁（哪个容器）了

2.宿主机本地存储类型

• emptyDir： 临时存储，由pause容器创建的临时空间，生命周期和Pod相同（类似电脑里常见的/temp目录，说不定什么时候就消失，一般是同生共死）；可以通过medium=Memory设置为使用内存（相当于把文件放到内存里，这样读取会更快）

• hostPath： 持久化存储，挂在宿主机上的文件和目录，可以用于持久化存储数据（不推荐把Pod持久化到宿主机上，风险是会随Pod调度变换主机，因为Pod可能会被调度，漂移），可以用于访问宿主机的Docker引擎，监控系统

3.持久存储PV和网络存储

PV ，PVC ，StorageClass （一般用不到）

PV是K8S中对存储资源的抽象，是容器可以使用的资源，为了动态根据用户需求创建PV，系统管理员会先定义好创建的PV的模板StorageClass，用户在使用时只需要引用相应的模板并写出所用存储的大小，读取权限等即可，这些信息记录在PVC中，存储插件控制器会根据StorageClass和PVC中其他信息自动创建。

传统PV-PVC创建过程：

第一步，管理员创建PV，第二步，用户创建PVC和PV绑定，然后PVC就可以正常使用了。

但是随着业务发展，管理员和用户不断地去创建PV和PVC就会很烦，于是有了StorageClass。

Storage创建过程：

比如现在买了一个88T的硬盘，就要创建一个StorageClass对象，部门里的张三想用5个G（此时创建的就是PVC ，PVC会指明我要用5个G，这个PVC也会指向管理添加的88T的StorageClass，创建好之后就会有一个存储模块–【存储控制器，可能是K8S自带，也可能是公司自己写的存储模块】），这时候存储管理模块就发现了用户想要创建5个G的PVC空间，他就去找相应的StorageClass，根据PVC和StorageClass会自动的 帮用户创建一个PV，PV指向了真正的存储，之后PVC绑定PV，就完成了PVC的创建和绑定，这时候张三就可以用他的5G了。 意味着管理员一次性创建StorageClass，用户什么时候需要分配内存了，就不用再去指定和绑定PV了，全是自动化完成创建绑定。

StorageClass

本质是自动化根据PVC创建PV并绑定，配置的参数包括：

• Provisioner：存储提供者，就是例子中88T的硬盘是哪家供应商提供的

• Reclaim Policy：资源回收策略，包括Delete（默认）和Retain

• Allow Volume Expansion： 是否运行扩容（比如申请的4个G，后面要升级5G），需要Volume底层支持该功能

• Volume Binding Mode： 绑定模式，Immediate（默认）和WaitForFirstConsumer（当消费PVC的Pod创建后才会创建PV并绑定）

PV状态的流转

PV在创建开始后，处于Pending，知道创建完成后状态变为available，当PVC和PV绑定后，状态变为bound，当绑定的PVC删除后，会变成released（被释放），released后的PV无法再次和PVC绑定。

Volume Plugins

如果本身存储资源有限的话，K8S本身就支持 一种存储方式（用它自带的就行了）。

PV，PVC这种存储管理机制其实是需要将存储管理的代码放到K8S代码库里，然后与K8S一起发布管理，称为In-Tree模式，这种模式与K8S紧耦合。

其实除了K8S能提供存储方式，公司厉害也能开发出存储方式， 这就得另外一种K8S存储方式–是基于CSI标准，代码独立存在的方式（在使用的时候K8S会调用公司开发的存储控制器，开发控制器的代码和K8S相互独立），称为Out-of-Tree，似乎是趋势倾向。

存储快照

已经有一部分的数据存在了，但接下来的实验有可能会出现问题，所以就有了快照一说，可以恢复到快照的时间节点。

存储快照的设计其实是仿照PVC&PV体系的设计思想，当用户需要存储快照功能时，可以通过VolumeSnapshot对象来声明，并制定相应的VolumeSnapshotClass对象，进行一个Class指向对象的操作（VolumeSnapshotClass指向VolumeSnapshot）的操作（VolumeSnapshotClass相当于PVC，VolumeSnapshot相当于PV），之后由集群中的相关组件动态生成存储快照以及存储快照对应的对象VolumeSnapshotContent。

PVC对象将其的dataSource字段指定为VolumeSnapshot对象，这样就可以恢复数据。