Kubernetes 弹性伸缩全场景解析 (四)- 让核心组件充满弹性

本文涉及的产品
云原生网关 MSE Higress,422元/月
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
函数计算FC,每月15万CU 3个月
简介: 前言在本系列的前三篇文章中,我们介绍了弹性伸缩的整体布局以及 HPA 的一些原理,HPA 的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是cluster-proportional-autoscaler 。

前言

在本系列的前三篇文章中,我们介绍了弹性伸缩的整体布局以及 HPA 的一些原理,HPA 的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天我们要讲解的是
cluster-proportional-autoscaler 。

cluster-proportional-autoscaler 是根据集群中节点的数目进行 Pod 副本数水平伸缩的组件。这个组件的产生主要是为了解决集群的核心组件负载弹性的问题。在一个 Kubernetes 集群中,除了 APIServer 等耳熟能详的 Control Pannel 组件,还有很多系统组件是部署在 worker 上的,例如 CoreDNSIngress ControllerIstio 等等。

这些核心组件大部分和我们的应用接入层息息相关,也就是说每当我们的系统处理了一条外部的请求,可能都会调用这些组件。由于这些组件的负载过大,很有可能造成应用的QPS达到瓶颈。那么一个集群该运行多少个核心组件副本呢?

很遗憾,这个问题是没有统一答案的,因为不同的类型的应用、不同的网络模型、不同的调度分布,都有可能会带来不同的挑战。在本篇文章中,我们不谈具体的指标和数据,只探讨解法。在本系列后面的文章中,会为大家深入解析。

大部分的情况下,核心组件的副本数目和集群的节点数目是成正比的,一个集群的节点数目越多,核心组件所需要的副本数就越多。今天我们以 CoreDNS 为例,通过 cluster-proportional-autoscaler,来实现一个动态的、基于节点数目的核心组件动态伸缩。

cluster-proportional-autoscaler 的使用

cluster-proportional-autoscaler 和传统的 Kubernetes 组件设计有所不同,我们已经见惯了各种 ControllerCRD 或者 Operator,而 cluster-proportional-autoscaler 走了另外一条非常简单的路。使用 cluster-proportional-autoscaler 只需要部署一个 Yaml 并选择一个伸缩的监听对象以及伸缩策略即可。如果需要有多个组件进行伸缩,那就部署多个 Yaml,每个 Yaml 包含一个 cluster-proportional-autoscaler。一个使用 cluster-proportional-autoscaler 弹性伸缩 coredns 的模板如下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns-autoscaler
  namespace: kube-system
  labels:
    k8s-app: dns-autoscaler
spec:
  selector:
    matchLabels:
       k8s-app: dns-autoscaler
  template:
    metadata:
      labels:
        k8s-app: dns-autoscaler
    
    spec:
      serviceAccountName: admin
      containers:
      - name: autoscaler
        image: registry.cn-hangzhou.aliyuncs.com/ringtail/cluster-proportional-autoscaler-amd64:v1.3.0
        resources:
            requests:
                cpu: "200m"
                memory: "150Mi"
        command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":16,"nodesPerReplica":2,"min":1,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=2

cluster-proportional-autoscaler 的伸缩策略主要有两种:一种是线性模型,一种是梯度模型。

简单的理解,线性模型就是 y = rate * x + min,设置最小值,以及伸缩的区间,并根据当前节点的数目,通过线性模型计算所需的核心组件数目。在上面的例子中,我们用的就是线性模型,线性模型支持的配置参数如下:

{
      "coresPerReplica": 2,
      "nodesPerReplica": 1,
      "min": 1,
      "max": 100,
      "preventSinglePointFailure": true
}

minmax、以及 preventSinglePointFailure 都比较好理解,coresPerReplica 的意思是按照核心数目来计算副本集,nodesPerReplica 是按照节点数目来计算副本集。

用一个实际的例子进行举例,例如当前集群有两个节点,每个节点的配置是 4C8G,那么如果按照 coresPerReplica 这个指标计算,则需要弹出 42/2=4 个副本。如果按照 nodesPerReplica 来计算,则需要弹出 21 = 2 个副本。此时 cluster-proportional-autoscaler 会取两者之间的大的数值,也就是 4 作为最后的伸缩数目进行扩容。

梯度模型就是分级的机制,每个梯度对应了一个副本,例如:

{
      "coresToReplicas":
      [
        [ 1, 1 ],
        [ 64, 3 ],
        [ 512, 5 ],
        [ 1024, 7 ],
        [ 2048, 10 ],
        [ 4096, 15 ]
      ],
      "nodesToReplicas":
      [
        [ 1, 1 ],
        [ 2, 2 ]
      ]
    }

