第15关 K8s HPA:自动水平伸缩Pod,实现弹性扩展和资源优化

这篇具有很好参考价值的文章主要介绍了第15关 K8s HPA:自动水平伸缩Pod,实现弹性扩展和资源优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

------> 课程视频同步分享在今日头条和B站

大家好,我是博哥爱运维,这节课带来k8s的HPA 自动水平伸缩pod( 视频后面有彩蛋 : ) )。
第15关 K8s HPA:自动水平伸缩Pod,实现弹性扩展和资源优化,2023年Kubernetes实战攻略,kubernetes,docker,云原生,容器

我们知道,初始Pod的数量是可以设置的,同时业务也分流量高峰和低峰,那么怎么即能不过多的占用K8s的资源,又能在服务高峰时自动扩容pod的数量呢,在K8s上的答案是Horizontal Pod Autoscaling,简称HPA 自动水平伸缩,这里只以我们常用的CPU计算型服务来作为HPA的测试,这基本满足了大部分业务服务需求,其它如vpa纵向扩容,还有基于业务qps等特殊指标扩容这个在后面计划会以独立高级番外篇来作教程。

自动水平伸缩,是指运行在k8s上的应用负载(POD),可以根据资源使用率进行自动扩容、缩容,它依赖metrics-server服务pod使用资源指标收集;我们知道应用的资源使用率通常都有高峰和低谷,所以k8s的HPA特性应运而生;它也是最能体现区别于传统运维的优势之一,不仅能够弹性伸缩,而且完全自动化!

我们在生产中通常用得最多的就是基于服务pod的cpu使用率metrics来自动扩容pod数量,下面来以生产的标准来实战测试下(注意:使用HPA前我们要确保K8s集群的dns服务和metrics服务是正常运行的,并且我们所创建的服务需要配置指标分配)

# pod内资源分配的配置格式如下:
# 默认可以只配置requests,但根据生产中的经验,建议把limits资源限制也加上,因为对K8s来说,只有这两个都配置了且配置的值都要一样,这个pod资源的优先级才是最高的,在node资源不够的情况下,首先是把没有任何资源分配配置的pod资源给干掉,其次是只配置了requests的,最后才是两个都配置的情况,仔细品品
      resources:
        limits:   # 限制单个pod最多能使用1核(1000m 毫核)cpu以及2G内存
          cpu: "1"
          memory: 2Gi
        requests: # 保证这个pod初始就能分配这么多资源
          cpu: "1"
          memory: 2Gi

我们先不做上面配置的改动,看看直接创建hpa会产生什么情况:

# 为deployment资源web创建hpa,pod数量上限3个,最低1个,在pod平均CPU达到50%后开始扩容
kubectl  autoscale deployment web --max=3 --min=1 --cpu-percent=50

#过一会看下这个hpa资源的描述(截取这下面一部分)
# 下面提示说到,HPA缺少最小资源分配的request参数
Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: missing request for cpu
Events:
  Type     Reason                        Age                     From                       Message
  ----     ------                        ----                    ----                       -------
  Warning  FailedComputeMetricsReplicas  3m46s (x12 over 6m33s)  horizontal-pod-autoscaler  invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: missing request for cpu
  Warning  FailedGetResourceMetric       89s (x21 over 6m33s)    horizontal-pod-autoscaler  missing request for cpu

我们现在以上面创建的deployment资源web来实践下hpa的效果,首先用我们学到的方法导出web的yaml配置,并增加资源分配配置增加:

# cat web.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx:1.21.6
        name: nginx
        resources:
          limits:   # 因为我这里是测试环境,所以这里CPU只分配50毫核(0.05核CPU)和20M的内存
            cpu: "50m"
            memory: 20Mi
          requests: # 保证这个pod初始就能分配这么多资源
            cpu: "50m"
            memory: 20Mi

更新web资源:

# kubectl  apply -f web.yaml              
deployment.apps/web configured

