Horizontal Pod Autoscaler(Pod水平自动伸缩)

Horizontal Pod Autoscaler 根据观察到的CPU利用率(或在支持自定义指标的情况下,根据其他一些应用程序提供的指标)自动伸缩 replication controller, deployment, replica set, stateful set 中的pod数量。注意,Horizontal Pod Autoscaling不适用于无法伸缩的对象,例如DaemonSets。

Horizontal Pod Autoscaler 被实现作为Kubernetes API资源和控制器。该资源决定控制器的行为。控制器会定期调整副本控制器或部署中副本的数量,以使观察到的平均CPU利用率与用户指定的目标相匹配。

1. Horizontal Pod Autoscaler 是如何工作的

Horizontal Pod Autoscaler 实现为一个控制循环,其周期由--horizontal-pod-autoscaler-sync-period选项指定(默认15秒)。

在每个周期内,controller manager都会根据每个HorizontalPodAutoscaler定义的指定的指标去查询资源利用率。 controller manager从资源指标API(针对每个pod资源指标)或自定义指标API(针对所有其他指标)获取指标。

对于每个Pod资源指标(比如:CPU),控制器会从资源指标API中获取相应的指标。然后,如果设置了目标利用率值,则控制器计算利用率值作为容器上等效的资源请求百分比。如果设置了目标原始值,则直接使用原始指标值。然后,控制器将所有目标容器的利用率或原始值(取决于指定的目标类型)取平均值,并产生一个用于缩放所需副本数量的比率。

如果某些Pod的容器未设置相关资源请求,则不会定义Pod的CPU使用率,并且自动缩放器不会对该指标采取任何措施。

2. 算法细节

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

直译为:(当前指标值 ? 期望指标值) ?? 当前副本数 ,结果再向上取整,最终结果就是期望的副本数量

例如,假设当前指标值是200m ,期望指标值是100m,期望的副本数量就是双倍。因为,200.0 / 100.0 == 2.0

如果当前值是50m,则根据50.0 / 100.0 == 0.5,那么最终的副本数量就是当前副本数量的一半

如果该比率足够接近1.0,则会跳过伸缩

当targetAverageValue或者targetAverageUtilization被指定的时候,currentMetricValue取HorizontalPodAutoscaler伸缩目标中所有Pod的给定指标的平均值。

所有失败的和标记删除的Pod将被丢弃,即不参与指标计算

当基于CPU利用率来进行伸缩时,如果有尚未准备好的Pod(即它仍在初始化),那么该Pod将被放置到一边,即将被保留。

kubectl 也支持Horizontal Pod Autoscaler

# 查看autoscalers列表
kubectl get hpa
# 查看具体描述
kubectl describe hpa
# 删除autoscaler
kubectl delete hpa

# 示例:以下命名将会为副本集foo创建一个autoscaler,并设置目标CPU利用率为80%,副本数在2~5之间
kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80

3. 演示

Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment, replica set or stateful set based on observed CPU utilization.

创建Dockerfile,并构建镜像

FROM java:8
COPY ./hello-world-0.0.1-SNAPSHOT.jar hello-world.jar
CMD java -jar hello-world.jar 

在hello-world.jar中执行一些CPU密集型计算

运行镜像并暴露为服务

kubectl run hello-world-example \
     --image=registry.cn-hangzhou.aliyuncs.com/chengjs/hello-world:2.0 \
     --requests=‘cpu=200m‘ \
     --limits=‘cpu=500m‘ \
     --expose \
     --port=80 \
     --generator=run-pod/v1 

创建 Horizontal Pod Autoscaler

HPA将增加和减少副本数量,以将所有Pod的平均CPU利用率维持在50%

kubectl autoscale deployment hello-world-example --cpu-percent=50 --min=1 --max=10 

检查autoscaler的当前状态

kubectl get hpa 

增加负载

接下来,利用压测工具持续请求,以增加负载,再查看

kubectl get deployment hello-world-example

通过使用autoscaling/v2beta2版本,你可以定义更多的指标

首先,以autoscaling/v2beta2格式获取HorizontalPodAutoscaler的YAML

kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml

在编辑器中打开/tmp/hpa-v2.yaml文件,接下来对其进行修改

第一个可以替换的指标类型是Pod指标。这些指标在各个容器中平均在一起,并且和目标值进行比较,已确定副本数。例如:

type: Pods
pods:
  metric:
    name: packets-per-second
  target:
    type: AverageValue
    averageValue: 1k 

第二个可以替换的指标类型是对象指标。顾名思义,它描述的是Object,而不是Pod。例如:

type: Object
object:
   metric:
      name: requests-per-second
   describedObject:
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      name: main-route
   target:
      type: Value
      value: 2k 

修改后完整的/tmp/hpa-v2.yaml文件如下:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
  metadata:
    name:hello-world-example
    namespace:default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hello-world-example
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      target:
        type: AverageValue
        averageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      target:
        type: Value
        value: 10k
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
    current:
      averageUtilization: 0
      averageValue: 0
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      current:
        value: 10k

4. Docs

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

原文地址:https://www.cnblogs.com/cjsblog/p/12266093.html

时间: 2024-11-05 22:31:32

