- 共享 Volume。目前 Pod 内的 Volume 其实跟 Pod 是存在静态的一一绑定关系，即生命周期绑定。这导致不同 Pod 之间无法共享 Volume。
- 复用 Volume 中的数据。当 Pod 由于某种原因失败，被工作负载控制器删除重新创建后，我们需要能够复用 Volume 中的旧数据。
- Volume 自身的一些强关联诉求。对于有状态工作负载 StatefulSet 来说，当其管理的 Pod 由于所在的宿主机出现一些硬件或软件问题，比如磁盘损坏、kernel 异常等，Pod 重新“长”到别的节点上，这时该如何保证 Volume 和 Pod 之间强关联的关系？
- Volume 功能及语义扩展，比如容量大小、标签信息、扩缩容等。
通过 PV，我们也可以和 Pod 自身的生命周期进行解耦。一个 PV 可以被几个 Pod 同时使用，即使 Pod 被删除后，PV 这个对象依然存在，其他新的 Pod 依然可以复用。
-
ReadOnlyMany（ ROX）表示该卷可以挂载到多个节点上，并被多个 Pod 以只读方式挂载
-
ReadWriteMany（RWX）表示卷可以被多个节点以读写方式挂载供多个 Pod 同时使用。
访问模式是什么？其实就是：我要使用的存储是可以被多个node共享还是只能单node独占访问(注意是node level而不是pod level)
默认是 Retain，即 PV 使用完后数据保留，需要由管理员手动清理数据。除了 Retain 外，还支持如下策略：
-
Recycle，即回收，这个时候会清除 PV 中的数据
-
Delete，即删除，这个策略常在云服务商的存储服务中使用到，比如 AWS EBS。
PV 一般会有如下五种状态：
-
Pending 表示目前该 PV 在后端存储系统中还没创建完成
-
Available 即闲置可用状态，这个时候还没有被绑定到任何 PVC 上
-
Bound 就像上面例子里似的，这个时候已经绑定到某个 PVC 上了
-
Released 表示已经绑定的 PVC 已经被删掉了，但资源还未被回收掉（STATUS 列显示持久卷的状态是 Released 不像之前那样是 Available 原因在于之前己经使用过这个卷，所以它可能包含前个声明人的数据，如果集群管理员还没来得及清理，那么不应该将这个卷绑定到全新的声明中。除此之外，通过使用相同的持久卷，新 pod 可以读取由前一个 pod 存放的数据，即使声明和pod 是在不同的命名 间中创建的（因此有可能属于不同的集群租户）
-
Failed 已经绑定的 PVC 已经被删掉了表示回收失败。
同样，对于 PVC 来说，也有如下三种状态：
-
Bound 表示已经和某个 PV 进行了绑定；
答：Kubernetes 支持两种资源的存储供应模式：静态模式（Static）和动态模式（Dynamic）。
静态模式：集群管理员手工创建许多 PV，在定义 PV 时需要将后端存储的特性进行设置。
动态模式：集群管理员无须手工创建 PV，而是通过 StorageClass 的设置对后端存储进行描述，标记为某种类型。此时要求 PVC 对存储的类型进行声明，系统将自动完成 PV 的创建及与 PVC 的绑定。
而这么做的好处也很明显：这个 PVC 和 PV 的绑定关系，就完全在我自己的掌控之中。
答：Kubernetes CSI 是 Kubernetes 推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用 Kubernetes 的原生存储机制为容器提供存储服务。
CSI 使得存储提供方的代码能和 Kubernetes 代码彻底解耦，部署也与 Kubernetes 核心组件分离，显然，存储插件的开发由提供方自行维护，就能为Kubernetes 用户提供更多的存储功能，也更加安全可靠。
- CSI Controller 的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。
