使用 kube-downscaler 降低Kubernetes集群成本

新钛云服已累计为您分享772篇技术干货

介绍

Kube-downscaler 是一款开源工具,允许用户定义 Kubernetes 中 pod 资源自动缩减的时间。这有助于通过减少非高峰时段的资源使用量来降低基础设施成本。

在本文中,我们将详细介绍 kube-downscaler 的功能、安装和配置,以及它的用例和未来前景。

kube-downscaler的特点

Kube-downscaler 是一款基于调度的强大工具,用于在 Kubernetes 集群中对应用程序进行升级或降级。在本节中,我们将探讨该工具的一些关键功能:

与Kubernetes功能或工具的兼容性

Kube-downscaler 还支持水平 Pod 自动缩放 (HPA),并可以与 HPA 结合使用,以确保为应用程序维护所需的副本数量。这使得 kube-downscaler 能够为 Kubernetes 中的应用程序扩展提供额外的灵活性和细粒度的控制。

Karpenter 和 kube-downscaler 是两个可以结合使用的工具,可以为 Kubernetes 集群提供完整且强大的资源管理解决方案。通过结合使用 Karpenter 和 kube-downscaler,Kubernetes 集群可以从水平和垂直扩展中受益。 Downscaler 允许减少 Pod 数量,而 Karpenter 通过将 Pod 整合到更少或不同类型的机器上来优化节点利用率。

与Kubernetes功能或工具的兼容性

Kube-downscaler 还支持水平 Pod 自动缩放 (HPA),并可以与 HPA 结合使用,以确保为应用程序维护所需的副本数量。这使得 kube-downscaler 能够为 Kubernetes 中的应用程序扩展提供额外的灵活性和细粒度的控制。

Karpenter 和 kube-downscaler 是两个可以结合使用的工具,可以为 Kubernetes 集群提供完整且强大的资源管理解决方案。通过结合使用 Karpenter 和 kube-downscaler,Kubernetes 集群可以从水平和垂直扩展中受益。 Downscaler 允许减少 Pod 数量,而 Karpenter 通过将 Pod 整合到更少或不同类型的机器上来优化节点利用率。

根据定义的时间段自动扩展部署副本

Kube-downscaler 可以根据预定义的时间段自动扩展部署副本。这意味着我们可以设置一个计划,在一天、一周或一个月的特定时间增加或减少副本数量。

比如,如果我们知道应用程序在一天中的某些时段遇到高流量,则可以将 kube-downscaler 配置为在这些时段自动扩展副本,然后在流量减少时缩小副本。

这可以允许在预期峰值负载的情况下进行扩展,而不是等待峰值负载发生并由 HPA 处理。这可以帮助优化资源使用并确保您的应用程序始终可用且响应迅速。

但是 Kube-downscaler 主要用于缩小副本并优化集群的成本,我们通常使用 HPA 来管理扩展。

kube-downscaler的安装和配置

kubernetes集群上kube-downscaler安装说明

  1. 从 GitHub 克隆 kube-downscaler 存储库:
复制代码
php 复制代码
git clone <https://codeberg.org/hjacobs/kube-downscaler.git>

‍‍‍

  1. 进入 kube-downscaler 目录:
复制代码
bash 复制代码
cd kube-downscaler

‍‍‍

  1. 编辑 deploy/kube-downscaler.yaml 文件以根据您的具体需求自定义配置。例如,可以调整时区、计划和缩放规则。

  2. 将配置应用到您的 Kubernetes 集群:

复制代码
nginx 复制代码
kubectl apply -f deploy/

‍‍‍

此命令将部署 kube-downscaler 控制器并创建 kube-downscaler 部署。

可以通过检查 kube-downscaler 部署的日志来验证 kube-downscaler 控制器是否正在运行:

复制代码
nginx 复制代码
kubectl logs -f deployment/kube-downscaler

‍‍‍

安装完成后,需要进行一下配置。

根据具体用户需求配置kube-downscaler

Kube-downscaler 通过在 Kubernetes 部署对象上使用注释来提供扩展计划的定制。

部署对象中的 downTimePeriod注释可用于指定不应扩展部署的停机时间段。

minReplicas 注释可用于设置部署的最小副本数。

这些字段与 kube-downscaler 注释结合使用,允许您根据特定的业务需求和资源利用模式创建自定义的扩展计划。

通过调整这些字段,可以配置 kube-downscaler 以优化应用程序可用性和成本效率的方式扩展部署。

以下是使用 kube-downscaler 进行部署的简单配置。

