目前,越来越多的公司正在将其基础设施从硬件服务器和自己的虚拟机转移到云端。 这个解决方案很容易解释:无需担心硬件,集群可以通过多种不同方式轻松配置......最重要的是,现有技术(如 Kubernetes)使得可以根据负载简单地扩展计算能力。
财务方面始终很重要。 本文讨论的工具旨在帮助减少将云基础设施与 Kubernetes 结合使用时的预算。
介绍
我们在熟悉的 AWS 和 GCP 云中都有使用 Kubernetes 的客户,在 Linux 社区、Azure 中则更少——一般来说,在 Kubecost 支持的所有平台上都有使用 Kubernetes 的客户。 对于其中一些,我们自己计算集群内服务的成本(使用类似于 Kubecost 使用的方法),并且还监控基础设施成本并尝试对其进行优化。 因此,我们对自动化此类任务的可能性感兴趣是合乎逻辑的。
Kubecost 主模块的源代码根据开源许可证(Apache License 2.0)条款开放。 它可以自由使用,可用的功能对于小型项目来说应该足够了。 然而,生意就是生意:产品的其余部分是封闭的,可以由
一切如何运作
所以,Kubecost的主要部分是应用程序
一般来说,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 有多种方式:
- 标准安装方法描述于
指示 在开发者的网站上。必需 将 cost-analyzer 存储库添加到 Helm,然后安装图表。 剩下的就是转发您的端口并手动(通过 kubectl)和/或使用成本模型 Web 界面将设置调整为所需状态。我们甚至没有尝试过这种方法,因为我们不使用第三方现成的配置,但它看起来是一个很好的“亲自尝试”选项。 如果您已经安装了一些系统组件或者您想要进行更多微调,最好考虑第二条路径。
- 本质上使用
同一张图表 ,但是要自己配置和安装 以任何方便的方式。如前所述,除了 kubecost 本身之外,该图表还包含 Grafana 和 Prometheus 图表,也可以根据需要进行自定义。
图表上可用
values.yaml
for cost-analyzer 允许您配置:- 需要部署的成本分析器组件列表;
- 您的 Prometheus 端点(如果您已经有);
- 成本模型和 Grafana 的域和其他入口设置;
- Pod 的注释;
- 使用永久存储的需求及其大小。
可用配置选项的完整列表及其说明可在
文件资料 .由于基本版本的 kubecost 无法限制访问,因此您需要立即为 Web 面板配置 basic-auth。
- 要安装 仅系统核心 - 成本模型。 为此,您必须在集群中安装 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 细分的成本,而账单永远不会向您显示。
说起 标签。 您应该立即转到设置并设置将用作分组成本的附加类别的标签名称:
您可以在上面悬挂任何标签 - 如果您已经拥有自己的标签系统,那么会很方便。
此外,您还可以更改成本模型连接的 API 端点的地址,调整 GCP 中的折扣大小,并设置您自己的资源价格和货币以进行测量(由于某种原因,该功能不会影响总成本)。
Kubecost可以显示各种 集群中的问题 (甚至在出现危险时保持警惕)。 不幸的是,该选项不可配置,因此,如果您有开发人员环境并使用它们,您将不断看到如下内容:
一个重要的工具—— 集群节省。 它测量 Pod 的活动(资源消耗,包括网络资源),并计算多少钱以及您可以节省什么。
优化技巧似乎很明显,但经验表明仍然有一些东西需要注意。 特别是监控 Pod 的网络活动(Kubecost 建议关注不活动的),比较请求的和实际的内存和 CPU 消耗,以及集群节点使用的 CPU(建议将多个节点合并为一个)、磁盘负载和几十个其他参数。
与任何优化问题一样,基于 Kubecost 数据优化资源需要: 谨慎对待。 例如,Cluster Savings 建议删除节点,声称它是安全的,但没有考虑到部署在其上的 pod 中存在节点选择器和污点,而这些节点在其他节点上不可用。 一般来说,即使是该产品的作者
结果
在几个项目中使用 kubecost 一个月后,我们可以得出结论,它是一个有趣的(也易于学习和安装)工具,用于分析和优化用于 Kubernetes 集群的云提供商服务的成本。 计算结果非常准确:在我们的实验中,它们与提供商的实际要求相符。
还有一些缺点:存在非关键错误,并且在某些地方功能不能满足某些项目的特定需求。 但是,如果您需要快速了解资金的去向以及可以“削减”哪些内容,以便持续将云服务费用减少 5-30%(这就是我们案例中发生的情况),那么这是一个不错的选择。
PS
另请阅读我们的博客:
- «
Kubernetes 中的自动扩展和资源管理(评论和视频报告) “; - «
Kubernetes 冒险 Dailymotion:在云端 + 本地创建基础设施 “; - «
Kubernetes 提示和技巧:关于节点分配和 Web 应用程序负载 “。
来源: habr.com