Kubernetes系列之Kubernetes的弹性伸缩（HPA）

###前言
在kubernetes中，我们使用pod对外提供服务。这时候，我们需要以下两种情形需要关注：

Pod因为不明原因挂掉，导致服务不可用
Pod在高负荷的情况下，不能支撑我们的服务

如果我们人工监控pods，人工进行调整副本那么这个工作量无疑是巨大的，但kubernetes已经有了相应的机制来应对了。

###HPA全称Horizontal Pod Autoscaler控制器工作流程（V1版本）

更详细的介绍参考官方文档Horizontal Pod Autoscaler

  • 流程

    1. 创建HPA资源对象，关联对应资源例如Deployment，设定目标CPU使用率阈值，最大，最小replica数量。
      前提：pod一定要设置资源限制，参数request，HPA才会工作。
    2. HPA控制器每隔15秒钟（可以通过设置controller manager的–horizontal-pod-autoscaler-sync-period参数设定，默认15s）通过观测metrics值获取资源使用信息
    3. HPA控制器将获取资源使用信息与HPA设定值进行对比，计算出需要调整的副本数量
    4. 根据计算结果调整副本数量，使得单个POD的CPU使用率尽量逼近期望值，但不能照顾设定的最大，最小值。
    5. 以上2,3,4周期循环
  • 周期
    1. HPA控制器观测资源使用率并作出决策是有周期的，执行是需要时间的，在执行自动伸缩过程中metrics不是静止不变的，可能降低或者升高，如果执行太频繁可能导致资源的使用快速抖动，因此控制器每次决策后的一段时间内不再进行新的决策。对于扩容这个时间是3分钟，缩容则是5分钟，对应调整参数

      --horizontal-pod-autoscaler-downscale-delay
--horizontal-pod-autoscaler-upscale-delay
    2. 自动伸缩不是一次到位的，而是逐渐逼近计算值，每次调整不超过当前副本数量的2倍或者1/2
      本记录是对kubernetes HPA功能的验证，参考kubernetes官方文档，使用的是官方文档提供的镜像php-apache进行测试。
  • metrics server
    kubernetes集群需要配置好metrics server，配置参考文档Kubernetes部署metrics-server

###配置HPA实现应用横向扩展

  1. 配置启动deployment：php-apache

    
cat hpa-deployment.ymal

apiVersion: apps/v1
kind: Deployment
metadata:
name: php-apache
labels:
app: hpa-test
spec:
replicas: 1
selector:
matchLabels:
name: php-apache
app: hpa-test
template:
metadata:
labels:
name: php-apache
app: hpa-test
spec:
containers:

  • name: php-apache
    image: mirrorgooglecontainers/hpa-example:latest
    ports:

    • containerPort: 80
      name: http
      protocol: TCP
      resources:
      requests:
      cpu: 0.005
      memory: 64Mi
      limits:
      cpu: 0.05
      memory: 128Mi

      2. 配置service: php-apache-svc

      cat hpa-svc.yaml

apiVersion: v1
kind: Service
metadata:
name: php-apache-svc
labels:
app: hpa-test
spec:
selector:
name: php-apache
app: hpa-test
ports:

  • name: http
    port: 80
    protocol: TCP

    3. 配置hpa:php-apache-hpa

    cat hpa-hpa.yaml
    apiVersion: autoscaling/v1
    kind: HorizontalPodAutoscaler
    metadata:
    name: php-apache-hpa
    labels:
    app: hpa-test
    spec:
    scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
    minReplicas: 1
    maxReplicas: 10
    targetCPUUtilizationPercentage: 50

    4. 启动deployment,service,hpa,并验证

    kubectl apply -f ./

    deployment.apps/php-apache configured
    service/php-apache-svc unchanged
    horizontalpodautoscaler.autoscaling/php-apache-hpa unchanged

kubectl get all

