Kubernetes 群集的存储选项

本文比较 Amazon Elastic Kubernetes 服务（EKS）和 Azure Kubernetes 服务（AKS）的存储功能。 它还介绍了 AKS 上的工作负荷数据的存储选项。

注意

本文是一系列文章的一部分，可帮助熟悉 Amazon EKS 的专业人员了解 Azure Kubernetes 服务（AKS）。

Amazon EKS 存储选项

Amazon EKS 为需要数据存储的应用程序提供不同类型的存储卷。 可以将这些卷用于临时和持久存储。

临时卷

对于需要临时本地卷但不需要在重启后保留数据的应用程序，请使用临时卷。 Kubernetes 支持不同类型的临时卷，例如 emptyDir、ConfigMap、downwardAPI、Secret 和 hostPath。 为确保成本效益和性能，请选择最合适的主机卷。 在 Amazon EKS 中，可以使用 gp3 作为主机根卷，成本低于 gp2 卷。

还可以使用 Amazon EC2 实例存储，为 EC2 实例提供临时块级存储。 这些卷物理连接到主机，仅在实例的生命周期内存在。 若要在 Kubernetes 中使用本地存储卷，必须使用 Amazon EC2 用户数据对磁盘进行分区、配置和格式化。

永久性卷

通常使用 Kubernetes 运行无状态应用程序，但有时需要持久性数据存储。 可以使用 Kubernetes 永久性卷 独立于 pod 存储数据，这样数据即使在特定 pod 的生存期结束后仍然可以持久保存。 Amazon EKS 为永久性卷支持不同类型的存储选项，包括 Amazon EBS、 Amazon Elastic File System （EFS）、 Amazon FSx for Lustre 和 Amazon FSx for NetApp ONTAP。

将 Amazon EBS 卷用于块级存储和数据库和吞吐量密集型应用程序。 Amazon EKS 用户可以使用最新一代块存储 gp3 来平衡价格和性能。 对于更高性能的应用，可以使用 io2 Block Express 卷。

Amazon EFS 是一个无服务器弹性文件系统，可在多个容器和节点之间共享。 当添加或删除文件时，它会自动增长和收缩，这消除了容量规划的需要。 Amazon EFS 容器存储接口 （CSI） 驱动程序将 Amazon EFS 与 Kubernetes 集成。

Amazon FSx for Lustre 提供高性能并行文件存储。 对于需要高吞吐量和低延迟作的方案，请使用这种类型的存储。 可以将此文件存储链接到 Amazon S3 数据存储库，以存储大型数据集。 Amazon FSx for NetApp ONTAP 是基于 NetApp 的 ONTAP 文件系统构建的完全托管的共享存储解决方案。

若要优化存储配置并管理备份和快照，请使用 AWS 计算优化器和Velero 等工具。

AKS 存储选项

在 AKS 中运行的应用程序可能需要存储和检索数据。 某些应用程序工作负荷可以在不需要的空节点上使用本地快速存储。 但是，其他应用程序工作负荷需要在 Azure 平台上更常规的数据卷中持久化的存储。 多个 pod 可能需要：

• 共享相同的数据容量。
• 重新附加数据卷（如果在不同节点上重新计划 pod）。

以下部分介绍了在 AKS 中向应用程序提供存储的存储选项和核心概念。

卷类型

Kubernetes 卷代表的不仅仅是用于存储和检索信息的传统磁盘。 还可以使用 Kubernetes 卷将数据注入 Pod，以供其容器使用。

Kubernetes 中的常见卷类型包括 emptyDirs、 secrets 和 ConfigMaps。

EmptyDirs

对于定义了 emptyDir 卷的 Pod，该卷会在 Pod 被分配给节点时创建。 顾名思义，emptyDir 卷最初是空的。 pod 中的所有容器都可以读写 emptyDir 卷中的相同文件，尽管每个容器可以将该卷挂载到相同或不同的路径上。 当因任何原因从节点中删除 Pod 时，emptyDir 中的数据将被永久删除。

机密

