k8s教程(pod篇)-扩缩容

这篇具有很好参考价值的文章主要介绍了k8s教程(pod篇)-扩缩容。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

01 引言

声明:本文为《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第5版)》的读书笔记

在实际生产系统中,我们经常会遇到某个服务需要扩容的场景,也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。此时可以利用Deployment/RCScale机制来完成这些工作

Kubernetes对Pod的扩缩容操作提供了手动和自动两种模式。

02 手动扩缩容机制

手动模式通过运行kubectl scale命令或通过RESTful API对一个Deployment/RC进行Pod副本数量的设置,即可一键完成

以部署nginx为例子,使用命令查看当前部署 nginx pod的数量,正在运行的副本数为3:
k8s教程(pod篇)-扩缩容
通过kubectl scale命令可以将Pod副本数量从初始的3个更新为5个:
k8s教程(pod篇)-扩缩容
-replicas的值设置为比当前Pod副本数量更小的数字,系统将会“杀掉”一些运行中的Pod,以实现应用集群缩容:
k8s教程(pod篇)-扩缩容

03 自动扩缩容机制

自动模式则需要用户根据某个性能指标或者自定义业务指标,并指定Pod副本数量的范围,系统将自动在这个范围内根据性能指标的变化进行调整

3.1 HPA控制器

Kubernetes从1.l版本开始,新增了名为Horizontal Pod Autoscaler(HPA) 的控制器,用于实现 基于CPU使用率进行自动Pod扩缩容的功能

如下图所示,HPA控制器基于Masterkube-controller-manager服务启动参数--horizontal-pod-autoscaler-- symc-period定义的探测周期(默认值为15s),周期性地监测目标Pod的资源性能指标,并与HPA资源对象中的扩缩容条件进行对比,在满足条件时对Pod副本数量进行调整

k8s教程(pod篇)-扩缩容
Metrics Server持续采集所有Pod副本的指标数据,HPA 控制器通过Metrics Server的API获取这些数据,基于用户定义的扩缩容规则进行计算,得到目标Pod的副本数量

当目标Pod副本数量与当前副本数量不同时, HPA控制器就向Pod的副本控制器(DeploymentRCReplicaSet)发起scale操作,调整Pod的副本数量,完成扩缩容操作。

3.2 指标的类型

Masterkube-controller-manager服务持续监测目标Pod的某种性能指标, 以计算是否需要调整副本数量,目前Kubernetes支持的指标类型如下:

指标 描述
Pod资源使用率 Pod级别的性能指标,通常是一个比率值,例如CPU使用率
Pod自定义指标 Pod级别的性能指标,通常是一个数值,例如接收的请求数量
Object自定义指标或外部自定义指标 通常是一个数值,需要容器应用以某种方式提供,例如通过HTTP URL “/metrics” 提供,或者使用外部服务提供的指标采集URL

3.3 扩缩容算法

Autoscaler控制器从聚合API获取到Pod性能指标数据之后,基于下面的算法计算出目标Pod副本数量,与当前运行的Pod副本数量进行对比,决定是否需要进行扩缩容操作:

desiredReplicas = ceil [currentReplicas * (currentMetricValue/desiredMetricValue ) ]

即:当前副本数×(当前指标值/期望的指标值),将结果向上取整

以CPU请求数量为例,如果用户设置的期望指标值为100m,当前实际使用的指标值为200m,则计算得到期望的Pod副本数量应为两个(200/100=2)。如果当前实际使用的指标值为50m,计算结果为0.5,则向上取整,值为1,得到目标Pod副本数量应为1个。

也可以设置容忍度和期望指标值来控制

  • 当计算结果与1非常接近时,可以设置一个容忍度让系统不做扩缩容操作。容忍度通过kube-controller--manager,服务的启动参数--horizontal-pod-autoscaler- tolerance进行设置,默认值为0.1(即10%),表示基于上述算法得到的结果在 [-10%,+10%]区间内,即[0.9,1.1]区间,控制器都不会进行扩缩容操作
  • 也可以将期望指标值(desiredMetricValue)设置为指标的平均值类型,例如targetAveragevaluetargetAverageUtilization,此时当前指标值 (currentMetricValue)的算法为所有Pod副本当前指标值的总和除以Pod副本数量得到的平均值

3.4 HorizontalPodAutoscaler配置详解

Kubernetes将 HorizontalPodAutoscaler资源对象 提供给用户来定义扩缩容的规则,HorizontalPodAutoscaler资源对象处于Kubernetes的API组“autoscaling” 中,下面对HorizontalPodAutoscaler的配置和用法进行说明。

3.4.1 基于autoscaling/v1版本的配置

配置如下:

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler
metadata:
	name: php-apache
