Kubernetes 叢集的儲存體選項
本文比較 Amazon Elastic Kubernetes Service (Amazon EKS) 和 Azure Kubernetes Service (AKS) 的儲存體功能,並說明在 AKS 上儲存工作負載資料的選項。
注意
本文是一系列文章的一部分,有助於熟悉 Amazon EKS 的專業人員了解 Azure Kubernetes Service (AKS)。
Amazon EKS 儲存體選項
執行需要資料儲存的應用程式時,Amazon EKS 會針對暫時和長期儲存提供不同類型的磁碟區。
暫時卷
對於需要暫存本機磁碟區但不需要在重新啟動後保存數據的應用程式,可以使用暫時磁碟區。 Kubernetes 支援不同類型的暫時磁碟區,例如 emptyDir、configMap、向下API、秘密,以及 hostpath。 為了確保成本效益和效能,請務必選擇最適合的主機磁碟區。 在 Amazon EKS 中,您可以使用 gp3 作為主機根磁碟區,相較於 gp2 磁碟區,其價格較低。
暫時磁碟區的另一個選項是 Amazon EC2 實例存放區,這會為 EC2 實例提供暫存區塊層級記憶體。 這些磁碟區會實際附加至主機,且只存在於實例的存留期間。 在 Kubernetes 中使用本地儲存磁碟區需要使用 Amazon EC2 用戶數據來分割、設定和格式化磁碟。
永續性磁碟區
雖然 Kubernetes 通常與執行中的無狀態應用程式相關聯,但在某些情況下需要持續性數據記憶體。 Kubernetes 永續性磁碟區 (PVs) 可用來獨立儲存與 Pod 的數據,讓數據在指定 Pod 的存留期之後保存。 Amazon EKS 支援不同類型的 PV 儲存選項,包括 Amazon EBS、Amazon EFS、Amazon FSx for Lustre,以及 Amazon FSx for NetApp ONTAP。
Amazon EBS 磁碟區適用於區塊層級儲存,而且非常適合資料庫和高吞吐量的應用程式。 Amazon EKS 使用者可以使用最新一代的區塊記憶體 gp3,以平衡價格和效能。 針對較高效能的應用程式,可以使用 io2 Block Express 磁碟區。
Amazon EFS 是一種無伺服器彈性文件系統,可跨多個容器和節點共用。 當新增或移除檔案時,它會自動成長和縮小,而不需要進行容量規劃。 Amazon Elastic File System Container Storage Interface (CSI) Driver 可用來整合 Amazon EFS 與 Kubernetes。
適用於 Lustre 的 Amazon FSx 提供高效能的平行檔案記憶體,適用於需要高輸送量和低延遲作業的案例。 它可以連結至 Amazon S3 資料存放庫來儲存大型數據集。 Amazon FSx for NetApp ONTAP 是以 NetApp ONTAP 檔系統為基礎的完全受控共用記憶體解決方案。
Amazon EKS 使用者可以使用 AWS 計算優化器 和 Velero 等工具來優化記憶體設定,以及管理備份和快照集。
AKS 儲存選項
在 Azure Kubernetes Service 中執行的應用程式可能需要儲存和擷取數據。 雖然某些應用程式工作負載可以在不再使用的、已清空的節點上使用本機、快速的存儲,但其他工作負載則需要在 Azure 平臺內較為持久的數據磁碟區中保存的存儲。 多個 Pod 可能需要:
- 共用相同的數據磁碟區。
- 如果 Pod 重新排程在不同的節點上,請重新附加數據磁碟區。
本文介紹在 AKS 中為您的應用程式提供記憶體的記憶體選項和核心概念。
磁碟區類型
Kubernetes 磁碟區不只是用來儲存和擷取資訊的傳統磁碟。 Kubernetes 磁碟區也可用來將數據插入 Pod,以供其容器使用。
Kubernetes 中的常見磁碟區類型包括 EmptyDirs、Secret和 ConfigMaps。
EmptyDirs
當 Pod 定義了一個 emptyDir
磁碟區並指派給節點時,該磁碟區就會被建立。 如名稱所示,emptyDir
磁碟區一開始是空的。 Pod 中的所有容器都可以讀取和寫入 emptyDir
磁碟區中的相同檔案,不過此磁碟區可以掛接在每個容器中的相同或不同路徑。 基於任何原因從節點移除Pod時,會永久刪除 emptyDir
中的數據。
秘密
秘密 是保存少量敏感數據的物件,例如密碼、令牌或密鑰。 否則,這些資訊會包含在 Pod 規格或容器映像中。 藉由使用秘密,您可以避免將機密數據直接內嵌在應用程式程序代碼中。 由於秘密可以獨立於使用這些秘密的 Pod 建立,因此在建立、檢視和編輯 Pod 的過程中,可能會降低公開秘密(及其數據)的風險。 Kubernetes 以及叢集中執行的應用程式,也可以對 Secrets 採取額外的安全措施,例如防止敏感數據寫入非揮發性存儲。 雖然秘密與 ConfigMap 類似,但特別設計用來儲存機密數據。
您可以使用秘密進行下列用途:
Kubernetes 控制平面也會使用秘密,例如 啟動程式令牌秘密,這是協助自動化節點註冊的機制。
ConfigMaps
ConfigMap 是 Kubernetes 物件,用來將非機密數據儲存在索引鍵/值組中。 Pod 可以取用 ConfigMaps 作為環境變數、命令行自變數或 磁碟區中的組態檔,。 ConfigMap 可讓您將環境特定設定與 容器映射分離,以便輕鬆地移植應用程式。
ConfigMap 不提供保密或加密。 如果您想要儲存的數據是機密數據,請使用 Secret,而不是 ConfigMap,或使用其他 (第三方) 工具來將數據保持私人。
您可以使用 ConfigMap,將組態資料與應用程式程式代碼分開設定。 例如,假設您正在開發可在自己的計算機上執行的應用程式(用於開發)和雲端中(以處理實際流量)。 您可以撰寫程式代碼來尋找名為 DATABASE_HOST
的環境變數。 在本機,您可以將該變數設定為 localhost
。 在雲端中,您會將其設定為參考 Kubernetes Service,以公開資料庫元件給叢集。 這可讓您擷取在雲端中執行的容器映像,並視需要在本機偵錯完全相同的程序代碼。
永續性磁碟區
作為 Pod 生命週期一部分而定義和創建的磁碟區,僅在您刪除 Pod 之前存在。 Pod 通常預期在維護事件中,若重新排程到不同的主機上,特別是在 StatefulSets 中,其存儲應能夠保留。 永續性磁碟區 (PV) 是由 Kubernetes API 所建立和管理的記憶體資源,可存在於個別 Pod 的存留期之外。 您可以使用下列 Azure 記憶體服務來提供永續性磁碟區:
如 磁碟區 一節所述,Azure 磁碟或 Azure 檔案記憶體的選擇通常取決於同時存取數據或效能層的需求。
叢集管理員可以以靜態方式 建立永續性磁碟區,也可以由 Kubernetes API 伺服器動態 建立磁碟區。 如果 Pod 已排程並要求目前無法使用的儲存空間,Kubernetes 可以建立基礎 Azure 磁碟或檔案儲存體,並將其連結至 Pod。 動態布建會使用 記憶體類別 來識別需要建立的資源類型。
重要
由於兩個操作系統之間在文件系統支持上的不同,Windows 和 Linux Pod 無法共享持久性磁碟區。
如果您想要完全受控的解決方案來存取數據區塊層級,請考慮使用 Azure Container Storage,而不是 CSI 驅動程式。 Azure Container Storage 與 Kubernetes 整合,允許動態和自動布建永續性磁碟區。 Azure Container Storage 支援 Azure 磁碟、暫時磁碟和 Azure 彈性 SAN(預覽版)作為備份記憶體,為 Kubernetes 叢集上執行的具狀態應用程式提供彈性和延展性。
記憶體類別
若要指定不同層級的記憶體,例如進階或標準,您可以建立 記憶體類別。
記憶體類別也會定義 回收原則。 當您刪除永續性磁碟區時,回收原則會控制基礎 Azure 儲存體資源的行為。 基礎資源可以刪除或保留,以便與未來的 Pod 一起使用。
針對使用 Azure Container Storage的叢集,您會看到名為 acstor-<storage-pool-name>
的額外記憶體類別。 也會建立內部儲存類別。
針對使用 容器記憶體介面 (CSI) 驅動程式的叢集,會建立下列額外的記憶體類別:
記憶體類別 | 描述 |
---|---|
managed-csi |
使用 Azure 標準 SSD 本地備援記憶體 (LRS) 來建立受控磁碟。 回收政策確保當使用 Azure 磁碟的持久性磁碟區被刪除時,基礎 Azure 磁碟也會被刪除。 記憶體類別也會將永續性磁碟區設定為可擴充。 您可以編輯永續性磁碟區宣告,以指定新的大小。 從 Kubernetes 1.29 版開始,在跨多個可用性區域部署的 Azure Kubernetes Service (AKS) 叢集中,此記憶體類別會利用 Azure 標準 SSD 區域備援記憶體 (ZRS) 來建立受控磁碟。 |
managed-csi-premium |
使用 Azure Premium 本地備援記憶體 (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。 接著,您可以在永續性磁碟區宣告 (PV) 中使用新的儲存類別。
您可以使用 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 之後的磁碟區掛接。
一旦將可用的記憶體資源指派給要求記憶體的Pod,持續性磁碟區就會 系結至永續性磁碟區宣告。 永續性磁碟區會對應至 1:1 對應中的宣告。
下列範例 YAML 指令清單顯示永續性磁碟區宣告,該宣告會使用 受控進階 儲存體類別,並要求大小 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 會自動將虛擬機器的 OS 磁碟複寫至 Azure 儲存體,以避免 VM 在遷往另一部主機時遺失資料。 不過,由於容器不是設計來保存本機狀態,因此,此行為提供的價值有限,同時還會有一些缺點。 這些缺點包括但不限於節點佈建較慢及更高的讀取/寫入延遲。
相較之下,暫時性 OS 磁碟只會儲存在主機電腦上,就像暫存磁碟一樣。 藉由此設定,您可以取得更低的讀取/寫入延遲,以及更快的節點縮放和叢集升級。
當您未明確要求適用於 OS 的 Azure 受控磁碟 (部分機器翻譯) 時,如果指定的節點集區設定可能的話,AKS 就會預設為暫時性 OS。
Azure VM 檔提供暫時 OS 磁碟的大小需求和建議。 以下是一些一般尺寸考量:
- 如果您選擇使用 AKS 預設 VM 大小 Standard_DS2_v2 SKU,預設 OS 磁碟大小為 100 GiB,預設 VM 大小支援暫時 OS,但只有 86 GiB 的快取大小。 如果您未明確指定受控磁碟,此組態會預設為受控磁碟。 如果您請求暫時性操作系統,您會收到驗證錯誤。
- 如果您要求與 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大小,則支援暫時OS磁碟,但只有75 GB的暫存記憶體。 如果您未明確指定,此設定會預設為受控 OS 磁碟。 如果您確實要求暫時的 OS 磁碟,您會收到驗證錯誤。
- 如果您要求與 60 GiB OS 磁碟相同的 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 Files,或 Azure Blob。
注意
根據您使用的 VM SKU,Azure 磁碟 CSI 驅動程式可能會有每個節點磁碟區的限制。 對於某些高效能 VM(例如 16 個核心),每個節點的限制為 64 個磁碟區。 若要識別每個 VM SKU 的限制,請檢閱每個 VM SKU 所提供的 最大數據磁碟 資料行。 如需提供的 VM SKU 清單及其對應的詳細容量限制,請參閱 一般用途虛擬機大小。
若要協助判斷 Azure Files 與 Azure NetApp Files 之間最適合您的工作負載,請檢閱 Azure Files 和 Azure NetApp Files 比較一文中提供的訊息。
Azure 磁碟
根據預設,AKS 叢集隨附使用managed-csi
的預先建立 managed-csi-premium
和 儲存體類別。 與 Amazon EBS 類似,這些類別會建立受控磁碟或連結至節點以進行 Pod 存取的區塊裝置。
磁碟類別同時允許靜態和動態磁碟區佈建。 回收原則可確保磁碟是使用永續性磁碟區刪除的。 您可以編輯永續性磁碟區宣告來擴充磁碟。
這些儲存體類別會使用 Azure 受控磁碟搭配本地備援儲存體 (LRS)。 LRS 表示資料在 Azure 主要區域的單一實體位置內具有三個同步複本。 LRS 是成本最低的複寫選項,但無法防止資料中心失敗。 您可以定義使用區域備援記憶體 (ZRS) 受控磁碟的自訂記憶體類別。 區域冗餘儲存(ZRS)會在您選定的區域內,跨三個 Azure 可用性區域同步複寫您的 Azure 受控磁碟。 每個可用性區域都是具有獨立電源、冷卻和網路功能的個別實體位置。 ZRS 磁碟在指定一年內提供至少 99.9999999999% (12 9 秒) 的持久性。 ZRS 受控磁碟可由不同 可用性區域中的虛擬機連結。 ZRS 磁碟目前在並非所有 Azure 區域皆有提供。 如需 ZRS 磁碟的詳細資訊,請參閱 Azure 磁碟 區域備援記憶體 (ZRS) 選項,以取得高可用性。 此外,若要降低數據遺失的風險,您可以使用 Azure Kubernetes Service Backup 或第三方解決方案,例如 Velero 或 Azure 備份 來使用內建快照集技術,來建立磁碟記憶體數據的一般備份或快照集。
您可以使用 Azure 磁碟 來建立 Kubernetes DataDisk 資源。 磁碟類型包括:
提示
針對大部分的生產與開發工作負載,請使用進階 SSD。
因為 Azure 磁碟會掛接為 ReadWriteOnce,所以只能供單一節點使用。 若要讓 Pod 同時在多個節點上存取的儲存體磁碟區,請使用 Azure 檔案。
Azure 進階 SSD v2 磁碟
Azure 進階 SSD v2 磁碟提供 IO 密集的企業工作負載、一致的子磁碟延遲,以及高 IOPS 和輸送量。 進階 SSD v2 磁碟的效能 (容量、輸送量和 IOPS) 可隨時單獨設定,因此在更多情況下都能更輕易地符合成本效益,同時達到效能需求。 如需如何設定新的或現有的 AKS 叢集以使用 Azure 進階 SSD v2 磁碟的詳細資訊,請參閱在 Azure Kubernetes Service 上使用 Azure 進階 SSD v2 磁碟。
Ultra 磁碟儲存體
Ultra 磁碟儲存體是 Azure 受控磁碟層,可為 Azure VM 提供高輸送量、高 IOPS 和一致的低延遲磁碟儲存體。 Ultra 磁碟儲存體適用於資料和交易繁重的工作負載。 與其他磁碟儲存體 SKU 和 Amazon EBS 一樣,Ultra 磁碟儲存體會一次掛接一個 Pod,而且不提供並行存取。
使用旗標 --enable-ultra-ssd
在 AKS 叢集上啟用 Ultra 磁碟儲存體。
如果您選擇 Ultra 磁碟儲存體,請注意其限制,並確定選取相容的 VM 大小。 Ultra 磁碟儲存體可與本地備援儲存體 (LRS) 複寫搭配使用。
自攜式金鑰 (BYOK)
Azure 會靜態加密受控磁碟中的所有資料。 根據預設,資料是以使用 Microsoft 管理的金鑰加密。 若要進一步控制加密金鑰,您可以提供客戶自控金鑰,以用於 AKS 叢集中 OS 和資料磁碟的待用加密。 有關詳細資訊,請參閱在 Azure Kubernetes 服務 (AKS) 中使用 Azure 受控磁碟自攜式金鑰 (BYOK)。
Azure 檔案
磁碟儲存無法提供磁碟區的同時存取,但您可以使用 Azure Files 掛載由 Azure 儲存體支援的伺服器訊息區塊 SMB 3.1.1 版共用或網路檔案系統 NFS 4.1 版共用。 此程序提供類似於 Amazon EFS 的網路連接儲存體。 與磁碟儲存體一樣,提供兩種選項:
- Azure 檔案儲存體標準儲存體由一般硬碟 (HDD) 支援。
- Azure 檔案儲存體進階儲存體會使用高效能 SSD 磁碟機來備份檔案共用。 進階儲存體的最小檔案共用大小為 100 GB。
Azure 檔案儲存體具有下列儲存體帳戶複寫選項,以在失敗時保護您的資料:
- Standard_LRS:標準本地備援儲存體 (LRS)
- Standard_GRS:標準異地備援儲存體 (GRS)
- Standard_ZRS:標準區域備援儲存體 (ZRS)
- Standard_RAGRS:標準 讀取存取異地備援儲存體 (RA-GRS)
- Standard_RAGZRS:標準讀取權限異地區域備援儲存體 (RA-GZRS)
- Premium_LRS:進階本地備援儲存體 (LRS)
- Premium_ZRS:進階區域備援儲存體 (ZRS)
若要將 Azure 檔案儲存體的成本最佳化,請購買 Azure 檔案儲存體容量保留。
Azure NetApp Files
Azure NetApp Files 是在 Azure 上執行的企業級高效能計量檔案記憶體服務,並支援使用 NFS (NFSv3 或 NFSv4.1)、SMB,以及 雙重通訊協定 (NFSv3 和 SMB,或 NFSv4.1 和 SMB) 的磁碟區。 Kubernetes 使用者有兩個選項可針對 Kubernetes 工作負載使用 Azure NetApp Files 磁碟區:
-
靜態建立 Azure NetApp Files 磁碟區。 在此情境中,磁碟區的建立是在 AKS 之外完成的。 磁碟區是使用 Azure CLI 或從 Azure 入口網站建立,然後藉由建立
PersistentVolume
向 Kubernetes 公開。 以靜態方式建立的 Azure NetApp Files 磁碟區有許多限制(例如無法擴充、需要預留過多資源等等)。 在大部分的使用案例中,不建議使用靜態建立的磁碟區。 - 動態建立 Azure NetApp Files 磁碟區,並透過 Kubernetes 協調。 此方法是直接透過 Kubernetes 建立多個磁碟區的 慣用 方式,而且是使用 Astra Trident來達成。 Astra Trident 是符合 CSI 規範的動態記憶體協調器,可協助透過 Kubernetes 原生布建磁碟區。
如需詳細資訊,請參閱 為 Azure Kubernetes Service 設定 Azure NetApp Files。
Azure Blob 記憶體
Azure Blob 記憶體容器記憶體介面 (CSI) 驅動程式 是 Azure Kubernetes Service (AKS) 用來管理 Azure Blob 記憶體生命週期的 CSI 規格相容驅動程式。 CSI 是將任意區塊和檔案記憶體系統公開至 Kubernetes 上容器化工作負載的標準。
透過採用和使用 CSI,AKS 現在可以撰寫、部署和反覆改進外掛程式,以在 Kubernetes 中曝光新儲存系統或改善現有儲存系統。 在 AKS 中使用 CSI 驅動程式可避免必須觸碰核心 Kubernetes 程式代碼,並等候其發行週期。
當您將 Azure Blob 記憶體掛接為檔案系統到容器或 Pod 時,它可讓您將 Blob 記憶體與許多可運作大量非結構化數據的應用程式搭配使用。 例如:
- 記錄檔數據
- 影像、檔和串流視訊或音訊
- 災害復原數據
您可以使用 blobFuse blobFuse 或 網路文件系統 (NFS) 3.0 通訊協定來存取物件記憶體上的數據。 在引進 Azure Blob 記憶體 CSI 驅動程式之前,唯一的選項是手動安裝不支援的驅動程式,以從 AKS 上執行的應用程式存取 Blob 記憶體。 在 AKS 上啟用 Azure Blob 記憶體 CSI 驅動程式時,有兩個內建的記憶體類別:azureblob-fuse-premium,azureblob-nfs-premium。
若要建立具有 CSI 驅動程式支援的 AKS 叢集,請參閱在 AKS 上CSI 驅動程式。 若要深入瞭解使用 NFS 通訊協定之每個 Azure 記憶體類型之間的存取差異,請參閱 比較 Azure 檔案記憶體、Blob 記憶體和 Azure NetApp Files 與 NFS的存取權。
Azure HPC Cache
Azure HPC Cache 會加快對 HPC 工作資料的存取速度,並具備雲端解決方案的所有可擴縮性。 如果您選擇此儲存體解決方案,請務必將 AKS 叢集部署在支援 Azure HPC 快取的區域。
NFS 伺服器
共用 NFS 存取的最佳選項是使用 Azure 檔案儲存體或 Azure NetApp Files。 您也可以在匯出磁碟區的 Azure VM 上建立 NFS 伺服器。
請注意,此選項僅支援靜態佈建。 您必須在伺服器上手動佈建 NFS 共用,且無法自動從 AKS 進行。
此解決方案是以基礎結構即服務 (IaaS) 而不是平台即服務 (PaaS) 為基礎。 您負責管理 NFS 伺服器,包括 OS 更新、高可用性、備份、災害復原和可擴縮性。
攜帶您自己的金鑰 (BYOK) 與 Azure 磁碟
Azure 記憶體會加密待用記憶體帳戶中的所有數據,包括 AKS 叢集的 OS 和數據磁碟。 根據預設,資料是以使用 Microsoft 管理的金鑰加密。 若要進一步控制加密金鑰,您可以提供客戶管理的金鑰,以用於 AKS 叢集的作業系統和數據磁碟的其餘部分進行加密。 如需詳細資訊,請參閱
- BYOK 與 AKS中的 Azure 磁碟。
- Azure 磁碟記憶體的伺服器端加密。
Azure 容器儲存體
Azure 容器儲存體是雲端式磁碟區管理、部署和協調流程服務,專為容器原生建置。 它與 Kubernetes 整合,可讓您動態且自動佈建永續性磁碟區,以儲存 Kubernetes 叢集上執行之具狀態應用程式的資料。
Azure 容器儲存體會針對實際資料記憶體利用現有的 Azure 記憶體供應專案,並提供專為容器所建置的磁碟區協調流程和管理解決方案。 支援的備份儲存體選項包括:
- Azure 磁碟:對儲存體 SKU 和組態的細微控制。 它們適用於第 1 層和一般用途資料庫。
- 暫時性磁碟:利用 AKS 節點上的本機儲存資源 (NVMe 或暫存 SSD)。 最適合不需要資料持久性或內建資料複寫支援的應用程式。 AKS 會探索 AKS 節點上可用的暫時性記憶體,並取得它們以進行磁碟區部署。
- Azure Elastic SAN:依需求佈建,完全受控資源。 適用於一般用途資料庫、串流和傳訊服務、CD/CI 環境以及其他第 1 層/第 2 層工作負載。 多個叢集可以同時存取單一 SAN,不過永續性磁碟區一次只能由一個取用者連結。
到目前為止,為容器提供雲端儲存體需要使用單個容器儲存體介面 (CSI) 驅動程式,以使用適用於以基礎設施即服務 (IaaS) 為中心的工作負載的儲存體服務,並使其適用於容器。 這會建立作業額外負荷,並增加應用程式可用性、延展性、效能、可用性和成本的問題風險。
Azure 容器儲存體衍生自 OpenEBS,這是提供 Kube 容器記憶體功能的開放原始碼解決方案。 透過 Kube 環境中的微服務型記憶體控制器提供受控磁碟區協調流程解決方案,Azure 容器儲存體會啟用真正的容器原生記憶體。
Azure 容器儲存體適用於下列案例:
加速 VM 對容器計劃: Azure 容器儲存體會顯示先前僅適用於 VM 且可供容器使用的 Azure 區塊儲存體供應專案的完整範圍。 這包括暫時性磁碟,可為 Cassandra 等工作負載提供極低的延遲,以及提供原生 iSCSI 和共用佈建目標的 Azure 彈性 SAN。
簡化 Kube 的磁碟區管理: 透過 Kube 控制平面提供磁碟區協調流程,Azure 容器儲存體可讓您輕鬆地在 Kube 內部署和管理磁碟區,而不需要在不同的控制平面之間來回移動。
降低總擁有成本 (TCO): 藉由增加每個 Pod 或節點支援的永續性磁碟區規模來提升成本效益。 藉由動態共用儲存體資源來減少佈建所需的儲存體資源。 請注意,不支持儲存體集區本身的相應擴大支援。
Azure 容器儲存體的主要優點如下:
快速擴增具狀態 Pod: Azure 容器儲存體會透過網路區塊儲存體通訊協定 (NVMe-oF 或 iSCSI) 裝載永續性磁碟區,提供持續性磁碟區的快速連結和中斷連結。 您可以視需要一點點開始部署資源,同時確定應用程式不會在初始化期間或實際執行環境中耗盡或中斷。 應用程式復原功能已透過 Pod 重新產生整個叢集來改善,需要快速移動永續性磁碟區。 Azure 容器儲存體使用遠端網路通訊協定與 Pod 生命週期緊密耦合,以支援 AKS 上具有高度彈性的大規模具狀態應用程式。
改善具狀態工作負載的效能: Azure 容器儲存體可提升讀取效能,並使用 NVMe-oF over RDMA 提供近乎磁碟寫入效能。 這可讓客戶符合各種容器工作負載的效能需求,包括第 1 層 I/O 密集、一般用途、輸送量敏感性和開發/測試。 加速永續性磁碟區的連結/中斷連結時間,並將 Pod 容錯移轉時間降到最低。
Kube 原生磁碟區協調流程: 建立存放集區和永續性磁碟區、擷取快照集,以及使用
kubectl
命令來管理磁碟區的整個生命週期,而不需在不同控制平面作業的工具組之間切換。
協力廠商解決方案
如同 Amazon EKS,AKS 是 Kubernetes 實作,您可以整合第三方 Kubernetes 儲存體解決方案。 以下是 Kubernetes 的第三方儲存體解決方案範例:
- Rook 透過自動化儲存體管理員工作,將分散式儲存體系統轉變為自我管理儲存體服務。 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 Files | X | X | X |
NFS 伺服器 | X | X | X |
Azure HPC Cache | X | X | X |
動態與靜態佈建
動態佈建磁碟區以減少靜態建立永續性磁碟區的管理額外負荷。 設定正確的回收原則,以避免在刪除 Pod 時有未使用的磁碟。
Backup
選擇要備份永續性資料的工具。 此工具應符合您的儲存體類型,例如快照集、Azure 備份、Velero 或 Kasten。
成本最佳化
若要最佳化 Azure 儲存體成本,請使用 Azure 保留。 請務必檢查哪些服務支援 Azure 保留。 另請參閱 Kubernetes 叢集的成本管理。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者:
- Paolo Salvatori | 首席系統工程師
- 蘿拉·尼古拉斯 |資深雲端解決方案架構師
其他投稿人:
- Chad Kittel | 首席軟體工程師
- Ed Price | 資深內容計劃經理
- Theano Petersen | 技術寫入員
若要查看非公開的 LinkedIn 設定檔,請登入 LinkedIn。
下一步
- 適用於 Amazon EKS 專業人員的 AKS
- Kubernetes 身分識別與存取權管理
- Kubernetes 監視和記錄
- 對 Kubernetes 的安全網路存取
- Kubernetes 的成本管理
- Kubernetes 節點和節點集區管理
- 叢集治理