机密是保存少量敏感数据的对象，例如密码、令牌或密钥。 如果不使用秘密，这些信息会包含在 Pod 规范或容器映像中。 机密可防止需要在应用程序代码中直接嵌入机密数据。 可以独立于使用秘密的 Pod 来创建秘密。 这种做法可降低在创建、查看和编辑 Pod 时公开机密及其数据的风险。 Kubernetes 和群集中运行的应用程序可以通过对机密采取额外的预防措施，例如防止敏感数据写入非易失性存储。 机密类似于 ConfigMaps，但它们专门用于存储机密数据。

可以出于以下目的使用机密：

• 设置容器的环境变量。
• 向 Pod 提供 SSH 密钥或密码等凭据。
• 允许 kubelet 从专用注册表拉取容器映像。

Kubernetes 控制平面还使用秘密，如 bootstrap 令牌秘密，以帮助实现节点注册自动化。

ConfigMaps

ConfigMap 是一个 Kubernetes 对象，用于在键值对中存储非实体数据。 Pod 可以将 ConfigMaps 用作环境变量、命令行参数或卷中的配置文件。 可以使用 ConfigMap 将特定于环境的配置与 容器映像分离，从而使应用程序易于移植。

ConfigMap 不提供保密或加密。 如果要存储机密数据，请使用 机密 而不是 ConfigMap，或使用其他合作伙伴工具将数据保密。

可以使用 ConfigMap 与应用程序代码分开设置配置数据。 例如，可以开发一个应用程序，以便在计算机上运行以供开发，并在云中运行以处理实际流量。 可以编写代码来查找名为 DATABASE_HOST 的环境变量。 在本地，将该变量设置为 localhost. 在云中，将其设置为 Kubernetes 服务，以将数据库组件公开给您的群集。 此方法允许提取在云中运行的容器映像，并根据需要在本地调试相同的代码。

永久性卷

作为 Pod 生命周期的一部分定义和创建的卷只会在删除 Pod 之前存在。 如果在维护事件期间（尤其是在 StatefulSets 中）于另一台主机上重新计划 Pod，则 Pod 通常会预期其存储会被保留。 永久性卷是 Kubernetes API 创建和管理的存储资源。 永久性卷可以在单个 Pod 的生命周期结束后继续存在。 可以使用以下 Azure 存储工具来提供永久性卷：

• Azure 磁盘存储
• Azure 文件存储
• Azure NetApp 文件
• Azure Blob 存储
• Azure 容器存储

若要在 Azure 磁盘存储或 Azure 文件存储之间进行决定，请考虑应用程序是否需要并发数据访问或特定的性能层。

此图显示了两种方案：单节点或 Pod 访问以及多个并发节点或 Pod 访问。 单节点或 Pod 访问方案使用 Azure 托管磁盘（标准存储或高级存储）。 多个并发节点或 Pod 访问方案使用 Azure 文件（标准存储）。 这两种情况都指向 AKS 群集内的永久性卷。

群集管理员可以 静态 创建永久性卷，或者 Kubernetes API 服务器可以 动态 创建卷。 如果一个 Pod 被计划并请求当前不可用的存储，则 Kubernetes 可以创建基础 Azure 磁盘或文件存储，并将其附加到 Pod。 动态预配使用存储类来标识需要创建的资源类型。

重要

Windows 和 Linux Pod 无法共享持久卷，因为操作系统支持不同的文件系统。

如果需要完全托管的解决方案来对数据进行块级访问，请考虑使用 Azure 容器存储，而不是 CSI 驱动程序。 Azure 容器存储与 Kubernetes 集成，提供永久性卷的动态和自动预配。 Azure 容器存储支持 Azure 磁盘、临时磁盘和 Azure 弹性 SAN（预览版）作为支持存储。 这些选项为 Kubernetes 群集上运行的有状态应用程序提供灵活性和可伸缩性。

存储类

若要指定不同的存储层（例如高级层或标准层），可以创建存储类。

存储类还定义了回收策略。 删除永久性卷时，回收策略控制基础 Azure 存储资源的行为。 可删除基础资源，也可保留以供未来的 Pod 使用。

