編輯

共用方式為

Kubernetes 的成本管理

Azure 成本管理
Azure Kubernetes Service (AKS)
Azure 受控磁碟
Azure 儲存體
Azure 虛擬機器

本指南說明 Azure Kubernetes Service （AKS） 與 Amazon Elastic Kubernetes Service （Amazon EKS） 相比，定價和成本管理的運作方式。 本文說明如何優化成本，並實作 AKS 叢集的成本治理解決方案。

注意

本文是一系列文章的一部分，可協助熟悉 Amazon EKS 的專業人員瞭解 Azure Kubernetes Service （AKS）。

Amazon EKS 成本基本概念

在 Amazon EKS 中，您會為每個 Amazon EKS 叢集支付每小時固定價格。 您也會為叢集所使用的網路、作業工具和記憶體付費。

Amazon EKS 背景工作節點是標準 Amazon EC2 實例，因此會產生一般 Amazon EC2 價格。 您也會支付您布建以執行 Kubernetes 背景工作節點的其他 Amazon Web Services （AWS） 資源的費用。

使用 Amazon EKS 受控節點群組不需要額外費用。 您只需支付您布建的 AWS 資源，包括 Amazon EC2 實例、Amazon EBS 磁碟區、Amazon EKS 叢集時數，以及任何其他 AWS 基礎結構。

建立受控節點群組時，您可以選擇使用 隨選或現成實例容量類型 來管理代理程序節點的成本。 Amazon EKS 會部署受控節點群組，其中包含 所有隨選或所有 Spot 實例的 Amazon EC2 自動調整群組 。

使用隨選實例時，您會以第二個方式支付計算容量費用，而不需要長期承諾。 Amazon EC2 Spot Instances 是備用 Amazon EC2 容量，相較於隨選價格提供折扣。

  • 當 EC2 需要容量回來時，Amazon EC2 Spot 實例可能會中斷兩分鐘的中斷通知。

  • Amazon 提供 Spot Fleet，這個方法可將隨選實例和現成實例群組自動化，以及 Spot Instance Advisor，以協助預測哪些區域或可用性區域可能會提供最少的中斷。

  • AWS Spot 實例價格會有所不同。 AWS 會根據現成實例容量的長期供需趨勢來設定價格，而且您支付實例啟動期間生效的價格。

Azure Kubernetes Service 成本分析

Azure Kubernetes Service （AKS） 叢集依賴各種 Azure 資源，例如虛擬機、虛擬磁碟、負載平衡器和公用 IP 位址。 這些資源可由多個應用程式使用，這些應用程式可能由組織內的不同小組管理。 這些資源的耗用量模式可能會有所不同，導致對叢集資源總成本的貢獻不同。 此外，某些應用程式可能會跨多個叢集佔用使用量，讓成本歸因和管理成為挑戰。

針對叢集包含單一工作負載的案例， Microsoft成本管理 可用來測量叢集資源群組下的叢集資源耗用量。 不過，某些案例並非單獨由該解決方案所涵蓋，例如：

  • 資源使用量的細微細分，例如計算、網路和記憶體。
  • 區分個別應用程式成本和共用成本。
  • 分析相同訂用帳戶範圍中多個叢集的成本。

為了提高成本可檢視性，AKS 已與 Microsoft 成本管理整合，以提供叢集和命名空間等 Kubernetes 建構的詳細成本向下鑽研。 此整合可在 Azure 計算、網路和記憶體類別中進行成本分析。

AKS 成本分析附加元件建置在 OpenCost 上，這是使用方式數據收集的開放原始碼專案。 它會藉由將數據與您的 Azure 發票對帳來提供成本可見度。 處理後的數據會直接顯示在成本管理成本分析入口網站中。 如需詳細資訊，請參閱 Azure Kubernetes Service 成本分析。

成本定義

在 Kubernetes 命名空間和資產檢視中，您會看到費用，例如：

  • 閑置費用：代表任何工作負載未使用之可用資源容量的成本。
  • 服務費用： 代表與運行時間服務等級協定（SLA） 和適用於容器的Defender Microsoft等服務相關聯的費用。
  • 系統費用： 代表 AKS 在每個節點上保留的容量成本，以執行叢集所需的系統進程。
  • 未配置的費用：代表無法配置給命名空間的資源成本。

AKS 成本基本概念

