随着云原生技术的发展，越来越多的公司正在选择将应用运行在云上或者自建的 Kubernetes 集群上，但是许多机构的调研发现，绝大多数的用户集群资源利用率并不高，浪费严重。本文就带大家来了解Crane，以及通过实践，体验它的魅力。

Crane是什么

Crane 是由腾讯云主导开源的国内第一个基于云原生技术的成本优化项目，同时遵循 FinOps 标准，它的愿景是在保证客户应用运行质量的前提下实现极致的降本。目前已经获得FinOps基金会授予的全球首个认证降本增效开源方案。它为使用 Kubernetes 集群的企业提供了一种简单、可靠且强大的自动化部署工具。

如何在 Crane 中开启成本优化之旅？

  1. 成本展示: Kubernetes 资源( Deployments, StatefulSets )的多维度聚合与展示。
  2. 成本分析: 周期性的分析集群资源的状态并提供优化建议。
  3. 成本优化: 通过丰富的优化工具更新配置达成降本的目标。

Crane整体架构

Crane 的整体架构如下：

Crane Overview

由Craned整体架构可知Craned 是 Crane 的最核心组件，它管理了 CRDs 的生命周期以及API。Craned 通过 Deployment 方式部署且由两个容器组成：

  • Craned: 运行了 Operators 用来管理 CRDs，向 Dashboard 提供了 WebApi，Predictors 提供了 TimeSeries API
  • Dashboard: 基于 TDesign’s Starter 脚手架研发的前端项目，提供了易于上手的产品功能

Fadvisor

Fadvisor 提供一组 Exporter 计算集群云资源的计费和账单数据并存储到你的监控系统，比如 Prometheus。Fadvisor 通过 Cloud Provider 支持了多云计费的 API。

Metric Adapter

Metric Adapter 实现了一个 Custom Metric Apiserver. Metric Adapter 读取 CRDs 信息并提供基于 Custom/External Metric API 的 HPA Metric 的数据。

Crane Agent

Crane Agent 通过 DaemonSet 部署在集群的节点上。

Crane安装

因为我的是mac电脑，所以我只对mac电脑下的安装，进行演示。

安装 kind

请参考官方文档https://kind.sigs.k8s.io/docs/user/quick-start/#installation，这里我用的命令是

brew install kind

安装 Helm

请参考官方文档：https://helm.sh/zh/docs/intro/install/，这里我用的是

brew install helm

安装 kubectl

请参考官方文档https://kubernetes.io/zh-cn/docs/tasks/tools/，这里我用的是

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"

安装 Docker

请参考官方文档安装 docker：https://docs.docker.com/get-docker/，这里我用的是

image-20230518085700157

然后

以下命令将安装 Crane 以及其依赖 (Prometheus/Grafana).

curl -sf https://raw.githubusercontent.com/gocrane/crane/main/hack/local-env-setup.sh | sh -

如果网络有问题，可以直接用我提供的资料，进行本地安装

bash installation/local-env-setup.sh

确保所有 Pod 都正常运行:

$ export KUBECONFIG=${HOME}/.kube/config_crane
$ kubectl get pod -n crane-system

NAME                                             READY   STATUS    RESTARTS       AGE
craned-6dcc5c569f-vnfsf                          2/2     Running   0              4m41s
fadvisor-5b685f4cd6-xpxzq                        1/1     Running   0              4m37s
grafana-64656f6d54-6l24j                         1/1     Running   0              4m46s
metric-adapter-967c6d57f-swhfv                   1/1     Running   0              4m41s
prometheus-kube-state-metrics-7f9d78cffc-p8l7c   1/1     Running   0              4m46s
prometheus-server-fb944f4b7-4qqlv                2/2     Running   0              4m46s

访问 Crane Dashboard

kubectl -n crane-system port-forward service/craned 9090:9090

# 后续的终端操作请在新窗口操作，每一个新窗口操作前请把配置环境变量加上(不然会出现8080端口被拒绝的提示)
export KUBECONFIG=${HOME}/.kube/config_crane

注意：后续的终端操作请在新窗口操作，每一个新窗口操作前请把配置环境变量加上(不然会出现8080端口被拒绝的提示)

export KUBECONFIG=${HOME}/.kube/config_crane

点击 这里 访问 Crane Dashboard

成本展示

