Horizontal Pod Autoscaler(HPA)

我们可以通过手动执行kubeclt sacle命令实现Pod的扩缩容，但是这显然不符合Kubernetes的定位目标—自动化和智能化。Kubernetes期望可以通过监测Pod的使用情况，实现Pod数量的自动调整，于是就产生了HPA这种控制器。

HPA可以获取每个Pod的利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量调整。其实HPA和之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析目标Pod的负载变化情况，来确定是否需要针对性的调整目标Pod的副本数。

安装metrice-server(v0.3.6)

metrics-server可以用来收集集群中的资源使用情况。

获取metrics-server,可以直接访问Github进行获取，自行从Github上获取注意版本号。Github地址

这里我也提供了下载链接，点击下载

在部署前需要修改metrics-server-deployment.yaml文件 。

cd metrics-server-0.3.6/deploy/1.8+/

vim metrics-server-deployment.yaml

按照图片上标注的位置，加入下面配置：

hostNetwork: true

image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6

args:

  - --kubelet-insecure-tls

  - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

修改完成后，安装metrics-server：

[root@master 1.8+]# kubectl apply -f ./

clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created

clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created

rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created

apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

serviceaccount/metrics-server created

deployment.apps/metrics-server created

service/metrics-server created

clusterrole.rbac.authorization.k8s.io/system:metrics-server created

clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created

查看metrics-server生成的Pod ：

# kubectl get pod -n kube-system

NAME                                       READY   STATUS    RESTARTS   AGE

calico-kube-controllers-59877c7fb4-t5qvj   1/1     Running   0          25h

calico-node-67xqv                          1/1     Running   0          150m

calico-node-8t2n5                          1/1     Running   0          25h

calico-node-jnst5                          1/1     Running   0          25h

coredns-7ff77c879f-9zmp4                   1/1     Running   0          27h

coredns-7ff77c879f-kbmqc                   1/1     Running   0          27h

etcd-master                                1/1     Running   0          27h

kube-apiserver-master                      1/1     Running   0          27h

kube-controller-manager-master             1/1     Running   0          27h

kube-proxy-255pm                           1/1     Running   0          27h

kube-proxy-7b2qg                           1/1     Running   0          150m

kube-proxy-xcd9f                           1/1     Running   0          27h

kube-scheduler-master                      1/1     Running   0          27h

metrics-server-5f55b696bd-rfxkv            1/1     Running   0          53s

我们发现metrics-server的pod已经生成。接着我们使用kubectl top命令查看资源使用情况：

# kubectl top node && kubectl top pod -n kube-system

NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%

master   590m         7%     1524Mi          19%

node1    305m         3%     771Mi           21%

node2    308m         3%     506Mi           13%

NAME                                       CPU(cores)   MEMORY(bytes)

calico-kube-controllers-59877c7fb4-t5qvj   2m           16Mi

calico-node-67xqv                          102m         47Mi

calico-node-8t2n5                          91m          85Mi

calico-node-jnst5                          90m          79Mi

coredns-7ff77c879f-9zmp4                   7m           14Mi

coredns-7ff77c879f-kbmqc                   10m          14Mi

etcd-master                                43m          33Mi

kube-apiserver-master                      125m         356Mi

kube-controller-manager-master             57m          48Mi

kube-proxy-255pm                           2m           31Mi

kube-proxy-7b2qg                           2m           16Mi

kube-proxy-xcd9f                           2m           20Mi

kube-scheduler-master                      8m           17Mi

metrics-server-5f55b696bd-rfxkv            2m           14Mi

HPA

现在我们用 Deployment 来创建一个 Nginx Pod，然后利用 HPA 来进行自动扩缩容。资源清单如下所示：（hpa-demo.yaml）

apiVersion: apps/v1 # 版本号

kind: Deployment # 类型

metadata: # 元数据

  name: nginx # deployment的名

spec: # 详细描述

  selector: # 选择器，通过它指定该控制器可以管理哪些Pod

    matchLabels: # Labels匹配规则

      app: nginx-pod

  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本

    metadata:

      labels:

        app: nginx-pod

    spec:

      containers:

        - name: nginx # 容器名称

          image: nginx:1.17.1 # 容器需要的镜像地址

          ports:

            - containerPort: 80 # 容器所监听的端口

              protocol: TCP

          resources: # 资源限制

            requests:

              cpu: "100m" # 100m表示100millicpu，即0.1个CPU