properties 复制代码
apiVersion: apps/v1
kind: Deployment
metadata:
  name: random-deployment
    annotations:
        # Kube-downscaler
        downscaler/downtimePeriod: "Mon-Fri 00:00-07:00 Europe/Berlin"
        downscaler/minReplicas: 1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: random
  template:
    metadata:
      labels:
        app: random
    spec:
      containers:
      - name: random-container
        image: random-image

‍‍‍

通过此配置,从周一到周五午夜到早上 7 点(在欧洲/柏林时间线上),副本数量将减少到 1 个。

kube-downscaler 将根据定义的计划自动开始缩减 pod。

目前我们已经在 Kubernetes 集群上安装并运行了 kube-downscaler。

算法

Kube-downscaler 如果满足以下所有条件,将缩减部署的副本:

  • current time 不是"uptime "计划的一部分,也不是"downtime"计划的一部分。 如果为 true,则按以下顺序评估计划:

    • downscaler/downscale-perioddownscaler/downtime 工作负载定义的注释

    • downscaler/upscale-perioddownscaler/uptime 工作负载定义的注释

    • downscaler/downscale-perioddownscaler/downtime 工作负载命名空间上的注释

    • downscaler/upscale-perioddownscaler/uptime 工作负载命名空间上的注释

    • --upscale-period--default-uptime CLI 参数

    • --downscale-period--default-downtime CLI 参数

    • UPSCALE_PERIODDEFAULT_UPTIME 环境变量

    • DOWNSCALE_PERIODDEFAULT_DOWNTIME 环境变量

  • 工作负载的命名空间不是排除列表的一部分:

    • 如果提供排除列表,它将用于代替默认值(仅包括kube-system )。
  • 工作负载的标签与标签列表不匹配。

  • 工作负载的名称不是排除列表的一部分

  • 工作负载未标记为排除(注释 downscaler/exclude: "true"downscaler/exclude-until: "2024-04-05"

  • 没有活动 Pod 强制整个集群进入正常运行时间(注释 downscaler/force-uptime: "true"

Minimum replicas最小副本数

默认情况下,部署将缩减为零副本。这可以通过部署或其命名空间的注释进行配置, downscaler/downtime-replicas 也可以通过 CLI 使用 --downtime-replicas .

Ex: downscaler/downtime-replicas: "1"

Specific workload特定工作负载

在正常的情况下 HorizontalPodAutoscalers ,该字段不能设置为零, 因此downscaler/downtime-replicas 至少 1 应设置为 。 关于 CronJobs ,它们的状态将按照我们的预期进行定义 suspend: true

注意点

请注意,默认的宽限期为 15 分钟适用于新的 nginx 部署,即

  • 如果当前时间不在 ,它不会立即缩小 Mon-Fri 9-17 (Buenos Aires timezone) ,而是在 15 分钟后缩小。downscaler最终会记录如下内容:
复制代码
javascript 复制代码
INFO: Scaling down Deployment default/nginx from 1 to 0 replicas (uptime: Mon-Fri 09:00-17:00 America/Buenos_Aires, downtime: never)

‍‍‍

请注意,如果 HorizontalPodAutoscaler (HPA) 与部署一起使用,请考虑以下事项:

  • 如果需要缩减到 0 个副本,则应在 上 Deployment 应用注释。这是一种特殊情况,因为 minReplicas 不允许在 HPA 上为 0。将部署副本设置为 0 实质上会禁用 HPA。在这种情况下,HPA 将发出事件,例如 failed to get memory utilization: unable to get metrics for resource memory: no metrics returned from resource metrics API 没有 Pod 可以从中检索指标。

  • 如果需要缩小大于 0,则应在 HPA 上应用注释。这允许在停机期间根据外部流量动态扩展 Pod,并在停机期间保持较低的 minReplicas 流量,如果没有低流量。如果对部署而不是 HPA 进行批注,则会导致争用条件,即缩减部署, kube-downscaler HPA 在部署更高时 minReplicas 将其升级。

若要使用 在 HPA 上 --downtime-replicas=1 启用downscaler,请确保将以下注释添加到部署和 HPA。

shell 复制代码
$ kubectl annotate deploy nginx 'downscaler/exclude=true'
$ kubectl annotate hpa nginx 'downscaler/downtime-replicas=1'
$ kubectl annotate hpa nginx 'downscaler/uptime=Mon-Fri 09:00-17:00 America/Buenos_Aires'

‍‍‍

详细配置

Uptime/downtime spec

downscaler通过命令行参数、环境变量或 Kubernetes 注释进行配置。

时间定义(例如 DEFAULT_UPTIME )接受以逗号分隔的规范列表,例如,以下配置将缩小非工作时间的所有部署:

ini 复制代码
DEFAULT_UPTIME="Mon-Fri 07:30-20:30 Europe/Berlin"

‍‍‍

仅在周末和周五 20:00 后缩小:

makefile 复制代码
DEFAULT_DOWNTIME="Sat-Sun 00:00-24:00 CET,Fri-Fri 20:00-24:00 CET'

‍‍‍

每个时间规范可以采用以下两种格式之一:

  • 重复规范格式 <WEEKDAY-FROM>-<WEEKDAY-TO-INCLUSIVE> <HH>:<MM>-<HH>:<MM> <TIMEZONE> .时区值可以是任何时区,例如"US/Eastern"、"PST"或"UTC"。

  • 绝对规范格式, <TIME_FROM>-<TIME_TO> 其中每个 <TIME> 格式都是ISO 8601日期和时间的格式 <YYYY>-<MM>-<DD>T<HH>:<MM>:<SS>[+-]<TZHH>:<TZMM>

基于periods的替代逻辑

您可以选择升级或缩减的时间段,而不是严格的正常运行时间或停机时间。时间定义是相同的。在这种情况下,放大或缩小只发生在时间段,其余时间将被忽略。

如果配置了升级或缩减周期,将忽略正常运行时间和停机时间。这意味着某些选项是互斥的,例如,您可以使用或 --default-downtime ,但不能同时使用 --downscale-period 两者。

此定义将在 19:00 到 20:00 之间缩减群集。如果手动升级集群,则在第二天 19:00-20:00 之前不会缩减集群。

ini 复制代码
DOWNSCALE_PERIOD="Mon-Sun 19:00-20:00 Europe/Berlin"

‍‍‍

命令行选项

可用的命令行选项:

  • --dry-run

    仅运行模式:不更改任何内容,只需打印将要执行的操作

  • --debug

    调试模式:打印更多信息

  • --once

    仅运行一次循环并退出

  • --interval

    循环间隔(默认:30 秒)

  • --namespace

    将downscaler限制为仅在单个命名空间(默认:所有命名空间)中工作。这主要适用于 kube-downscaler 的部署者只能访问给定命名空间(而不是集群访问权限)的部署场景。如果与 同时 --exclude-namespaces使用 ,则不应用任何应用。

  • --include-resources

    将此类资源缩小为逗号分隔列表。

  • --grace-period

    新部署在缩减部署之前的宽限期(以秒为单位)(默认值:15 分钟)。宽限期从创建部署时开始计算,即无论宽限期如何,更新的部署都将立即缩减。

  • --upscale-period

    仅在给定时间段内纵向扩展的替代逻辑(默认:从不),也可以通过环境变量 UPSCALE_PERIOD 或通过每个部署 downscaler/upscale-period 上的注释进行配置

  • --downscale-period

    仅在给定时间段内缩减的替代逻辑(默认:从不),也可以通过环境变量 DOWNSCALE_PERIOD 或通过每个部署 downscaler/downscale-period 上的注释进行配置

  • --default-uptime

    要纵向扩展的默认时间范围(默认:始终),也可以通过环境变量 DEFAULT_UPTIME 或通过每个部署 downscaler/uptime 上的注释进行配置

  • --default-downtime

    要缩减的默认时间范围(默认:从不),也可以通过环境变量 DEFAULT_DOWNTIME 或通过每个部署 downscaler/downtime 上的注释进行配置

  • --exclude-namespaces

    从降级中排除命名空间(正则表达式模式列表,默认:kube-system),也可以通过环境变量 EXCLUDE_NAMESPACES 进行配置。如果与 同时 --namespace 使用 ,则不应用任何应用。

  • --exclude-deployments

    从降级中排除特定部署/状态集/cronjobs(默认:kube-downscaler,downscaler),也可以通过环境变量 EXCLUDE_DEPLOYMENTS 进行配置。尽管名称如此,但此选项将与任何包含的资源类型(Deployment,StatefulSet,CronJob等)的名称匹配。

  • --downtime-replicas

    缩小到的副本的默认值,注释 downscaler/downtime-replicas 优先于此值。

  • --deployment-time-annotation

    可选:将使用的注释的名称,而不是资源的创建时间戳。如果您希望资源在部署后的宽限期 ( --grace-period ) 内保持纵向扩展,则应使用此选项。注释的时间戳值的格式必须与 Kubernetes 的格式完全相同: creationTimestamp %Y-%m-%dT%H:%M:%SZ 。建议:通过部署工具自动设置此批注。

  • --matching-labels

    可选:kube-downscaleer 范围涵盖的工作负载标签列表。标签与列表中的任何工作负载都不匹配的所有工作负载都将被忽略。为了向后兼容,如果未指定此参数,kube-downscaler 将应用于所有资源。

Namespace Defaults命名空间默认值

DEFAULT_UPTIMEDEFAULT_DOWNTIMEFORCE_UPTIME 排除也可以使用命名空间注释进行配置。在配置的情况下,这些值将取代其他全局默认值。

properties 复制代码
apiVersion: v1
kind: Namespace
metadata:
    name: foo
    labels:
        name: foo
    annotations:
        downscaler/uptime: Mon-Sun 07:30-18:00 CET

命名空间级别支持以下批注:

  • downscaler/upscale-period

  • downscaler/downscale-period

  • downscaler/uptime :为此命名空间中的所有资源设置"正常运行时间"

  • downscaler/downtime :为此命名空间中的所有资源设置"停机时间"

  • downscaler/force-downtime :强制缩减此命名空间中的所有资源 - 可以是 true / false

  • downscaler/force-uptime :强制向上扩展此命名空间中的所有资源 - 可以是 true / false

  • downscaler/exclude :设置为 以 true 排除命名空间中的所有资源

  • downscaler/exclude-until :暂时排除命名空间中的所有资源,直到给定的时间戳

  • downscaler/downtime-replicas :覆盖默认目标副本以缩小到(默认值:零)

使用案例

该工具的主要用例是通过优化 Kubernetes 集群资源的利用率来降低成本。不过,它也可以用来预热集群,避免过度依赖 HPA。

虽然这不是其主要目的,但这种组合提供了一种替代解决方案,可确保应用程序的高可用性,同时最大限度地降低基础设施成本。

降低成本

kube-downscaler 的另一个用例是防止高峰使用期间的服务中断。通过定义在高需求期间扩展资源的计划,kube-downscaler 可以帮助预先扩展部署并避免 HPA 延迟,以确保应用程序即使在高峰使用期间也保持可用和响应。

服务中断预防

kube-downscaler 的另一个用例是防止高峰使用期间的服务中断。通过定义在高需求期间扩展资源的计划,kube-downscaler 可以帮助预先扩展部署并避免 HPA 延迟,以确保应用程序即使在高峰使用期间也保持可用和响应。

建议

基于预定义计划的扩展,这可能并不适合所有用例。此外,它不支持自动缩放,这意味着用户必须手动调整缩放计划以满足不断变化的需求。

另一种可供考虑的解决方案是 Keda。 Keda是一个开源项目,为Kubernetes应用程序提供动态自动伸缩功能。使用 Keda,用户可以根据各种指标(例如队列长度、CPU 使用率或自定义指标)设置自定义扩展规则。

这允许对资源使用进行更精细的控制,并确保应用程序始终能够正确扩展以满足需求。

此外,Keda 兼容广泛的 Kubernetes 应用程序,包括有状态和无状态应用程序,并支持多种事件源,例如 Azure Event Hubs、Kafka 和 RabbitMQ。

结论

Kube-downscaler 是管理 Kubernetes 集群中资源使用情况的强大工具。通过定义扩展计划,用户可以优化集群中的资源使用并降低成本,同时确保应用程序即使在高峰使用期间也保持可用和响应。

虽然 kube-downscaler 是管理 Kubernetes 集群中资源使用情况的一个有价值的工具,但它可能有一些限制。如果需要对资源扩展进行更精细的控制或需要自动扩展功能,那么可能值得考虑像 Keda 这样的替代解决方案。

推荐阅读

推荐视频

相关推荐
川石课堂软件测试20 分钟前
性能测试|docker容器下搭建JMeter+Grafana+Influxdb监控可视化平台
运维·javascript·深度学习·jmeter·docker·容器·grafana
昌sit!6 小时前
K8S node节点没有相应的pod镜像运行故障处理办法
云原生·容器·kubernetes
A ?Charis9 小时前
Gitlab-runner running on Kubernetes - hostAliases
容器·kubernetes·gitlab
wclass-zhengge10 小时前
Docker篇(Docker Compose)
运维·docker·容器
茶馆大橘10 小时前
微服务系列五:避免雪崩问题的限流、隔离、熔断措施
java·jmeter·spring cloud·微服务·云原生·架构·sentinel
北漂IT民工_程序员_ZG10 小时前
k8s集群安装(minikube)
云原生·容器·kubernetes
coding侠客10 小时前
揭秘!微服务架构下,Apollo 配置中心凭啥扮演关键角色?
微服务·云原生·架构
梦魇梦狸º13 小时前
腾讯轻量云服务器docker拉取不到镜像的问题:拉取超时
docker·容器·github
南猿北者16 小时前
docker镜像仓库常用命令
运维·docker·容器
2301_8061313617 小时前
Kubernetes的基本构建块和最小可调度单元pod-0
云原生·容器·kubernetes