NAME READY STATUS RESTARTS AGE
pod/php-apache-6b9f498dc4-vwlfr 1/1 Running 0 3h14m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 7d20h
service/php-apache-svc ClusterIP 10.104.34.168 <none> 80/TCP 3h14m

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/php-apache 1/1 1 1 3h14m

NAME DESIRED CURRENT READY AGE
replicaset.apps/php-apache-6b9f498dc4 1 1 1 3h14m

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/php-apache-hpa Deployment/php-apache 20%/50% 1 10 1 3h14m

###压力测试，观察HPA效果
>1.生成一个压测客户端，持续压力测试

kubectl run --generator=run-pod/v1 -i --tty load-generator --image=busybox /bin/sh

while true; do wget -q -O- http://php-apache-svc.default.svc.cluster.local; done

OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!

>2.压测一下，观察结果

kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 800%/50% 1 10 1 27m

kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 1000%/50% 1 10 2 27m

kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 1000%/50% 1 10 4 27m

kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 1000%/50% 1 10 8 27m

kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 120%/50% 1 10 10 27m

kubectl get deployment php-apache
NAME READY UP-TO-DATE AVAILABLE AGE
php-apache 10/10 10 10 28m

#####结论：随着压力测试进行，deployment下pod的CPU使用率增加，超过HPA设定的百分比50%,之后逐次翻倍扩容replicaset。达到上限停止扩容。根据replicaset设置的request QoS逐渐稳定资源的使用率。

>3.停止压测

while true; do wget -q -O- http://php-apache-svc.default.svc.cluster.local; done
OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!wget: can‘t connect to remote host (10.104.63.73): Connection refused
OK!OK!OK!OK!OK!OK!........OK!OK!OK! ^C
/ # exit
/ # Session ended, resume using ‘kubectl attach load-generator -c load-generator -i -t‘ command when the pod is running

#####CPU使用率恢复到最初值20%，controller会周期观测，逐次缩容到最小值。

kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 20%/50% 1 10 10 36m

#等待几分钟之后(默认5分钟)，原因:
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 20%/50% 1 10 4 41m

#再次等待几分钟后(默认5分钟)
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 20%/50% 1 10 2 46m

#再次等待几分钟后（默认5分钟），稳定在最小副本数量
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache-hpa Deployment/php-apache 20%/50% 1 10 1 53m

###其他
以上测试验证了HPA功能，使用的API版本是autoscaling/v1。通过kubectl api-versions可以查看到存在3个版本。v1版本只支持CPU，v2beta2版本支持多metrics(CPU，memory)以及自定义metrics。基于autoscaling/v2beta2的hpa yaml文件写法

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache-hpa
labels:
app: hpa-test
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:

  • type: Resource
    resource:
    name: cpu
    target:
    type: Utilization
    averageUtilization: 50

原文地址：https://blog.51cto.com/79076431/2475855

时间： 2024-10-03 01:45:31

Kubernetes系列之Kubernetes的弹性伸缩（HPA）的相关文章

Kubernetes系列之Kubernetes部署metrics-server

四.Kubernetes系列之Kubernetes部署metrics-server#一.metrics-server简介自kubernetes 1.8开始,资源使用指标(如容器 CPU 和内存使用率)通过 Metrics API 在 Kubernetes 中获取,metrics-server 替代了heapster.Metrics Server 实现了Resource Metrics API,Metrics Server?是集群范围资源使用数据的聚合器.?Metrics Server 从每个节点

Kubernetes系列之Kubernetes资源管理

Kubernetes 从创建之初的核心模块之一就是资源调度.想要在生产环境使用好 Kubernetes,必须对它的资源模型以及资源管理非常了解.这篇文章算是对散布在网络上的 Kubernetes 资源管理内容的一个总结.干货文章,强列推荐一读. Kubernetes 资源简介 什么是资源? 在 Kubernetes 中,有两个基础但是非常重要的概念:Node 和 Pod.Node 翻译成节点,是对集群资源的抽象:Pod 是对容器的封装,是应用运行的实体.Node 提供资源,而 Pod 使用资源,

