如何指定pod的运行节点？

实际生产系统, 会遇到 某个服务需要扩容 的场景，也可能会遇到由于 资源紧张 或者 工作负载降低 而需要 减少服务实例数量 的场景。

此时可以利用 Deployment/RC 的 Scale机制 来完成这些工作。

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

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

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

以Deployment nginx为例：

Kubernetes从11版本开始，新增了名为 Horizontal Pod Autoscaler（HPA ）的 控制器 ，用于实现 基于CPU使用率 进行 自动Pod扩缩容 的功能。

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

Kubernetes中的 某个Metrics Server （ Heapster 或 自定义Metrics Server ）持续采集 所有Pod副本的指标数据 。

HPA控制器 通过 Metrics Server 的 API （Heapster的API或聚合API）获取这些数据，基于 用户定义的扩缩容规则 进行计算，得到 目标Pod副本数量 。

当目标Pod副本数量与当前副本 数量不同 时， HPA控制器 就向 Pod的副本控制器 （ Deployment 、 RC 或 ReplicaSet ）发起 scale *** 作 ，调整Pod的副本数量，完成扩缩容 *** 作。

Master的 kube-controller-manager 服务持续监测 目标Pod 的某种性能指标，以计算是否需要调整副本数量。

目前Kubernetes支持的指标类型如下。

Kubernetes从111版本开始， 弃用！！！ 基于 Heapster组件 完成 Pod的CPU使用率 采集的机制，全面转向 基于Metrics Server 完成 数据采集 。

Metrics Server 将采集到的 Pod性能指标数据 通过 聚合API（Aggregated API ）如metricsk8sio、custommetricsk8sio和externalmetricsk8sio提供给 HPA控制器 进行查询。

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

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

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

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

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

此外，存在几种Pod异常的情况，如下所述。

在计算“当前指标值/期望的指标值”（currentMetricValue / desiredMetricValue）时将不会包括上述这些异常Pod

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

此外，如果存在未达到Ready状态的Pod，并且系统原本会在不考虑缺失指标或NotReady的Pod情况下进行扩展，则系统仍然会保守地假设这些Pod消耗期望指标值的0%，从而进一步抑制扩容 *** 作。

如果在HorizontalPodAutoscaler中设置了多个指标，系统就会对每个指标都执行上面的算法，在全部结果中以期望副本数的最大值为最终结果。如果这些指标中的任意一个都无法转换为期望的副本数（例如无法获取指标的值），系统就会跳过扩缩容 *** 作。

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

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

HorizontalPodAutoscaler资源对象处于Kubernetes的API组“ autoscaling ”中，目前包括 v1 和 v2 两个版本

其中 autoscaling/v1 仅支持 基于CPU使用率 的 自动扩缩容 ， autoscaling/v2 则用于支持基于 任意指标 的自动扩缩容配置，包括基于资源使用率、Pod指标、其他指标等类型的指标数据，当前版本为 autoscaling/v2beta2 。

下面对HorizontalPodAutoscaler的配置和用法进行说明。

（1）基于 autoscaling/v1 版本的HorizontalPodAutoscaler配置， 仅可以设置CPU使用率 ：

主要参数如下

为了使用 autoscaling/v1 版本的HorizontalPodAutoscaler，需要 预先安装Heapster组件 或 Metrics Server ，用于 采集Pod的CPU使用率 。

Heapster 从Kubernetes 111版本开始进入 弃用阶段 ，不再对Heapster进行详细说明。

（2）基于 autoscaling/v2beta2 的HorizontalPodAutoscaler配置：

主要参数如下。

可以将metrics中的 type（指标类型 ）设置为以下三种，可以设置一个或多个组合，如下所述。

（1） Resource ：基于 资源的指标值 ，可以设置的资源为 CPU 和 内存 。

（2） Pods ：基于 Pod的指标 ，系统将对全部Pod副本的指标值进行 平均值计算 。

（3） Object ：基于某种资源对象（如Ingress）的指标或应用系统的任意自定义指标。

Resource类型 的指标可以设置 CPU 和 内存 。

指标数据可以通过API“ metricsk8sio ”进行查询，要求 预先启动Metrics Server服务 。

Pods类型 和 Object类型 都属于 自定义指标类型 ，指标的数据通常需要搭建自定义Metrics Server和监控工具进行采集和处理。指标数据可以通过API“custommetricsk8sio”进行查询，要求预先启动自定义Metrics Server服务。

类型为Pods 的指标数据来源于 Pod对象本身 ，其target指标类型 只能使用AverageValue ，示例如下：

其中，设置Pod的 指标名 为 packets-per-second ，在目标指标平均值为1000时触发扩缩容 *** 作。

类型为 Object 的指标数据来源于 其他资源对象 或 任意自定义指标 ，其target指标类型可以使用 Value 或 AverageValue （根据 Pod副本数计算平均值 ）进行设置。下面对几种常见的自定义指标给出示例和说明。

例1，设置指标的名称为requests-per-second，其值来源于Ingress “main-route”，将目标值（value）设置为2000，即在Ingress的每秒请求数量达到2000个时触发扩缩容 *** 作：

例2，设置指标的名称为>