主持人 > 博客 > 管理 > Kubecost 審查在雲端的 Kubernetes 上節省資金

Kubecost 審查在雲端的 Kubernetes 上節省資金

Kubecost 審查在雲端的 Kubernetes 上節省資金

目前，越來越多的公司正在將其基礎設施從硬體伺服器和自己的虛擬機器轉移到雲端。 這個解決方案很容易解釋：無需擔心硬件，叢集可以透過多種不同方式輕鬆配置......最重要的是，現有技術（如 Kubernetes）使得可以根據負載簡單地擴展運算能力。

財務方面始終很重要。 本文討論的工具旨在協助減少將雲端基礎架構與 Kubernetes 結合使用時的預算。

介紹

庫貝成本 是一家來自 Google 的加州新創公司，創建了一個解決方案，用於計算雲端服務中的基礎設施成本（在 Kubernetes 叢集 + 共享資源內）、搜尋叢集設定中的瓶頸並向 Slack 發送適當的通知。

我們在熟悉的 AWS 和 GCP 雲端中都有使用 Kubernetes 的客戶，在 Linux 社群、Azure 中則更罕見——一般來說，在 Kubecost 支援的所有平台上都有使用 Kubernetes 的客戶。 對於其中一些，我們自己計算叢集內服務的成本（使用類似於 Kubecost 使用的方法），並且還監控基礎設施成本並嘗試對其進行最佳化。 因此，我們對自動化此類任務的可能性感興趣是合乎邏輯的。

Kubecost 主模組的原始碼依據開源授權（Apache License 2.0）條款開放。 它可以自由使用，可用的功能對於小型專案來說應該足夠了。 然而，生意就是生意：產品的其餘部分是封閉的，可以由 付費訂閱，這也意味著商業支援。 此外，作者還提供小型叢集的免費許可證（1 個叢集有 10 個節點 - 在撰寫本文期間，此限制擴展到 20 個節點）或 1 個月的完整功能試用期。

一切如何運作

所以，Kubecost的主要部分是應用程式 成本模型，用 Go 寫。 描述整個系統的 Helm 圖表稱為 成本分析器 其核心是成本模型與 Prometheus、Grafana 和多個儀表板的組合。

一般來說，cost-model有自己的Web介面，以表格形式顯示圖表和詳細的成本統計數據，當然還有優化成本的技巧。 Grafana 中提供的儀表板是 Kubecost 開發的早期階段，包含與成本模型大致相同的數據，並補充了集群及其組件中 CPU/內存/網絡/磁碟空間消耗的常用統計數據。

Kubecost 是如何運作的？

  • 成本模型透過雲端提供者的 API 接收服務價格。
  • 此外，根據節點的鐵類型和區域，計算每個節點的成本。
  • 根據運行節點的成本，每個葉 Pod 都會獲得每小時 CPU 使用率、消耗的每 GB 記憶體以及每小時每 GB 儲存資料的成本 - 取決於它運行的節點或儲存類別。
  • 根據運行單一 Pod 的成本，計算命名空間、服務、部署、StatefulSet 的費用。
  • 統計數據是使用 kube-state-metrics 和 node-exporter 提供的指標計算的。

重要的是要考慮 Kubecost 預設僅計算 Kubernetes 中可用的資源。 外部資料庫、GitLab 伺服器、S3 儲存和其他不在叢集中的服務（即使位於同一雲端）對其不可見。 儘管對於 GCP 和 AWS，您可以新增服務帳戶的金鑰並一起計算所有內容。

安裝

Kubecost 需要：

  • Kubernetes 1.8 及更高版本；
  • kube 狀態指標；
  • 普羅米修斯；
  • 節點導出器。

碰巧在我們的叢集中，所有這些條件都已提前滿足，因此事實證明，只需指定正確的端點來存取 Prometheus 就足夠了。 然而，官方的 kubecost Helm 圖表包含了在裸叢集上運行所需的一切。