然后创建hpa:

# kubectl  autoscale deployment web --max=3 --min=1 --cpu-percent=50         
horizontalpodautoscaler.autoscaling/web autoscaled

# 等待一会,可以看到相关的hpa信息(K8s上metrics服务收集所有pod资源的时间间隔大概在60s的时间)
# kubectl get hpa -w
NAME   REFERENCE        TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
web    Deployment/web   <unknown>/50%   1         3         1          39s
web    Deployment/web   0%/50%          1         3         1          76s

我们来模拟业务流量增长,看看hpa自动伸缩的效果:

# 我们启动一个临时pod,来模拟大量请求
# kubectl run -it --rm busybox --image=registry.cn-shanghai.aliyuncs.com/acs/busybox:v1.29.2 -- sh
/ # while :;do wget -q -O- http://web;done

# 等待2 ~ 3分钟,注意k8s为了避免频繁增删pod,对副本的增加速度有限制
# kubectl get hpa web -w
NAME   REFERENCE        TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
web    Deployment/web   0%/50%    1         3         1          11m
web    Deployment/web   102%/50%   1         3         1          14m
web    Deployment/web   102%/50%   1         3         3          14m

# 看下hpa的描述信息下面的事件记录
# kubectl describe hpa web
Events:
  Type     Reason                        Age                From                       Message
  ----     ------                        ----               ----                       -------
...
  Normal   SuccessfulRescale             62s                horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target

好了,HPA的自动扩容已经见过了,现在停掉压测,观察下HPA的自动收缩功能:

# 可以看到,在业务流量高峰下去后,HPA并不急着马上收缩pod数量,而是等待5分钟后,再进行收敛,这是稳妥的作法,是k8s为了避免频繁增删pod的一种手段
# kubectl get hpa web -w
NAME   REFERENCE        TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
web    Deployment/web   102%/50%   1         3         3          16m
web    Deployment/web   0%/50%     1         3         3          16m
web    Deployment/web   0%/50%     1         3         3          20m
web    Deployment/web   0%/50%     1         3         1          21m
附:

VPA https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

KEDA基于自定义api接口伸缩
https://keda.sh/docs/2.12/scalers/metrics-api/

KEDA基于Prometheus指标伸缩

https://keda.sh/docs/2.12/scalers/prometheus/文章来源地址https://www.toymoban.com/news/detail-754104.html