使用 Azure 容器存储 的群集具有一 acstor-<storage-pool-name>个名为的额外存储类。 还会创建内部存储类。

对于使用 CSI 驱动程序的群集，将创建以下额外的存储类：

存储类	DESCRIPTION
managed-csi	将 Azure 标准 SSD 与本地冗余存储（LRS）配合使用来创建托管磁盘。 回收策略确保在删除使用基础 Azure 磁盘的永久性卷时会删除该磁盘。 存储类还会将永久性卷配置为可扩展。 可编辑持久卷声明以指定新的大小。 对于 Kubernetes 版本 1.29 及更高版本，此存储类使用具有区域冗余存储的标准 SSD（ZRS）为跨多个可用性区域部署的 AKS 群集创建托管磁盘。
managed-csi-premium	将 Azure 高级 SSD 与 LRS 配合使用来创建托管磁盘。 回收策略确保在删除使用基础 Azure 磁盘的永久性卷时会删除该磁盘。 此存储类允许扩展永久性卷。 对于 Kubernetes 版本 1.29 及更高版本，此存储类使用高级 SSD 和 ZRS 为跨多个可用性区域部署的 AKS 群集创建托管磁盘。
azurefile-csi	使用标准 SSD 存储创建 Azure 文件共享。 回收策略确保在删除使用基础 Azure 文件共享的永久性卷时会删除该文件共享。
azurefile-csi-premium	使用高级 SSD 存储创建 Azure 文件共享。 回收策略确保在删除使用基础 Azure 文件共享的永久性卷时会删除该文件共享。
azureblob-nfs-premium	使用高级 SSD 存储创建 Blob 存储容器，并通过网络文件系统 （NFS） v3 协议进行连接。 回收策略确保在删除使用基础 Blob 存储容器的永久性卷时会删除该文件共享。
azureblob-fuse-premium	使用高级 SSD 存储创建 Blob 存储容器并通过 BlobFuse 进行连接。 回收策略确保在删除使用基础 Blob 存储容器的永久性卷时会删除该文件共享。

除非为永久性卷指定存储类，否则将使用默认存储类。 请求永久性卷时，请确保卷使用所需的存储。

重要

对于 Kubernetes 版本 1.21 及更高版本，AKS 默认使用 CSI 驱动程序，并且已启用 CSI 迁移。 现有的树内永久性卷仍可继续运行，但对于 1.26 及更高版本，AKS 不再支持通过使用树内驱动程序创建的卷以及为文件和磁盘预留的存储。

该 default 类与 managed-csi 类相同。

对于 Kubernetes 版本 1.29 及更高版本，在跨多个可用性区域部署 AKS 群集时，AKS 使用 ZRS 在内置存储类中创建托管磁盘。 ZRS 确保在所选区域中的多个 Azure 可用性区域之间同步复制 Azure 托管磁盘。 此冗余策略可增强应用程序的复原能力，并帮助保护数据免受数据中心故障的影响。

但是，ZRS 的成本高于 LRS。 如果成本优化是优先级，则可以创建一个将 skuname 参数设置为 LRS 的新存储类。 然后就可以在永久性卷声明中使用新的存储类。

可以使用 kubectl 创建用于其他需求的存储类。 以下示例使用高级托管磁盘，并指定删除 Pod 时应 保留 基础 Azure 磁盘：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

AKS 协调默认存储类，并覆盖对这些存储类所做的任何更改。

有关详细信息，请参阅 Kubernetes 中的 StorageClass。

永久性卷声明

永久性卷声明请求存储特定存储类、访问模式和大小。 如果根据定义的存储类没有现有资源可以实现声明，Kubernetes API 服务器可动态预配基础 Azure 存储资源。

Pod 定义包括卷连接到 Pod 后的卷挂载。

左侧有两个部分：单节点或 Pod 访问和多个并发节点或 Pod 访问。 单节点或 Pod 访问使用 Azure 托管磁盘（标准存储或高级存储）。 从单个节点或 Pod 访问指向右侧 AKS 群集中的永久性卷的箭头。 多个并发节点或 Pod 的访问使用 Azure 文件（标准存储）。 从多个并发节点或 Pod 指向右侧 AKS 群集中的同一永久性卷的箭头。 在 AKS 群集内，一个永久性卷连接到一个永久性卷声明，而永久性卷要求连接到一个存储类。 永久性卷声明指向节点和 Pod。

