1、Pod Volumes

场景
- 同一个pod中的某个容器异常退出，kubelet重新拉起来，保证容器之前产生数据没丢
- 同一个pod的多个容器共享数据
常见类型
- 本地存储，常用的有 emptydir/hostpath；
- 网络存储：网络存储当前的实现方式有两种，一种是 in-tree，它的实现的代码是放在 K8s 代码仓库中的，随着k8s对存储类型支持的增多，这种方式会给k8s本身的维护和发展带来很大的负担；而第二种实现方式是 out-of-tree，它的实现其实是给 K8s 本身解耦的，通过抽象接口将不同存储的driver实现从k8s代码仓库中剥离，因此out-of-tree 是后面社区主推的一种实现网络存储插件的方式；
- Projected Volumes：它其实是将一些配置信息，如 secret/configmap 用卷的形式挂载在容器中，让容器中的程序可以通过POSIX接口来访问配置数据；
使用举例
在多个容器共享同一个卷的时候，为了隔离数据，通过 subPath 来完成这个操作。它会在卷里面建立两个子目录，容器 1 往 cache 下面写的数据其实都写在子目录 cache1 了，容器 2 往 cache 写的目录，其数据最终会落在这个卷里子目录下面的 cache2 下。
readOnly 的意思其实就是只读挂载
emptyDir 其实是在 pod 创建的过程中会临时创建的一个目录，这个目录随着 pod 删除也会被删除，里面的数据会被清空掉；
hostPath 是宿主机上的一个路径，在 pod 删除之后，这个目录还是存在的，它的数据也不会被丢失。

2、Persistent Volumes

存储和计算分离，解耦合pod和volume之间的生命周期的关联
yaml文件
- Capacity：存储对象的大小；
- AccessModes：使用这个 PV 的方式。它有三种使用方式。
  - ReadWriteOnce 单 node 读写访问；
  - ReadOnlyMany 多个 node 只读访问，是常见的一种数据的共享方式；
  - ReadWriteMany 多个 node 上读写访问。
- ReclaimPolicy：
  - delete，也就是说 PVC 被删除之后，PV 也会被删除；
  - Retain，就是保留，后面这个 PV 需要管理员来手动处理。
- StorageClassName：动态 Provisioning 时必须指定的一个字段，指定到底用哪一个模板文件来生成 PV ；
- NodeAffinity：能被哪些 node 去挂载使用pod 必须要调度到这些能访问 PV 的 node 上，才能使用这块 PV，之后存储拓扑调度会细讲。

3、Persistent Volume Claim

特点
- PVC是面向对象编程中抽象出来的接口，PV是接口对应的实现
- 通过kube-controller-manager中的PersistentVolumeController将PVC和PV绑定到一起
- PVC中声明需要存储的size、access mode（单node还是多node，只读还是可读可写）等
- 更容易控制安全访问策略
如何匹配PV：用户在提交 PVC 的时候，最重要的两个字段 —— Capacity 和 AccessModes。在提交 PVC 后，k8s 集群中的相关组件是如何去找到合适的 PV 呢？首先它是通过为 PV 建立的 AccessModes 索引找到所有能够满足用户的 PVC 里面的 AccessModes 要求的 PV list，然后根据PVC的 Capacity，StorageClassName, Label Selector 进一步筛选 PV，如果满足条件的 PV 有多个，选择 PV 的 size 最小的，accessmodes 列表最短的 PV，也即最小适合原则。

4、volume Provisioning

static volume Provisioning

概念：先预分配一些存储，即预先创建一些 PV；然后用户提交自己的存储需求（也就是 PVC），k8s 内部相关组件会将 PVC 和 PV 做绑定；之后用户再通过 pod 去使用存储，可通过 PVC 找到相应的 PV。
使用举例
- 创建PV
- 创建PVC
- 各方面符合要求的PVC才能和PV进行绑定（accessModes、storageClassName、volumeMode相同，storage可以比PV小）