Crane Dashboard 提供了各式各样的图表展示了集群的成本和资源用量，

image-20230518090123155

  • 当月总成本：过去一个月集群总成本。从安装Crane时间开始，按小时累加集群成本
  • 预估每月成本：以最近一小时成本估算未来一个月的成本。每小时成本 * 24 * 30
  • 预估CPU总成本：以最近一小时CPU成本估算未来一个月的CPU成本。每小时CPU成本 * 24 * 30
  • 预估Memory总成本：以最近一小时Memory成本估算未来一个月的Memory成本。每小时Memory成本 * 24 * 30

成本洞察->集群总览

image-20230518090541698

成本洞察->集群总览

image-20230518090551387

  • Workload Spec CPU Slack: Workload 的 CPU 规格 - 推荐的 CPU 规格
  • Workload Total CPU Slack: （Workload 的 CPU 规格 - 推荐的 CPU 规格）* Pod 数量

更多的成本分析图表可以通过登陆 Grafana 的页面或者分析源码研究。

登陆 Grafana 的方式可以通过以下命令建立一个 port-mapping：

优化应用配置

在 dashboard 中开箱后就可以看到相关的成本数据，是因为在添加集群的时候我们安装了推荐的规则。

推荐框架会自动分析集群的各种资源的运行情况并给出优化建议。Crane 的推荐模块会定期检测发现集群资源配置的问题，并给出优化建议。智能推荐提供了多种 Recommender 来实现面向不同资源的优化推荐。

在成本分析>推荐规则页面可以看到我们安装的两个推荐规则。

image-20230518090600115

计算成本

成本计算功能是由组件 Fadvisor 实现，在安装 Crane 时会一起安装，一起提供了成本展示和成本分析功能：

  • Server：收集集群 Metric 数据并计算成本
  • Exporter：将成本 Metric 暴露出来

原理

Fadvisor 成本模型提供了一个方法来估计和分析每个容器,pod 或其他资源在 Kubernetes 中的资源价格。

请注意,成本模型只是预估成本,而不是替代云订单,因为实际的计费数据取决于更多原因，比如各类计费逻辑。以下是计算理论：

  • 最简单的成本模型是以相同的价格估算所有节点或 pod 的资源价格。例如,在计算成本时,您可以假设所有容器的 CPU 和 RAM 单位价格相同,2 / 小时核心 , 0.3 /小时核心,0.3 /小时核心,0.3/小时 Gib
  • 高级成本模型是通过成本分摊来估计资源价格。 这一理论的基础是不同实例类型和计费类型的每个云机器实例的价格不同，不过 CPU 和 RAM 的价格比率是相对固定的，可以通过这个价格比率来计算资源成本。

成本分摊模型下的具体的计算公式如下：

  • 集群整体成本：cvm 成本之和
  • CPU/mem 价格比率相对固定
  • cvm 的成本 = CPU 成本 * CPU 数量 + mem 成本 * mem 数量
  • CPU 申请成本：整体成本 * （CPU 占 cvm 成本的比例）得到整体 CPU 成本，再按申请的 CPU 总览占整体 CPU 总量的比例计算出 CPU 申请的成本
  • namespace 下的 CPU 申请成本： CPU 申请成本按 namespace 聚合

image-20230518090612162

image-20230518090804492

Crane主要特点以及应用场景

image-20230517084312717

成本可视化和优化评估

  • 提供一组 Exporter 计算集群云资源的计费和账单数据并存储到你的监控系统，比如 Prometheus。
  • 多维度的成本洞察，优化评估。通过 Cloud Provider 支持多云计费。

推荐框架

推荐框架是指自动分析集群的各种资源的运行情况并给出优化建议。

Crane 的推荐模块定期的检测发现集群资源配置的问题，并给出优化建议。智能推荐提供了多种 Recommender 来实现面向不同资源的优化推荐。

目前支持的Recommender：

image-20230517090336746

智能推荐的典型用例

创建 RecommendationRule 配置

下面是一个 RecommendationRule 示例： workload-rule.yaml。

apiVersion: analysis.crane.io/v1alpha1
kind: RecommendationRule
metadata:
  name: workloads-rule