将可用存储资源分配给请求存储的 Pod 后，永久性卷会绑定到永久性卷声明。 每个持久卷都与一个持久卷申请相关联，以确保专用存储。

以下示例 YAML 清单显示了一个持久卷声明，该声明使用 managed-premium 存储类并请求一个大小为 5Gi 的 Azure 磁盘：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

创建 pod 定义时，还需指定：

• 用于请求所需存储的永久性卷声明。
• 供应用程序用于读取和写入数据的卷装载。

以下 YAML 清单示例显示了之前的永久性卷声明如何在 /mnt/azure 处挂载卷：

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

若要在 Windows 容器中装载存储卷，请指定驱动器号和路径：

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

临时 OS 磁盘

默认情况下，Azure 会自动将虚拟机（VM）的作系统磁盘复制到 Azure 存储，以避免在将 VM 重新定位到另一个主机时数据丢失。 但是，容器不设计为保留本地状态，因此此行为提供有限的值和缺点。 这些缺点包括节点预配速度较慢，读取和写入延迟更高。

相比之下，临时 OS 磁盘仅存储在主机上，例如临时磁盘。 此配置提供较低的读取和写入延迟，以及更快的节点缩放和群集升级。

如果未为操作系统请求 Azure 管理磁盘，对于特定节点池配置，AKS 会默认使用临时操作系统磁盘（如果可能）。

有关大小要求和建议，请参阅 Azure VM 的临时 OS 磁盘。 请考虑以下大小调整注意事项：

• 如果使用 AKS 默认 VM 大小 Standard_DS2_v2 SKU，默认 OS 磁盘大小为 100 GiB，则默认 VM 大小支持临时 OS 磁盘，但仅缓存大小为 86 GiB。 如果未指定，该配置默认为托管磁盘。 如果请求临时 OS 磁盘，将收到验证错误。

• 如果要求使用带有 60-GiB OS 磁盘的 Standard_DS2_v2 SKU，该配置默认为临时 OS 磁盘。 请求的 60 GiB 大小小于最大 86 GiB 缓存大小。

• 如果选择具有 100 GB OS 磁盘 的 Standard_D8s_v3 SKU，则此 VM 大小支持临时 OS 磁盘，并且缓存大小为 200 GiB。 如果未指定 OS 磁盘类型，则节点池默认接收临时 OS 磁盘。

最新一代 VM 系列没有专用缓存，并且只有临时存储。

• 如果选择默认 OS 磁盘大小为 100 GiB 的 Standard_E2bds_v5 VM 大小，则 VM 支持临时 OS 磁盘，但只有 75 GB 的临时存储。 如果未指定该配置，则此配置默认为托管 OS 磁盘。 如果请求临时 OS 磁盘，将收到验证错误。

• 如果请求 OS 磁盘大小为 60 GiB 的同一 Standard_E2bds_v5 VM 大小，则此配置将默认为临时 OS 磁盘。 请求的 60 GiB 大小小于 75 GiB 的最大临时存储。

• 如果选择具有 100 GiB OS 磁盘的 Standard_E4bds_v5 SKU，则此 VM 大小支持临时 OS 磁盘，并且具有 150 GiB 的临时存储。 如果未指定 OS 磁盘类型，Azure 会将临时 OS 磁盘预配到节点池。

客户管理的密钥

可以在 AKS 群集上使用自己的密钥来管理临时 OS 磁盘的加密。 有关详细信息，请参阅在 AKS 中使用 Azure 托管磁盘自带密钥。

体积

Kubernetes 通常将各个 Pod 视为瞬态的可处置资源。 应用程序使用不同的方法来使用和保存数据。 卷表示一种跨 Pod 和应用程序生命周期存储、检索及保存数据的方法。