Kubernetes系列02—Kubernetes设计架构和设计理念

1.Kubernetes设计架构 Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc),一切都基于分布式的存储系统.下面这张图是Kubernetes的架构图. 2.Kubernetes节点 2.1 介绍 ① 在这张系统架构图中,我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务. ② Kubernetes节点有运行应用容器必备的服务,而这些都是受Master的控制. ③ 每次个节点上当然都要运行Docker.Docker来

在Kubernetes上运行SAP UI5应用(下): 一个例子体会Kubernetes内容器的高可用性和弹性伸缩

上一篇文章 在Kubernetes上运行SAP UI5应用(上),我介绍了如何在Docker里运行一个简单的SAP UI5应用,并且已经成功地将一个包含了这个UI5应用的docker镜像上传到Docker hub上. 这篇文章作为这个主题的下半部分,将会介绍如何在Kubernetes里运行这个docker镜像. 文章目录 Kubernetes里的两个重要概念:pod和deployment Kubernetes保证应用程序高可用性和伸缩性的一些体验 Kubernetes滚动升级(Rolling U

Kubernetes系列：Kubernetes Dashboard

15.1.Dashboard 作为Kube认得Web用户界面,用户可以通过Dashboard在Kubernetes集群中部署容器化的应用,对应用进行问题处理和管理,并对集群本身进行管理.通过Dashboard,用户可以查看集群中应用的运行情况,同时也能够基于Dashboard创建或修改部署.任务.服务等Kubernetes的资源.通过部署向导,用户能够对部署进行扩容缩容,进行滚动更新.重启Pod或部署新应用,也能够查看Kubernetes资源的状态. dashboard-secret.yaml

Kubernetes系列之Kubernetes Pod控制器

#一.常见Pod控制器及含义 ###1. ReplicaSets ReplicaSet是下一代复本控制器.ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持.Replication Controller只支持基于等式的selector(env=dev或environment!=qa),但ReplicaSet还支持新的,基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)).大多数kub

Kubernetes系列之Kubernetes使用ingress-nginx作为反向代理

#一.Ingress简介 在Kubernetes中,服务和Pod的IP地址仅可以在集群网络内部使用,对于集群外的应用是不可见的.为了使外部的应用能够访问集群内的服务,在Kubernetes 目前 提供了以下几种方案:NodePortLoadBalancerIngress###1.Ingress组成ingress controller 将新加入的Ingress转化成Nginx的配置文件并使之生效ingress服务 将Nginx的配置抽象成一个Ingress对象,每添加一个新的服务只需写一个新的In

Kubernetes系列之kubernetes Prometheus Operator

Operator是由CoreOS公司开发的用来扩展Kubernetes API的特定应用程序控制器,用来创建.配置和管理复杂的有状态应用,例如Mysql.缓存和监控系统.目前CoreOS官方提供了几种Operator的代码实现,其中就包括Prometheus Operator 下图为Prometheus Operator 架构图 Operator作为一个核心的控制器,它会创建Prometheus.ServiceMonitor.alertmanager以及我们的prometheus-rule这四个

Kubernetes高级进阶之多维度弹性伸缩

**基于Kubernetes的多维度的弹性伸缩** 目录:2.1 传统弹性伸缩的困境2.2 kubernetes 弹性伸缩布局2.3 Node 自动扩容/缩容2.4 pod自动扩容/缩容 (HPA)2.5 基于CPU指标缩放2.6 基于prometheus自定义指标缩放 2.1 传统伸缩的困境从传统意义上,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾蓝色水位线表示集群资源容量随着负载的增加不断扩容,红色曲线表示集群资源实际负载变化.弹性伸缩就是要解决当实际负载增加,而集群资源容量没来得及反应