Azure Kubernetes 服务 (AKS) 工作负载的 Azure Files 指南

Azure 文件存储提供通过 SMB 3.x 或 NFS 4.1 协议访问的文件共享（Azure 文件存储 SMB/NFS 终结点）。 将 Azure 文件与 Azure Kubernetes 服务（AKS）集成后，可以使用 （RWX） 访问模式为容器化应用程序 ReadWriteMany 提供持久共享存储。 此设置允许多个 Pod（Kubernetes 容器组）并发装载同一共享。

AKS 概述：Azure 上的托管 Kubernetes

Azure Kubernetes 服务是一种托管的 Kubernetes 服务，用于在 Azure 上部署和缩放容器化应用程序。 AKS 管理控制平面组件，例如 API 服务器、etcd 和计划程序。 您管理工作节点池。 AKS 版本 1.21 及更高版本默认包含 Azure 文件 CSI 驱动程序。

Azure 文件在 AKS 存储中的优势

Azure 文件支持实现多 Pod 共享存储所需的ReadWriteMany访问模式。 Azure 文件有两个媒体层：固态硬盘（SSD）和硬盘驱动器（HDD）。 Azure 文件存储还提供三种不同的 计费模型： 预配的 v2、 即用即付和旧的 预配 v1 计费模型。

使用以下 SKU 指南：

Azure 文件共享上存在 每文件性能上限 。 有关完整的可伸缩性和性能信息，请参阅 Azure 文件的可伸缩性和性能目标。

在 AKS 群集所在的同一 Azure 区域中部署存储帐户，以最大程度地减少网络延迟。 跨区域装载增加了 50-100 毫秒的延迟。

持久共享存储

与绑定到单个节点（Kubernetes 工作节点虚拟机）的本地存储不同，Azure 静态文件提供能够在 Pod 重启、节点故障和群集（AKS）扩展事件中保持存活的持久存储。 不同节点上的多个 Pod 可以同时访问同一个文件共享，从而支持共享数据场景和有状态应用程序。

Kubernetes 原生集成

Azure 文件通过 Azure 文件容器存储接口 （CSI） 驱动程序与 Kubernetes 集成。 使用持久卷（PV）和持久卷申领（PVC）来预配和管理文件共享。 CSI 驱动程序处理 Azure API 调用、通过托管标识或存储帐户密钥进行身份验证以及装载操作。

SSD 文件共享以实现最佳性能

对于新部署，将 SSD 媒体层与大多数工作负荷的预配 v2 计费模型结合使用：

• SSD （建议）：用于日志记录、媒体服务、数据库和延迟敏感的工作负荷。 与预配的 v2 计费模型（建议）PremiumV2_LRS / PremiumV2_ZRS或旧版预配的 v1 计费模型（）一起使用。Premium_LRS / Premium_ZRS 每个共享最多 102,400 IOPS 和 10,340 MiB/秒的吞吐量。
• HDD：用于配置文件和不经常访问。 可用于预配的 v2 计费模型（StandardV2_LRS / StandardV2_ZRS）或即用即付计费模型（Standard_LRS / Standard_ZRS）。 每个预配 v2 共享可实现最多 50,000 IOPS 和 5,120 MiB/秒的吞吐量。 对于非常小的共享，HDD 即用即付（Standard_LRS / Standard_ZRS）可能更具成本效益，因为 HDD 预配的 v2 需要最少预配的 IOPS 和吞吐量，且没有免费基线。 对于大多数其他 HDD 工作负载，由于包含基线 IOPS 和吞吐量，SSD 预配 v2 在较小规模的共享中更具成本效益。

协议支持

• SMB 3.x：Linux 和 Windows 节点。 需要端口 445 出站。 支持存储帐户密钥或Microsoft Entra ID 身份验证。
• NFS 4.1：仅限 Linux 节点。 需要 SSD 文件共享和已启用虚拟网络的存储帐户。 无身份验证;依赖于网络安全。

安全性和合规性

Azure 文件的安全功能包括静态存储的 AES-256 加密、传输中的 TLS 1.2+ 加密、与 SMB 的 Microsoft Entra ID 和 RBAC 集成，以及专用端点支持，以限制流量到虚拟网络。

Azure 文件 CSI 驱动程序：Kubernetes 集成

Azure 文件 CSI 驱动程序将 Azure 文件连接到 Kubernetes 群集。 CSI 规范为存储系统定义了一个标准接口，用于向容器化工作负荷公开功能。 有关配置详细信息，请参阅 在 AKS 中使用 Azure 文件 CSI 驱动程序。