传统卷会作为由 Azure 存储支持的 Kubernetes 资源进行创建。 你可以手动创建数据卷以直接分配给 Pod，也可以让 Kubernetes 自动创建它们。 数据卷可以使用 Azure 磁盘存储、Azure 文件存储、Azure NetApp 文件存储或 Blob 存储。

注意

根据 VM SKU 的不同，Azure 磁盘 CSI 驱动程序可能会对每个节点设置卷限制。 对于某些高性能 VM（例如 16 个核心），每个节点的限制为 64 个卷。 要确定每个 VM SKU 的限制，请查看每个 VM SKU 的“最大数据磁盘数”列。 有关 VM SKU 及其相应容量限制的列表，请参阅 “常规用途 VM 大小”。

若要在 Azure 文件和 Azure NetApp 文件之间进行决定，请参阅 Azure 文件和 Azure NetApp 文件比较。

Azure 磁盘存储

默认情况下，AKS 群集附带预创建的managed-csi和managed-csi-premium存储类，这些存储类使用Azure 磁盘存储。 与 Amazon EBS 类似，这些类会创建托管磁盘或块设备，并附加到节点上，为 Pods 提供访问。

磁盘类允许静态和动态卷预配。 重新声明策略可确保磁盘与永久性卷一起删除。 若要扩展磁盘，请编辑持久卷声明。

这些存储类将 Azure 托管磁盘与 LRS 配合使用。 LRS 中的数据在 Azure 主要区域中的单个物理位置内有三个同步副本。 LRS 是成本最低的复制选项，但不提供针对数据中心故障的保护。 可以定义使用 ZRS 托管磁盘的自定义存储类。

ZRS 跨区域中的三个 Azure 可用性区域同步复制 Azure 托管磁盘。 每个可用性区域都是一个单独的物理位置，具有独立的电源、冷却和网络。 ZRS 磁盘在一年内的持久性至少达到 99.9999999999%。 不同可用性区域中的 VM 可以连接 ZRS 托管磁盘。 ZRS 磁盘在所有 Azure 区域中都不可用。 有关详细信息，请参阅 Azure 磁盘的 ZRS 选项以提高可用性。

若要降低数据丢失的风险，请使用 AKS 备份 来定期备份或磁盘存储数据的快照。 或者，可以使用具有内置快照技术的合作伙伴解决方案（如 Velero 或 Azure 备份）。

可以使用 Azure 磁盘存储 创建 Kubernetes DataDisk 资源。 可以使用以下磁盘类型：

• 高级 SSD （建议用于大多数工作负荷）
• 高级 SSD v2
• Azure 超级磁盘存储
• 标准 SSD
• Azure 标准硬盘驱动器 (HDD)

小提示

对于大多数生产和开发工作负载，请使用高级 SSD。

Azure 磁盘装载为 ReadWriteOnce，因此它仅适用于单个节点。 对于多个节点上的 Pod 可以同时访问的存储卷，请使用 Azure 文件。

高级 SSD v2 磁盘

高级 SSD v2 磁盘 专为输入/输出（I/O）密集型企业工作负荷而设计。 它们提供低于毫秒级的一致磁盘延迟、高输入/输出操作次数（IOPS）和高吞吐量。 可以随时独立配置高级 SSD v2 磁盘的性能（容量、IOPS 和吞吐量）。 因此，在满足性能需求的同时，可以轻松提高成本效益。 有关如何配置新的或现有的 AKS 群集以使用 Azure 高级 SSD v2 磁盘的详细信息，请参阅 AKS 上使用高级 SSD v2 磁盘。

超级磁盘存储

超级磁盘存储是一个 Azure 托管磁盘层，可为 Azure VM 提供高吞吐量、高 IOPS 和一致的低延迟磁盘存储。 对数据密集型和事务密集型工作负荷使用超级磁盘存储。 与其他磁盘存储 SKU 和 Amazon EBS 一样，超级磁盘存储一次装载一个 Pod，不提供并发访问。

若要 在 AKS 群集上启用超级磁盘存储，请使用标志 --enable-ultra-ssd。

请注意超级磁盘存储 限制，并选择兼容的 VM 大小。 超级磁盘存储具有 LRS 复制。

自带密钥 (BYOK)

