使用 Kubecost 和 Kyverno 對云原生工作負載進行成本治理

譯文精選

作者：王志軍 2022-04-27 10:40:38

云計算云原生

雖然云使我們的業務快速發展，讓服務也變得越來越敏捷，但這是有成本代價的。所有預分配的云資源，無論是過度使用還是未充分使用，都有與之相關的運行成本。

譯者 | 王志軍

審校 | 孫淑娟梁策

一、背景

當前，大多數應用程序都使用云基礎設施來托管。云基礎設施可以是AWS/GCP/Azure等公有云中可用的資源，也可以是以虛擬機(VM)和容器的形式運行云工作負載的數據中心服務器等計算資源。

雖然云使我們的業務快速發展，讓服務也變得越來越敏捷，但這是有成本代價的。所有預分配的云資源，無論是過度使用還是未充分使用，都有與之相關的運行成本。組織經常面臨管理此類成本的挑戰，并需要主動采取必要的措施。

解決與成本相關的挑戰的一種方法是設置一個固定的資源配額來限制資源的使用。另一種選擇是使用合適的工具(云或本地)定期統計所使用資源的運行“總成本” 。

資源配額可能是一個簡單的解決方案，但這種一刀切的方法并非對所有場景都適用。即使通過工具進行成本識別也能很好地獲取與資源相關的成本信息，但無法擴展到那些需要主動行動的不同場景中(即定義一個特定條件滿足的條件;采取行動，要么報告，要么糾正)，，比如使用低代碼、閉環自動化。

Nirmata DevSecOps平臺旨在全面解決這些挑戰。它是一個開放且易于使用的平臺，可在任何基礎設施上部署、運行和優化 Kubernetes 工作負載，實現自助服務、職責分離以及安全和治理控制。在這篇文章中，我們將使用Kyverno作為策略引擎，當 kubecost 統計的某個 Kubernetes 工作負載的成本高于分配的值時，它會報警。

二、Kubecost

Kubecost為使用 Kubernetes 的團隊提供實時成本可視化和透視，幫助您不斷降低云成本。Kubecost解決了以下挑戰：

1.成本分配：根據 Kubernetes 資源劃分成本，包括部署、服務、 namespace 標簽等。在單個視圖中或通過單個 API Endpoint 查看多個集群的成本。

2.統一成本監控：對Kubernetes的成本以及任何外部云服務或基礎設施的成本有一個全面了解。外部成本可以分攤，然后圍繞所有 Kubernetes以全面了解支出。

3.優化洞察：透視哪些資源增加了成本，以及優化這些資源的潛在方式。在不犧牲性能的情況下，獲取減少開支的動態建議。優先考慮關鍵基礎設施或應用程序更改，以提高資源效率和可靠性。

4.告警和治理：通過集成 PagerDuty 和 Slack 等工具來保持工程工作流。在成本超支和基礎設施中斷風險成為麻煩之前，快速發現這些風險并發出通知。

三、Kyverno策略引擎

Kyverno是一個開源的Kubernetes 原生策略引擎，它作為準入控制器運行，可以根據可定制的策略驗證、修改和生成任何配置數據。

盡管其他通用策略解決方案已針對 Kubernetes 進行了改造，但Kyverno是專為 Kubernetes 設計的。與 Kubernetes 一樣， Kyverno采用聲明式管理范式。Kyverno策略是 Kubernetes 的資源，不需要學習一門新語言。

Kyverno通過防止錯誤配置和增強安全性來保護 Kubernetes 配置。

四、Nirmata DevSecOps平臺

Nirmata DevSecOps平臺 (NDP) 集成了所需的工具和流程，使企業能夠將 Kubernetes 作為其云原生操作系統進行標準化，從而為運營商、開發人員和安全團隊干凈地解耦工作流。

該平臺幫助企業運營團隊為開發人員提供自助服務的安全環境，解鎖DevOps的敏捷性。Nirmata Kubernetes平臺支持Kubecost作為認證插件。

Nirmata開發了CNCF開源項目Kyverno，并在其DevSecOps平臺上原生支持該項目。Kyverno策略引擎是一個強大的工具，可以確保遵循安全性和操作最佳實踐。NDP將被用來部署Kubecost附加組件。

五、信息匯總

接下來，我們將介紹集群策略如何利用Kyverno監控Kubernetes namespace 的總運行成本。當總成本高于閾值時， Kyverno會創建違規/失敗。總成本信息使用Kubecost REST API 存儲在Config Map。我們將在下面詳細介紹這些組件。

首先，在各自的 namespace 中部署Kubecost和Kyverno。

出于演示的目的，我們將有一個名為 Nginx 的demo namespace 運行 Nginx Web 服務器的副本。

Kubecost也可以使用Nirmata部署為附加組件 DevSecOps平臺(在這種情況下， Kubecost使用OpenEBS-hostpath存儲類進行動態卷創建)。該鏈接包含在參考資料部分中。

六、Demo組件

所有相關文件都存放在Nirmata git repo。