CSI 驱动程序的工作原理

在 AKS 群集中，会自动安装和管理 Azure 文件 CSI 驱动程序。 驱动程序通过多个关键组件进行作：

• CSI 驱动程序 Pod：在 AKS 群集中的每个节点上作为 DaemonSet 运行，负责装载和卸载 Azure 文件共享
• CSI 控制器：管理 Azure 文件共享的生命周期，包括创建、删除和卷扩展
• 存储类：定义用于动态预配 Azure 文件共享的参数和策略
• 持久卷：表示 Kubernetes 中实际的 Azure 文件共享
• 持久卷声明：用户请求的存储绑定到持久卷

当 Pod 通过永久性卷声明请求存储时，CSI 驱动程序会与 Azure API 协调，以创建新的 Azure 文件共享（动态预配），或连接到现有共享（静态预配）。 然后，驱动程序将共享装载到 Pod 的文件系统命名空间中，使应用程序可以访问该共享。

CSI 驱动程序功能

Azure 文件 CSI 驱动程序提供了多种高级功能：

• 动态卷预配：基于存储类定义自动创建 Azure 文件共享
• 卷扩展：支持联机扩展现有 Azure 文件共享
• 快照支持：为备份和恢复方案启用时间点快照
• 跨平台兼容性：适用于 AKS 中的 Linux 和 Windows 节点池（AKS 计算组）

Azure 文件使用场景：AKS 工作负载场景

使用 AKS 的 Azure 文件存储的一些常见用例包括：

• 共享配置和机密管理：Azure 文件支持集中存储多个 Pod 需要访问的配置文件、证书和其他共享资源。
• 日志聚合和集中式日志记录：Azure 文件可以作为应用程序日志的中央存储库，从多个 Pod 启用日志聚合，并为日志分析工具提供持久性存储。
• 内容管理系统和媒体存储：对于处理用户生成的内容、媒体文件或文档管理的应用程序，Azure 文件存储提供可由多个应用程序实例访问的可缩放共享存储。
• 批处理和 ETL 工作负载：Azure 文件支持在批处理作业、ETL 管道和数据处理工作流之间高效共享数据，其中多个 Pod 需要访问输入数据和输出结果。
• 开发和测试环境：用于开发团队的共享存储，用于协作处理代码、共享测试数据，并在不同的 Pod 和节点上维护一致的开发环境。

动态预配：自动创建 Azure 文件共享

创建持久卷声明时，动态预配会自动创建 Azure 文件共享。 验证环境是否满足以下要求：

通过动态预配，系统会在创建永久性卷声明时自动创建存储。 Azure 文件 CSI 驱动程序支持通过 Kubernetes 存储类进行动态配置。

动态预配的先决条件

在创建用于动态预配的 StorageClass 之前，请确保满足以下先决条件：

• AKS 群集版本 1.21 或更高版本
• Linux 节点池（适用于 NFS）或 Linux/Windows 节点池（适用于 SMB）
• 资源组上具有 存储帐户参与者 角色的 AKS 群集标识
• 对于 NFS：启用了虚拟网络服务终结点的 SSD 文件共享（例如 PremiumV2_LRS 或 Premium_LRS）
• 对于专用终结点： 专用 DNS 区域中的专用 DNS 区域参与者 角色

配置动态预配的步骤

1. 创建 StorageClass - 定义预配参数（SKU、协议、装载选项）。
2. 创建 PersistentVolumeClaim （PVC） - 引用 StorageClass;CSI 驱动程序会自动创建 Azure 文件共享。
3. 部署工作负荷 - 在 Pod 规范中装载 PVC。
4. 验证 - 确认 PVC 是否 Bound 且装载路径可访问。

用于动态预配的 StorageClass 参数

为 Azure 文件存储动态预配定义 StorageClass 时，请使用以下参数：

此 YAML 定义存储类（Kubernetes 预配模板），用于使用 SMB 协议动态预配 SSD 预配 v2 Azure 文件共享。 有关 Linux 装载选项，请参阅 SMB 装载选项参考。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
parameters:
  skuName: PremiumV2_LRS          # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)
  protocol: smb
allowVolumeExpansion: true
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict
  - actimeo=30

验证 StorageClass：

# Check StorageClass exists
kubectl get sc azurefile-csi-premiumv2-custom -o jsonpath="{.provisioner}"
# Expected: file.csi.azure.com

# Test dynamic provisioning with a PVC (replace with your PVC name)
kubectl get pvc <YOUR_PVC_NAME, e.g., my-azurefile-pvc> -o jsonpath="{.status.phase}"
# Expected: Bound (after creating a PVC referencing this StorageClass)

