Kubernetes 中的动态制备和存储类

存储是运行容器的关键部分，Kubernetes 提供了一些强大的原语来管理它。动态卷配置是 Kubernetes 独有的功能，允许按需创建存储卷。如果没有动态配置，集群管理员必须手动调用其云或存储提供商来创建新的存储卷，然后创建 PersistentVolume 对象以在 Kubernetes 中表示它们。动态配置功能消除了集群管理员预配置存储的需求。相反，它会在用户请求时自动配置存储。此功能在 Kubernetes 1.2 中作为 alpha 版本引入，并在最新版本 1.4 中得到改进并提升为 beta 版本。此版本使动态配置更加灵活和有用。

有什么新功能？

动态配置的 alpha 版本仅允许集群中同时使用一个硬编码的配置器。这意味着当 Kubernetes 确定需要动态配置存储时，它总是使用相同的卷插件进行配置，即使集群上存在多个存储系统。要使用的配置器是根据云环境推断出来的——AWS 使用 EBS，Google Cloud 使用 Persistent Disk，OpenStack 使用 Cinder，vSphere 使用 vSphere Volumes。此外，用于配置新存储卷的参数是固定的：只有存储大小可配置。这意味着所有动态配置的卷除了存储大小之外都将是相同的，即使存储系统在配置期间暴露其他参数（例如磁盘类型）以供配置。

尽管该功能的 alpha 版本实用性有限，但它让我们对这个想法进行了一些“实践”，并帮助确定了我们想要的方向。

Kubernetes 1.4 中新增的动态配置 Beta 版本引入了一个新的 API 对象，即 StorageClass。可以定义多个 StorageClass 对象，每个对象指定用于配置卷的卷插件（又称配置器）以及在配置时传递给该配置器的一组参数。这种设计允许集群管理员在集群中定义和公开多种类型的存储（来自相同或不同存储系统），每种类型都带有一组自定义参数。这种设计还确保了最终用户不必担心存储配置的复杂性和细微差别，但仍然能够从多个存储选项中进行选择。

我该如何使用它？

以下是集群管理员如何公开两个存储层以及用户如何选择和使用其中一个的示例。有关更多详细信息，请参阅参考和示例文档。

管理员配置

集群管理员定义两个 StorageClass 对象并将其部署到 Kubernetes 集群

kind: StorageClass

apiVersion: storage.k8s.io/v1beta1

metadata:

  name: slow

provisioner: kubernetes.io/gce-pd

parameters:

  type: pd-standard

这会创建一个名为“slow”的存储类，它将配置标准磁盘类别的持久磁盘。

kind: StorageClass

apiVersion: storage.k8s.io/v1beta1

metadata:

  name: fast

provisioner: kubernetes.io/gce-pd

parameters:

  type: pd-ssd

这会创建一个名为“fast”的存储类，它将配置 SSD 类别的持久磁盘。

用户请求

用户通过在其 PersistentVolumeClaim 中包含存储类来请求动态配置的存储。对于此功能的 Beta 版本，这通过 `volume.beta.kubernetes.io/storage-class` 注解完成。此注解的值必须与管理员配置的 StorageClass 名称匹配。

例如，要选择“fast”存储类，用户将创建以下 PersistentVolumeClaim

{

  "kind": "PersistentVolumeClaim",

  "apiVersion": "v1",

  "metadata": {

    "name": "claim1",

    "annotations": {

        "volume.beta.kubernetes.io/storage-class": "fast"

    }

  },

  "spec": {

    "accessModes": [

      "ReadWriteOnce"

    ],

    "resources": {

      "requests": {

        "storage": "30Gi"

      }

    }

  }

}

此声明将导致自动配置 SSD 类别的持久磁盘。当声明被删除时，卷也将被销毁。

默认行为

可以为集群启用动态配置，以便所有声明都在没有存储类注解的情况下动态配置。此行为由集群管理员通过将一个 StorageClass 对象标记为“default”来启用。通过向 StorageClass 添加 `storageclass.beta.kubernetes.io/is-default-class` 注解，可以将其标记为默认。

当存在默认 StorageClass 并且用户创建没有存储类注解的 PersistentVolumeClaim 时，新的 DefaultStorageClass 准入控制器（也在 v1.4 中引入）会自动添加指向默认存储类的类注解。

我还能使用 Alpha 版本吗？

Kubernetes 1.4 保持与动态配置功能 alpha 版本的向后兼容性，以便更平稳地过渡到 beta 版本。alpha 行为由 alpha 动态配置注解（`volume.alpha.kubernetes.io/storage-class`）的存在触发。请记住，如果存在 beta 注解（`volume.beta.kubernetes.io/storage-class`），它将优先，并触发 beta 行为。

alpha 版本的支持已被弃用，并将在未来的版本中移除。

接下来会发生什么？

动态配置和存储类将在未来的版本中继续发展和完善。以下是一些正在考虑进一步开发的领域。

标准云提供商

对于将 Kubernetes 部署到云提供商，我们正在考虑自动为云的本地存储系统创建配置器。这意味着在 AWS 上的标准部署将生成一个配置 EBS 卷的 StorageClass，在 Google Cloud 上的标准部署将生成一个配置 GCE PD 的 StorageClass。目前还在讨论这些配置器是否应该被标记为默认，这将使动态配置成为默认行为（无需注解）。

树外配置器

关于 Kubernetes 存储插件应该“在树内”还是“在树外”一直存在争论。尽管如何实现树外插件的细节仍在讨论中，但有一个提案引入了一种标准化方法来实现树外动态配置器。

我如何参与？

如果您有兴趣参与 Kubernetes 存储的设计和开发，请加入 Kubernetes 存储特别兴趣小组 (SIG)。我们正在迅速发展，并始终欢迎新的贡献者。

• 下载 Kubernetes
• 在 GitHub 上参与 Kubernetes 项目
• 在 Stack Overflow 上提问（或回答问题）
• 在 Slack 上与社区联系
• 在 Twitter 上关注我们 @Kubernetesio 获取最新更新

• ←上一篇
• 下一篇→