极致成本优化背景下，如何通过优化k8s调度器实现计算资源的按需付费（四）

之四：GKE节点自动扩缩容实验

实验目的

验证gce的自动缩容时机以及扩容需要的时长：扩容一个节点需要等待多长时间，一个节点在没有Pod的情况下多久后会回收。结合scheduler-plugins框架验证。由于scheduler-plugins只是在Score阶段对节点打分，并未在其它阶段阻止Pod调度到分数为0的Node上，例如基于目标负载感知调度，当所有Node的负载都达到目标负载后，即便节点的requests满足Pod所需，是否能走扩容节点，而不是硬塞到现有节点上。

实施步骤

集群配置：

三个2c4g固定节点，每个节点可用cpu为：940m，内存为：2806.0Mi。
弹性节点配置：最小0个，最大3个，规格2c4g，每个节点可用cpu为：940m，内存为：2806.0Mi。

一、验证扩容

demo配置requests让每个pod只能部署到一个节点上。

requests:
   cpu: 600m
   memory: 1000Mi

先3个副本把固定节点占满。扩容节点耗时：

	扩展第1个节点	扩展第2个节点	扩展第3个节点	扩展第3个节点
耗时（秒）	58	57	74	达到上限，无法扩
平均耗时（秒）	63秒（1分钟）

二、验证缩容

每缩容1个副本，观察节点多久后回收。

	缩容第1个节点	缩容第2个节点	缩容第3个节点
延迟	10分40秒	10分50秒	10分50秒
平均延迟	10分50秒（因为是用计时器算的，秒数部分不精准）

在1分钟左右，会给节点添加第一个污点：DeletionCandidateOfClusterAutoscaler。
在10分钟左右，会给节点添加第二个污点：ToBeDeletedByClusterAutoscaler。
在第二个污点添加的一分钟后，会给节点添加第三个污点，然后过个几秒就删除了。

缩容一个节点的时间几乎是固定的，大概11分钟。根据官方文档的描述：https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-does-scale-down-work，这个应该是可以在Node资源配置的。

cluster-autoscaler缩容时间配置

另外有一个坑，缩容如果Pod不是在弹性节点上的，弹性节点就无法被回收，而固定节点又会空置。可能需要考虑怎么控制Demployment控制器在缩容的时候优先缩弹性节点上的Pod。

三、requests未超，目标负载已超，是否能扩

demo配置requests。

requests:
   cpu: 100m
   memory: 100Mi

初始副本数15，Pod调度到三个固定节点的分布如下：

	节点1（ncck）	节点2（71zk）	节点3（r408）
Pod数	6	7	2

集群真实负载情况：

wujiuye@wujiuyedeMacBook-Pro cloud_native % kubectl top node
NAME                                                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
gke-nebula-test-cluster-default-pool-521b9803-71zk   78m          8%     1024Mi          36%       
gke-nebula-test-cluster-default-pool-521b9803-ncck   55m          5%     1066Mi          37%       
gke-nebula-test-cluster-default-pool-521b9803-r408   66m          7%     1338Mi          47%

每个节点抽取一个demo Pod，把节点的总负载调超30%。

wujiuye@wujiuyedeMacBook-Pro cloud_native % kubectl top node
NAME                                                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
gke-nebula-test-cluster-default-pool-521b9803-71zk   377m         40%    1027Mi          36%       
gke-nebula-test-cluster-default-pool-521b9803-ncck   355m         37%    1064Mi          37%       
gke-nebula-test-cluster-default-pool-521b9803-r408   366m         38%    1350Mi          48%

增加副本数，看新的Pod是否触发扩容。

结果：否，未触发节点扩容。节点得分虽然很低，但没有插件阻止调度。

原因是，只有Pod的状态为Pending才会走节点自动扩缩容。

Pod一开始也是Pending状态，什么条件下才会触发Node扩容？

根据文档的描述，Pod只有处理Pending状态，并且处理Pending状态的原因是Unschedulable，那么才会触发节点扩容，例如：

status:
  phase: Pending
  conditions:
    - type: PodScheduled
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2024-01-25T06:47:58Z'
      reason: Unschedulable
      message: >-
        0/3 nodes are available: 3 Insufficient cpu. preemption: 0/3 nodes are
        available: 3 No preemption victims found for incoming pod..
  qosClass: Burstable

结论

单节点扩容耗时1分钟左右。
单节点缩容延迟11分钟左右。
需要考虑怎么控制Demployment控制器在缩容的时候优先缩弹性节点上的Pod，使弹性的节点能够被回收。
节点自动扩缩容结合scheduler-plugins插件使用目标负载感知调度插件并不会触发节点扩容，需要增强scheduler-plugins适配自动扩缩容的场景。