用于共享配置和机密的 Azure 文件存储

在部署共享配置存储之前，请验证环境是否满足以下要求：

Azure 文件存储特别适用于：

• 配置管理：存储需要跨多个实例共享的应用程序配置文件。
• 证书分发：集中管理和分发 SSL/TLS 证书。
• 共享库：存储多个应用程序访问的通用库或二进制文件。

此 YAML 示例创建了用于共享配置存储的持久卷声明，以及在多个 Pod 副本中装载此存储的部署对象。 此示例使用 SMB 协议，适用于 Linux 和 Windows 节点池：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: config-storage
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi-premiumv2-custom
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        volumeMounts:
        - name: config-volume
          mountPath: /app/config
      volumes:
      - name: config-volume
        persistentVolumeClaim:
          claimName: config-storage

验证部署：

# Check PVC is bound
kubectl get pvc config-storage -o jsonpath="{.status.phase}"
# Expected: Bound

# Confirm mount in pod
kubectl exec deploy/app-deployment -- ls -la /app/config
# Expected: directory listing (empty or with config files)

用于日志聚合和集中式日志记录的 Azure 文件

在部署集中式日志记录存储之前，请验证环境是否满足以下要求：

Azure 文件可以充当应用程序日志的中心存储库。 它使你能够聚合来自多个 Pod 的日志，并为日志分析工具提供持久性存储。

此 YAML 示例演示了一个 DaemonSet（每个节点上的 Pod），用于日志收集，其中包含用于集中日志聚合的共享 Azure 文件存储。 此示例面向 Linux 节点池并使用 SMB 协议：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: logs-storage
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi-premiumv2-custom
  resources:
    requests:
      storage: 100Gi
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
      - name: log-collector
        image: fluent/fluent-bit:latest
        volumeMounts:
        - name: logs-volume
          mountPath: /logs
        - name: varlog
          mountPath: /var/log
          readOnly: true
      volumes:
      - name: logs-volume
        persistentVolumeClaim:
          claimName: logs-storage
      - name: varlog
        hostPath:
          path: /var/log

验证部署：

# Check PVC is bound
kubectl get pvc logs-storage -o jsonpath="{.status.phase}"
# Expected: Bound

# Confirm DaemonSet pods running (one per node)
kubectl get pods -l app=log-collector -o wide
# Expected: Running pod on each node

# Verify mount and log collection
kubectl exec ds/log-collector -- ls -la /logs
# Expected: directory listing with log files

静态预配：使用现有的 Azure 文件共享

静态预配连接到预先存在的 Azure 文件共享。 验证环境是否满足以下要求：

对于现有的 Azure 文件共享，您可以创建持久卷，参照已预创建的存储。

静态预配的先决条件

在为静态预配创建 PersistentVolume 之前，请确保满足以下先决条件：

• AKS 群集版本 1.21 或更高版本
• Linux 节点池（适用于 NFS）或 Linux/Windows 节点池（适用于 SMB）
• 预先存在的 Azure 存储帐户和文件共享
• 对于 SMB：Kubernetes Secret 包含 azurestorageaccountname 和 azurestorageaccountkey
• 对于 NFS：具有 SSD 文件共享（例如 PremiumV2_LRS 或 Premium_LRS）和虚拟网络服务终结点的存储帐户;无需机密
• 从 AKS 节点到存储帐户（公共终结点、服务终结点或专用终结点）的网络连接

配置静态预配的步骤

1. 创建 Azure 文件共享 - 使用 Azure 门户、Azure CLI 或 Bicep/Terraform 创建存储帐户和文件共享。
2. （仅 SMB） 创建 Kubernetes 机密 - 存储存储帐户名称和密钥。

   kubectl create secret generic azure-secret \
     --from-literal=azurestorageaccountname=<STORAGE_ACCOUNT_NAME, e.g., myteaborgstorage> \
     --from-literal=azurestorageaccountkey=<STORAGE_ACCOUNT_KEY, e.g., abc123...base64key>
   

3. 创建 PersistentVolume（PV） - 使用 CSI 卷属性引用现有共享。
4. 创建 PersistentVolumeClaim （PVC） - 通过匹配 storageClassName 和访问模式绑定到 PV。
5. 部署工作负荷 - 在 Pod 配置中装载 PVC。
6. 验证 - 确认 PV 是否 Bound 且现有共享内容可见。

用于静态预配的 PersistentVolume 参数

定义 PersistentVolume 以引用现有的 Azure 文件共享时，请使用以下参数：