Horizontal Pod Autoscaler(Pod水平自动伸缩)的相关文章

kubernetes云平台管理实战:HPA水平自动伸缩(十一)

一.自动伸缩 1.启动 [root@k8s-master ~]# kubectl autoscale deployment nginx-deployment --max=8 --min=2 --cpu-percent=80 deployment "nginx-deployment" autoscaled 2.查看创建 [root@k8s-master ~]# kubectl get all NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE de

通过一个实际例子理解Kubernetes里pod的自动scale - 水平自动伸缩

kubectl scale命令用于程序在负载加重或缩小时进行pod扩容或缩小,我们通过一些实际例子来观察scale命令到底能达到什么效果. 命令行创建一个deployment: kubectl run jerry-nginx --image=nginx:1.12.2 kubectl get deploy查看刚刚创建的deployment: 自动被deployment创建的pod: kubectl get pod: 使用下列命令查看生成的deployment明细: kubectl get depl

Kubernetes -- Horizontal Pod Autoscaler

前言 在kubernetes中,我们使用pod对外提供服务.这时候,我们需要以下两种情形需要关注: pod因为不明原因挂掉,导致服务不可用 Pod在高负荷的情况下,不能支撑我们的服务 如果我们人工监控pods,人工进行调整副本那么这个工作量无疑是巨大的,但kubernetes已经有了相应的机制来应对了. 那么今天就来介绍一下在k8s 1.6中的弹性伸缩的实施 k8s是kubernetes的官方简称HPA全称Horizontal Pod Autoscaler HPA的原理 Kubernetes有一

Azure Kubernetes 水平自动扩充Pod

当我们将应用部署到AKS中以pod的形式对外提供服务时,为了确保用户可以获得良好的使用体验,我们需要关注如下两种情况: POD因为不明原有挂掉,导致服务不可用 当出现大量用户访问时,Pod在高负荷的情况下能否支撑我们的应用 对于Pod的高可用性我们可以使用AKS的deployment控制器来确保Pod可以持续对外提供服务,但是对于面临大量用户访问时,我们就需要扩展我们的资源来满足业务需求.前面的文章中给大家介绍了手动扩展pod来满足业务的扩展需求,但是相信大家都已经意识到了如果我们人工监控pod

Kubernetes基本概念和术语之Deployment、Horizontal Pod Autoscaler和StatefulSet

1.Deployment Deployment是为了更好的解决Pod的编排问题才引入的,可以把它看作是RC的一次升级,最大的升级是我么可以看到Pod部署的进度. Deployment典型的使用场景如下: 创建一个Deployment对象来生成对应的Replica Set(相当于RC的进化版,kubernetes v1.2引入)并完成Pod副本的创建过程 检查Deployment的状态来看部署动作是否完成(Pod副本的数量是否达到预期值) 更新Deployment以创建新的Pod(如镜像升级) 若

Kubernetes集群水平扩展——HPA(自动伸缩)

Kubernetes集群可以通过Replication Controller的scale机制完成服务的扩容或缩容,实现具有伸缩性的服务. Kubernetes集群自动伸缩分为: sacle手动伸缩:可参考K8s资源对象的基本管理之使用命令行的方式(升级.回滚.扩容.缩容): autoscale自动伸缩:也就是本篇博文所介绍的HPA: Kubernetes自动扩展主要分为: 水平扩展:针对实例数目的增减: 垂直扩展:也就是单个实例就可以使用的资源的增减,比如增加CPU.内存: 一.HPA简介 HP

基于metric server的自动伸缩hpa

#(1)概念: hpa功能: 能根据pod的cpu丶内存以及其它指标自动伸缩pod副本数量, 该指标由metrics-service和custom-metrics-apiserver提供 hpa版本: 通过kubectl api-versions查看 autoscaling/v1 autoscaling/v2beta1 由metrics-service提供, 仅支持cpu指标来弹性伸缩 autoscaling/v2beta2 由custom-metrics-apiserver来提供, 支持内存网

Android中仿淘宝首页顶部滚动自定义HorizontalScrollView定时水平自动切换图片

Android中仿淘宝首页顶部滚动自定义HorizontalScrollView定时水平自动切换图片 自定义ADPager 自定义水平滚动的ScrollView效仿ViewPager 当遇到要在ViewPager中添加多张网络请求图片的情况下,不能进行复用,导致每次都要重新去求情已经请求过的数据致使流量数据过大 自定义的数据结构解决了这个问题,固定传递的图片数据之后进行统一请求,完成后进行页面切换数据复用 代码中涉及网络请求是用的Volley网络请求框架 PicCarousel是网络数据请求的U

深入kubernetes之Pod——一pod多容器

六.深入Pod--一pod多容器 一pod多容器,可以说是kube精华所在,让多个同应用的单一容器可以整合到一个类虚拟机中,使其所有容器共用一个vm的资源,提高耦合度,神来之笔,从而方便副本的复制,提高整体的可用性 接下来会从我自己的学习历程,讲诉一pod多容器,其中历经的困难,此问题有困扰一个月之久. 1.测试过程: 根据文章:http://www.csdn.net/article/2014-12-18/2823196 ,看到pod还有一pod多容器的功能,仅是看了文章便激动不已,一pod多容