开发者学堂课程【企业级运维之云原生与 Kubernets 实战课程：Kubernetes 存储 】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/913/detail/14599
Kubernetes 存储
摘要：本小节主要内容为存储卷介绍，包括：Persistent Volumes(PV)、Persistent VolumesClaim(PVC) 的特点及使用。
目录
Ÿ Volume 存储卷介绍
Ÿ Persistent Volumes (PV)
Ÿ Persistent VolumesClaim (PVC)
一、Volume 存储卷介绍
1. 什么是存储卷
K8s 容器运行时，在没有做日志持久化的情况下，容器重启后导致日志丢失，这时就需要一个中间设备，既可以被 Pod 调用将日志输出，又可以被分析应用读取（如 Grafana、Elastic ）进行相关分析，这个中间设备就是存储卷。
2. 存储卷类型
a. 本地存储 /hostpath
Ÿ Emptydir：当 Pod 被分配给节点时，先创建 emptyDir 卷，并且只要该 Pod 在该节点上运行，该卷就会存在，它最初是空的，Pod 中的容器可以读取和写入emptyDir 卷中的相同文件，该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir 中的数据将被永久删除。如果 Pod发生重启，而 emptydir 使用了 medium (内存)模式，则有可能没有被删除。
Ÿ Hostpath：将宿主机上的目录挂载到 Pod 上，实现容器与宿主机的共享。
b. 网络存储
云厂商阿里、aws、google 会提供类似云盘、OSS、NAS 等的网络存储。
c. Projected Volume
Ÿ ConfigMap
ž ConfigMap 提供了向 Pod 注入数据的方法，以键值对方式存储在 K8s 系统中；
ž 两种使用方式：环境变量引用、数据卷的方式挂载；
ž 可以定义一个 Pod，以环境变量的形式进行使用，引用 configmap 或者通过挂载数据卷的方式，定义 Volume 类型为 configmap ，再去引用 configmap 信息，数据卷的方式挂载是以文件的方式挂载到容器的定义的路径下；
ž 两种方式区别：configmap 热更新时如果使用环境变量方式，需要手动方式更新环境变量，Pod 所引用的 configmap 才会生效；而使用数据卷挂载方式，更新configmap 时 Pod 所引用的 configmap 会生效（有 10 秒到 1 分钟的延迟）。
Ÿ Secret
Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。Secret 有几种类型：
ž Opaque：base64 编码格式的 Secret，用来存储密码、密钥等，相当来说不安全；
ž SA（ServiceAccout）：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的特点目录中。每个 Pod 都有 SA ，路径 /run/secrets/kubernets.io/serviceaccount，包含了公钥、namespace、token；
ž 其他：像 tls 客户端或服务端进行数据加密，ssh 的身份认证 secret ；用于储存镜像仓库的认证信息的 dockerconfigjson ，在镜像拉取时，可以通过引用的方式使用。
d. PVC 与 PV 体系
二、Persistent Volumes(PV)
1. Pod 中声明的 volume 的生命周期与 Pod 相同，常见场景：
a. Pod销毁重建(如 Deployment 管理的 Pod 镜像升级)；
b. 宿主机故障迁移(如 StatefulSet 管理的 Pod 带远程 volume 迁移)；
c. 多 Pod 共享同一个数据 volume；
d. 数据 volume snapshot，resize 等功能的扩展实现；
2. PV 的不足之处
使用 Pod Volumes 无法准确表达数据 volume 复用/共享语义，新功能扩展很难实现。
3. PV 的优化
如果能将存储与计算分离，使用不同的组件( Controllers )管理存储与计算资源，解耦 PodVolume 的生命周期关联，可以很好解决这些场景下的问题。
PV(Persistent Volumes) 定义一种存储资源类似 CPU 和 Memory，类型可以为云盘、NAS 可以是只读（RO）、可读可写（RW）等。
三、Persistent VolumesClaim(PVC)
1. PVC 是什么
存储对于上层应用 Pod 而言，并不关心底层存储是通过哪种方式创建，而是注重存储大小、挂载的方式，这时需要定义存储格式、类型，由定义去找符合条件的存储，于是 PVC 就产生了。
2. 有了 PV，为什么又设计了 PVC
Ÿ 职责分离，PVC 中只用声明自己需要的存储 size、access mode（单 node 独占还是多 node 共享、只读还是读写访问)等业务真正关心的存储需求(不用关心存储实现细节)，PV 和其对应的后端存储信息则由交给 cluster admin 统一运维和管控，安全访问策略更容易控制。
Ÿ PVC 简化了 User 对存储的需求，PV 才是存储的实际信息的承载体，通过 kube-controller-manager 中的 PersisentVolumeController 将 PVC 与合适的 PV bound到一起，从而满足 User 对存储的实际需求。
Ÿ PVC 像是面向对象编程中抽象出来的接口，PV 是接口对应的实现。
3. Static Volume Provisioning
Static Volume Provisioning 表示已在集群中创建完成存储资源，在 Pod 指定时，同时通过 PVC 进行分配挂载存储卷。
Static Volume Provisioning 的不足：
Cluster Admin 需要提前规化或预测存储需求，而 User 的需求是多样化的，很容易导致 User 提交的 PVC 找不到合适的 PV。
更好的方式：
Cluster Admin 只创建不同类型存储的模板，User 在 PVC 中指定使用哪种存储模板以及自己需要的大小、访问方式等参数，然后 K8s 自动生成相应的 PV 对象。
4. Dynamic Volume Provisioning
集群没有提供可用 PV，通过 PVC 的 Storage Class 创建所需要的 PV，然后挂载到 Pod 上。这就是声明定义创建 PV，而不需要关注创建的细节，K8s 则会结合 PVC 和 SC 两者的信息动态创建 PV 对象。
5. 静态使用 PV、PVC（以云盘为例）
Ÿ 编写 yaml 创建一个 PV，定义 PV 名字、大小等信息（可以使用命令 kubectl get pv 查看）；
Ÿ 编写 PVC 的 yaml 文件，定义 PVC 名称、PVC 接入方式、需要 PV 的大小，然后创建 PVC 后会自动绑定上面创建的 PV；
5. 动态使用 PV、PVC
动态 PV、PVC 不需要定义 PV 资源，只需要在 Storage Class（可以认为是存储插件进行调用资源）的 yaml 中定义名称、调用的存储插件、文件的形式、是否加密、回收模式等信息，然后创建 Storage Class，再创建 statefulset 类型的 Pod 与之关联；
statefulset 创建多个副本数是有序的，首先创建完成一个 Pod 副本后才会创建下一个，且副本名字无论是删除或重拉后都是不变的，挂载的存储会重新挂载到新拉起的 Pod 上。
假如 statefulset 创建了三个 Pod ，进行更新为 2 个副本后，删除的副本一定是最后创建的那个副本。
statefulset 特点：
Ÿ Pod 名称是 statefulset- 序号
Ÿ 有序部署
Ÿ 有序删除
Ÿ 有序拓展
访问方式可以通过 Pod 的名字或 headless 名字如：
headless nginx.namespace.svc.cluster.local
web-0.nginx1.default.svc.cluster.local
statefulset 的使用场景：
Ÿ 应用需要稳定持久化存储；
Ÿ 应用是有序的，无论 Pod 发生什么变化，Pod 启动后状态是不变的；
Ÿ 应用需要稳定的网络标识。
