01 引言
声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记
在实际生产系统中，我们经常会遇到某个服务需要扩容的场景，也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。此时可以利用Deployment/RC的Scale机制来完成这些工作。
Kubernetes对Pod的扩缩容操作提供了手动和自动两种模式。
02 手动扩缩容机制
手动模式通过运行
kubectl scale命令或通过RESTful API对一个Deployment/RC进行Pod副本数量的设置，即可一键完成。
以部署nginx为例子，使用命令查看当前部署 nginx pod的数量，正在运行的副本数为3：
通过kubectl scale命令可以将Pod副本数量从初始的3个更新为5个：
将-replicas的值设置为比当前Pod副本数量更小的数字，系统将会“杀掉”一些运行中的Pod，以实现应用集群缩容：
03 自动扩缩容机制
自动模式则需要用户根据某个性能指标或者自定义业务指标，并指定Pod副本数量的范围，系统将自动在这个范围内根据性能指标的变化进行调整。
3.1 HPA控制器
Kubernetes从1.l版本开始，新增了名为Horizontal Pod Autoscaler（HPA） 的控制器，用于实现 基于CPU使用率进行自动Pod扩缩容的功能。
如下图所示，HPA控制器基于Master的kube-controller-manager服务启动参数--horizontal-pod-autoscaler-- symc-period定义的探测周期（默认值为15s)，周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整。
Metrics Server持续采集所有Pod副本的指标数据，HPA 控制器通过Metrics Server的API获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod的副本数量。
当目标Pod副本数量与当前副本数量不同时， HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）发起scale操作，调整Pod的副本数量，完成扩缩容操作。
3.2 指标的类型
Master的kube-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 ) ] • 1
即：当前副本数×（当前指标值/期望的指标值），将结果向上取整。
以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）设置为指标的平均值类型，例如targetAveragevalue或targetAverageUtilization，此时当前指标值 (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架构如图所示：
关键组件包括如下：
| 组件 | 描述 |
| 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扩缩容的一些概念以及案例，希望能帮助到大家，谢谢大家的阅读，本文完！
