看得见的成本!1款工具实现K8S资源成本监控可视化

标签: 成本 工具 k8s | 发表时间:2020-11-11 20:44 | 作者:Rancher
出处:http://weekly.dockone.io


本文来自 Rancher Labs


关注我们,第一时间获取技术干货

计算Kubernetes成本的复杂性

采用Kubernetes和基于服务的架构可以为企业带来诸多好处,如团队可以更快地迁移以及应用程序可以更轻松地扩展等。但是这一转变也带来了一些复杂性,比如云成本的可见性。这是由于应用程序及其资源需求常常是动态变化的,并且团队共享核心资源而没有与工作负载挂钩的透明价格。此外,能够充分意识到Kubernetes所带来的优势的企业通常会将资源运行在不同类型的机器上,甚至会运行在多个云提供程序上。

在本文中,我们将了解在企业中为showback/chargeback项目实现成本监控的最佳实践和不同实现方式,以及如何授权用户对这些信息采取行动。我们首先会了解Kubecost,它提供了一种开源的方式来确保跨所有Kubernetes工作负载一致和准确的可见性。



让我们进一步了解最佳实践,以准确分配和监控Kubernetes的工作负载成本以及相关托管服务上的支出。

成本分配

精确分配资源成本是在Kubernetes环境中创建成本可见性和实现高效成本利用的首要步骤。

要正确进行这一步骤,你需要在工作负载层面通过单个容器进行成本分配。工作负载分配完成后,通过汇总不同的工作负载集合,成本可以正确地分配给各个团队、部门甚至个人开发者。在工作负载层面的成本分配框架如下所示:



让我们一点点拆解这个框架。

资源消耗的平均数量由Kubernetes scheduler进行计算或者由云提供程序提供,这取决于被测量的特定资源。我们建议根据request和usage的最大值来计算内存和CPU分配。这样就能够反映出由Kubernetes scheduler本身所预留的资源量。另一方面,诸如负载均衡器和持久卷等资源会严格基于由提供程序所提供的数量。

Kubernetes API可以直接计算出资源消耗的时间段。这由资源(如内存、CPU和GPU等)在Running状态所消耗的时间决定。要让数据对云chargeback来说足够精确,我们建议团队将这些数据与云提供程序提供的特定云资源(如节点)所花费的时间进行协调,保持一致。在之后的部分我们将对此进行更多介绍。

资源价格是通过观察环境中每种特定资源的成本来确定的。例如,us-east-1 AWS区域中m5.xlarge spot实例的CPU小时价格与同一实例的按需价格不同。

使用这一框架可以在各个工作负载之间适当分配成本,那么它们就可以通过任何Kubernetes概念(如命名空间、标签、注释或controller)轻松聚合。

Kubernetes成本监控

通过Kubernetes概念(如pod或controller)分配的成本,你可以开始准确地将支出映射到任何内部业务层级,如团队、产品、部门或成本中心。企业通常的做法是通过Kubernetes命名空间来划分团队工作负载,而其他的做法可能使用Kubernetes标签或注释来识别工作负载属于哪个团队。

在不同应用、团队等之间进行成本监控的另一个关键因素是确定谁应该为闲置的容量付费。具体而言是指仍在向企业计费但未使用的集群资源。通常情况下,这些费用要么计入中央基础设施成本中心,要么按比例分配给应用团队。将这些成本分配给负责供应决策的团队,通过调整激励措施来拥有一个高效规模的集群,从而产生积极的效果。

核对云账单

Kubernetes提供了大量实时数据。这让开发人员可以直接访问成本指标。尽管这些实时数据通常都是精确的,但它可能与云提供商的计费数据不完全一致。例如,在确定AWS spot节点的小时费率时,用户需要等待Spot数据源或成本和使用报告来确定准确的费率。出于计费和收费的目的,你应该将数据与实际账单进行核对。



通过Kubecost获得更好的可见性和治理

我们已经了解了如何观察数据以计算Kubernetes工作负载的成本。还有另一个方法是利用Kubecost,这是一个建立在开源基础上的成本和容量管理解决方案,提供了对整个Kubernetes环境的可见性。Kubecost为Kubernetes工作负载以及它们所消耗的相关管理服务(如S3或RDS)提供成本可见性和洞察力。该产品收集Kubernetes的实时数据,还能与你的云计费数据进行核对,以反映你支付的实际价格。



有了像Kubecost这样的解决方案,你可以授权应用工程师做出明智的实时决策,并开始实施即时和长期的实践,以优化和治理云支出。这包括在不影响性能的情况下采用成本优化的方案、实施Kubernetes预算和告警、showback/chargeback项目甚至基于成本的自动化。