此 YAML 示例演示如何通过静态预配引用现有 Azure 文件共享来创建持久卷。 此示例使用 SMB 协议，适用于 Linux 和 Windows 节点池：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: existing-azurefile-pv
spec:
  capacity:
    storage: 100Gi                     # Must match existing share quota
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: azurefile-csi
  csi:
    driver: file.csi.azure.com
    readOnly: false
    volumeHandle: unique-volume-id-001  # <UNIQUE_ID, e.g., existing-file-share-id> - must be unique per cluster
    volumeAttributes:
      resourceGroup: rg-aks-storage     # <RESOURCE_GROUP, e.g., rg-aks-storage>
      storageAccount: staborgstorage01  # <STORAGE_ACCOUNT, e.g., staborgstorage01>
      shareName: aksfileshare           # <SHARE_NAME, e.g., aksfileshare>
      protocol: smb

验证部署：

# Check PV is available
kubectl get pv existing-azurefile-pv -o jsonpath="{.status.phase}"
# Expected: Available (or Bound if PVC exists)

# After creating a matching PVC and pod, confirm mount
kubectl exec <POD_NAME, e.g., my-app-pod-abc123> -- ls -la <MOUNT_PATH, e.g., /mnt/azure>
# Expected: contents of existing Azure file share

Azure 文件装载选项：优化性能

这些装载选项适用于使用 SMB 协议 （CIFS） 的 Linux 节点。 Windows 节点使用本机 SMB 并忽略这些选项。

SMB 装载选项参考 （Linux）

规范权限集：dir_mode=0755、、file_mode=0755uid=1000、 gid=1000。 仅当应用程序需要根所有权或可写访问权限（例如，作为根运行的旧应用或容器）时才使用0777/uid=0/gid=0。

示例 YAML：

mountOptions:
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl

Azure 文件存储的专用终结点：确保 AKS 存储的安全性

通过使用专用终结点，可以将 Azure 文件服务的流量限制到虚拟网络，并消除对公共互联网的公开。

专用终结点配置的先决条件

在为 Azure 文件配置专用终结点之前，请确保满足以下先决条件：

• 具有虚拟网络集成的 AKS 群集版本 1.21 或更高版本
• 与 AKS 群集位于同一区域中的 Azure 存储帐户
• 区域中的privatelink.file.core.chinacloudapi.cn角色
• 用于创建专用终结点的虚拟网络/子网上的网络参与者角色
• 链接到 AKS 虚拟网络的专用 DNS 区域（用于自动 DNS 解析）

使用 Azure Files 配置专用终结点的步骤

1. 创建专用终结点 - 使用 Azure 门户、Azure CLI 或 Bicep 为面向 file 子资源的存储帐户创建专用终结点。
2. 配置专用 DNS - 将 privatelink.file.core.chinacloudapi.cn 专用 DNS 区域链接到 AKS 虚拟网络。
3. 创建 StorageClass - 在参数中设置 networkEndpointType: privateEndpoint 。
4. 创建 PVC - 引用 StorageClass;CSI 驱动程序通过专用终结点预配存储。
5. 部署工作负荷 - 在 Pod 配置中装载 PVC。
6. 验证 - 确认 PVC 绑定，并且 DNS 解析为专用 IP（nslookup <storageaccount>.file.core.chinacloudapi.cn）。

此 YAML 示例演示如何使用专用终结点配置创建 Azure 文件存储，以提高安全性。 CSI 驱动程序会自动从 AKS 群集配置中发现虚拟网络，因此vnetResourceGroupvnetNamesubnetName，如果虚拟网络与 AKS 群集位于同一资源组中，则为可选。 在跨资源组或多个虚拟网络的场景中显式指定它们。 有关 Linux 装载选项，请参阅 SMB 装载选项参考。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-private-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: PremiumV2_LRS          # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2)
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict
  - nosharesock
  - actimeo=30
  - nobrl

验证部署：

# Check StorageClass exists with private endpoint
kubectl get sc azurefile-csi-private-custom -o jsonpath="{.parameters.networkEndpointType}"
# Expected: privateEndpoint

# After creating a PVC, verify private endpoint connectivity
kubectl get pvc <YOUR_PVC_NAME, e.g., secure-pvc> -o jsonpath="{.status.phase}"
# Expected: Bound (requires virtual network integration and private DNS configured)

另请参阅

• Azure 文件的可伸缩性和性能目标
• 在 AKS 中使用 Azure 文件存储 CSI 驱动程序
• 在 AKS 中创建和使用 Azure Files 卷