我们直接创建后查看状态：

# kubectl get pod

NAME                     READY   STATUS    RESTARTS   AGE

nginx-587f44948f-669b5   1/1     Running   0          26s

# kubectl get deployment

NAME    READY   UP-TO-DATE   AVAILABLE   AGE

nginx   1/1     1            1           34s

接着我们创建一个Service,为了给我们提供一个外部访问的IP,方便我们后面的压测：

# kubectl expose deployment nginx --name=nginx --type=NodePort --port=80 --target-port=80

service/nginx exposed

# kubectl get svc

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE

kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        27h

nginx        NodePort    10.103.32.192   <none>        80:30372/TCP   51s

接下来我们需要创建HPA的资源文件了(hpa.yaml)：

apiVersion: autoscaling/v1 # 版本号

kind: HorizontalPodAutoscaler # 类型

metadata: # 元数据

  name: pc-hpa # deployment的名称

spec:

  minReplicas: 1 # 最小Pod数量

  maxReplicas: 10 # 最大Pod数量

  targetCPUUtilizationPercentage: 3 # CPU使用率指标

  scaleTargetRef:  # 指定要控制的Deployment

    apiVersion: apps/v1

    kind: Deployment

    name: nginx

创建后我们进行查看hpa的状态：

# kubectl get hpa

NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE

pc-hpa   Deployment/nginx   0%/3%     1         10        1          57s

下面我们准备一段go脚本，并发访问：

package testing

import (

	"fmt"

	"net/http"

	"testing"

)

func Test_k8s(t *testing.T) {

	for i := 0 ; i < 10000; i ++ {

		go func(){

            // ip : master Ip

            // port: svc暴露给我们的port

			resp, err := http.Get("http://192.168.209.148:30372")

			if err != nil {

				fmt.Println(err)

			} else {

				fmt.Println(resp)

			}

		}()

	}

	select{}

}

最后我们开启三个窗口，分别查看hpa,deploy以及pod的状态变化

hpa :

# kubectl get hpa -w

NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE

pc-hpa   Deployment/nginx   0%/3%     1         10        1          14m

pc-hpa   Deployment/nginx   188%/3%   1         10        1          14m

pc-hpa   Deployment/nginx   188%/3%   1         10        4          14m

pc-hpa   Deployment/nginx   188%/3%   1         10        8          15m

pc-hpa   Deployment/nginx   188%/3%   1         10        10         15m

pc-hpa   Deployment/nginx   2%/3%     1         10        10         15m

pc-hpa   Deployment/nginx   0%/3%     1         10        10         16m

deploy:

# kubectl get deploy -w

NAME    READY   UP-TO-DATE   AVAILABLE   AGE

nginx   1/1     1            1           21m

nginx   1/4     1            1           22m

nginx   1/4     1            1           22m

nginx   1/4     1            1           22m

nginx   1/4     4            1           22m

nginx   2/4     4            2           22m

nginx   3/4     4            3           22m

nginx   4/4     4            4           22m

nginx   4/8     4            4           23m

nginx   4/8     4            4           23m

nginx   4/8     4            4           23m

nginx   4/8     8            4           23m

nginx   5/8     8            5           23m

nginx   6/8     8            6           23m

nginx   7/8     8            7           23m

nginx   8/8     8            8           23m

nginx   8/10    8            8           23m

nginx   8/10    8            8           23m

nginx   8/10    8            8           23m

nginx   8/10    10           8           23m

nginx   9/10    10           9           23m

nginx   10/10   10           10          23m

pod：

# kubectl get pod -w

NAME                     READY   STATUS    RESTARTS   AGE

nginx-587f44948f-669b5   1/1     Running   0          21m

nginx-587f44948f-dwcw8   0/1     Pending   0          0s

nginx-587f44948f-ktjrm   0/1     Pending   0          0s

nginx-587f44948f-mvz2d   0/1     Pending   0          0s

nginx-587f44948f-dwcw8   0/1     Pending   0          0s

nginx-587f44948f-ktjrm   0/1     Pending   0          0s

nginx-587f44948f-mvz2d   0/1     Pending   0          0s

