五個代價高昂的Kubernetes成本陷阱及其解決方案

2021-06-28 10:45:21

人們需要了解Kubernetes在成本管理方面帶來的挑戰，並使用一些優秀實踐解決Kubernetes成本優化的問題。

如今，Kubernetes的成本管理變得越來越複雜，越來越多的組織面臨這個問題。根據調研機構Gartner公司的調查，到2022年，75%的組織將在生產中運行容器化應用程式。

如果你在AWS雲平臺上使用Kubernetes，可能已經在實施優秀實踐來減少運營費用。但是，為了最大限度地節省雲端計算成本，需要了解Kubernetes在成本管理和優化方面帶來的具體挑戰，並瞭解它們是什麼以及如何處理它們。

為什麼Kubernetes雲端計算成本如此令人困惑?

在組織採用容器化技術之前，分配資源和成本要容易得多。只需將資源標記為特定項目或團隊，這足以讓FinOps (成本優化)確定組織的典型成本結構，並更好地控制預算。一旦組織映射了供應商標籤並確定了擁有該項目的團隊，則計算項目總成本就會變得更加容易。

當然，在這種情況下，組織也會面臨過度配置資源的風險。開發人員可能會訂購比他們需要更多的資源，以確保應用程式不間斷地運行。隨著Kubernetes和其他容器化工具的普及，傳統的成本分配和報告流程不再適用。而弄清楚Kubernetes的成本估算、分配和報告並不容易。

如果你仍然無法詳細瞭解團隊的成本，不要擔心，因為你並不是唯一一個努力控制成本的人。為了改進成本控制，首先要探索這些成本帶來的挑戰。

需要避免的5個Kubernetes成本陷阱

(1)計算每個容器的成本

計算單個容器的成本並不難，但它需要基礎設施和更多的時間來完成。

Kubernetes叢集是由多個團隊運行的共享服務，擁有許多容器幷包含各種應用程式。在部署容器之後，你將使用叢集的一些資源，併為屬於該叢集的每個伺服器例項支付費用。

現在假設你有三個團隊在開發10個獨特的應用程式，瞭解哪個應用程式使用叢集資源幾乎是不可能的，因為這些項目中的每個項目都使用多個容器，因此你不知道給定團隊使用的是哪個部分，以及在特定項目中使用了多少。

簡而言之，尚不清楚單個容器從一臺特定伺服器使用了多少資源。這使得計算和分配成本變得更加困難。

(2)通過不同的成本中心支付費用

如果你所在的組織包含多個成本中心，並非所有開發成本都來自DevOps預算。某些應用程式可能由組織的產品團隊、研發團隊或IT部門的另一個團隊為影子IT項目創建。

這裡的關鍵是組織的規模和結構。如果你的組織提供多個數字服務，其中每個數字服務都有其特定團隊和預算，跟蹤雲端計算服務的成本將變得更加複雜。當多個團隊使用同一個叢集時，確定哪個團隊或項目負責最終賬單的哪個部分將成為挑戰。

(3)跨雲平臺跟蹤成本並不容易

如果使用多雲，跟蹤其成本就會變得更加困難。Gartner公司對公共雲使用者的調查表明， 81%的受訪者正在與兩個或更多的雲端計算提供商合作。根據ICD公司的調查，到2022年，90%的組織將採用多個雲平臺或內部部署、私有云、混合雲和公共雲的組合。

因此，很快組織可能會在多個雲平臺運行Kubernetes叢集，並且其容器將使用不同的節點。組織的應用程式可以分散在不同的雲平臺中，例如AWS、谷歌雲、Azure等。它們中的每一個可能只承載組織整體工作負載的一小部分，這進一步使跟蹤節點和叢集變得更加複雜。

(4)擴展使問題進一步複雜化

為了充分利用Kubernetes，大多數團隊使用內建的Kubernetes自動擴展機制。配置得越緊密，運行叢集的浪費就越少，成本也就越低。

Vertical　Pod　Autoscaler(VPA)會自動調整請求，並限制配置以降低成本，而Horizontal　Pod　Autoscaler(HPA)專注於橫向擴展，以達到分配給現有例項的合適CPU或記憶體數量的目的。

然而，這些擴展機制會影響成本計算。VPA不斷地改變容器上的請求數量、擴大和縮小其資源分配。另一方面，HPA會動態更改容器的數量。例如，假設三個Web伺服器容器在夜間運行。而在高峰時段，HPA從3個容器擴展到50個容器。然後，其數量在每天的中午減小，然後再逐漸擴展。而到了晚上，其數量穩定在一個更低的水平。

這意味著容器的數量及其大小是非常動態的，這使得計算和預測成本的過程變得更加困難。

(5)容器更加動態

藉助容器，組織可以跨區域、專區或例項類型重新安排工作負載。通常一個容器的壽命只有一天，與虛擬機器的持續時間相比很短。越來越多的組織在Kubernetes上運行函數和cron作業，它們的壽命從幾秒到幾分鐘不等。

容器化環境的動態特性為混合增加了另一層複雜性，組織的成本管理系統需要能夠處理這個問題。