Kubernetes 架構是以兩個層級為基礎，控制平面和一或多個節點或節點集區。 AKS 定價模型是以兩個 Kubernetes 架構層為基礎。

  • 控制 平面 提供 核心 Kubernetes 服務，例如 API 伺服器和 etcd，以及應用程式工作負載協調流程。 Azure 平臺會管理 AKS 控制平面，而針對 AKS 免費層，控制平面 不需要任何成本。

  • 節點，也稱為代理程序節點或背景工作節點，裝載 Kubernetes 工作負載和應用程式。 在 AKS 中，客戶完全管理和支付代理程式節點的所有成本。

下圖顯示 AKS Kubernetes 架構中控制平面與節點之間的關聯性。

顯示 AKS 架構中控制平面和節點的圖表。

控制平面

當您建立 AKS 叢集時，Azure 會自動布建並設定控制平面層。 針對 AKS 免費層，控制平面是免費的。

針對較高的控制平面服務等級協定 （SLA），您可以在標準層中建立 AKS 叢集。 運行時間 SLA 預設包含在標準層中，且會依每個叢集啟用。 定價為每一個叢集每小時 $0.10 美元。 如需詳細資訊，請參閱 AKS 定價詳細數據。

標準層中的叢集有更多的控制平面資源，例如 API 伺服器實例數目、Etcd 資源限制、 延展性高達 5,000 個節點，以及現有的財務支援的運行時間 SLA 支援。 AKS 會跨更新和容錯網域使用主要節點複本，以符合可用性需求。

最好在生產工作負載中使用標準層，以提供更高的控制平面元件可用性。 免費層叢集的復本和有限的控制平面資源較少，不建議用於生產工作負載。

節點

在 AKS 中，您會在一或多個節點集區中建立代理程式或背景工作角色節點，以在 Kubernetes 環境中使用許多 Azure 核心功能。 AKS 只會針對連結至 AKS 叢集的節點收費。

AKS 節點會使用數個 Azure 基礎結構資源，包括虛擬機擴展集、虛擬網路和受控磁碟。 例如，您可以直接在 AKS 內使用大部分的 Azure 虛擬機 （VM） 類型。 您可以使用 Azure 保留 和 Azure 節省方案進行計算 ，以取得這些資源的大幅折扣。

AKS 叢集定價是以節點集區中 VM 的類別、數目和大小為基礎。 VM 成本取決於大小、CPU 類型、vCPU 數目、記憶體、系列和記憶體類型可用，例如高效能固態硬碟 （SSD） 或標準 HDD。 如需詳細資訊，請參閱 虛擬機系列。 根據應用程式需求、節點數目和叢集延展性需求規劃節點大小。

如需代理程式節點和節點集區的詳細資訊，請參閱 本系列中的節點 集區一文，以及 建立和管理 Azure Kubernetes Service （AKS） 中叢集的多個節點集區。

AKS 叢集部署

每個 AKS 部署跨越兩個 Azure 資源群組。

  • 您建立第一個資源群組，其中只包含 Kubernetes 服務資源，且沒有與其相關聯的成本。

  • AKS 資源提供者會在部署期間自動建立第二個或節點資源群組。 此資源群組的預設名稱是 MC_<resourcegroupname>_<clustername>_<location>，但您可以指定另一個名稱。 如需詳細資訊，請參閱 為 AKS 節點資源群組提供我自己的名稱。

    節點資源群組包含所有叢集基礎結構資源，而且是您訂用帳戶費用的叢集資源。 資源包括 Kubernetes 節點 VM、虛擬網路、記憶體和其他服務。 AKS 會在刪除叢集時自動刪除節點資源群組，因此您應該只將它用於共用叢集生命周期的資源。

計算成本

您會根據其大小和使用量來支付 Azure VM 的費用。 如需 Azure 計算與 AWS 比較方式的相關信息，請參閱 Azure 和 AWS 上的計算服務。

一般而言，您為節點集區選取的 VM 大小愈大，代理程序節點的每小時成本就越高。 您用於節點集區的 VM 系列越特製化，例如圖形處理單元（GPU）啟用或記憶體優化，集區成本就越高。

