

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 儲存
<a name="cost-opt-storage"></a>

## 概觀
<a name="_overview"></a>

在某些情況下，您可能想要執行需要短期或長期保留資料的應用程式。對於此類使用案例， Pod 可以定義和掛載磁碟區，以便其容器可以利用不同的儲存機制。Kubernetes 支援不同類型的磁碟[區](https://kubernetes.io/docs/concepts/storage/volumes/)，用於暫時性和持久性儲存。儲存體的選擇主要取決於應用程式需求。對於每種方法，都會有成本影響，以下詳述的實務將協助您在 EKS 環境中需要某種形式的儲存體的工作負載實現成本效益。

## 暫時性容積
<a name="_ephemeral_volumes"></a>

暫時性磁碟區適用於需要暫時性本機磁碟區，但不需要在重新啟動後保留資料的應用程式。此範例包括暫存空間、快取和唯讀輸入資料的需求，例如組態資料和秘密。您可以在[此處](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/)找到 Kubernetes 暫時性磁碟區的詳細資訊。大多數暫時性磁碟區 （例如 emptyDir、configMap、downwardAPI、秘密、hostpath) 都由本機連接的可寫入裝置 （通常是根磁碟） 或 RAM 提供支援，因此請務必選擇最具成本效益且效能最佳的主機磁碟區。

