kubernetes-水平Pod自动伸缩
在当前的版本中,Pod水平自动伸缩支持基于CPU使用情况对Pod进行自动伸缩。Pod水平自动伸缩通过Kubernetes API资源和控制器进行实现。控制器会根据CPU的使用情况周期性的调整Pod的副本数量。
1、水平Pod自动伸缩是如何工作的?
水平Pod自动伸缩被实现为控制周期循环,其周期由控制器管理器的–horizontal-pod-autoscaler-sync-period标志进行控制(默认值为30秒)。在每个周期间,控制器管理器会根据每个HorizontalPodAutoscaler定义中指定的度量标准查询资源利用率。控制器管理器从资源指标的API(针对每个窗格的资源指标)或自定义指标的API(针对所有其他指标)获取度量。
- 对于每个Pod资源指标(如CPU),控制器为HorizontalPodAutoscaler的目标Pod从资源指标API中获取指标。如果设置了目标利用率的值,则控制器将在会计算使用率,作为每个Pod中容器的等效资源请求的百分比。如果设置了目标原始值,则直接使用原始指标标准值。然后,控制器在所有目标Pod中获取利用率的平均值或原始值(取决于指定的目标类型),并产生用于缩放所需副本数量的比率。
需要注意的,如果某些Pod的容器没有设置相关的资源请求,则不会定义Pod的CPU利用率,并且autoscaler不会对该指标标准采取任何操作。
- 对于每个Pod自定义的指标,与每个pod资源指标的工作机理类似;不同之处在于它使用初始值,而不是使用率值。
- 对于对象指标和外部指标,将获取单个指标,该指标将描述相关对象。该指标将与目标值进行比较,以产生如上所述的比率。在
autoscaling/v2beta2
API版本中,可以选择在进行比较之前将该值除以pod的数量。
HorizontalPodAutoscaler通常从一系列的API聚集中获取指标(metrics.k8s.io, custom.metrics.k8s.io和external.metrics.k8s.io)。该metrics.k8s.io API通常由指标服务器提供,其需要单独启动。自动缩放器使用伸缩子资源访问相应的可伸缩控制器(例如复制控制器,部署和副本集)。Scale是一个接口,允许您动态设置副本数并检查每个当前状态。
2、算法
从最基本的角度来看,HorizontalPodAutoscaler控制器根据所需指标与当前指标之间的比率进行操作:
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
例如,如果当前的指标值为200m,而期望的指标值为100m,则Pod的副本数量将会翻倍,即200/100=2;如果当前的指标值为50m,则会将Pod的副本数减半。如果比率足够接近1.0(在全局可配置的容差范围内,从–horizontal-pod-autoscaler-tolerance标志,默认为0.1),将会忽略缩放。当指定targetAverageValue或targetAverageUtilization时,currentMetricValue会通过所有Pod(HorizontalPodAutoscaler伸缩目标)获取给定指标的平均值来计算。当基于CPU进行伸缩时,如果任意Pod还未准备就绪,则此Pod放弃。currentMetricValue / desiredMetricValue伸缩比率基于保留的Pod进行计算,而不是放弃的Pod进行计算。如果在HorizontalPodAutoscaler中指定了多个指标,则会计算每一个指标,并选择期望副本数最大的指标。
3、在kubectl中使用水平Pod自动伸缩
与所有API资源一样,kubectl以标准方式支持水平Pod自动伸缩。可以使用kubectl create命令创建一个新的自动缩放器。通过kubectl get hpa可以列出自动伸缩器,通过kubectl describe hpa能够获得自动伸缩器的详细说明。最后,可以使用kubectl delete hpa删除自动缩放器。此外,还有一个特殊kubectl autoscale命令可以轻松创建HorizontalPodAutoscaler。
1)创建autoscale
$ kubectl autoscale deployment netdisk --min=2 --max=5 --cpu-percent=80
为部署netdisk创建一个自动伸缩器,目标CPU利用率设置为80%,副本数量介于2和5之间。
2)获取autoscale
获取default命名空间下的hpa
$ kubectl get hpa
3)查看autoscale
查看netdisk hpa的详细信息。
$ kubectl describe hpa netdisk
4)删除autoscale
$ kubectl delete hpa netdisk
4、kubectl autoscale命令
kubectl autoscale命令的使用方法
$ autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]
字段说明
名称 | Shorthand | 默认值 | 使用说明 |
---|---|---|---|
allow-missing-template-keys | true | 如果值为真,则忽略模板中的任何错误。仅仅能够应用到golang和jsonpath输出格式。 | |
cpu-percent | -1 | The target average CPU utilization (represented as a percent of requested CPU) over all the pods. If it’s not specified or negative, a default autoscaling policy will be used. | |
dry-run | false | If true, only print the object that would be sent, without sending it. | |
filename | f | [] | Filename, directory, or URL to files identifying the resource to autoscale. |
generator | horizontalpodautoscaler/v1 | The name of the API generator to use. Currently there is only 1 generator. | |
max | -1 | The upper limit for the number of pods that can be set by the autoscaler. Required. | |
min | -1 | The lower limit for the number of pods that can be set by the autoscaler. If it’s not specified or negative, the server will apply a default value. | |
name | The name for the newly created object. If not specified, the name of the input resource will be used. | ||
output | o | Output format. One of: json|yaml|name|template|go-template|go-template-file|templatefile|jsonpath|jsonpath-file. | |
record | false | Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists. | |
recursive | R | false | Process the directory used in -f, –filename recursively. Useful when you want to manage related manifests organized within the same directory. |
save-config | false | If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. | |
template | Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview]. |
参考材料
1.《Horizontal Pod Autoscaler》地址:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
本文转自中文社区-kubernetes-水平Pod自动伸缩
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
初试 Kubernetes 集群中使用 Contour 反向代理
在 Kubernetes 中运行大规模以 Web 为中心的工作负载,最关键的需求之一就是在 L7 层实现高效流畅的入口流量管理。自从第一批 Kubernetes Ingress Controller 开发完成以来,Envoy(由 Matt Klein 和 Lyft 团队开发)已经成为云原生生态系统中的新生力量。Envoy 之所以受到支持,因为它是一个 CNCF 托管的项目,与整个容器圈和云原生架构有着天然的支持。 容器公司 Heptio 开源的项目 Contour 使用 Envoy 作为 Kubernetes 的 Ingress Controller 实现,为大家提供了一条新的 Kubernetes 外部负载均衡实现思路。 据官方博客介绍,Heptio Contour 可以为用户提供以下好处: 一种简单的安装机制来快速部署和集成 Envoy。 与 Kubernetes 对象模型的集成。 Ingress 配置的动态更新,而无需重启底层负载均衡器。 项目成熟后,将允许使用 Envoy 一些强大的功能,如熔断器、插件式的处理器链,以及可观测性和可调试性。 下面我们就来试用一下。 1. 安装步...
- 下一篇
GCP为Kubernetes引擎提供支持原生容器的负载均衡器
GCP现在为运作于Google Kubernetes Engine(GKE)的应用程序,以及安装在Compute Engine上的Kubernetes,提供原生容器负载均衡。 用户现在能使用网络端点组(Network Endpoint Groups,NEGs),以任意网络端点编写负载均衡器作为IP端口对,并且对容器直接进行负载均衡。通过这个GCP上新的数据模型抽象层,企业可以获得精确Pods的原生运作状况,甚至是负载均衡到Pods之间 。 最初负载均衡器是为支持虚拟机的资源分配而设计,但是这样的设计对于容器来说,并不能达到最佳效能,像是GKE这样的容器协调器( Container Orchestrator),没有一组为Pods定义的后端方法,所以负载均衡器会以实例分组作为后端。 像是GKE中的Ingress支持就以实例分组,使用HTTP/HTTPS负载均衡器对集群中的节点进行负载均衡,这些节点遵循IPTable的规则,将请求路由到Pods中,但由于虚拟机等级的负载均衡器,无法将Pods或是容器视为后端,导致负载不平衡,而且在节点之间还会发生次优路径大量数据流量跳跃的情况发生。 GCP为...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启