使用 Kubecost 和 Kyverno 对云原生工作负载进行成本治理-51CTO.COM

译者 | 王志军

审校 | 孙淑娟梁策

一、背景

当前，大多数应用程序都使用云基础设施来托管。云基础设施可以是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多年工作经验，长期从事解决方案架构设计、微服务、容器、网络运维等相关工作。专注于云原生、微服务、容器等技术领域。拥有丰富的多云混合云架构规划、设计和落地经验，已帮助多家企业成功上云。