Kubecost社区版可以免费使用,并且具有上述所有功能。你可以在Rancher应用商店中找到Kubecost Helm chart,轻松完成部署。借助Rancher,你可以获得Kubernetes集群可视化和绝佳控制力的体验,与此同时Kubecost为你提供了对支出和如何优化成本的直接观察。它们共同为使用Kubernetes的团队提供了一个完成的成本管理解决方案。

相关 [成本 工具 k8s] 推荐:

看得见的成本!1款工具实现K8S资源成本监控可视化

- - DockOne.io
本文来自 Rancher Labs. 关注我们,第一时间获取技术干货. 计算Kubernetes成本的复杂性. 采用Kubernetes和基于服务的架构可以为企业带来诸多好处,如团队可以更快地迁移以及应用程序可以更轻松地扩展等. 但是这一转变也带来了一些复杂性,比如云成本的可见性. 这是由于应用程序及其资源需求常常是动态变化的,并且团队共享核心资源而没有与工作负载挂钩的透明价格.

CentOS7 安装 K8S

- - 企业架构 - ITeye博客
前提:VirtualBox CentOS7. 物理机IP   192.168.18.8. 虚拟机1IP:192.168.18.100(VMaster master). 虚拟机2IP:192.168.18.101(VServer1 node1). 虚拟机3IP:192.168.18.102(VServer2 node2).

k8s水平扩容

- - Bboysoul's Blog
k8s 的好处就是可以弹性水平扩容和纵向扩容,平时纵向扩容用的不太多,所以今天说说水平扩容,在创建hpa之前你要确定集群中已经安装了metrics-server,我使用的是k3s,直接自带. 首先创建需要的容器,下面是dockerfile. 原理就是当你访问index.php的时候会进行一个循环计算来提高cpu的使用率.

# [k8s] HPA: Horizontal Pod Autoscaling

- - V2EX - 技术
HPA 是 K8S 的一大利器. 通过 HPA, 我们可以让服务的 pod 数量根据特定指标自动增加或减少, 使得在高峰期有足够的资源服务请求, 在低峰期又可以避免占用过多的资源. 同时, 在 SOA 架构下, 我们也习惯通过 HPA 来避免劳心劳力的为每个微服务计算所需的资源.. minReplicas: 允许的最小 pod 数量.

K8S 1.24.0 安装部署

- - Share
在 v1.2x 版本中, Kubernetes 支持的最大节点数为 5000. 更具体地说,我们支持满足以下所有条件的配置:. 每个节点的 pod 数量不超过. Kubernetes v1.20 开始,默认移除 docker 的依赖,如果宿主机上安装了 docker 和 containerd,将优先使用 docker 作为容器运行引擎,如果宿主机上未安装 docker 只安装了 containerd,将使用 containerd 作为容器运行引擎;.

k8s docker集群搭建 - CSDN博客

- -
一、Kubernetes系列之介绍篇.     - 一次构建,到处运行. 2.什么是kubernetes.   首先,他是一个全新的基于容器技术的分布式架构领先方案. Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg). 在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性.

深入掌握K8S Pod - Yabea - 博客园

- -
K8S configmap介绍. Pod是k8s中最小的调度单元,包含了一个“根容器”和其它用户业务容器. 如果你使用过k8s的话,当然会了解pod的基本使用,但是为了更好的应用,你需要深入了解pod的配置、调度、升级和扩缩容等. pod包含一个或多个相对紧密耦合的容器,处于同一个pod中的容器共享同样的存储空间、IP地址和Port端口.

浅谈 k8s ingress controller 选型 - 知乎

- -
大家好,先简单自我介绍下,我叫厉辉,来自腾讯云. 业余时间比较喜欢开源,现在是Apache APISIX PPMC. 今天我来简单给大家介绍下 K8S Ingress 控制器的选型经验,今天我讲的这些内容需要大家对 K8S 有一定的了解,下面是我的分享. 阅读本文需要熟悉以下基本概念:. 集群:是指容器运行所需云资源的集合,包含了若干台云服务器、负载均衡器等云资源.

SkyWalking探针在 k8s 中集成

- - 掘金 后端
最近公司需要在 k8s 环境接入 SkyWalking,要让应用无感知接入. 开始打算的是把agent文件放到基础镜像中,这样应用只需要引用包含agent的基础镜像即可. 但是这样会有几个问题,首先不好管理agent,升级需要应用重新打镜像部署,动静太大. 第二,不是所有应用都需要接入,要按需引入不同基础镜像,这样就多个一个步骤,应用会有感知.

记一次K8s排错实战

- - 掘金 后端
这是我参与更文挑战的第3天,活动详情查看:. 收到测试环境集群告警,登陆K8s集群进行排查. 查看kube-system node2节点calico pod异常. 查看详细信息,查看node2节点没有存储空间,cgroup泄露. 登陆node2查看服务器存储信息,目前空间还很充足. 集群使用到的分布式存储为ceph,因此查看ceph集群状态.