spec:
  runInterval: 6h                            # 每6h运行一次
  resourceSelectors:                          # 资源的信息
    - kind: Deployment
      apiVersion: apps/v1
    - kind: StatefulSet
      apiVersion: apps/v1
  namespaceSelector:
    any: true                                 # 扫描所有namespace
  recommenders:                               # 使用 Workload 的副本和资源推荐器
    - name: Replicas
    - name: Resource

在该示例中：

  • 每隔24小时运行一次分析推荐，runInterval格式为时间间隔，比如: 1h，1m，设置为空表示只运行一次。
  • 待分析的资源通过配置 resourceSelectors 数组设置，每个 resourceSelector 通过 kind，apiVersion，name 选择 k8s 中的资源，当不指定 name 时表示在 namespaceSelector 基础上的所有资源
  • namespaceSelector 定义了待分析资源的 namespace，any: true 表示选择所有 namespace
  • recommenders 定义了待分析的资源需要通过哪些 Recommender 进行分析。
  • 资源类型和 recommenders 需要可以匹配，比如 Resource 推荐默认只支持 Deployments 和 StatefulSets

1.通过以下命令创建 RecommendationRule，刚创建时会立刻开始一次推荐。

kubectl apply -f workload-rules.yaml

这个时候，就会对所有 namespace 中的 Deployments 和 StatefulSets 做资源推荐和副本数推荐。

基于预测的水平弹性器

EffectiveHorizontalPodAutoscaler 支持了预测驱动的弹性。它基于社区 HPA 做底层的弹性控制，支持更丰富的弹性触发策略（预测，观测，周期），让弹性更加高效，并保障了服务的质量。

特点是：

  • 提前扩容，保证服务质量：通过算法预测未来的流量洪峰提前扩容，避免扩容不及时导致的雪崩和服务稳定性故障。
  • 减少无效缩容：通过预测未来可减少不必要的缩容，稳定工作负载的资源使用率，消除突刺误判。
  • 支持 Cron 配置：支持 Cron-based 弹性配置，应对大促等异常流量洪峰。
  • 兼容社区：使用社区 HPA 作为弹性控制的执行层，能力完全兼容社区。

它的功能我们可以根据通过一个简单的 EHPA yaml 文件进行了解：

apiVersion: autoscaling.crane.io/v1alpha1
kind: EffectiveHorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef: #(1)
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1 #(2)
  maxReplicas: 10 #(3)
  scaleStrategy: Auto #(4)
  metrics: #(5)
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  prediction: #(6)
    predictionWindowSeconds: 3600 #(7)
    predictionAlgorithm:
      algorithmType: dsp
      dsp:
        sampleInterval: "60s"
        historyLength: "3d"
  1. ScaleTargetRef 配置你希望弹性的工作负载。
  2. MinReplicas 指定了自动缩容的最小值。
  3. MaxReplicas 指定了自动扩容的最大值。
  4. ScaleStrategy 定义了弹性的策略，值可以是 “Auto” and “Preview”.
  5. Metrics 定义了弹性阈值配置。
  6. Prediction 定义了预测算法配置。
  7. PredictionWindowSeconds 指定往后预测多久的数据。

负载感知的调度器

kubernetes 的原生调度器只能通过资源请求来调度 pod，这很容易造成一系列负载不均的问题：

  • 对于某些节点，实际负载与资源请求相差不大，这会导致很大概率出现稳定性问题。
  • 对于其他节点来说，实际负载远小于资源请求，这将导致资源的巨大浪费。

为了解决这些问题，动态调度器根据实际的节点利用率构建了一个简单但高效的模型，并过滤掉那些负载高的节点来平衡集群。

这里主要用到的就是Crane-scheduler ，Crane-scheduler是一组基于scheduler framework的调度插件， 包含：Dynamic scheduler：负载感知调度器插件

拓扑感知的调度器

现代多核服务器大多采用非统一内存访问架构（来提高硬件的可伸缩性），由于在 Kubernetes 中，调度是指将 Pod 放置到合适的节点上，一个节点会运行多个Pod。所以在某些延迟敏感的场景下，可能希望Kubernetes为Pod分配拓扑最优的节点和硬件，以提升硬件利用率和程序性能。为了解决这一类问题，资源拓扑感知调度给予了精细调度的能力，将调度的粒度扩展到设备级别。下图是它的设计结构。topology-awareness-architecture