这个配置表示存在 coresToReplicas 和 nodesToReplicas 两个梯度,其中 coresToReplicas 的梯度表示:最小为 1 个副本;CPU 核心数目大于 3 小于 64 的时候,为 2 个副本;依次类推。

同样 nodesToReplicas 表示 1 个节点的时候为 1 个副本,2 个节点的时候为 2 个副本。

最后

至此,cluster-proportional-autoscaler 的使用就给大家讲解完了,建议优先配置 CoreDNS 的 autoscaler,对于负载不高的场景可以考虑节点副本 1:2 的比例,如果负载比较高,可以 1:1 的配置进行配置。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
8月前
|
缓存 Kubernetes Docker
GitLab Runner 全面解析:Kubernetes 环境下的应用
GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式(如 Shell、Docker、Kubernetes),可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法,重点探讨了流水线缓存(以 Python 项目为例)和构建镜像的应用,特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建,能够显著提升 CI/CD 流水线的效率和可靠性,助力开发团队实现持续集成与交付的目标。
|
6月前
|
存储 弹性计算 安全
阿里云服务器ECS通用型规格族解析:实例规格、性能基准与场景化应用指南
作为ECS产品矩阵中的核心序列,通用型规格族以均衡的计算、内存、网络和存储性能著称,覆盖从基础应用到高性能计算的广泛场景。通用型规格族属于独享型云服务器,实例采用固定CPU调度模式,实例的每个CPU绑定到一个物理CPU超线程,实例间无CPU资源争抢,实例计算性能稳定且有严格的SLA保证,在性能上会更加稳定,高负载情况下也不会出现资源争夺现象。本文将深度解析阿里云ECS通用型规格族的技术架构、实例规格特性、最新价格政策及典型应用场景,为云计算选型提供参考。
|
10月前
|
Kubernetes 监控 API
深入解析Kubernetes及其在生产环境中的最佳实践
深入解析Kubernetes及其在生产环境中的最佳实践
571 93
|
6月前
|
人工智能 自然语言处理 算法
DeepSeek大模型在客服系统中的应用场景解析
在数字化浪潮下,客户服务领域正经历深刻变革,AI技术成为提升服务效能与体验的关键。DeepSeek大模型凭借自然语言处理、语音交互及多模态技术,显著优化客服流程,提升用户满意度。它通过智能问答、多轮对话引导、多模态语音客服和情绪监测等功能,革新服务模式,实现高效应答与精准分析,推动人机协作,为企业和客户创造更大价值。
604 5
|
8月前
|
存储 人工智能 NoSQL
Tablestore深度解析:面向AI场景的结构化数据存储最佳实践
《Tablestore深度解析:面向AI场景的结构化数据存储最佳实践》由阿里云专家团队分享,涵盖Tablestore十年发展历程、AI时代多模态数据存储需求、VCU模式优化、向量检索发布及客户最佳实践等内容。Tablestore支持大规模在线数据存储,提供高性价比、高性能和高可用性,特别针对AI场景进行优化,满足结构化与非结构化数据的统一存储和高效检索需求。通过多元化索引和Serverless弹性VCU模式,助力企业实现低成本、灵活扩展的数据管理方案。
395 12
|
8月前
|
Kubernetes Linux 虚拟化
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
2329 11
|
8月前
|
存储 缓存 人工智能
深度解析CPFS 在 LLM 场景下的高性能存储技术
本文深入探讨了CPFS在大语言模型(LLM)训练中的端到端性能优化策略,涵盖计算端缓存加速、智能网卡加速、数据并行访问及数据流优化等方面。重点分析了大模型对存储系统的挑战,包括计算规模扩大、算力多样性及数据集增长带来的压力。通过分布式P2P读缓存、IO加速、高性能存算通路技术以及智能数据管理等手段,显著提升了存储系统的吞吐量和响应速度,有效提高了GPU利用率,降低了延迟,从而加速了大模型的训练进程。总结了CPFS在AI训练场景中的创新与优化实践,为未来大模型发展提供了有力支持。
|
10月前
|
监控 网络协议 算法
OSPFv2与OSPFv3的区别:全面解析与应用场景
OSPFv2与OSPFv3的区别:全面解析与应用场景
389 0
|
10月前
|
负载均衡 网络协议 算法
OSPF与其他IGP协议的比较:全面解析与应用场景
OSPF与其他IGP协议的比较:全面解析与应用场景
309 0
|
10月前
|
存储 Kubernetes 调度
深度解析Kubernetes中的Pod生命周期管理
深度解析Kubernetes中的Pod生命周期管理

相关产品

  • 容器服务Kubernetes版
  • 推荐镜像

    更多