Azure 会加密托管磁盘中的所有静态数据，包括 AKS 群集的 OS 和数据磁盘。 默认情况下，数据使用 Microsoft 管理的密钥进行加密。 为了更好地控制加密密钥，可以提供客户管理的密钥，为 AKS 群集中的 OS 和数据磁盘提供静态加密。 有关详细信息，请参阅 Azure 托管磁盘在 AKS 中的 BYOK 和 Azure 磁盘存储的服务器端加密。

Azure 文件存储

磁盘存储无法提供对卷的并发访问，但可以使用 Azure 文件 存储来装载由 Azure 存储支持的服务器消息块（SMB）版本 3.1.1 共享或 NFS 版本 4.1 共享。 此过程提供类似于 Amazon EFS 的网络连接存储。 Azure 文件存储有两个存储选项：

• Azure 文件标准存储使用普通硬盘驱动器 (HDD) 来备份文件共享。

• Azure 文件高级存储使用高性能固态硬盘（SSD）支持文件共享。 高级版的最低文件共享大小为 100 GB。

如果发生故障，Azure 文件存储具有以下存储帐户复制选项来保护数据：

• Standard_LRS：标准 LRS
• Standard_GRS：标准异地冗余存储 (GRS)
• Standard_ZRS：标准 ZRS
• Standard_RAGRS：标准读取访问 GRS (RA-GRS)
• Standard_RAGZRS：标准读取访问异地区域冗余存储 (RA-GZRS)
• Premium_LRS：高级 LRS
• Premium_ZRS：高级 ZRS

要优化 Azure 文件存储的成本，请购买 Azure 文件存储容量预留。

Azure NetApp 文件

Azure NetApp 文件是一种企业级高性能计量文件存储服务，可在 Azure 上运行，并通过使用 NFS（NFSv3 或 NFSv4.1）、SMB 和 双协议（NFSv3 和 SMB 或 NFSv4.1 和 SMB）卷来支持卷。 Kubernetes 用户在将 Azure NetApp 文件卷用于 Kubernetes 工作负荷时有两个选项：

• 静态创建 Azure NetApp 文件卷。 通过 Azure CLI 或 Azure 门户在 AKS 外部创建卷。 在创建后，这些卷会通过创建 PersistentVolume 公开给 Kubernetes。 静态创建的 Azure NetApp 文件卷存在许多限制。 例如，它们无法扩展，因此需要过度预配。 对于大多数用例，我们不建议静态创建卷。

• 通过 Kubernetes 动态创建 Azure NetApp 文件卷。 这是使用 Astra Trident 通过 Kubernetes 直接创建多个卷的首选方法。 Astra Trident 是符合 CSI 规范的动态存储业务流程协调程序，可帮助通过 Kubernetes 在本地预配卷。

有关详细信息，请参阅 为 AKS 配置 Azure NetApp 文件。

Blob 存储

Blob 存储 CSI 驱动程序是 AKS 用于管理 Blob 存储生命周期的符合 CSI 规范的驱动程序。 CSI 是有关对 Kubernetes 上的容器化工作负载公开任意块和文件存储系统的一个标准。

采用并使用 CSI，以便 AKS 可以编写、部署和迭代插件。插件公开新的存储系统或改进 Kubernetes 中的现有存储系统。 AKS 中的 CSI 驱动程序无需修改核心 Kubernetes 代码并等待其发布周期。

将 Blob 存储作为文件系统装载到容器或 Pod 时，可以将其与处理大量非结构化数据的应用程序一起使用，例如：

• 日志文件数据。
• 图像、文档和流式传输视频或音频。
• 灾难恢复数据。

应用程序可以通过 BlobFuse 或 NFS 3.0 协议访问对象存储中的数据。 在引入 Blob 存储 CSI 驱动程序之前，唯一的选择是手动安装不受支持的驱动程序，以便从 AKS 上运行的应用程序访问 Blob 存储。 AKS 上启用的 Blob 存储 CSI 驱动程序具有两个内置存储类： azureblob-fuse-premium 和 azureblob-nfs-premium。