到了这里,关于第15关 K8s HPA:自动水平伸缩Pod,实现弹性扩展和资源优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • HPA (Horizontal Pod Autoscaler) In K8s

    没准正在建设中哈哈哈 作为一位城市观察者和设计师,我想借助Kubernetes的HPA机制思想来描述城市红绿灯自动调节的场景。 在这个故事中,我们的城市面临着日益增长的交通流量和挤塞问题。为了应对这一挑战,城市决定引入智能化红绿灯系统,以更好地管理交通流量和提高

    2024年02月07日
    浏览(40)
  • k8s 1.23.10 动态POD扩缩容(HPA )

    目录 为什么要自动扩缩容? 再K8S中扩容分为两种: 一、Node层面: 二、Pods层面: 自动扩缩容的方案有哪些 Kubernetes HPA (Horizontal Pod Autoscaling) Kubernetes KPA (Knative Pod Autoscaler) Kubernetes VPA (Vertical Pod Autoscaler) 基于HPA进行POD的扩缩容 kube-apiserver 配置: 安装metrcs-server与addon-

    2024年02月06日
    浏览(55)
  • 【k8s、云原生】基于metrics-server弹性伸缩

    第四阶段 时  间:2023年8月18日 参加人:全班人员 内  容: 基于metrics-server弹性伸缩 目录 一、Kubernetes部署方式 (一)minikube (二)二进制包 (三)Kubeadm 二、基于kubeadm部署K8S集群 (一)环境准备 (二)部署kubernetes集群 (三)安装Dashboard UI (四)metrics-server服务部署 (

    2024年02月12日
    浏览(40)
  • K8s(健康检查+滚动更新+优雅停机+弹性伸缩+Prometheus监控+配置分离)

    前言 快速配置请直接跳转至汇总配置 K8s + SpringBoot实现零宕机发布:健康检查+滚动更新+优雅停机+弹性伸缩+Prometheus监控+配置分离(镜像复用) 配置 健康检查 业务层面 定义访问端口、路径及权限 application.yaml 将暴露/actuator/health/readiness和/actuator/health/liveness两个接口,访问方

    2024年02月14日
    浏览(41)
  • SpringBoot + K8S 中的滚动发布、优雅停机、弹性伸缩、应用监控、配置分离

    前言 配置 健康检查 滚动更新 弹性伸缩 Prometheus集成 配置分离 汇总配置 业务层面 运维层面 K8s + SpringBoot实现零宕机发布:健康检查+滚动更新+优雅停机+弹性伸缩+Prometheus监控+配置分离(镜像复用) 基于 Spring Boot + MyBatis Plus + Vue Element 实现的后台管理系统 + 用户小程序,支持

    2024年02月07日
    浏览(41)
  • 第16关 革新云计算:如何利用弹性容器与托管K8S实现极速服务POD扩缩容

    ------ 课程视频同步分享在今日头条和B站 天下武功,唯快不破! 大家好,我是博哥爱运维。这节课给大家讲下云平台的弹性容器实例怎么结合其托管K8S,使用混合服务架构,带来极致扩缩容快感。 下面是全球主流云平台弹性容器相关使用文档: 这里以阿里云的ACK托管K8S平台

    2024年02月04日
    浏览(56)
  • 企业级实战 Spring Boot + K8S 中的滚动发布、优雅停机、弹性伸缩、应用监控、配置分离

    下面为大家介绍我司生产环境使用了3年的基于K8S的dev ops 配置实现 K8s + SpringCloud实现零宕机发版,优雅重启:健康检查+滚动更新+优雅停机+弹性伸缩+Prometheus监控+配置分离(镜像复用) 业务层面 项目依赖 pom.xml 使用 spring-boot-starter-actuator 镜像 存活、就绪检查 使用 prometheus

    2024年02月06日
    浏览(51)
  • 【云原生•监控】基于Prometheus实现自定义指标弹性伸缩(HPA)

    「Autoscaling即弹性伸缩,是Kubernetes中的一种非常核心的功能,它可以根据给定的指标(例如 CPU 或内存)自动缩放Pod副本,从而可以更好地管理和利用计算资源,提高系统的可用性和性能,同时减少开销和成本。弹性伸缩可以解决服务负载存在较大波动或资源实际使用与预估

    2024年02月14日
    浏览(46)
  • Kubernetes 笔记(17)— 系统监控、使用Metrics Server、hpa 自动伸缩 Pod 数量、Prometheus 的使用

    如果你对 Linux 系统有所了解的话,也许知道有一个命令 top 能够实时显示当前系统的 CPU 和内存利用率,它是性能分析和调优的基本工具,非常有用。 Kubernetes 也提供了类似的命令,就是 kubectl top ,不过默认情况下这个命令不会生效,必须要安装一个插件 Metrics Server 才可以。

    2024年02月01日
    浏览(40)
  • 阿里云ACK(容器服务)+ElasticWorkload弹性负载+HPA弹性伸缩实践

    阿里云ACK(kubernetes容器服务),高弹性,高稳定性,低成本解决方案。 通过将ECI服务以虚拟节点的方式接入ACK容器集群,将集群中pod应用的固定量调度到现有的ACK容器服务的ECS node节点上,将集群中pod应用的弹性量通过ElasticWorkload组件调度的ECI服务的虚拟节点上。 以ACK容器服务

    2024年02月11日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包