譯者 | 王志軍
審校 | 孫淑娟 梁策
一、背景
當(dāng)前，大多數(shù)應(yīng)用程序都使用云基礎(chǔ)設(shè)施來托管。云基礎(chǔ)設(shè)施可以是AWS/GCP/Azure等公有云中可用的資源，也可以是以虛擬機(VM)和容器的形式運行云工作負(fù)載的數(shù)據(jù)中心服務(wù)器等計算資源。
雖然云使我們的業(yè)務(wù)快速發(fā)展，讓服務(wù)也變得越來越敏捷，但這是有成本代價的。所有預(yù)分配的云資源，無論是過度使用還是未充分使用，都有與之相關(guān)的運行成本。組織經(jīng)常面臨管理此類成本的挑戰(zhàn)，并需要主動采取必要的措施。
解決與成本相關(guān)的挑戰(zhàn)的一種方法是設(shè)置一個固定的資源配額來限制資源的使用。另一種選擇是使用合適的工具(云或本地)定期統(tǒng)計所使用資源的運行“總成本” 。
資源配額可能是一個簡單的解決方案，但這種一刀切的方法并非對所有場景都適用。即使通過工具進行成本識別也能很好地獲取與資源相關(guān)的成本信息，但無法擴展到那些需要主動行動的不同場景中(即定義一個特定條件滿足的條件;采取行動，要么報告，要么糾正)，，比如使用低代碼、閉環(huán)自動化。
Nirmata DevSecOps平臺旨在全面解決這些挑戰(zhàn)。它是一個開放且易于使用的平臺，可在任何基礎(chǔ)設(shè)施上部署、運行和優(yōu)化 Kubernetes 工作負(fù)載，實現(xiàn)自助服務(wù)、職責(zé)分離以及安全和治理控制。在這篇文章中，我們將使用Kyverno作為策略引擎，當(dāng) kubecost 統(tǒng)計的某個 Kubernetes 工作負(fù)載的成本高于分配的值時，它會報警。
二、Kubecost
Kubecost為使用 Kubernetes 的團隊提供實時成本可視化和透視，幫助您不斷降低云成本。Kubecost解決了以下挑戰(zhàn)：
1.成本分配：根據(jù) Kubernetes 資源劃分成本，包括部署、服務(wù)、 namespace 標(biāo)簽等。在單個視圖中或通過單個 API Endpoint 查看多個集群的成本。
2.統(tǒng)一成本監(jiān)控：對Kubernetes的成本以及任何外部云服務(wù)或基礎(chǔ)設(shè)施的成本有一個全面了解。外部成本可以分?jǐn)?，然后圍繞所有 Kubernetes以全面了解支出。
3.優(yōu)化洞察：透視哪些資源增加了成本，以及優(yōu)化這些資源的潛在方式。在不犧牲性能的情況下，獲取減少開支的動態(tài)建議。優(yōu)先考慮關(guān)鍵基礎(chǔ)設(shè)施或應(yīng)用程序更改，以提高資源效率和可靠性。
4.告警和治理：通過集成 PagerDuty 和 Slack 等工具來保持工程工作流。在成本超支和基礎(chǔ)設(shè)施中斷風(fēng)險成為麻煩之前，快速發(fā)現(xiàn)這些風(fēng)險并發(fā)出通知。
三、Kyverno策略引擎
Kyverno是一個開源的Kubernetes 原生策略引擎，它作為準(zhǔn)入控制器運行，可以根據(jù)可定制的策略驗證、修改和生成任何配置數(shù)據(jù)。
盡管其他通用策略解決方案已針對 Kubernetes 進行了改造，但Kyverno是專為 Kubernetes 設(shè)計的。與 Kubernetes 一樣， Kyverno采用聲明式管理范式。Kyverno策略是 Kubernetes 的資源，不需要學(xué)習(xí)一門新語言。
Kyverno通過防止錯誤配置和增強安全性來保護 Kubernetes 配置。
四、Nirmata DevSecOps平臺
Nirmata DevSecOps平臺 (NDP) 集成了所需的工具和流程，使企業(yè)能夠?qū)?Kubernetes 作為其云原生操作系統(tǒng)進行標(biāo)準(zhǔn)化，從而為運營商、開發(fā)人員和安全團隊干凈地解耦工作流。
該平臺幫助企業(yè)運營團隊為開發(fā)人員提供自助服務(wù)的安全環(huán)境，解鎖DevOps的敏捷性。Nirmata Kubernetes平臺支持Kubecost作為認(rèn)證插件。
Nirmata開發(fā)了CNCF開源項目Kyverno，并在其DevSecOps平臺上原生支持該項目。Kyverno策略引擎是一個強大的工具，可以確保遵循安全性和操作最佳實踐。NDP將被用來部署Kubecost附加組件。
五、信息匯總
接下來，我們將介紹集群策略如何利用Kyverno監(jiān)控Kubernetes namespace 的總運行成本。當(dāng)總成本高于閾值時， Kyverno會創(chuàng)建違規(guī)/失敗?？偝杀拘畔⑹褂肒ubecost REST API 存儲在Config Map。我們將在下面詳細(xì)介紹這些組件。
首先，在各自的 namespace 中部署Kubecost和Kyverno。
出于演示的目的，我們將有一個名為 Nginx 的demo namespace 運行 Nginx Web 服務(wù)器的副本。
Kubecost也可以使用Nirmata部署為附加組件 DevSecOps平臺(在這種情況下， Kubecost使用OpenEBS-hostpath存儲類進行動態(tài)卷創(chuàng)建)。該鏈接包含在參考資料部分中。
六、Demo組件
所有相關(guān)文件都存放在Nirmata git repo。
1.收集腳本 – kubecost-collector.py
a. 作為 Kubernetes cron作業(yè)在后臺運行的 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策略監(jiān)控存儲在 namespace-configmap 中的數(shù)據(jù)以了解成本值的變化
b. 如果 Nginx namespace 的總成本高于閾值，則創(chuàng)建報告失敗。
上述組件可以從參考資料部分的Github頁面下載。
七、Demo 工作流程
1.創(chuàng)建一個 Nginx namespace 并部署 Nginx replicas。
kubectl create namespace nginx
Kubectl create deploy nginx -—image = nginx -—replicas=10
我們假設(shè)Kyverno在 Kyverno namespace 中運行，并且Kubecost應(yīng)用程序已啟動并運行以向我們提供成本信息。
2.使用cm.yaml在 namespace Kyverno中創(chuàng)建
configmap namespace-cost
kubectl create -f cm.yaml -n kyverno
3.創(chuàng)建更新namespace-cost中的ConfigMap所需的RBAC 資源( ServiceAccount 、 ClusterRole 、 ClusterRoleBindings ) 。
kubectl create -f rbac.yaml
4.將采集腳本 kubecost-collector.py 復(fù)制到 Kubernetes 集群。
A. 將kubecost-collector放入文件夾后，使用Dockerfile構(gòu)建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 中創(chuàng)建的 cm 的成本現(xiàn)在已更新為非零值，因為kubecost -collector正在從kubecost REST API Endpoint獲取實時值。
-collector正在從kubecost REST API Endpoint獲取實時值。
Data
====
nginx
----
0.481581
BinaryData
====
5.創(chuàng)建Kyverno集群策略
namespace-cost
kubectl apply -f policy.yaml
在應(yīng)用之前在策略中設(shè)置合適的成本閾值。由于工作負(fù)載是最近的，它最初可能具有非常低的成本。
6.驗證namespace-cost策略是否處于 READY 狀態(tài)。
kubectl get cpol
NAME BACKGROUND ACTION READY
namespace-cost true audit true
該策略應(yīng)該立即通過，因為新創(chuàng)建的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 服務(wù)器副本中運行 CPU/內(nèi)存密集型工作負(fù)載。
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
以上故障可以通過描述查看詳細(xì)信息。
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
八、總結(jié)
當(dāng) namespace 超出成本閾值時，用戶可以向各個團隊發(fā)出告警，并基于特定事件對其采取行動。Kyverno提供不同的規(guī)則(Mutate, Validate, Generate)來對用戶定義的現(xiàn)有和新工作負(fù)載采取行動，甚至基于策略中定義的條件(Generate)創(chuàng)建新資源。
原文鏈接：https://dzone.com/articles/cost-governance-of-cloud-native-workloads-using-kubecost-and-kyverno
譯者介紹
王志軍(besterjun)，51CTO社區(qū)編輯，國內(nèi)某云廠商解決方案架構(gòu)師，擁有10多年工作經(jīng)驗，長期從事解決方案架構(gòu)設(shè)計、微服務(wù)、容器、網(wǎng)絡(luò)運維等相關(guān)工作。專注于云原生、微服務(wù)、容器等技術(shù)領(lǐng)域。擁有豐富的多云混合云架構(gòu)規(guī)劃、設(shè)計和落地經(jīng)驗，已幫助多家企業(yè)成功上云。