調查 Azure VM 定價時，請注意下列幾點：

  • 每個區域的價格不同，並非所有服務和 VM 大小都可在每個區域中使用。

  • 有多個 VM 系列，已針對不同類型的工作負載進行優化。

  • 作為OS磁碟驅動器使用的受控磁碟會另外收費，您必須將其成本新增至您的估計值。 受控磁碟大小取決於類別，例如標準 HDD、標準 SSD、進階 SSD 或 Ultra 磁碟記憶體。 每秒的輸入輸出作業數 （IOPS） 和輸送量以 MB/秒為單位取決於大小和類別。 暫時OS磁碟 是免費的，並包含在VM價格中。

  • 數據磁碟，包括使用永續性磁碟區宣告建立的數據磁碟是選擇性的，而且會根據其類別個別收費，例如標準 HDD、標準 SSD、進階 SSD 和 Ultra 磁碟記憶體。 您必須明確地將數據磁碟新增至成本估計。 允許的數據磁碟數目、暫存記憶體 SSD、IOPS，以及 MB/秒的輸送量取決於 VM 大小和類別。

  • 代理程式節點啟動並執行的時間越多，叢集總成本就越高。 開發環境通常不需要持續執行。

  • 網路介面 （NIC） 是免費的。

儲存體費用

容器記憶體介面 （CSI） 是將區塊和檔案記憶體系統公開至 Kubernetes 上容器化工作負載的標準。 藉由採用和使用 CSI，AKS 可以撰寫、部署及逐一查看公開 Kubernetes 儲存系統的外掛程式，而不需要觸及核心 Kubernetes 程式代碼或等待其發行週期。

如果您在 AKS 叢集上執行使用 CSI 永續性磁碟區的工作負載，請考慮應用程式佈建和使用之記憶體的相關成本。 AKS 上的 CSI 記憶體驅動程式提供下列記憶體選項的原生支援：

  • Azure 磁碟 會建立 Kubernetes 數據磁碟資源。 Azure 磁碟可以使用採用高效能 SSD 的 Azure 進階儲存體，或是採用一般 HDD 或標準 HDD 的 Azure 標準儲存體。 大部分的生產與開發工作負載都會使用 進階儲存體。 Azure 磁碟會掛接為 ReadWriteOnce，讓它們只能供一個 AKS 節點使用。 針對多個 Pod 可以同時存取的記憶體磁碟區，請使用 Azure 檔案儲存體。 如需成本資訊，請參閱 受控磁碟 定價。

  • Azure 檔案儲存體 將伺服器傳訊區塊 （SMB） 3.0/3.1 檔案共用掛接至 AKS Pod Azure 儲存體 帳戶支援。 您可以跨多個節點和 Pod 共享數據。 Azure 檔案儲存體 可以使用標準記憶體，由一般 HDD 支援，或使用高效能 SSD 支援的進階記憶體。 Azure 檔案儲存體 會使用 Azure 儲存體 帳戶，並根據下列因素產生費用：

    • 服務：Blob、檔案、佇列、數據表或非受控磁碟
    • 記憶體帳戶類型：GPv1、GPv2、Blob 或進階 Blob
    • 復原能力：本地備援記憶體 （LRS）、區域備援記憶體 （ZRS）、異地備援記憶體 （GRS） 或讀取許可權異地備援記憶體 （RA-GRS）
    • 存取層：經常性存取層、非經常性存取層或封存
    • 作業和數據傳輸
    • GB 中的已使用容量

  • Azure NetApp Files 可在數個 SKU 層中使用，且至少需要 4 TiB 的布建容量，且會遞增 1 TiB。 Azure NetApp Files 費用是以下列因素為基礎：

    • SKU
    • 復原能力：LRS、ZRS 或 GRS
    • 布建的大小或容量，而非使用的容量
    • 作業及資料傳輸
    • 備份和還原

網路成本

數個 Azure 網路服務可以提供在 AKS 中執行之應用程式的存取權：

  • Azure Load Balancer。 根據預設，Load Balancer 會使用標準 SKU。 Load Balancer 費用是以下列為基礎：

    • 規則：已設定的負載平衡和輸出規則數目。 輸入網路位址轉換 （NAT） 規則不會計入規則總數。
    • 已處理的數據：處理輸入和輸出的數據量，與規則無關。 標準負載平衡器沒有每小時的費用，且未設定任何規則。

  • Azure 應用程式閘道。 AKS 通常會透過 應用程式閘道 輸入控制器使用 應用程式閘道，或透過手動管理 應用程式閘道 來前端不同的輸入控制器。 應用程式閘道 支援閘道路由、傳輸層安全性 （TLS） 終止和 Web 應用程式防火牆 功能。 應用程式閘道 費用是以下列為基礎：

    • 固定價格依小時或部分小時設定。
    • 容量單價，以使用量為基礎的成本。 每個容量單位最多都有一個計算單位、2,500 個持續性連線和 2.22 Mbps 輸送量。

  • 公用IP位址 具有相依於下列專案的相關聯成本：

    • 保留與動態關聯。
    • 基本與區域備援標準層。

