023.掌握Pod-Pod扩容和缩容

一 pod的扩容和缩容

kubernetes对pod的扩缩容操作提供了手动和自动两种模式，手动模式通过执行kubectl scale命令或通过restful api对一个deployment/rc进行pod副本数量的设置。自动模式则需要用户根据某个性能指标或者自定义业务指标，并指定pod副本数量的范围，系统将自动在这个范围内根据性能指标的变化进行调整。

1.1 手动缩容和扩容

  1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml
  2 apiversion: apps/v1beta1
  3 kind: deployment
  4 metadata:
  5   name: nginx-deployment
  6 spec:
  7   replicas: 3
  8   template:
  9     metadata:
 10       labels:
 11         app: nginx
 12     spec:
 13       containers:
 14       - name: nginx
 15         image: nginx:1.7.9
 16         ports:
 17         - containerport: 80

  1 [root@uk8s-m-01 study]# kubectl create -f nginx-deployment.yaml
  2 [root@uk8s-m-01 study]# kubectl scale deployment nginx-deployment --replicas=5	#扩容至5个
  3 [root@uk8s-m-01 study]# kubectl get pods	                                	#查看扩容后的pod

  1 [root@uk8s-m-01 study]# kubectl scale deployment nginx-deployment --replicas=2	#缩容至2个
  2 [root@uk8s-m-01 study]# kubectl get pods

1.2 自动扩容机制

kubernetes使用horizontal pod autoscaler（hpa）的控制器实现基于cpu使用率进行自动pod扩缩容的功能。hpa控制器基于master的kube-controller-manager服务启动参数--horizontal-pod-autoscaler-sync-period定义的探测周期（默认值为15s），周期性地监测目标pod的资源性能指标，并与hpa资源对象中的扩缩容条件进行对比，在满足条件时对pod副本数量进行调整。

• hpa原理

kubernetes中的某个metrics server（heapster或自定义metricsserver）持续采集所有pod副本的指标数据。hpa控制器通过metrics server的api（heapster的api或聚合api）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标pod副本数量。

当目标pod副本数量与当前副本数量不同时，hpa控制器就向pod的副本控制器（deployment、rc或replicaset）发起scale操作，调整pod的副本数量，完成扩缩容操作。

• hpa指标类型

master的kube-controller-manager服务持续监测目标pod的某种性能指标，以计算是否需要调整副本数量。目前kubernetes支持的指标类型如下：

pod资源使用率：pod级别的性能指标，通常是一个比率值，例如cpu使用率。

pod自定义指标：pod级别的性能指标，通常是一个数值，例如接收的请求数量。

object自定义指标或外部自定义指标：通常是一个数值，需要容器应用以某种方式提供，例如通过http url“/metrics”提供，或者使用外部服务提供的指标采集url。

metrics server将采集到的pod性能指标数据通过聚合api（aggregated api） 如metrics.k8s.io、 custom.metrics.k8s.io和external.metrics.k8s.io提供给hpa控制器进行查询。

• 扩缩容算法

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

desiredreplicas = ceil[currentreplicas * ( currentmetricvalue / desiredmetricvalue )]

即当前副本数 x（当前指标值/期望的指标值），将结果向上取整。

释义：以cpu请求数量为例，如果用户设置的期望指标值为100m，当前实际使用的指标值为200m，则计算得到期望的pod副本数量应为两个（200/100=2）。如果设置的期望指标值为50m，计算结果为0.5，则向上取整值为1， 得到目标pod副本数量应为1个。

注意：当计算结果与1非常接近时，可以设置一个容忍度让系统不做扩缩容操作。容忍度通过kube-controller-manager服务的启动参数--horizontalpod-autoscaler-tolerance进行设置，默认值为0.1（即10%），表示基于上述算法得到的结果在[-10%-+10%]区间内，即[0.9-1.1]，控制器都不会进行扩缩容操作。

也可以将期望指标值（desiredmetricvalue）设置为指标的平均值类型，例如targetaveragevalue或targetaverageutilization，此时当前指标值（currentmetricvalue） 的算法为所有pod副本当前指标值的总和除以pod副本数量得到的平均值。

此外，存在几种pod异常的如下情况：

• pod正在被删除（设置了删除时间戳）：将不会计入目标pod副本数量。
• pod的当前指标值无法获得：本次探测不会将这个pod纳入目标pod副本数量，后续的探测会被重新纳入计算范围。
• 如果指标类型是cpu使用率，则对于正在启动但是还未达到ready状态的pod，也暂时不会纳入目标副本数量范围。

提示：可以通过kubecontroller-manager服务的启动参数--horizontal-pod-autoscaler-initialreadiness-delay设置首次探测pod是否ready的延时时间，默认值为30s。