若要创建支持 CSI 驱动程序的 AKS 群集，请参阅 AKS 上的 CSI 驱动程序。 有关详细信息，请参阅 比较对 Azure 文件、Blob 存储和 Azure NetApp 文件的访问与 NFS。

Azure HPC 缓存

HPC 缓存 可加速对数据的访问，以便执行高常量计算任务，并提供云解决方案的可伸缩性。 如果选择此存储解决方案，请确保在 支持 HPC 缓存的区域部署 AKS 群集。

NFS 服务器

对于共享 NFS 访问，应使用 Azure 文件或 Azure NetApp 文件。 还可以在导出卷的 Azure VM 上创建 NFS 服务器。

此选项仅支持静态预配。 必须在服务器上手动预配 NFS 共享。 无法在 AKS 上自动预配 NFS 共享。

该解决方案基于基础架构即服务 (IaaS) 而不是平台即服务 (PaaS)。 可以管理 NFS 服务器，包括 OS 更新、高可用性、备份、灾难恢复和可伸缩性。

Azure 容器存储

Azure 容器存储 是一种基于云的卷管理、部署和业务流程服务，专为容器本机构建。 它与 Kubernetes 集成，以便可以动态自动预配永久性卷，以存储 Kubernetes 群集上运行的有状态应用程序的数据。

Azure 容器存储使用现有的 Azure 存储产品/服务进行实际数据存储，并提供专为容器生成的卷业务流程和管理解决方案。 Azure 容器存储支持以下后备存储：

• Azure 磁盘： 提供对存储 SKU 和配置的精细控制。 Azure 磁盘适合第 1 层和常规用途数据库。

• 临时磁盘： 在 AKS 节点上使用本地存储资源（NVMe 或临时 SSD）。 临时磁盘适用于没有数据持久性要求或具有内置数据复制支持的应用程序。 AKS 发现 AKS 节点上的可用临时存储，并获取它们进行卷部署。

• 弹性 SAN：按需预配全面受管理资源。 弹性 SAN 适用于常规用途数据库、流式处理和消息传递服务、持续集成和持续交付环境，以及其他第 1 层或第 2 层工作负荷。 多个群集可以同时访问单个存储区域网络（SAN）。 但是，永久性卷每次只能由一个使用者附加。

以前，若要为容器提供云存储，需要单个 CSI 驱动程序来适应面向 IaaS 为中心的工作负荷的存储服务。 此方法增加了操作开销，并提升了与应用程序可用性、伸缩性、性能、易用性和成本相关联的风险。

Azure 容器存储派生自 OpenEBS，这是一种为 Kubernetes 提供容器存储功能的开源解决方案。 Azure 容器存储可在 Kubernetes 环境中通过基于微服务的存储控制器提供托管卷协调解决方案。 此功能启用真正的容器原生存储。

Azure 容器存储适用于以下方案：

• 加速 VM 到容器计划：Azure 容器存储挖掘出以前仅适用于 VM 的各种 Azure 块存储产品/服务，使其可供容器使用。 此存储包括临时磁盘存储，为 Cassandra 等工作负荷提供极其低的延迟。 它还包括弹性 SAN，它提供原生 iSCSI 和共享的预配置目标。

• 使用 Kubernetes 简化卷管理： Azure 容器存储通过 Kubernetes 控制平面进行卷编排。 此功能简化了 Kubernetes 中卷的部署和管理，而无需在不同的控制平面之间切换。

• 降低总拥有成本：为提高成本效益，增加每个 Pod 或节点支持的永久性卷的容量。 若要减少预配所需的存储资源，请动态共享存储资源。 不包括对存储池本身的纵向扩展支持。

Azure 容器存储提供以下主要优势：

• 快速横向扩展有状态 Pod：Azure 容器存储通过网络块存储协议（如 NVMe-oF 或 iSCSI）挂载永久性卷。 此功能可确保快速挂载和卸载永久性卷。 可以从小规模开始，根据需要部署资源，以确保应用程序在初始化或生产过程中不会出现资源不足或中断的情况。 当 Pod 在群集中重新生成时，必须将相关的永久性卷快速转移到新 Pod 中，以保持应用程序的弹性。 通过使用远程网络协议，Azure 容器存储与 Pod 生命周期紧密耦合，以支持 AKS 上具有高度弹性的大规模有状态应用程序。