向外延展成本

調整 AKS 叢集有多個選項，可將額外的容量新增至節點集區：

  • 您可以視需要手動更新屬於節點集區一部分的 VM 數目，或新增更多節點集區。

  • AKS 叢集自動調整程式 會監看因為資源限制而無法在節點上排程的 Pod，並自動增加節點數目。

  • AKS 支援使用虛擬 kubelet 實作，在 Azure 容器執行個體 上執行容器。 AKS 虛擬節點會布建 容器執行個體 Pod，以秒為單位啟動，讓 AKS 以足夠的容量執行平均工作負載。 當 AKS 叢集用盡容量時，您可以相應放大更多 容器執行個體 Pod，而不需要管理任何其他伺服器。 您可以將此方法與叢集自動調整程式和手動調整結合。

如果您使用隨選調整或叢集自動調整程式，請考慮新增的 VM。 容器執行個體 費用是以下列因素為基礎：

  • 每個容器群組的使用量型計量計費
  • 收集 vCPU 和記憶體
  • 單一容器使用或多個容器共用
  • 使用共用網路和節點生命週期的共同排程容器
  • 從映像提取啟動或重新啟動計算的使用量持續時間，直到停止為止
  • 已新增 Windows 容器群組的費用

升級成本

AKS 叢集生命週期的一部分牽涉到定期升級至最新的 Kubernetes 版本。 請務必套用最新的安全性版本並取得最新的功能。 您可以手動或自動升級 AKS 叢集和單一節點集區。 如需詳細資訊，請參閱 升級 Azure Kubernetes Service （AKS） 叢集。

根據預設，AKS 會設定升級以激增一個額外的節點。 設定的預設值1max-surge會藉由建立額外的節點來取代舊版節點，以在封鎖或清空現有應用程式之前，將工作負載中斷降至最低。 您可以自定義 max-surge 每個節點集區的值，以在升級速度和升級中斷之間取得取捨。 max-surge增加值會更快完成升級程式，但的較大值max-surge可能會在升級程序期間造成中斷，併產生額外的 VM 成本。

其他成本

根據使用量和需求，AKS 叢集可能會產生下列額外成本：

成本最佳化