1.收集腳本 – kubecost-collector.py

a. 作為 Kubernetes cron作業在后臺運行的 Python 腳本從 Nginx namespace 的Kubecost REST API Endpoint收集成本信息。http://>/model/allocation

b. 定期更新configmap namespace-cost configmap中存在的成本信息

2.ConfigMap

a. Kyverno namespace 中的ConfigMap ，其中包含 Nginx namespace 的成本信息

3.Kyverno Policy

a. Kyverno策略監控存儲在 namespace-configmap 中的數據以了解成本值的變化

b. 如果 Nginx namespace 的總成本高于閾值，則創建報告失敗。

上述組件可以從參考資料部分的Github頁面下載。

七、Demo 工作流程

1.創建一個 Nginx namespace 并部署 Nginx replicas。

kubectl create namespace nginx
Kubectl create deploy nginx -—image = nginx -—replicas=10

我們假設Kyverno在 Kyverno namespace 中運行，并且Kubecost應用程序已啟動并運行以向我們提供成本信息。

2.使用cm.yaml在 namespace Kyverno中創建

configmap namespace-cost
kubectl create -f cm.yaml -n kyverno

3.創建更新namespace-cost中的ConfigMap所需的RBAC 資源( ServiceAccount 、 ClusterRole 、 ClusterRoleBindings ) 。


kubectl create -f rbac.yaml

4.將采集腳本 kubecost-collector.py 復制到 Kubernetes 集群。

A. 將kubecost-collector放入文件夾后，使用Dockerfile構建Docker鏡像。確保使用***kubecost*** cost-analyzer REST API Endpoint 更新腳本。

mkdir <FOLDER_NAME>
cp Dockerfile <FOLDER_NAME>
cp kubecost-collector.py <FOLDER_NAME>
docker build -t kubecost-collector

一旦上述命令完成了kubecost -collector鏡像是否存在的驗證。

dockerimages kubecost-collector
REPOSITORY   TAG  IMAGE ID   CREATED  SIZE
kubecost-collector  latest    47a05cdc11bf   16 minutes ago   205MB

B. kubecost -collector作為 Kubernetes cron job運行kubectl create -f cron.yaml

驗證在步驟 2 中創建的 cm 的成本現在已更新為非零值，因為kubecost -collector正在從kubecost REST API Endpoint獲取實時值。

-collector正在從kubecost REST API Endpoint獲取實時值。
Data
====
nginx
----
0.481581

BinaryData
====

5.創建Kyverno集群策略

 namespace-cost
kubectl apply -f policy.yaml

在應用之前在策略中設置合適的成本閾值。由于工作負載是最近的，它最初可能具有非常低的成本。

6.驗證namespace-cost策略是否處于 READY 狀態。

kubectl get cpol

NAME             BACKGROUND   ACTION   READY

namespace-cost   true         audit    true

該策略應該立即通過，因為新創建的Nginx namespace 的運行成本將低于分配的閾值。


kubectlget cpolr
NAME  PASS   FAIL   WARN   ERROR   SKIP   AGE
clusterpolicyreport  1      0      0      0       20     3m8s

7.將Nginx replicas提高到更高的值，使總成本值高于policy.yaml中分配的閾值。

或者，您也可以在Nginx namespace 而不是nginx Web 服務器副本中運行 CPU/內存密集型工作負載。

8.隨著 namespace Nginx的成本變高，策略將失敗。使用kubectl檢查策略報告以獲取polr 。可以使用Nirmata Policy Reports UI 進行驗證。

kubectlget cpolr
NAME    PASS   FAIL   WARN   ERROR   SKIP   AGE
clusterpolicyreport  0      1      0      0       20     5m8s

以上故障可以通過描述查看詳細信息。


kubectl describe cpolr clusterpolicyreport | grep "Result: \+fail" -B10
Timestamp:
    Nanos:    0
    Seconds:  1644935662
  Message:    The namespace running cost not within defined threshold
  Policy:     namespace-cost
  Resources:
    API Version:  v1
    Kind:         Namespace
    Name:         nginx
    UID:          f1d06aa0-6fdf-44ab-a935-c5b8cf903e2e
  Result:         fail

八、總結

當 namespace 超出成本閾值時，用戶可以向各個團隊發出告警，并基于特定事件對其采取行動。Kyverno提供不同的規則(Mutate, Validate, Generate)來對用戶定義的現有和新工作負載采取行動，甚至基于策略中定義的條件(Generate)創建新資源。

原文鏈接：https://dzone.com/articles/cost-governance-of-cloud-native-workloads-using-kubecost-and-kyverno

譯者介紹

王志軍(besterjun)，51CTO社區編輯，國內某云廠商解決方案架構師，擁有10多年工作經驗，長期從事解決方案架構設計、微服務、容器、網絡運維等相關工作。專注于云原生、微服務、容器等技術領域。擁有豐富的多云混合云架構規劃、設計和落地經驗，已幫助多家企業成功上云。

責任編輯：武曉燕來源： 51CTO技術棧