• 提高有状态工作负荷的性能： Azure 容器存储支持卓越的读取性能，并通过 RDMA 使用 NVMe-oF 提供近磁盘写入性能。 借助此功能，可以经济高效地满足各种容器工作负荷的性能要求，包括第 1 层 I/O 密集型、常规用途、吞吐量敏感和开发/测试工作负荷。 加速永久性卷的附加和分离时间，并将 Pod 故障转移时间降至最低。

• 协调 Kubernetes 本机卷：使用 kubectl 命令创建存储池和永久性卷、捕获快照并管理卷的整个生命周期，而无需在工具集之间切换不同的控制平面操作。

合作伙伴解决方案

与 Amazon EKS 一样，AKS 是 Kubernetes 实现，你可以集成合作伙伴 Kubernetes 存储解决方案。 下面是适用于 Kubernetes 的合作伙伴存储解决方案的一些示例：

• Rook 通过自动执行 Azure 存储管理员任务，将分布式存储系统转变为自我管理存储服务。 Rook 通过 Kubernetes 运营商为每个存储提供商提供服务。

• GlusterFS 是一个免费且开源的可扩展网络文件系统，它使用通用的现成硬件为数据量大和带宽密集型任务创建大型分布式存储解决方案。

• Ceph 提供可靠且可缩放的统一存储服务，该服务包含基于商品硬件组件生成的单个群集的对象、块和文件接口。

• MinIO 多云对象存储允许企业在任何云上构建 AWS S3 兼容的数据基础结构。 它为数据和应用程序提供一致的可移植接口。

• Portworx 是用于 Kubernetes 项目和基于容器的计划的端到端存储和数据管理解决方案。 Portworx 提供容器粒度存储、灾难恢复、数据安全性和多云迁移。

• Quobyte 提供高性能文件和对象存储，可在任何服务器或云上部署，以缩放性能、管理大量数据并简化管理。

• Ondat 跨任何平台提供一致的存储层。 可以在 Kubernetes 环境中运行数据库或任何持久性工作负载，而无需管理存储层。

Kubernetes 存储注意事项

为 Amazon EKS 或 AKS 选择存储解决方案时，请考虑以下因素。

存储类访问模式

在 Kubernetes 版本 1.21 及更高版本中，默认情况下，AKS 和 Amazon EKS 存储类仅使用 CSI 驱动程序 。

不同的服务支持具有不同访问模式的存储类。

服务	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
Azure 磁盘存储	X
Azure 文件存储	X	X	X
Azure NetApp 文件	X	X	X
NFS 服务器	X	X	X
HPC 缓存	X	X	X

动态预配与静态预配

动态预配卷可减少静态创建永久性卷的管理开销。 设置适当的回收策略，以在删除 Pod 时消除未使用的磁盘。

备份

选择一个工具来备份持久数据。 该工具应与你的存储类型匹配，例如快照、Azure 备份、Velero 或 Kasten。

成本优化

要优化 Azure 存储成本，如果服务支持 Azure 保留，请使用 Azure 保留。 有关详细信息，请参阅 Kubernetes 群集的成本管理。

贡献者

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• Paolo Salvatori | 首席系统工程师
• 劳拉·尼古拉斯 |高级云解决方案架构师

其他参与者：

• 查德·基特尔 |首席软件工程师 - Azure 模式和做法
• Ed Price | 高级内容项目经理
• Theano Petersen | 技术文档撰写人

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

• 培训：Azure 存储服务
• 培训：在 Azure 中存储数据
• 培训：Kubernetes 简介
• 培训：Azure NetApp 文件简介

相关资源

• 适用于 Amazon EKS 专业人员的 AKS
• Kubernetes 标识和访问管理
• Kubernetes 监视和日志记录
• 保护对 Kubernetes 的网络访问
• Kubernetes 的成本管理
• Kubernetes 节点和节点池管理
• 群集治理