nginx-587f44948f-dwcw8   0/1     ContainerCreating   0          0s

nginx-587f44948f-ktjrm   0/1     ContainerCreating   0          0s

nginx-587f44948f-mvz2d   0/1     ContainerCreating   0          0s

nginx-587f44948f-dwcw8   0/1     ContainerCreating   0          1s

nginx-587f44948f-mvz2d   0/1     ContainerCreating   0          1s

nginx-587f44948f-mvz2d   1/1     Running             0          2s

nginx-587f44948f-dwcw8   1/1     Running             0          2s

nginx-587f44948f-ktjrm   0/1     ContainerCreating   0          3s

nginx-587f44948f-ktjrm   1/1     Running             0          3s

nginx-587f44948f-kr49r   0/1     Pending             0          0s

nginx-587f44948f-vk24j   0/1     Pending             0          0s

nginx-587f44948f-bmkwv   0/1     Pending             0          0s

nginx-587f44948f-vfvwb   0/1     Pending             0          0s

nginx-587f44948f-kr49r   0/1     Pending             0          0s

nginx-587f44948f-vk24j   0/1     Pending             0          0s

nginx-587f44948f-bmkwv   0/1     Pending             0          0s

nginx-587f44948f-vfvwb   0/1     Pending             0          0s

nginx-587f44948f-vk24j   0/1     ContainerCreating   0          0s

nginx-587f44948f-kr49r   0/1     ContainerCreating   0          0s

nginx-587f44948f-vfvwb   0/1     ContainerCreating   0          0s

nginx-587f44948f-bmkwv   0/1     ContainerCreating   0          0s

nginx-587f44948f-vk24j   0/1     ContainerCreating   0          6s

nginx-587f44948f-vfvwb   0/1     ContainerCreating   0          6s

nginx-587f44948f-vk24j   1/1     Running             0          7s

nginx-587f44948f-vfvwb   1/1     Running             0          7s

nginx-587f44948f-bmkwv   0/1     ContainerCreating   0          11s

nginx-587f44948f-kr49r   0/1     ContainerCreating   0          12s

nginx-587f44948f-bmkwv   1/1     Running             0          12s

nginx-587f44948f-kr49r   1/1     Running             0          12s

nginx-587f44948f-4wxvp   0/1     Pending             0          0s

nginx-587f44948f-wq52m   0/1     Pending             0          0s

nginx-587f44948f-4wxvp   0/1     Pending             0          0s

nginx-587f44948f-wq52m   0/1     Pending             0          0s

nginx-587f44948f-4wxvp   0/1     ContainerCreating   0          0s

nginx-587f44948f-wq52m   0/1     ContainerCreating   0          0s

nginx-587f44948f-4wxvp   0/1     ContainerCreating   0          2s

nginx-587f44948f-wq52m   0/1     ContainerCreating   0          2s

nginx-587f44948f-4wxvp   1/1     Running             0          2s

nginx-587f44948f-wq52m   1/1     Running             0          3s

