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. 【BUG】鸿蒙模拟器虚拟化问题的解决方案

    创建记事本文档.txt,键入以下代码: pushd "%~dp0" dir /b %SystemRoot%\servicing\Packages\*Hyper-V*.mum > ...

  2. docker push image harbor http 镜像

    前言 搭建的 harbor 仓库为 http 协议,在本地登录后,推送镜像发生如下报错: docker push 192.168.xx.xx/test/grafana:v10.1.1 The push ...

  3. SQL索引失效的场景有哪些

    SQL优化里面主要是围绕索引来展开的,SQL优化的一大重点就是避免索引失效,因为索引失效就会导致全表扫描,数据量很大的情况下能明显感受到查询速度的降低. 下面说说索引失效的各种场景. 使用索引的时候, ...

  4. CSAPP学习笔记——chapter8 异常控制流

    CSAPP学习笔记--chapter8 异常控制流 简介 异常控制流(Exceptional Control Flow,ECF)是在计算机系统中处理不寻常或异常情况的一种机制.它允许系统跳出正常的顺序 ...

  5. etcd和Zookeeper孰优孰劣对比

    背景 最近在看到Pachyderm的介绍时,看到作者拿YARN和Kubernetes做类比,拿Zookeeper和etcd做对比.YARN和Kubernetes的类比还相对比较好理解,毕竟他们都有资源 ...

  6. 【python-日期和时间处理】datetime模块基本使用

    1. 获取datetime对象 获取当前datetime对象 方法:datetime.now(cls, tz=None) -> datetime 参数说明: tz:时区信息,不传该参数时,默认使 ...

  7. MCP （Model Context Protocol）初体验：企业数据与大模型融合初探

    简介 模型上下文协议(Model Context Protocol,简称MCP)是一种创新的开放标准协议,旨在解决大语言模型(LLM)与外部数据和工具之间的连接问题.它为AI应用提供了一种统一.标准化 ...

  8. 不同数据库Oracle、PostgreSQL、Vertical、Mysql常用操作

    不同数据库Oracle.PostgreSQL.Vertical.Mysql常用操作 授权语句用于管理数据库用户的权限,常见的授权语句如下: 1.授权用户对表的SELECT权限 GRANT SELECT ...

  9. 从零开始构建智能聊天机器人：Rasa与ChatGPT API实战教程

    引言:AI对话系统的时代机遇 在数字化转型浪潮中,聊天机器人已成为连接用户与服务的关键纽带.无论是客服系统中的7×24小时即时响应,还是智能家居中的语音交互,聊天机器人正在重塑人机交互方式.本文将通过 ...

  10. 整合阿里OSS进行文件上传

    3.整合阿里OSS进行文件上传 1).引入spring-cloud-starter-alicloud-oss包 2).在配置文件中配置Key.endpoint 3).自动注入private OSSCl ...