安裝 Kubecost 有多種方式：

  1. 標準安裝方法描述於 路線 在開發者的網站上。必需 將 cost-analyzer 儲存庫新增至 Helm，然後安裝圖表。 剩下的就是轉發您的連接埠並手動（透過 kubectl）和/或使用成本模型 Web 介面將設定調整為所需狀態。

    我們甚至沒有嘗試過這種方法，因為我們不使用第三方現成的配置，但它看起來是一個很好的「親自嘗試」選項。 如果您已經安裝了一些系統元件或您想要進行更多微調，最好考慮第二條路徑。

  2. 本質上使用 同一張圖表，但是要自行設定和安裝 以任何方便的方式。

    如前所述，除了 kubecost 本身之外，該圖表還包含 Grafana 和 Prometheus 圖表，也可以根據需要進行自訂。

    圖表上可用 values.yaml for cost-analyzer 讓您設定：

    • 需要部署的成本分析器元件清單；
    • 您的 Prometheus 端點（如果您已經有）；
    • 成本模型和 Grafana 的域和其他入口設置；
    • Pod 的註解；
    • 使用永久儲存的需求及其大小。

    可用配置選項的完整清單及其說明可在 文件.

    由於基本版本的 kubecost 無法限制訪問，因此您需要立即為 Web 面板配置 basic-auth。

  3. 建立 僅系統核心 - 成本模型。 為此，您必須在叢集中安裝 Prometheus，並在變數中指定其位址的對應值 prometheusEndpoint 對於頭盔。 之後 - 申請 一組 YAML 配置 在集群中。

    同樣，您必須使用 basic-auth 手動新增 Ingress。 最後，您需要新增一個部分來收集成本模型指標 extraScrapeConfigs 在普羅米修斯配置中：

    - job_name: kubecost
  honor_labels: true
  scrape_interval: 1m
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  dns_sd_configs:
  - names:
    - <адрес вашего сервиса kubecost>
    type: 'A'
    port: 9003

我們得到什麼？

完整安裝後，我們可以使用 kubecost 和 Grafana Web 面板以及一組儀表板。

總成本主畫面上顯示的 ，實際上顯示了當月的資源估計成本。 這 預計的 價格反映了在當前資源消耗水準下使用群集的成本（每月）。

該指標更多的是用於分析費用並優化它們。 在 kubecost 中查看抽象 XNUMX 月的總成本不太方便：你必須 去結算。 但您可以看到 1/2/7/30/90 天按命名空間、標籤、pod 細分的成本，而帳單永遠不會向您顯示。

Kubecost 審查在雲端的 Kubernetes 上節省資金

說起 標籤。 您應該立即轉到設定並設定將用作分組成本的附加類別的標籤名稱：

Kubecost 審查在雲端的 Kubernetes 上節省資金

您可以在上面懸掛任何標籤 - 如果您已經擁有自己的標籤系統，那麼會很方便。

此外，您還可以更改成本模型連接的 API 端點的位址，調整 GCP 中的折扣大小，並設定您自己的資源價格和貨幣以進行測量（由於某種原因，該功能不會影響總成本）。

Kubecost可以顯示各種 集群中的問題 （甚至在出現危險時保持警覺）。 不幸的是，該選項不可配置，因此，如果您有開發人員環境並使用它們，您將不斷看到類似這樣的內容：

Kubecost 審查在雲端的 Kubernetes 上節省資金

一個重要的工具— 叢集節省。 它測量 Pod 的活動（資源消耗，包括網路資源），並計算多少錢以及您可以節省什麼。

優化技巧似乎很明顯，但經驗表明仍然有一些東西需要注意。 特別是監控 Pod 的網路活動（Kubecost 建議專注於不活動的），比較請求的和實際的記憶體和 CPU 消耗，以及叢集節點使用的 CPU（建議將多個節點合併為一個）、磁碟負載和數十個其他參數。

與任何最佳化問題一樣，基於 Kubecost 資料最佳化資源需要： 謹慎對待。 例如，Cluster Savings 建議刪除節點，聲稱它是安全的，但沒有考慮到部署在其上的 pod 中存在節點選擇器和污點，而這些節點在其他節點上不可用。 一般來說，即使是該產品的作者 最近的文章 （順便說一句，這對於對專案主題感興趣的人來說非常有用）建議不要急於進行成本優化，而是要深思熟慮地處理問題。

結果

在幾個專案中使用 kubecost 一個月後，我們可以得出結論，它是一個有趣的（也易於學習和安裝）工具，用於分析和優化用於 Kubernetes 叢集的雲端供應商服務的成本。 計算結果非常準確：在我們的實驗中，它們與提供者的實際要求相符。

還有一些缺點：存在非關鍵錯誤，並且在某些地方功能不能滿足某些項目的特定需求。 但是，如果您需要快速了解資金的去向以及可以「削減」哪些內容，以便持續將雲端服務費用減少 5-30%（這就是我們案例中發生的情況），那麼這是一個不錯的選擇。

聚苯乙烯

另請閱讀我們的博客：

來源： www.habr.com

添加評論