# [k8s] HPA: Horizontal Pod Autoscaling

标签: k8s hpa horizontal | 发表时间:2023-03-07 16:44 | 作者:GopherDaily
出处:https://www.v2ex.com/

[k8s] HPA: Horizontal Pod Autoscaling

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

HPA 的几个关键参数:

  • minReplicas: 允许的最小 pod 数量
  • maxReplicas: 允许的最大 pod 数量
  • scaleTargetRef: hpa 针对的具体资源, 一般而言是 deployment
  • metrics 指定增加 /减少 pod 数量的标准, 常见的以 CPU 使用率来判断是否需要伸缩. K8S 也支持其他指标, 包括用户自定义指标.

以下案例就指定了 demo 的最小 pod 数量为 2, 最大为 8.

  spec:
  maxReplicas: 8
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo
  targetCPUUtilizationPercentage: 250

targetCPUUtilizationPercentage 是旧版本 API 中的字段, 指定了所有 pod 的 CPU 平均使用率高于 250% 是进行扩容, 低于 250% 时进行缩容. 当以 CPU 使用率为扩容缩容的标准时, 我们需要注意对应数值是与 usage/request 比较, 而不是 usage/limit. 即分子是实际使用的 CPU 时间, 分母是在 deployment 中申请的 CPU 时间.

HPA 计算所需 pod 数量的公式比较直观: desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] 在上述案例中, desireMetricValue 为 250. 如果实际 CPU 使用率为 320, 当前 pod 数量为 4, 则 desiredReplicas = ceil[4 * (320/ 250)], 即 5.12 向上取整的结果 6.

在实际计算中, HPA 会额外区分出 unreadyPod, missingPod 和 ignoredPod, 并根据初步计算结果选择忽视某些类型的 pod 指标再次计算, 突出一个稳. 具体逻辑可以参考 calcPlainMetricReplicas, 简单而言:

  • missingPod 指没有正确获取到对应 metric 的 pod.
  • ignoredPod 指已经或正在被删除的 pod, 和失败的 pod.
  • unreadyPod 包含多类情况:
    • 处于 Pending 状态的 Pod.
    • 启动不久且不是 Ready 状态的 Pod.
    • 启动不久且 CPU 信息采集时间和 Ready 时间过近.
    • 启动一段时间, 但是从未 Ready 过的 Pod.

最后需要注意的是, 当开启了 HPA 后, 我们不应该再设置 deployment 的 spec.replicas. 否则, 当你发布时, K8S 会按照 spec.replicas 来计算诸如 rolling update 的步骤, 导致一些非预期的行为. 比如说, spec.replicas 为 6, HPA 的范围为 2 到 25, 当前实际 pod 数量为 20, 则一旦发布, 大概率会出现 14 个以上的 pod 同时被销毁, 导致服务用户请求的资源锐减, 业务出现抖动.

相关 [k8s hpa horizontal] 推荐:

# [k8s] HPA: Horizontal Pod Autoscaling

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

k8s 自动扩缩容HPA原理及adapter配置详解

- - 掘金 后端
大家好,我是蓝胖子,都知道,k8s拥有自动扩缩容机制HPA,我们能够通过配置针对不同的扩缩容场景进行自动扩缩容,往往初学者在面对其中繁多配置的时候会学了又忘记,今天我将会以一种不同的视角,结合api server 请求 来探索这部分的配置,看完本篇,应该会对扩缩容这部分配置会有更深的理解. 我们先来看一下自动扩缩容的原理,在k8s中HPA这个模块的逻辑会定时请求api server 获取相应的pod或者CRD或者其他资源的指标信息,这些指标信息是用户创建HPA的yaml配置文件时指定的.

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 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集群状态.