spec:
	scaleTargetRef:
		apiversion: apps/v1
		kind: Deployment
		name: php-apache
	minReplicas: 1
	maxReplicas: 10
	targetCPUUtilizationPercentage: 50

参数解析:

参数 解析
scaleTargetRef 目标作用对象,可以是Deployment、ReplicationController或ReplicaSet…
targetCPUUtilizationPercentage 期望每个Pod的CPU使用率都为50%,该使用率基于Pod设置的CPU Request值进行计算,例如该值为200m,那么系统将维持Pod的实际CPU使用值为100m
minReplicas和maxReplicas Pod副本数量的最小值和最大值,系统将在这个范围内进行自动扩缩容操作,并维持每个Pod的CPU使用率为50%

为了使用autoscaling/v1版本的HorizontalPodAutoscaler,需要预先安装Metrics Server,用于采集Pod的CPU使用率

3.4.2 基于autoscaling/v2beta2版本的配置

配置如下:

apiVersion: autoscaling/v2beta2 
kind: HorizontalPodAutoscaler
metadata: 
	name: php-apache
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

参数解析:

参数 解析
scaleTargetRef 目标作用对象,可以是Deployment、ReplicationController或ReplicaSet…
minReplicas和maxReplicas Pod副本数量的最小值和最大值,系统将在这个范围内进行自动扩缩容操作,并维持每个Pod的CPU使用率为50%
metrics 目标指标值,在metrics中通过参数type定义指标的类型;通过参数target定义相应的指标目标值,系统将在指标数据达到目标值时(考虑容忍度 的区间,见前面算法部分的说明)触发扩缩容操作

可以将 metrics中的type(指标类型)设置为以下四种:

指标类型 描述
Resource 指的是当前伸缩对象下Pod的CPU和Memory指标,只支持Utilization和Averagevalue类型的目标值。对于CPU使用率,在target参数中设置 averageUtilization定义目标平均CPU使用率。对于内存资源,在target参数中设置Averagevalue定义目标平均内存使用值
Pods 指的是伸缩对象Pod的指标,数据需要由第三方的Adapter提供, 只允许Averagevalue类型的目标值
Object Kubernetes内部对象的指标,数据需要由第三方Adapter提供, 只支持Value和Averagevalue类型的目标值
External 指的是Kubernetes外部的指标,数据同样需要由第三方Adapter提供,只支持Value和Averagevalues类型的目标值

3.4.3 举例

3.4.3.1 Metrics示例 - Pod类型

下面是一个类型为Pods的Metrics示例:

metrics:
- type: Pods
  pods
	  metric:
	  	name: packets-per-second
	  target:
		type: Averagevalue
		averagevalue: 1k

含义:设置Pod的指标名为packets-per-second,在目标指标平均值为1000时
触发扩缩容操作。

3.4.3.2 Metrics示例 - Object类型

例1:设置指标的名称为requests–per-second,其值来源于Ingress “main- route’”,将目标值(value)设置为2000,即在Ingress的每秒请求数量达到2000个时触发扩缩容操作:

metrics:
- type: Object
  object:
  	metric:
  		name: requests-per-second 
  	describedobject:
  		apiVersion:	extensions/vlbeta1 
  		kind: Ingress
  		name: main-route
  	target:
  		type: Value
  		value: 2k

例2:设置指标的名称为http_requests, 并且该资源对象具有标签 verb=GET,在指标平均值达到500时触发扩缩容操作:

metrics:
- type: Object
  object:
	  metric:
		  name: 'http requests' 
		  selector: 'verb=GET'
	  target:
		  type: Averagevalue
		  averagevalue: 500

3.5 基于自定义指标的HPA实践

基于自定义指标进行自动扩缩容时,需要预先部署自定义Metrics Server,目前可以使用基于Prometheus、Microsoft Azure、Datadog Cluster等系统的Adapter实现自定义Metrics Server,未来还将提供基于Google Stackdriver的实现自定义Metrics Server。

以下是基于Prometheus的HPA架构如图所示:
k8s教程(pod篇)-扩缩容

关键组件包括如下:

组件 描述
Prometheus 定期采集各Pod的性能指标数据
Custom Metrics Server 自定义Metrics Server,用Prometheus Adapter进行具体实现。它从Prometheus服务采集性能指标数据,通过Kubernetes的Metrics Aggregation层将自定义指标API注册到Master的API Server中, 以/apis/custom.metrics.k8s.io路径提供指标数据。
HPA Controller Kubernetes的HPA控制器,基于用户定义的HorizontalPodAutoscaler进行自动扩缩容操作

由于篇幅原因,本文不再详述整个实现的过程!有兴趣的童鞋可以参考教程:https://imroc.cc/k8s/best-practice/custom-metrics-hpa/