Crane-Scheduler和Crane-Agent配合工作，支持更为精细化的资源拓扑感知调度和多种绑核策略，可解决复杂场景下“吵闹的邻居问题"，使得资源得到更合理高效的利用。完成拓扑感知调度与资源分配的工作。

Crane-Agent从节点采集资源拓扑，包括NUMA、Socket、设备等信息，汇总到NodeResourceTopology这个自定义资源对象中。

Crane-Scheduler在调度时会参考节点的NodeResourceTopology对象获取到节点详细的资源拓扑结构，在调度到节点的同时还会为Pod分配拓扑资源，并将结果写到Pod的annotations中。

Crane-Agent在节点上Watch到Pod被调度后，从Pod的annotations中获取到拓扑分配结果，并按照用户给定的CPU绑定策略进行CPUSet的细粒度分配。

基于 QOS 的混部

QOS相关能力保证了运行在 Kubernetes 上的 Pod 的稳定性。具有多维指标条件下的干扰检测和主动回避能力，支持精确操作和自定义指标接入；具有预测算法增强的弹性资源超卖能力，复用和限制集群内的空闲资源；具备增强的旁路cpuset管理能力，在绑核的同时提升资源利用效率。同时，crane支持自定义指标适配整个干扰检测框架，只需要完成排序定义等一些操作，即可复用包含精确操作在内的干扰检测和回避流程。

参考文档

快速开始

https://github.com/gocrane/crane

总结

通过本文的学习，知道了Crane是什么、以及它的愿景，同时我们也了解了Crane的整体架构和主要特点，还在本地安装体验了Crane，理清了他的应用场景。也感受到了它的魅力。确实在落地方面，保证客户应用运行质量的前提下实现了极致的降本。对于目前的大环境和行业来说，有着十足的诚意。最后想说的是你的公司涉及到的相关业务无论是否需要资源优化，当你希望实践 FinOps 时，Crane 都可以作为尝试对象。你可以首先通过集群的成本展示了解当前的 Kubernetes 集群的现状，并根据问题所在选择优化的方式。

就拿降本来说，可以提前通过预测算法提前扩容，利用预测数据做降级，利用平滑的预测指标缓解抖动，比如我们可以先在 CI/CD 环境验证配置的准确性再更新生产环境。 然后先优化浪费严重的业务，再优化已经比较低配置的业务 ，根据业务特征配置推荐参数。发布平台通过提示用户建议的配置，让用户确认后再更新以防止意料之外的线上变更。以实现更高的利用率。

关于腾讯云 Finops Crane 集训营：

Finops Crane集训营主要面向广大开发者，旨在提升开发者在容器部署、K8s层面的动手实践能力，同时吸纳Crane开源项目贡献者，鼓励开发者提交issue、bug反馈等，并搭载线上直播、动手实验组队、有奖征文等系列技术活动。既能让开发者通过活动对 Finops Crane 开源项目有深入了解，同时也能帮助广大开发者在云原生技能上有实质性收获。
为奖励开发者，我们特别设立了积分获取任务和对应的积分兑换礼品。

👉活动介绍送门：https://marketing.csdn.net/p/038ae30af2357473fc5431b63e4e1a78

👉开源项目： https://github.com/gocrane/crane

# 腾讯云 # kubernetes # Crane # 云原生
Logo
腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

Springboot+MySQL 实现从数据库获取数据展示到前端

1.运行效果效果图如下：2.创建数据库表数据库名为"springboot",数据库表名为"user"，数据库表里面放了5条数据，字段分别为：“id”，“name”，“age”，“email”。3.新建SpringBoot项目1、选择Spring Initial...

avatar 腾讯云开发者社区

数据库 实验二 数据库的简单查询和连接查询实验

– l）用Transact-SQL语句表示下列操作．在学生选课库中实现其数据查询操作．– ①求数学系学生的学号和姓名。select sno,sname from student where sdept='MA';– ②求选修了课程的学生学号。select distinct sno from sc;– ③求选修C1课程的学生学号和成绩，并要求对查询结果按成绩降序排列，如果成绩相同则按学号升序排列。s

avatar 腾讯云开发者社区

Spring Boot Mybatis数据库datasource多数据源配置

application.yaml文件配置spring:datasource:db1:driver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://192.168.0.1:3306/ellassay_dev?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBe

avatar 腾讯云开发者社区