dynamic volume provisioning

概念:K8s 集群中的管控组件，会结合 PVC 和 StorageClass 的信息动态，生成用户所需要的存储（PV），将 PVC 和 PV 进行绑定后，pod 就可以使用 PV 了。通过 StorageClass 配置生成存储所需要的存储模板，再结合用户的需求动态创建 PV 对象，做到按需分配。
StorageClass:提供了一种描述存储“类”的方法，满足用户不同的服务质量级别、备份策略等
- 主要包含三个字段：Provisioner、parameters、reclaimpolicy
  - Provisioner：指定配置PV的卷的类型
使用方法
- 创建PV的模板StorageClass
- 创建PVC文件，增加一个字段StorageClassName
- Pod使用该PVC，通过persistentVolumeClaim.claimName

PV的状态流转
在这里插入图片描述

当用户在使用完 PVC，将其删除后，这个 PV 就处在 released 状态
当 PV 已经处在 released 状态下，它是没有办法直接回到 available 状态，无法被一个新的 PVC 去做绑定。解决方案：
- 举例：K8s中的 StatefulSet 管理的 Pod 带存储的迁移。原理：在删除 pod 之后，不要去删除 PVC 对象，这样给 PV 绑定的 PVC 还是存在的，下次 pod 使用的时候，就可以直接通过 PVC 去复用。
- 新建一个 PV 对象，之前的 released 的 PV 的相关字段的信息填到新的 PV 对象里面，这样的话，这个 PV 就可以结合新的 PVC 了。

5、架构设计

csi ：container storage interface，两部分组成
- k8s社区实现：csi-provisioner 和csi-attacher controller
- 云存储厂商实现：对接云存储厂商的 OpenApi，主要是实现真正的 create/delete/mount/unmount 存储的相关操作，csi-controller-server和csi-node-server。
Pod使用PV：
- 用户在提交 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。
通过csi使用存储的主要流程
第一个阶段(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 上面；
第三个阶段（mount阶段）：第三个阶段发生在kubelet 创建 pod的过程中，它在创建 pod 的过程中，首先要去做一个 mount，这里的 mount 操作是为了将已经attach到这个 node 上面那块盘，进一步 mount 到 pod 可以使用的一个具体路径，之后 kubelet 才开始创建并启动容器。

6、应用存储和持久化数据卷：存储快照和拓扑调度

存储快照

k8s通过csi snapshotter controller实现存储快照
流程：用户通过volumesnapshot对象来声明，指定volumesnapshotclass对象，然后集群中的controller生产volumesnapshotcontent

利用存储快照恢复数据

通过yaml文件，将.spec.dataSource指定为VolumeSnapshot对象，然后根据pvc生成pv，数据通过volumesnapshotcontent恢复。

拓扑

基本概念：管理的nodes划分的一种位置关系
- region：标记nodes属于哪个地区
- zone：available zone，标识跨zone的nodes属于哪个可用区
- hostname：单机维度

存储拓扑调度

k8s创建pod的流程和创建pv的流程，并行独立
- 需要保障pod最后运行的node，可以访问到存储
解决方案
- pod调度结果出来后，根据pod的拓扑动态创建pv
- kube-scheduler为pod选择node节点时，需要考虑pv的nodeAffinity

具体例子1

当用户开始提交 PVC 的时候，pv controller 在看到这个 pvc 的时候，它会找到相应的 storageClass，发现这个 BindingMode 是延迟绑定，它就不会做任何事情。
之后当真正使用这个 pvc 的 pod，在调度的时候，当它恰好调度在符合 pv nodeaffinity 的 node 的上面后，这个 pod 里面所使用的 PVC 才会真正地与 PV 做绑定，这样就保证我 pod 调度到这台 node 上之后，这个 PVC 才与这个 PV 绑定，最终保证的是创建出来的 pod 能访问这块 Local PV

具体例子2