04 文末

本文主要讲解pod扩缩容的一些概念以及案例,希望能帮助到大家,谢谢大家的阅读,本文完!文章来源地址https://www.toymoban.com/news/detail-480457.html

到了这里,关于k8s教程(pod篇)-扩缩容的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 持续集成部署-k8s-资源调度:HPA - Pod 基于负载指标自动水平扩容缩容

    首先我们找一个 Deployment 配置文件: nginx-deploy.yaml

    2024年02月07日
    浏览(54)
  • Kubernetes中Pod的扩缩容介绍

    在实际生产系统中,我们经常会遇到某个服务需要扩容的场景,也可能会遇到由于资源紧张或者工作负载降低而需 要减少服务实例数量的场景。此时可以利用 Deployment/RC 的 Scale 机制来完成这些工作。 Kubernetes 对 Pod 的扩缩容操作提供了手动和自动两种模式,手动模式通过执行

    2024年02月07日
    浏览(49)
  • 18. Pod 自动管理——HPA 自动扩缩容机制

    前言 HPA 自动扩缩容机制 前面我们学习了 Deployment、 StatefulSet、DeamonSet、Job,明白了 Kubernetes 为了帮助我们更好的管理 Pod,提供了一系列好用的工具。但是还远远不止于此,以上工具还需要我们手动设置 replicas 副本数量。 我们来想象一种场景,我们服务已经正常上线了,运

    2024年02月03日
    浏览(41)
  • k8s教程(pod篇)-定时任务

    声明:本文为《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第5版)》的读书笔记 Kubernetes 从1.5版本开始增加了一种新类型的 Job ,即类似 Linux Cron 的定时任务 Cron Job ,下面看看如何定义和使用这种类型的 Job 。 首先,确保 Kubernetes 的版本为 1.8 及以上。 Cron Job的定时表

    2023年04月20日
    浏览(37)
  • k8s教程(pod篇)-配置管理

    应用部署的一个最佳实践是将应用所需的配置信息与程序分类,就像是微服务Nacos配置中心一样。 因此,kubernetes从1.2版本开始就提供了一种统一的应用配置管理方案,也就是本文要讲的ConfigMap 。 ConfigMap以一个或多个 key:value 的形式保存在 Kubenetes 系统中供应用使用 ,它既可

    2024年02月04日
    浏览(500)
  • k8s基础4——deployment控制器、应用部署、升级、回滚、水平扩容缩容

    基本了解: Deployment是最常用的K8s工作负载控制器(Workload Controllers),实际项目部署调试中必用资源之一,所以必须要熟练掌握deploy资源的使用。 它是K8s的一个抽象概念,用于更高级层次对象,部署和管理Pod。 其他控制器还有DaemonSet、StatefulSet等,不同控制器针对不同的需

    2024年02月03日
    浏览(56)
  • 云原生 黑马Kubernetes教程(K8S教程)笔记——第一章 kubernetes介绍——Master集群控制节点、Node工作负载节点、Pod控制单元

    参考文章:kubernetes介绍 本章节主要介绍应用程序在服务器上部署方式演变以及kubernetes的概念、组件和工作原理。 在部署应用程序的方式上,主要经历了三个时代: 传统部署:互联网早期,会直接将应用程序部署在物理机上 优点:简单,不需要其它技术的参与 缺点:不能为

    2024年02月04日
    浏览(57)
  • k8s、pod

    k8s中的port【端口:30000-32767】 port :为Service 在 cluster IP 上暴露的端口 targetPort:对应容器映射在 pod 端口上 nodePort:可以通过k8s 集群外部使用 node IP + node port 访问Service containerPort:容器内部使用的端口 k8s 集群内部流程: 客户端→clusterIP:port→通过 tagerport→pod IP:container

    2024年02月06日
    浏览(35)
  • k8s关于pod

      目录 1、POD 的创建流程 kubectl 发起创建 Pod 请求: API Server 接收请求并处理: 写入 Etcd 数据库: Kubelet 监听并创建 Pod: Pod 状态更新和汇报: 2、POD 的状态解析 1. Pending Pod 2. Running Pod 3. Succeeded Pod 4. Failed Pod 5. Unknown 6. CrashLoopBackOff 7. ImagePullBackOff Pod 8. Terminating 9. Evicted 10.

    2024年03月18日
    浏览(50)
  • K8s Pod详解

    每个Pod中都可以包含一个或者多个容器,这些容器可以分为两类: 用户程序所在的容器,数量可多可少 Pause容器,这是每个Pod都会有的一个 根容器 ,它的作用有两个: 可以以它为依据,评估整个Pod的健康状态 可以在根容器上设置Ip地址,其它容器都此Ip(Pod IP),以实现

    2024年02月01日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包