Kubernetes控制器-Horizontal Pod Autoscaler(HPA)的更多相关文章

  1. Horizontal Pod Autoscaler（Pod水平自动伸缩）

    Horizontal Pod Autoscaler 根据观察到的CPU利用率(或在支持自定义指标的情况下,根据其他一些应用程序提供的指标)自动伸缩 replication controller, de ...

  2. Kubernetes 弹性伸缩HPA功能增强Advanced Horizontal Pod Autoscaler -介绍部署篇

    背景 WHAT(做什么) Advanced Horizontal Pod Autoscaler(简称:AHPA)是kubernetes中HPA的功能增强. 在兼容原生HPA功能基础上,增加预测.执行模 ...

  3. Kubernetes Horizontal Pod Autoscaler

    非常牛逼的技术,目前最新的版本支持众多的Feature HPA功能需要Heapster收集的CPU.内存等数据作为支撑 配置示例: apiVersion: autoscaling/v2beta1 ki ...

  4. kubernetes 控制器详解【持续完善中】

    目录 资源创建详解 一:Pod及常用参数 1.简介 2.模板 3.删除pod 4.设置Pod主机名 5.镜像拉取策略(ImagePullPolicy) 二:RC 1.简介 2.模板 三:Deploym ...

  5. k8s 自动伸缩 pod（HPA）

    上一篇简单说了一下使用 kubeadm 安装 k8s.今天说一下 k8s 的一个神奇的功能:HPA (Horizontal Pod Autoscaler). HPA 依赖 metrics-server ...

  6. [置顶] kubernetes资源对象--Horizontal Pod Autoscaling（HPA）

    概念 HPA全称Horizontal Pod Autoscaling,即pod的水平自动扩展.自动扩展主要分为两种,其一为水平扩展,针对于实例数目的增减:其二为垂直扩展,即单个实例可以使用的资源的增减 ...

  7. Kubernetes Horizontal Pod Autoscaling

    HPA介绍 Horizo​​ntal Pod Autoscaler基于观察到的CPU利用率(或借助自定义指标 支持,基于其他一些应用程序提供的指标)自动缩放复制控制器,部署或副本集中的Pod数量 .请 ...

  8. Kubernetes 笔记 012 Pod 的自动扩容与缩容

    本文首发于我的公众号 Linux云计算网络(id: cloud_dev),专注于干货分享,号内有 10T 书籍和视频资源,后台回复「1024」即可领取,欢迎大家关注,二维码文末可以扫. Hi,大家好, ...

  9. Kubernetes 控制器

    在实际使用的时候并不会直接使用 Pod,而是会使用各种控制器来满足我们的需求,Kubernetes 中运行了一系列控制器来确保集群的当前状态与期望状态保持一致,它们就是 Kubernetes 的大脑. ...

  10. Kubernetes 基于 Metrics Server 与 HPA 的使用

    在 Kubernetes 中可以手动通过 kubectl scale 命令或通过修改 replicas 数量,可以实现 Pod 的扩容或缩容.Kubernetes 中还提供了 HPA(Horizont ...

随机推荐

  1. DB读写分离情况下，如何解决缓存和数据库不一致性问题？

    前言 在读写分离的情况下,缓存和数据库数据不一致怎么解决? 请看这一篇如何更新缓存保证缓存和数据库双写一致性? 如何解决DB数据库的数据不一致问题? 请看这一篇怎么解决DB读写分离,导致数据不一致问题 ...

  2. go time时间格式化

    时间戳与时间格式相互转化 例一 // 时间戳转时间 str_time := time.Unix(1617279282,0).Format("2006-01-02 15:04:05" ...

  3. Ubuntu 卸载安装nginx

    nginx很顽强,单独的删除它的文件是不够的,这会导致你再次安装时出现一系列的问题. 1.卸载nginx,及其配置文件 sudo apt-get --purge remove nginx 2.自动全部 ...

  4. jquery简单的上传图片预览

    html <div id="bcd"></div> <input type="file" id="abc"&g ...

  5. C#通过FTP获取服务端文件

    一.简介   实际需求是在前端修改了配置文件后,由上位机统一分发给所有设备,因为下位机支持FTP协议,因此选用FTP来实现文件传输功能. 二.准备工作 1.FTP服务搭建 FTP服务端选用FileZi ...

  6. linux下nacos集群部署报错Error: Could not create the Java Virtual Machine.

    修改startup.sh时注意空格 注意这里-Dserver "-"之后没有空格 nohup $JAVA -Dserver.port=${PORT} ${JAVA_OPT} nac ...

  7. Linux系统中的目录和文件夹的区别

    Linux系统中的目录和文件夹的区别 目录 Linux系统中的目录和文件夹的区别 一.概念与术语背景 1.目录(Directory) 2.文件夹(Folder) 二.技术实现差异 1.存储内容 2.权 ...

  8. Quartz.NET - 教程 12: Quartz 的其他特性

    译者注: 目录在这 Quartz.NET 3.x 教程 原文在这 Lesson 12: Miscellaneous Features of Quartz 插件 Quartz 提供了一个用于插入附加功能 ...

  9. RL · Exploration | 使用时序距离构造 intrinsic reward，鼓励 agent 探索

    论文标题:Episodic Novelty Through Temporal Distance. ICLR 2025,8 8 6 5 poster. arxiv:https://arxiv.org/a ...

  10. 如何使用Nacos作为配置中心统一管理配置

    如何使用Nacos作为配置中心统一管理配置 1).引入依赖, <dependency> <groupId>com.alibaba.cloud</groupId> & ...