Kubernetes 中的动态供应和存储类

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

新增功能

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

尽管该功能的 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 并且用户创建没有 storage-class 注释的 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 获取最新更新

• ←上一页
下一页→