pod调度原理,pod调度使用法则

导读：在《一文读懂 K8s 持久化存储流程》一文我们重点介绍了 K8s 内部的存储流程，以及 PV、PVC、StorageClass、Kubelet 等之间的调用关系。接下来本文将将重点放在 CSI（Container Storage Interface）容器存储接口上，探究什么是 CSI 及其内部工作原理。

K8s 原生支持一些存储类型的 PV，如 iSCSI、NFS、CephFS 等等（详见链接），这些 in-tree 类型的存储代码放在 Kubernetes 代码仓库中。这里带来的问题是 K8s 代码与三方存储厂商的代码强耦合：

• 更改 in-tree 类型的存储代码，用户必须更新 K8s 组件，成本较高
• in-tree 存储代码中的 bug 会引发 K8s 组件不稳定
• K8s 社区需要负责维护及测试 in-tree 类型的存储功能
• in-tree 存储插件享有与 K8s 核心组件同等的特权，存在安全隐患
• 三方存储开发者必须遵循 K8s 社区的规则开发 in-tree 类型存储代码

CSI 容器存储接口标准的出现解决了上述问题，将三方存储代码与 K8s 代码解耦，使得三方存储厂商研发人员只需实现 CSI 接口（无需关注容器平台是 K8s 还是 Swarm 等）。

在详细介绍 CSI 组件及其接口之前，我们先对 K8s 中 CSI 存储流程进行一个介绍。《一文读懂 K8s 持久化存储流程》一文介绍了 K8s 中的 Pod 在挂载存储卷时需经历三个的阶段：Provision/Delete（创盘/删盘）、Attach/Detach（挂接/摘除）和 Mount/Unmount（挂载/卸载），下面以图文的方式讲解 K8s 在这三个阶段使用 CSI 的流程。

1. Provisioning Volumes

1.集群管理员创建 StorageClass 资源，该 StorageClass 中包含 CSI 插件名称（provisioner:pangu.csi.alibabacloud.com）以及存储类必须的参数（parameters: type=cloud_ssd）。sc.yaml 文件如下：

2.用户创建 PersistentVolumeClaim 资源，PVC 指定存储大小及 StorageClass（如上）。pvc.yaml 文件如下：