基于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来提供, 支持内存网络cpu等指标

#(2)实验目标: 创建一个pod,然后创建一个hpa监控pod的cpu使用率, 再对实施压测, 查看hpa是否根据pod的使用率伸缩pod副本

1)创建pod

kubectl run hpa-test --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 -o yaml --dry-run
kubectl run hpa-test --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 

2)创建hpa 超过cpu使用50% 最少创建一个pod, 最多创建10个pod

kubectl autoscale deployment hpa-test --cpu-percent=50 --min=1 --max=10 -o yaml --dry-run
kubectl autoscale deployment hpa-test --cpu-percent=50 --min=1 --max=10 

3)启动一个程序进行压力测试

kubectl run -i --tty load-generator --image=busybox /bin/sh
#while true; do wget -q -O- http://hpa-test.default.svc.cluster.local; done
![](https://s1.51cto.com/images/blog/201903/07/290af885aede8e6d6cbb647a6d30a25a.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)

4)过一段时间查看 cpu超高, 自动扩展pod

5)停止压力测试,过一段时间自动减少 貌似我等了很久

#(3)扩展:同时针对cpu和内存设置, api版本: autoscaling/v2beta2

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
    creationTimestamp: null
    name: hpa-test
spec:
    maxReplicas: 10
    minReplicas: 1
    scaleTargetRef:
        apiVersion: extensions/v1beta1
        kind: Deployment
        name: hpa-test
    metrics:
    - type: Resource
        resource:
            name: cpu
            targetAverageUtilization: 50

    - type: Resource
        resource:
            name: memory
            targetAverageValue: 50Mi

原文地址:https://blog.51cto.com/1000682/2359784

时间: 2024-11-11 01:03:15

基于metric server的自动伸缩hpa的相关文章

kubernetes 1.9.3自动伸缩HPA HorizontalPodAutoscaler配置

排错 1: Warning FailedGetResourceMetric 12s (x41 over 20m) horizontal-pod-autoscaler unable to get metrics for resource cpu: unable to fetch metrics from API: the server could not find the requested resource (get pods.metrics.k8s.io) 解决:kube-controller

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集群水平扩展——HPA(自动伸缩)

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

在微服务领域Spring Boot自动伸缩如何实现

自动伸缩是每个人都想要的,尤其是在微服务领域.让我们看看如何在基于Spring Boot的应用程序中实现. 我们决定使用 Kubernetes . Pivotal Cloud Foundry 或 HashiCorp's Nomad 等工具的一个更重要的原因是为了让系统可以自动伸缩.当然,这些工具也提供了许多其他有用的功能,在这里,我们只是用它们来实现系统的自动伸缩.乍一看,这似乎很困难,但是,如果我们使用 Spring Boot 来构建应用程序,并使用 Jenkins 来实现 CI ,那么就用不

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资源和控制器

基于Windows Server 2012 R2部署KMS服务器

基于Windows Server 2012 R2部署KMS服务器 关于Microsoft Windows / Microsoft Office "VLK" 和"MAK"两种激活的异同 "VLK"和"MAK"都是微软为"大客户"量身特定的激活方式.只要实施激活,就是永久激活."VLK"是Volume Licensing Key的缩写.微软对于"VLK"密钥施行"

基于Windows Server 2008 R2架设站点到站点的×××连接

通过×××实现总部与分公司网络的互联. 实验环境:我是用两台电脑的VMware模拟的实验环境,将两台电脑的VMnet8网段利用×××实现互联.一台电脑模拟公司总部,另一台电脑模拟分公司.总公司架设一台基于Windows Server 2008 R2的×××服务器,配置两块网卡,一块网卡设为桥接模式,处于外网网段172.16.0.0/24,IP地址为172.16.0.7/24.另一块网卡设为NAT模式,处于内网网段192.168.80.0/24,IP地址为192.168.80.100/24.分公司

[html]三列居中自动伸缩的结构

html三列居中自动伸缩的结构 <div style="width:100%;height:80px;border:1px solid #DDD;margin-bottom:10px;">Header</div> <div> <div style="width:200px;height:300px;border:1px solid #DDD;float:left;">Left</div> <div s

基于Windows Server 2012 R2部署SQL 2012的AlwaysOn群集

SQL Server2012中新增的AlwaysOn简介 SQL Server2012中新增的AlwaysOn是一个新增高可用性解决方案.在AlwaysOn之前,SQL Server已经有的高可用性和数据恢复方案,比如数据库镜像,日志传送和故障转移集群.都有其自身的局限性.而AlwaysOn作为微软新退出的解决方案,提取了数据库镜像和故障转移集群的优点.本文旨在通过实现一个AlwaysOn的实例来展现AlwaysOn. Windows2012群集要求作为群集运行的所有节点都必须采用投票算法确定该