另一个启动参数--horizontal-pod-autoscaler-cpuinitialization-period设置首次采集pod的cpu使用率的延时时间。

当存在缺失指标的pod时，系统将更保守地重新计算平均值。系统会假设这些pod在需要缩容（scale down） 时消耗了期望指标值的100%，在需要扩容（scale up）时消耗了期望指标值的0%，这样可以抑制潜在的扩缩容操作。

此外，如果存在未达到ready状态的pod，并且系统原本会在不考虑缺失指标或notready的pod情况下进行扩展，则系统仍然会保守地假设这些pod消耗期望指标值的0%，从而进一步抑制扩容操作。如果在horizontalpodautoscaler中设置了多个指标，系统就会对每个指标都执行上面的算法，在全部结果中以期望副本数的最大值为最终结果。如果这些指标中的任意一个都无法转换为期望的副本数（例如无法获取指标的值），系统就会跳过扩缩容操作。

最后， 在hpa控制器执行扩缩容操作之前，系统会记录扩缩容建议信息（scale recommendation）。控制器会在操作时间窗口（时间范围可以配置）中考虑所有的建议信息，并从中选择得分最高的建议。这个值可通过kube-controller-manager服务的启动参数--horizontal-podautoscaler-downscale-stabilization-window进行配置，默认值为5min。这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响。

1.3 horizontalpodautoscaler

kubernetes将horizontalpodautoscaler资源对象提供给用户来定义扩缩容的规则。

horizontalpodautoscaler资源对象处于kubernetes的api组“autoscaling”中， 目前包括v1和v2两个版本。 其中autoscaling/v1仅支持基于cpu使用率的自动扩缩容， autoscaling/v2则用于支持基于任意指标的自动扩缩容配置， 包括基于资源使用率、 pod指标、 其他指标等类型的指标数据。

示例1：基于autoscaling/v1版本的horizontalpodautoscaler配置，仅可以设置cpu使用率。

  1 [root@uk8s-m-01 study]# vi php-apache-autoscaling-v1.yaml
  2 apiversion: autoscaling/v1
  3 kind: horizontalpodautoscaler
  4 metadata:
  5   name: php-apache
  6 spec:
  7   scaletargetref:
  8     apiversion: apps/v1
  9     kind: deployment
 10     name: php-apache
 11   minreplicas: 1
 12   maxreplicas: 10
 13   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，需要预先安装heapster组件或metrics server，用于采集pod的cpu使用率。

示例2：基于autoscaling/v2beta2的horizontalpodautoscaler配置。

  1 [root@uk8s-m-01 study]# vi php-apache-autoscaling-v2.yaml
  2 apiversion: autoscaling/v2beta2
  3 kind: horizontalpodautoscaler
  4 metadata:
  5   name: php-apache
  6 spec:
  7   scaletargetref:
  8     apiversion: apps/v1
  9     kind: deployment
 10     name: php-apache
 11   minreplicas: 1
 12   maxreplicas: 10
 13   metrics:
 14   - type: resource
 15     resource:
 16       name: cpu
 17       target:
 18         type: utilization
 19         averageutilization: 50

释义：

scaletargetref：目标作用对象，可以是deployment、replicationcontroller或replicaset。

minreplicas和maxreplicas：pod副本数量的最小值和最大值，系统将在这个范围内进行自动扩缩容操作， 并维持每个pod的cpu使用率为50%。

metrics：目标指标值。在metrics中通过参数type定义指标的类型；通过参数target定义相应的指标目标值，系统将在指标数据达到目标值时（考虑容忍度的区间）触发扩缩容操作。

• metrics中的type（指标类型）设置为以下几种：

• resource：基于资源的指标值，可以设置的资源为cpu和内存。
• pods：基于pod的指标，系统将对全部pod副本的指标值进行平均值计算。
• object：基于某种资源对象（如ingress）的指标或应用系统的任意自定义指标。

resource类型的指标可以设置cpu和内存。对于cpu使用率，在target参数中设置averageutilization定义目标平均cpu使用率。对于内存资源，在target参数中设置averagevalue定义目标平均内存使用值。指标数据可以通过api“metrics.k8s.io”进行查询，要求预先启动metrics server服务。

pods类型和object类型都属于自定义指标类型，指标的数据通常需要搭建自定义metrics server和监控工具进行采集和处理。指标数据可以通过api“custom.metrics.k8s.io”进行查询，要求预先启动自定义metrics server服务。

类型为pods的指标数据来源于pod对象本身， 其target指标类型只能使用averagevalue，示例：

  1  metrics:
  2   - type: pods
  3     pods:
  4       metrics:
  5         name: packets-per-second
  6       target:
  7         type: averagevalue
  8         averagevalue: 1k