Azure Kubernetes Service (AKS) 中應用程式的儲存體選項 (部分機器翻譯)

發行項
07/23/2024

在 Azure Kubernetes Service (AKS) 中執行的應用程式可能會需要儲存和擷取資料。雖然某些應用程式工作負載可以在不需要、清空的節點上使用本機、快速的儲存體，但其他工作負載則需要在 Azure 平台內保存於較一般資料磁碟區的儲存體。

可能會需要多個 Pod：

共用相同的資料磁碟區。
如果 Pod 於不同節點上進行重新排程，則重新連結資料磁碟區。

您可能也需要收集敏感性資料或應用程式設定資訊並儲存至 Pod。

本文將介紹為 AKS 中的應用程式提供儲存體的核心概念：

磁碟區
永續性磁碟區
儲存類別
永續性磁碟區宣告

Azure Kubernetes Service (AKS) 叢集中應用程式適用的儲存體選項圖表。

預設 OS 磁碟大小調整

當您建立新的叢集或將新的節點集區新增至現有的叢集時，vCPU 依預設會決定 OS 磁碟大小。 vCPU 的數目是根據 VM SKU 而定。下表為每個 VM SKU 的預設 OS 磁碟大小：

VM SKU Cores (vCPU)	預設 OS 磁碟層	佈建的 IOPS	佈建的輸送量 (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

重要

只有在不支援暫時性 OS 磁碟且未指定預設 OS 磁碟大小時，才會在新叢集或節點集區上使用預設 OS 磁碟大小。預設 OS 磁碟大小可能會影響叢集的效能或成本。您無法在建立叢集或節點集區後變更 OS 磁碟大小。此預設磁片大小調整會影響在 2022 年 7 月或之後建立的叢集或節點集區。

暫時 OS 磁碟

根據預設，Azure 會自動將虛擬機器的 OS 磁碟複寫至 Azure 儲存體，以避免 VM 在遷往另一部主機時遺失資料。不過，由於容器不是設計來保存本機狀態，因此，此行為提供的價值有限，同時還會有一些缺點。這些缺點包括但不限於節點佈建較慢及更高的讀取/寫入延遲。

相較之下，暫時性 OS 磁碟只會儲存在主機電腦上，就像暫存磁碟一樣。藉由此設定，您可以取得更低的讀取/寫入延遲，以及更快的節點縮放和叢集升級。

注意

當您未明確要求適用於 OS 的 Azure 受控磁碟 (部分機器翻譯) 時，如果指定的節點集區設定可能的話，AKS 就會預設為暫時性 OS。

Azure VM 文件 (部分機器翻譯) 中提供暫時性 OS 磁碟的大小需求和建議。以下是一些一般調整大小考量：

如果您選擇使用預設 OS 磁碟大小為 100 GiB 的 AKS 預設 VM 大小 Standard_DS2_v2 SKU，預設 VM 大小就會支援暫時性 OS，但快取大小只有 86 GiB。如果您未明確指定，此設定會預設為受控磁碟。如果您確實要求暫時性 OS，則會收到驗證錯誤。
如果您要求 OS 磁碟為 60 GiB 的相同 Standard_DS2_v2 SKU，此設定就會預設為暫時性 OS。 60 GiB 的要求大小小於 86 GiB 的快取大小上限。
如果您選取 OS 磁碟為 100 GB 的 Standard_D8s_v3 SKU，此 VM 大小就會支援暫時性 OS，且快取空間為 200 GiB。如果您未指定 OS 磁碟類型，則節點集區預設會收到暫時性 OS。

最新一代的 VM 系列沒有專用快取，但只有暫存儲存體。例如，如果您選取預設 OS 磁碟大小為 100 GiB 的 Standard_E2bds_v5 VM 大小，則其支援暫時性 OS 磁碟，但暫存儲存體只有 75 GB。如果您未明確指定，此設定會預設為受控 OS 磁碟。如果您確實要求暫時性 OS 磁碟，則會收到驗證錯誤。

如果您要求 OS 磁碟為 60 GiB 的相同 Standard_E2bds_v5 VM 大小，此設定就會預設為暫時性 OS 磁碟。要求的 60 GiB 大小小於 75 GiB 的暫存儲存體上限。
如果您選取 OS 磁碟為 100 GiB 的 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 Files 或 Azure Blob。

注意

根據您使用的 VM SKU，Azure 磁碟 CSI 驅動程式可能具有每個節點的磁碟區限制。針對某些高效能 VM (例如 16 個核心)，每個節點的限制為 64 個磁碟區。若要識別每個 VM SKU 的限制，請檢閱所提供之每個 VM SKU 的最大資料磁碟資料行。如需所提供之 VM SKU 清單與其對應的詳細容量限制，請參閱一般用途虛擬機器大小 (部分機器翻譯)。

若要協助判斷 Azure 檔案儲存體與 Azure NetApp Files 之間最適合的工作負載，請檢閱 Azure 檔案儲存體和 Azure NetApp Files 的比較一文 (部分機器翻譯) 中提供的資訊。

Azure 磁碟

使用 Azure 磁碟 (部分機器翻譯) 來建立 Kubernetes DataDisk 資源。磁碟類型包括：

進階 SSD (建議用於大部分工作負載)
Ultra 磁碟
標準 SSD
標準 HDD

提示

針對大部分生產和開發工作負載，請使用進階 SSD。

Azure 磁碟會以 ReadWriteOnce 的形式掛接，因此僅適用於單一節點。針對多個節點上的 Pod 可同時存取的儲存體磁碟區，請使用 Azure 檔案儲存體。

Azure 檔案

使用 Azure 檔案儲存體掛接伺服器訊息區 (SMB) 3.1.1 版共用或網路檔案系統 (NFS) 4.1 版共用。 Azure 檔案儲存體能讓您在多個節點和 Pod 之間共用資料：

高效能 SSD 支援的 Azure 進階儲存體
一般 HDD 支援的 Azure 標準儲存體

Azure NetApp Files

Ultra Storage
進階儲存體
標準儲存體

Azure Blob 儲存體

使用 Azure Blob 儲存體建立 Blob 儲存體容器，然後使用 NFS v3.0 通訊協定或 BlobFuse 掛接。

區塊 Blob

磁碟區類型

Kubernetes 磁碟區不只是用來將資訊儲存和擷取的傳統磁碟。 Kubernetes 磁碟區也可用來將資料插入 Pod 中，供其容器使用。

Kubernetes 中常見的其他磁碟區類型包含：

emptyDir

通常用來作為 Pod 的暫存空間。 Pod 內的所有容器都可存取此磁碟區上的資料。寫入至此磁碟區類型的資料只會在 Pod 的存留期內保存。當您刪除 Pod 之後，此磁碟區就會遭到刪除。此磁碟區通常會使用基礎本機節點磁碟儲存體，但也只能留存於節點的記憶體中。

secret

您可以使用祕密磁碟區來將敏感性資料插入 Pod 中，例如密碼。

使用 Kubernetes API 來建立祕密。
定義 Pod 或部署，並要求特定的祕密。
- 祕密只會提供給已排程 Pod 所需要的祕密節點。
- 祕密會儲存至 tmpfs，而不會寫入至磁碟。
節點上最後一個需要祕密的 Pod 遭刪除後，即會從該節點的 tmpfs 中刪除秘密。
- 祕密會儲存在指定的命名空間內，且僅供相同命名空間中的 Pod 存取。

configMap

您可以使用 configMap 來將機碼值組屬性插入 Pod，例如應用程式設定資訊。將應用程式設定資訊定義為 Kubernetes 資源，不只能輕鬆更新，還能將已部署的 Pod 應用至新的執行個體。

如同使用祕密：

使用 Kubernetes API 來建立 ConfigMap。
在您定義 Pod 或部署時，可要求 ConfigMap。
- ConfigMaps 會儲存在指定的命名空間內，且僅供相同命名空間中的 Pod 存取。

永續性磁碟區

磁碟區會定義並建立為 Pod 生命週期的一部分，且在 Pod 刪除後就不會存在。如果 Pod 在維護事件期間重新排程於不同的主機上，Pod 通常會預期其儲存體能持續保存，尤其是在 StatefulSets 中。 永續性磁碟區 (PV) 是由 Kubernetes API 建立和管理的儲存體資源，可跨個別 Pod 的存留期持續保存。

若要提供持續性磁碟區，您可以使用下列 Azure 儲存體資料服務：

如先前關於磁碟區章節所說明，應選擇 Azure 磁碟或是 Azure 檔案儲存體，通常取決於資料的同時存取需求或效能層級需求。

Azure Kubernetes Service (AKS) 叢集中持續性磁碟區的圖表。

叢集管理員能以「靜態」方式建立持續性磁碟區，也能由 Kubernetes API 伺服器「動態」建立該磁碟區。如果 Pod 在排程後要求了目前無法使用的儲存體，Kubernetes 可以建立基礎 Azure 磁碟或檔案儲存體，並將其連結至 Pod。動態佈建會使用「儲存類別」來識別必須建立的儲存體類型。

重要

Windows 和 Linux Pod 無法共用永續性磁碟區，因為這兩個作業系統之間的檔案系統支援存在差異。

儲存類別

若要指定不同層級的儲存體 (例如進階和標準)，您可以建立「儲存類別」。

儲存體類別也會定義「回收原則」。刪除持續性磁碟區後，回收原則會控制基礎 Azure 儲存體資源的行為。可以刪除基礎資源，或將其保留以供未來的 Pod 使用。

如果是使用容器儲存體介面 (CSI) 驅動程式的叢集，系統會建立下列額外的儲存類別：

儲存類別	描述
`managed-csi`	使用 Azure 標準 SSD 本機備援儲存體 (LRS) 來建立受控磁碟。回收原則可確保在使用基礎 Azure 磁碟的永久性磁碟區遭到刪除時，會刪除該磁碟。此儲存類別也會將持續性磁碟區設定為可擴充。您可以編輯持續性磁碟區宣告以指定新的大小。自 Kubernetes 1.29 版開始，在跨多個可用性區域部署的 Azure Kubernetes Service (AKS) 叢集中，此儲存類別會利用 Azure 標準 SSD 區域備援儲存體 (ZRS) 來建立受控磁碟。
`managed-csi-premium`	使用 Azure 進階本地備援儲存體 (LRS) 來建立受控磁碟。回收原則可確保在使用基礎 Azure 磁碟的永久性磁碟區遭到刪除時，會刪除該磁碟。同樣地，此儲存類別允許將永續性磁片區展開。自 Kubernetes 1.29 版開始，在跨多個可用性區域部署的 Azure Kubernetes Service (AKS) 叢集中，此儲存類別會利用 Azure 進階區域備援儲存體 (ZRS) 來建立受控磁碟。
`azurefile-csi`	使用 Azure 標準儲存體來建立 Azure 檔案共用。回收原則可確保在使用基礎 Azure 檔案共用的永續性磁碟區遭到刪除時，會刪除該檔案共用。
`azurefile-csi-premium`	使用 Azure 進階儲存體來建立 Azure 檔案共用。回收原則可確保在使用基礎 Azure 檔案共用的永續性磁碟區遭到刪除時，會刪除該檔案共用。
`azureblob-nfs-premium`	使用 Azure 進階儲存體建立 Azure Blob 儲存體容器，然後使用 NFS v3 通訊協定連線。回收原則確保在删除使用基礎 Azure Blob 儲存體容器的永續性磁碟區時删除該容器。
`azureblob-fuse-premium`	使用 Azure 進階儲存體建立 Azure Blob 儲存體容器，並使用 BlobFuse 進行連線回收原則確保在删除使用基礎 Azure Blob 儲存體容器的永續性磁碟區時删除該容器。

除非已為持續性磁碟區指定儲存類別，否則會使用預設的儲存類別。當您要求永續性磁碟區時，請確認所需要的適當儲存體。

重要

從 Kubernetes 版本 1.21 開始，AKS 預設只使用 CSI 驅動程式，並且啟用了 CSI 移轉。雖然現有樹狀內永續性磁碟區從版本 1.26 開始繼續執行，但 AKS 將不再支援使用樹狀內驅動程式建立的磁碟區以及為檔案和磁碟佈建的儲存體。

default 類別將會與 managed-csi 相同。

自 Kubernetes 1.29 版開始，在跨多個可用性區域部署 Azure Kubernetes Service (AKS) 叢集時，AKS 現在會利用區域備援儲存體 (ZRS) 在內建儲存類別中建立受控磁碟。 ZRS 可確保在所選區域中，跨 Azure 可用性區域同步複寫 Azure 受控磁碟。此備援策略可強化應用程式的復原能力，並保護您的資料不受資料中心故障影響。

不過，請務必注意，相較於本地備援儲存體 (LRS)，區域備援儲存體 (ZRS) 的成本較高。若成本最佳化為優先考量，則可以將 skuname 參數設定為 LRS，建立新的儲存類別。接著，便可以在持續性磁碟區宣告 (PVC) 中使用新的儲存類別。

您可以使用 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 (英文)。

永續性磁碟區宣告

持續性磁碟區宣告 (PVC) 會要求特定儲存類別、存取模式和大小的儲存體。若現有的資源無法根據已定義的儲存類別來履行宣告，則 Kubernetes API 伺服器可動態佈建基礎 Azure 儲存體資源。

在磁碟區連線至 Pod 後，Pod 定義即會包含磁碟區掛接。

Azure Kubernetes Service (AKS) 叢集中持續性磁碟區宣告的圖表。

將可用的儲存體資源指派給要求儲存體的 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
...

下一步

如需相關聯的最佳做法，請參閱 AKS 中儲存體與備份的最佳做法 (部分機器翻譯) 和 AKS 儲存體考量 (部分機器翻譯)。

若要查看如何使用 CSI 驅動程式，請參閱下列操作說明文章：

Azure Kubernetes Service 上適用於 Azure 磁碟、Azure 檔案儲存體和 Azure Blob 儲存體的容器儲存體介面 (CSI) 驅動程式 (部分機器翻譯)
在 Azure Kubernetes Service 中使用 Azure 磁碟 CSI 驅動程式 (部分機器翻譯)
在 Azure Kubernetes Service 中，使用 Azure 檔案 CSI 驅動程式
在 Azure Kubernetes Service 中使用 Azure Blob 儲存體 CSI 驅動程式 (部分機器翻譯)
使用 Azure Kubernetes Service 設定 Azure NetApp Files (部分機器翻譯)

如需有關 Kubernetes 及 AKS 核心概念的詳細資訊，請參閱下列文章：

Kubernetes/AKS 叢集和工作負載 (部分機器翻譯)
Kubernetes/AKS 身分識別 (部分機器翻譯)
Kubernetes/AKS 安全性 (部分機器翻譯)
Kubernetes/AKS 虛擬網路 (部分機器翻譯)
Kubernetes/AKS 調整 (部分機器翻譯)

共用方式為