### 使用 EBS 磁碟區
<a name="_using_ebs_volumes"></a>

 *我們建議從 [gp3](https://aws.amazon.com/ebs/general-purpose/) 開始做為主機根磁碟區。*這是 Amazon EBS 提供的最新一般用途 SSD 磁碟區，相較於 gp2 磁碟區，它也提供較低的每 GB 價格 （最多 20%)。

### 使用 Amazon EC2 執行個體存放區
<a name="_using_amazon_ec2_instance_stores"></a>

 [Amazon EC2 執行個體存放](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)區為您的 EC2 執行個體提供暫時區塊層級儲存。EC2 執行個體存放區提供的儲存體可透過實體連接至主機的磁碟存取。與 Amazon EBS 不同，您只能在執行個體啟動時連接執行個體存放區磁碟區，而且這些磁碟區只在執行個體的生命週期內存在。它們無法分離並重新連接到其他執行個體。您可以[在這裡](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)進一步了解 Amazon EC2 執行個體存放區。*執行個體存放區磁碟區沒有相關的額外費用。*這使得它們 （執行個體存放區磁碟區） 比具有大型 EBS 磁碟區的一般 EC2 執行個體*更具成本效益*。

若要在 Kubernetes 中使用本機儲存磁碟區，您應該[使用 Amazon EC2 使用者資料](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-add-user-data.html)分割、設定和格式化磁碟區，以便在 Pod 規格中將磁碟區掛載為 [HostPath](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)。或者，您可以利用[本機持久性磁碟區靜態佈建器](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)來簡化本機儲存管理。本機持久性磁碟區靜態佈建器可讓您透過標準 Kubernetes PersistentVolumeClaim (PVC) 界面存取本機執行個體存放區磁碟區。此外，它會佈建 PersistentVolumes (PVs)，其中包含節點親和性資訊，將 Pod 排程至正確的節點。雖然它使用 Kubernetes PersistentVolumes，但 EC2 執行個體存放區磁碟區本質上是暫時性的。寫入暫時性磁碟的資料只能在執行個體的生命週期內使用。當執行個體終止時，資料也是。如需詳細資訊，請參閱此[部落格](https://aws.amazon.com/blogs/containers/eks-persistent-volumes-for-instance-store/)。

請記住，使用 Amazon EC2 執行個體存放區磁碟區時，總 IOPS 限制會與主機共用，並將 Pod 繫結至特定主機。在採用 Amazon EC2 執行個體存放區磁碟區之前，您應該徹底檢閱工作負載需求。

## 持久性磁碟區
<a name="_persistent_volumes"></a>

Kubernetes 通常與執行中無狀態應用程式相關聯。不過，在某些情況下，您可能想要執行微服務，而這些微服務需要保留從一個請求到下一個請求的持久性資料或資訊。資料庫是這類使用案例的常見範例。不過，Pod 和其中的容器或程序本質上是暫時性的。若要將資料保留超過 Pod 的生命週期，您可以使用 PVs 定義在獨立於 Pod 的特定位置對儲存體的存取。*與 PVs 相關的成本高度取決於使用的儲存體類型，以及應用程式如何使用它。*

[這裡](https://docs.aws.amazon.com/eks/latest/userguide/storage.html)列出支援 Amazon EKS 上 Kubernetes PVs 的不同儲存選項類型。以下涵蓋的儲存選項包括 Amazon EBS、Amazon EFS、Amazon FSx for Lustre、Amazon FSx for NetApp ONTAP。

### Amazon Elastic Block Store (EBS) 磁碟區
<a name="_amazon_elastic_block_store_ebs_volumes"></a>

Amazon EBS 磁碟區可作為 Kubernetes PVs 使用，以提供區塊層級儲存磁碟區。這些非常適合依賴隨機讀取和寫入的資料庫，以及執行長時間連續讀取和寫入的輸送量密集型應用程式。[Amazon Elastic Block Store Container Storage Interface (CSI) 驅動程式](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)可讓 Amazon EKS 叢集管理持久性磁碟區的 Amazon EBS 磁碟區的生命週期。容器儲存界面可啟用並促進 Kubernetes 與儲存系統之間的互動。當 CSI 驅動程式部署到您的 EKS 叢集時，您可以透過原生 Kubernetes 儲存資源存取其功能，例如持久性磁碟區 (PVs)、持久性磁碟區宣告 (PVCs) 和儲存類別 SCs)。[此連結](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes)提供如何與 Amazon EBS CSI 驅動程式互動的實用範例。

#### 選擇正確的磁碟區
<a name="_choosing_the_right_volume"></a>

 *我們建議您使用最新一代的區塊儲存 (gp3)，因為它可在價格和效能之間取得適當的平衡*。它還可讓您獨立擴展磁碟區 IOPS 和輸送量，而不需要佈建額外的區塊儲存容量。如果您目前正在使用 gp2 磁碟區，強烈建議遷移至 gp3 磁碟區。部落格文章[將 Amazon EKS 叢集從 gp2 遷移至 gp3 EBS 磁碟區](https://aws.amazon.com/blogs/containers/migrating-amazon-eks-clusters-from-gp2-to-gp3-ebs-volumes/)，說明如何使用需要應用程式停機時間的 CSI [磁碟區快照](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)功能，在 Amazon EKS 叢集**上使用備份和還原從 *gp3* 上的 gp2 遷移。

Amazon EBS 允許變更線上磁碟區大小、IOPS 和輸送量等磁碟區特性。利用此功能，即可使用此[部落格](https://aws.amazon.com/blogs/storage/simplifying-amazon-ebs-volume-migration-and-modification-using-the-ebs-csi-driver/)中所述的任一 PVC 註釋從 *gp3 上的 gp2* 遷移，而無需應用程式停機，這需要 EBS CSI 驅動程式 v1.19.0\$1，或從 Amazon EKS v1.31 和 EBS CSI 驅動程式 1.35 開始，方法是使用[此處](https://aws.amazon.com/blogs/containers/modify-amazon-ebs-volumes-on-kubernetes-with-volume-attributes-classes/)所述的 [VolumeAttributesClass API](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/)。 **

當您的應用程式需要更高的效能，且所需的磁碟區大於單一 [gp3 磁碟區可支援的磁碟區](https://aws.amazon.com/ebs/general-purpose/)時，您應該考慮使用 [io2 區塊表達](https://aws.amazon.com/ebs/provisioned-iops/)式。這種類型的儲存體非常適合您最大、最密集的 I/O 和關鍵任務部署，例如 SAP HANA 或其他低延遲需求的大型資料庫。請記住，執行個體的 EBS 效能受到執行個體效能限制的限制，因此並非所有執行個體都支援 io2 區塊表達磁碟區。您可以在此[文件中](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html)檢查支援的執行個體類型和其他考量事項。

 *單一 gp3 磁碟區最多可支援 16，000 個最大 IOPS、1，000 MiB/s 最大輸送量、16TiB。最新一代的佈建 IOPS SSD 磁碟區，可提供高達 256，000 IOPS、4，000 MiB/s、輸送量和 64TiB。*

在這些選項中，您應該根據應用程式的需求，量身打造最佳的儲存效能和成本。

#### 隨著時間的推移進行監控和最佳化
<a name="_monitor_and_optimize_over_time"></a>

請務必了解應用程式的基準效能，並針對選取的磁碟區進行監控，以檢查是否符合您的需求/期望，或是過度佈建 （例如，佈建 IOPS 未充分利用的情況）。

您可以在累積資料時逐漸增加磁碟區的大小，而不是從頭開始配置大型磁碟區。您可以使用 Amazon Elastic Block Store CSI 驅動程式 [(aws-ebs-csi-driver) 中的磁碟區調整大小](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/resizing)功能動態調整磁碟區大小。 aws-ebs-csi-driver *請記住，您只能增加 EBS 磁碟區大小。*

若要識別和移除任何懸置的 EBS 磁碟區，您可以使用 [AWS 信任顧問的成本最佳化類別](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)。此功能可協助您識別一段時間內寫入活動極低的未連接磁碟區或磁碟區。有一個雲端原生的開放原始碼唯讀工具，稱為 [Popeye](https://github.com/derailed/popeye)，可掃描即時 Kubernetes 叢集，並報告已部署資源和組態的潛在問題。例如，它可以掃描未使用的 PVs和 PVCs並檢查它們是否繫結，或是否有任何磁碟區掛載錯誤。

如需監控的詳細資訊，請參閱 [EKS 成本最佳化可觀測性指南](https://docs.aws.amazon.com/eks/latest/best-practices/cost-opt-observability.html)。

您可以考慮的另一個選項是 [AWS Compute Optimizer Amazon EBS 磁碟區建議](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ebs-recommendations.html)。此工具會自動識別最佳磁碟區組態，以及所需的正確效能等級。例如，它可以根據過去 14 天內的最大使用率，用於與佈建 IOPS、磁碟區大小和 EBS 磁碟區類型相關的最佳設定。它也會量化從其建議衍生的潛在每月成本節省。您可以檢閱此[部落格](https://aws.amazon.com/blogs/storage/cost-optimizing-amazon-ebs-volumes-using-aws-compute-optimizer/)以取得更多詳細資訊。

#### 備份保留政策
<a name="_backup_retention_policy"></a>

您可以透過拍攝point-in-time快照來備份 Amazon EBS 磁碟區上的資料。Amazon EBS CSI 驅動程式支援磁碟區快照。您可以使用[此處](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/snapshot/README.md)概述的步驟，了解如何建立快照和還原 EBS PV。

後續快照是增量備份，這表示只會儲存最近快照之後在裝置上變更的區塊。如此無須複製所有資料，可大幅減少建立快照所需的時間，並節省儲存成本。不過，在沒有適當保留政策的情況下增加舊 EBS 快照的數量，可能會導致大規模操作時產生非預期的成本。如果您透過 AWS API 直接備份 Amazon EBS 磁碟區，則可以利用 [Amazon Data Lifecycle Manager](https://aws.amazon.com/ebs/data-lifecycle-manager/) (DLM)，為 Amazon Elastic Block Store (EBS) 快照和 EBS 支援的 Amazon Machine Image (AMIs) 提供自動化的政策型生命週期管理解決方案。主控台可讓您更輕鬆地自動建立、保留和刪除 EBS 快照和 AMIs。

**注意**  
目前無法透過 Amazon EBS CSI 驅動程式使用 Amazon DLM。

在 Kubernetes 環境中，您可以利用名為 [Velero](https://velero.io/) 的開放原始碼工具來備份 EBS 持久性磁碟區。您可以在排程任務使備份過期時設定 TTL 旗標。以下是來自 Velero 的[指南](https://velero.io/docs/v1.12/how-velero-works/#set-a-backup-to-expire)範例。

### Amazon Elastic File System
<a name="_amazon_elastic_file_system_efs"></a>

 [Amazon Elastic File System (EFS)](https://aws.amazon.com/efs/) 是一種無伺服器、全彈性的檔案系統，可讓您使用標準檔案系統界面和檔案系統語意來共用檔案資料，以處理廣泛的工作負載和應用程式。工作負載和應用程式的範例包括 Wordpress 和 Drupal、JIRA 和 Git 等開發人員工具，以及 Jupyter 等共用筆記本系統以及主目錄。

Amazon EFS 的主要優點之一是，它可以由分散在多個節點和多個可用區域的多個容器掛載。另一個好處是您只需為所使用的儲存體付費。當您新增和移除不需要容量規劃的檔案時，EFS 檔案系統會自動成長和縮減。

若要在 Kubernetes 中使用 Amazon EFS，您需要使用 Amazon Elastic File System Container Storage Interface (CSI) Driver， [aws-efs-csi-driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver)。目前，驅動程式可以動態建立[存取點](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html)。不過，必須先佈建 Amazon EFS 檔案系統，並提供 做為 Kubernetes 儲存類別參數的輸入。

#### 選擇正確的 EFS 儲存類別
<a name="_choosing_the_right_efs_storage_class"></a>

Amazon EFS 提供[四個儲存類別](https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html)。

兩個標準儲存類別：
+ Amazon EFS 標準
+  [Amazon EFS Standard-Infrequent Access](https://aws.amazon.com/blogs/aws/optimize-storage-cost-with-reduced-pricing-for-amazon-efs-infrequent-access/) (EFS Standard-IA)

兩個單區域儲存類別：
+  [Amazon EFS 單區域](https://aws.amazon.com/blogs/aws/new-lower-cost-one-zone-storage-classes-for-amazon-elastic-file-system/) 
+ Amazon EFS One Zone-Infrequent Access (EFS One Zone-IA)

不常存取 (IA) 儲存類別針對未每天存取的檔案進行成本最佳化。透過 Amazon EFS 生命週期管理，您可以將生命週期政策期間 (7、14、30、60 或 90 天） 未存取的檔案移至 IA 儲存類別*，相較於 EFS Standard 和 EFS One Zone 儲存類別，這些儲存類別分別可將儲存成本降低高達 92%*。

透過 EFS Intelligent-Tiering，生命週期管理會監控檔案系統的存取模式，並自動將檔案移至最佳的儲存類別。

**注意**  
aws-efs-csi-driver 目前無法控制變更儲存類別、生命週期管理或 Intelligent-Tiering。這些應該在 AWS 主控台或透過 EFS APIs 手動設定。

**注意**  
aws-efs-csi-driver 與以視窗為基礎的容器映像不相容。

**注意**  
由於 [DiskUsage](https://github.com/kubernetes/kubernetes/blob/ee265c92fec40cd69d1de010b477717e4c142492/pkg/volume/util/fs/fs.go#L66) 函數會耗用與檔案系統大小成比例的記憶體量，因此啟用 *vol-metrics-opt-in* （發射磁碟區指標） 時，存在已知的記憶體問題。*目前，我們建議在大型檔案系統上停用* *`--vol-metrics-opt-in` 選項，以避免耗用太多記憶體。以下是 github 問題[連結](https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/1104)，以取得更多詳細資訊。*

### Amazon FSx for Lustre
<a name="_amazon_fsx_for_lustre"></a>

Lustre 是一種高效能平行檔案系統，通常用於需要高達數百 GB/秒輸送量和每次操作延遲低於毫秒的工作負載。它用於機器學習訓練、財務建模、HPC 和影片處理等案例。[Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) 提供具有可擴展性和效能的全受管共用儲存體，與 Amazon S3 無縫整合。

您可以使用 FSx for Lustre 支援的 Kubernetes 持久性儲存磁碟區，使用 Amazon EKS 的 [FSx for Lustre CSI 驅動程式](https://github.com/kubernetes-sigs/aws-fsx-csi-driver)或 AWS 上的自我管理 Kubernetes 叢集。如需詳細資訊和範例，請參閱 [Amazon EKS 文件](https://docs.aws.amazon.com/eks/latest/userguide/fsx-csi.html)。

#### Amazon S3 的連結
<a name="_link_to_amazon_s3"></a>

建議將位於 Amazon S3 上的高耐用性長期資料儲存庫與您的 FSx for Lustre 檔案系統連結。一旦連結，大型資料集會視需要從 Amazon S3 延遲載入至 FSx for Lustre 檔案系統。您也可以執行分析並將結果傳回 S3，然後刪除 Lustre 檔案系統。

#### 選擇正確的部署和儲存選項
<a name="_choosing_the_right_deployment_and_storage_options"></a>

FSx for Lustre 提供不同的部署選項。第一個選項稱為*暫存*，不會複寫資料，而第二個選項稱為*持久*性，顧名思義，會保留資料。

第一個選項 *（速記*) 可用來*降低暫時性短期資料處理的成本。*持久性部署選項*是專為長期儲存而設計*，可自動複寫 AWS 可用區域內的資料。它還支援 SSD 和 HDD 儲存。

您可以在 FSx 中的參數下，為 lustre 檔案系統的 Kubernetes StorageClass 設定所需的部署類型。以下是提供範例範本[的連結](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass)。

**注意**  
對於對延遲敏感的工作負載或需要最高 IOPS/輸送量層級的工作負載，您應該選擇 SSD 儲存。對於不對延遲敏感的以輸送量為中心的工作負載，您應該選擇 HDD 儲存。

#### 啟用資料壓縮
<a name="_enable_data_compression"></a>

您也可以指定「LZ4」為資料壓縮類型，在檔案系統上啟用資料壓縮。啟用後，所有新寫入的檔案都會在 FSx for Lustre 上自動壓縮，再寫入磁碟，並在讀取時解壓縮。LZ4 資料壓縮演算法無失真，因此原始資料可以從壓縮資料完全重建。

您可以在 FSx 中 lustre 檔案系統的 Kubernetes StorageClass 的參數下，將資料壓縮類型設定為 LZ4。當值設定為 NONE 時，壓縮會停用，這是預設值。[此連結](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass)提供範例範本。

**注意**  
Amazon FSx for Lustre 與以視窗為基礎的容器映像不相容。

### Amazon FSx for NetApp ONTAP
<a name="_amazon_fsx_for_netapp_ontap"></a>

 [Amazon FSx for NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/) 是建置在 NetApp ONTAP 檔案系統的全受管共用儲存體。FSx for ONTAP 提供功能豐富、快速且靈活的共用檔案儲存，可從 AWS 或內部部署中執行的 Linux、Windows 和 macOS 運算執行個體廣泛存取。

Amazon FSx for NetApp ONTAP 支援兩個儲存層：*1/主要層*和 *2/容量集區層。*

*主要層*是佈建的高效能 SSD 型層，用於主動、延遲敏感的資料。全彈性*容量集區層*針對不常存取的資料進行成本最佳化、隨著資料分層而自動擴展，並提供幾乎無限制的 PB 容量。您可以在容量集區儲存上啟用資料壓縮和重複資料刪除，並進一步減少資料使用的儲存容量。NetApp 的原生政策型 FabricPool 功能會持續監控資料存取模式，並在儲存層之間自動雙向傳輸資料，以最佳化效能和成本。

NetApp 的 Astra Trident 使用 CSI 驅動程式提供動態儲存協同運作，可讓 Amazon EKS 叢集管理 Amazon FSx for NetApp ONTAP 檔案系統支援的持久性磁碟區 PVs 生命週期。若要開始使用，請參閱 Astra Trident 文件中的[使用 Astra Trident 與 Amazon FSx for NetApp ONTAP](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html)。

## 其他考量
<a name="_other_considerations"></a>

### 最小化容器映像的大小
<a name="_minimize_the_size_of_container_image"></a>

部署容器後，容器映像會以多層的形式快取在主機上。透過減少映像的大小，可以減少主機上所需的儲存量。

透過從頭開始使用縮減的基礎映像，例如暫存映像或[無痕](https://github.com/GoogleContainerTools/distroless)容器映像 （僅包含您的應用程式及其執行時間相依性），*除了減少攻擊表面積和縮短映像提取時間等輔助優點之外，您還可以降低儲存成本。*

您也應該考慮使用開放原始碼工具，例如 [Slim.ai](https://www.slim.ai/docs/quickstart)，提供簡單、安全的方式來建立最少的映像。

多層套件、工具、應用程式相依性、程式庫可以輕鬆膨脹容器映像大小。透過使用多階段組建，您可以選擇性地將成品從一個階段複製到另一個階段，排除最終映像中不需要的所有項目。您可以在[此處](https://docs.docker.com/get-started/09_image_best/)查看更多映像建置最佳實務。

要考慮的另一件事是保留快取映像的時間。使用特定磁碟量時，您可能想要清除映像快取中的過時映像。這樣做有助於確保您有足夠的空間進行主機操作。根據預設， [kubelet](https://kubernetes.io/docs/reference/generated/kubelet) 每五分鐘對未使用的映像和每分鐘未使用的容器執行垃圾收集。

 *若要為未使用的容器和映像垃圾收集設定選項，請使用[組態檔案](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/)調整 kubelet，並使用 [https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/) 資源類型變更與垃圾收集相關的參數。*

您可以在 Kubernetes [文件](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#containers-images)中進一步了解。