下列建議可協助您優化 AKS 叢集成本：

  • 檢閱 適用於 AKS 的 Azure 架構架構成本優化 一節。

  • 對於多租使用者解決方案，實體隔離成本更高，而且會增加管理額外負荷。 邏輯隔離需要更多 Kubernetes 體驗，並增加變更和安全性威脅的介面區，但共用成本。

  • Azure 保留 可協助您節省成本，方法是承諾一年或三年期的數項產品方案，例如 AKS 叢集中的 VM。 您可以藉由保留容量來獲得折扣。 使用適用於記憶體和計算的 Azure 保留專案來降低代理程式節點的成本。

    保留最多可從隨用隨付價格降低 72% 的資源成本，而且不會影響資源的運行時間狀態。 購買保留之後，折扣就會自動套用至相符的資源。 您可以從 Azure 入口網站，或使用 Azure REST API、PowerShell 或 Azure CLI 購買保留。 如果您使用依賴 Log Analytics 工作區的操作工具，請考慮也使用此記憶體的保留。

  • 將一或多個現成節點集區新增至 AKS 叢集。 現成節點集區是 Azure Spot 虛擬機器擴展集 支援的節點集區。 使用 AKS 叢集節點的現成 VM，可大幅節省成本，利用未使用的 Azure 容量。 可用未使用的容量數量會根據數個因素而有所不同，包括節點大小、區域和一天中的時間。 如果可用的容量，Azure 會配置現成節點，但沒有現成節點的 SLA。 備份現成節點集區的現成擴展集會部署在單一容錯網域中，而且不提供高可用性保證。 當 Azure 需要容量回來時，Azure 基礎結構會收回現成節點。

    當您建立現成節點集區時，您可以定義每小時支付的最高價格，並啟用叢集自動調整程式，這是建議用於現成節點集區。 叢集自動調整程式會根據執行中的工作負載相應放大和相應放大節點集區中的節點數目。 針對現成節點集區，如果仍然需要節點，叢集自動調整程式會在收回后相應放大節點數目。 如需詳細資訊，請參閱 將現成節點集區新增至 Azure Kubernetes Service （AKS） 叢集。

  • 根據您的工作負載的CPU和記憶體需求，為您的AKS叢集節點集區選擇正確的 VM大小 。 Azure 提供許多不同的 VM 實例類型，其符合各種使用案例，以及 CPU、記憶體、記憶體和網路容量的不同組合。 每個類型都有一或多個大小，因此您可以輕鬆地調整資源。

    您現在可以使用在 Ampere Altra ARM 處理器上執行的 AKS 來部署和管理容器化應用程式。 如需詳細資訊，請參閱使用 Ampere Altra ARM 處理器的 Azure 虛擬機器。

  • 針對特殊用途和工作負載，建立具有不同 VM 大小的多個節點集區。 使用 Kubernetes 污點和容忍 和 節點標籤 ，在特定節點集區上放置耗用大量資源的應用程式，以避免發生雜亂的鄰近問題。 讓這些節點資源可供需要它們的工作負載使用，且不會在這些節點上排程其他工作負載。 針對不同的節點集區使用不同的 VM 大小，也可以將成本優化。 如需詳細資訊，請參閱 在 Azure Kubernetes Service （AKS） 中使用多個節點集區。

  • 系統模式節點集區至少必須包含一個節點，而使用者模式節點集區可以包含零個或多個節點。 您可以盡可能設定使用者模式節點集區，以自動從 0 調整為 N 節點。 您可以使用水準 Pod 自動調整程式，將工作負載設定為相應放大和相應縮小。 以 CPU 和記憶體為基礎自動調整，或使用 Kubernetes 事件驅動自動調整 （KEDA） 來根據 Apache Kafka、RabbitMQ 或 Azure 服務匯流排 等外部系統的計量進行自動調整。

  • 請務必正確設定 Pod的要求和限制 ，以改善應用程式密度，並避免將太多CPU和記憶體資源指派給工作負載。 使用 Prometheus 或 Container Insights 觀察 CPU 和記憶體的平均和最大耗用量。 在 YAML 指令清單、Helm 圖表和 Kustomize 指令清單中正確設定 Pod 的限制和配額。

  • 使用 ResourceQuota 對象，針對在指定 命名空間中執行的所有 Pod，設定記憶體總數和 CPU 的配額。 系統地使用資源配額可避免雜訊鄰近問題、改善應用程式密度，並減少代理程式節點數目和總成本。 也請使用 LimitRange 物件來設定命名空間中 Pod 的預設 CPU 和記憶體要求。

  • 使用 容器執行個體 進行高載。

  • 您的 AKS 工作負載可能不需要持續執行，例如開發叢集節點集區中的特定工作負載。 若要將成本優化，您可以完全關閉 AKS 叢集，或停止 AKS 叢集中的一或多個節點集區。 如需詳細資訊，請參閱 停止和啟動 Azure Kubernetes Service （AKS） 叢集 和 啟動和停止 Azure Kubernetes Service （AKS） 上的節點集區。

  • Azure 原則 透過內建原則與 AKS 整合，以套用集中式、一致、大規模強制執行和保護措施。 在您的叢集上啟用 Azure 原則 附加元件，並套用預設 CPU 要求和限制和記憶體資源限制，以確保叢集容器上定義了 CPU 和記憶體資源限制。

  • 使用 Azure Advisor 來監視和釋放未使用的資源。

  • 使用 Microsoft成本管理 預算和檢閱來追蹤支出。

成本治理

雲端可以大幅改善商務工作負載的技術效能。 雲端技術也可以降低管理組織資產的成本和額外負荷。 不過，此商機也會造成風險，因為雲端部署可能會增加浪費和效率不足的可能性。

成本治理是持續實作原則或控件以限制支出和成本的程式。 原生 Kubernetes 工具和 Azure 工具都支援使用主動式監視和基礎結構成本優化的成本治理。

  • Microsoft成本管理 是一套Microsoft工具，可協助您分析、管理及優化 Azure 工作負載成本。 使用套件來協助確保您的組織會利用雲端所提供的優點。

  • 檢閱成本管理專業領域的 雲端採用架構 治理最佳做法，以進一步瞭解如何管理和管理雲端成本。

  • 探索 KubeCost 之類的開放原始碼工具，以監視和管理 AKS 叢集成本。 您可以將成本配置範圍設定為部署、服務、標籤、Pod 和命名空間，以提供顯示和收取叢集使用者的彈性。

參考資料

以下是一些參考數據，可協助您進一步瞭解和使用 AKS 成本分析：

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步