作者：京东科技徐宪章

1 什么是超容量扩容

超容量扩容功能，是指预先调度一定数量的工作节点，当业务高峰期或者集群整体负载较高时，可以使应用不必等待集群工作节点扩容，从而迅速完成应用横向扩容。通常情况下HPA、ClusterAutosacler和超容量扩容同时使用以满足负载敏感度高的业务场景。

超容量扩容功能是通过K8S应用优先级设置和ClusterAutosaler共同作用实现的，通过调整低优先级空载应用的数量，使集群已调度资源保持在较高的状态，当其他高优先级应用因为HPA或者手动调整应用分片数量时，可以通过驱逐空载的方式腾空调度资源却保高优先级应用可以在第一时间调度并创建。当空载应用从被驱逐转变为等到状态时，ClusterAutosaler此时对集群机型扩容，确保下次高优先级应用调度时，有足够的空载应用可以被驱逐。

超容量扩容功能的核心为OverprovisionAutoscaler（超容量扩容）和ClusterAutosaler(集群自动扩容)，两者都需要通过不断调整参数配置去适配多重业务需求需求。

超容量扩容功能在一定程度上降低了资源使用饱和度，通过增加成本提高了集群和应用的稳定性，实际业务场景中需要根据需求进行取舍并合理配置。

2 什么情况下需要使用超容量扩容

当集群值开启Hpa和Autoscaler时，在发生节点扩容的情况下，应用调度时间通常为4-12分钟，主要取决于创建工作节点资源以及工作节点从加入集群到Ready的总耗时。以下为最佳和最差效率分析

最佳案例场景－４分钟

• 30秒 - 目标指标值更新：30-60秒

• 30秒 - HPA检查指标值：30秒 - >30秒 - HPA检查指标值：30秒 - >

• <2秒 - Pods创建之后进入pending状态<2秒－Pods创建之后进入pending状态

• <2秒 - CA看到pending状态的pods，之后调用来创建node 1秒<2秒－CA看到pending状态的pods，之后调用来创建node 1秒

• 3分钟 - cloud provider创建工作节点，之后加入k8s之后等待node变成ready

最糟糕的情况 - 12分钟

• 60 秒 —目标指标值更新

• 30 秒 — HPA检查指标值

• < 2 秒 — Pods创建之后进入pending状态

• < 2 秒 —CA看到pending状态的pods，之后调用来创建node 1秒

• 10 分钟 — cloud provider创建工作节点，之后加入ｋ8s之后等待node变成ready

两种场景下，创建工作节点耗时占比超过75%，如果可以降低或者完全不考虑该时间，将大大提高应用扩容速度，配合超容量扩容功能可以大大增强集群和业务稳定性。超容量扩容主要用于对应用负载敏感度较高的业务场景

大促备战
流计算/实时计算
Devops系统
其他调度频繁的业务场景

3 如何开启超容量扩容

超容量扩容功能以ClusterAutoscaler为基础，配合OverprovisionAutoscaler实现。以京东公有云Kubernetes容器服务为例

3.1 开启ClusterAutoscaler

https://cns-console.jdcloud.com/host/nodeGroups/list

• 进入 “kubernetes容器服务”->“工作节点组”

• 选择需要对应节点组，点击开启自动伸缩

• 设置节点数量区间，并点击确定

3.2 部署OverprovisionAutoscaler

1 部署控制器及配置

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: overprovisioning-autoscaler
5  namespace: default
6  labels:
7    app: overprovisioning-autoscaler
8    owner: cluster-autoscaler-overprovisioning
9spec:
10  selector:
11    matchLabels:
12      app: overprovisioning-autoscaler
13      owner: cluster-autoscaler-overprovisioning
14  replicas: 1
15  template:
16    metadata:
17      labels:
18        app: overprovisioning-autoscaler
19        owner: cluster-autoscaler-overprovisioning
20    spec:
21      serviceAccountName: cluster-proportional-autoscaler
22      containers:
23        - image: jdcloud-cn-north-1.jcr.service.jdcloud.com/k8s/cluster-proportional-autoscaler:v1.16.3
24          name: proportional-autoscaler
25          command:
26            - /autoscaler
27            - --namespace=default
28            ## 注意这里需要根据需要指定上述的configmap的名称 
29            ## /overprovisioning-autoscaler-ladder/overprovisioning-autoscaler-linear
30            - --configmap=overprovisioning-autoscaler-{provision-mode}
31            ## 预热集群应用（类型）/ 名称,基准应用和空值应用需要在同一个命名空间下
32            - --target=deployment/overprovisioning
33            - --logtostderr=true
34            - --v=2
35          imagePullPolicy: IfNotPresent
36          volumeMounts:
37            - name: host-time
38              mountPath: /etc/localtime
39      volumes:
40        - name: host-time
41          hostPath:
42            path: /etc/localtime
43---
44kind: ServiceAccount
45apiVersion: v1
46metadata:
47  name: cluster-proportional-autoscaler
48  namespace: default
49---
50kind: ClusterRole
51apiVersion: rbac.authorization.k8s.io/v1
52metadata:
53  name: cluster-proportional-autoscaler
54rules:
55  - apiGroups: [""]
56    resources: ["nodes"]
57    verbs: ["list", "watch"]
58  - apiGroups: [""]
59    resources: ["replicationcontrollers/scale"]
60    verbs: ["get", "update"]
61  - apiGroups: ["extensions","apps"]
62    resources: ["deployments/scale", "replicasets/scale","deployments","replicasets"]
63    verbs: ["get", "update"]
64  - apiGroups: [""]
65    resources: ["configmaps"]
66    verbs: ["get", "create"]
67---
68kind: ClusterRoleBinding
69apiVersion: rbac.authorization.k8s.io/v1
70metadata:
71  name: cluster-proportional-autoscaler
72subjects:
73  - kind: ServiceAccount
74    name: cluster-proportional-autoscaler
75    namespace: default
76roleRef:
77  kind: ClusterRole
78  name: cluster-proportional-autoscaler
79  apiGroup: rbac.authorization.k8s.io
80---
81apiVersion: scheduling.k8s.io/v1
82kind: PriorityClass
83metadata:
84  name: overprovisioning
85value: -1
86globalDefault: false
87description: "Priority class used by overprovisioning."
88
89
90

2 部署空载应用

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: overprovisioning
5  namespace: default
6  labels:
7    app: overprovisioning
8    owner: cluster-autoscaler-overprovisioning
9spec:
10  replicas: 1
11  selector:
12    matchLabels:
13      app: overprovisioning
14      owner: cluster-autoscaler-overprovisioning
15  template:
16    metadata:
17      annotations:
18        autoscaler.jke.jdcloud.com/overprovisioning: "reserve-pod"
19      labels:
20        app: overprovisioning
21        owner: cluster-autoscaler-overprovisioning
22    spec:
23      priorityClassName: overprovisioning
24      containers:
25        - name: reserve-resources
26          image: jdcloud-cn-east-2.jcr.service.jdcloud.com/k8s/pause-amd64:3.1
27          resources:
28            requests:
29              ## 根据预热预期设置配置的分片数量及单分片所需资源
30              cpu: 7
31          imagePullPolicy: IfNotPresent
32
33
34

3.3 验证超容量扩容功能是否正常

1 验证Autoscaler

• 查看autoscaler控制器是否Running

• 不断创建测试应用，应用需求资源略微小于节点组单节点可调度资源

• 观察集群节点状态，当资源不足导致pod 等待中状态时，autocalser是否会按照预设(扩容等待、扩容冷却、最大节点数量等)进行扩容

• 开启集群自动缩容，删除测试应用，观察集群节点资源Request到达阈值后是否发生缩容。

2 验证OverprovisionAutoscaler

• 查看OverprovisionAutoscaler控制器是否Running

• 不断创建测试应用，当发生autoscaler后，空载应用数量是否会根据配置发生变化

• 当业务应用pendding后，空载应用是否会发生驱逐，并调度业务应用

4 设置OverprovisionAutoscaler及ClusterAutoscaler参数

4.1 配置ClusterAutoscaler

1 ca参数说明

2 推荐配置

1# 其他保持默认
2scan_interval=10s
3max_node_provision_time=180s
4scale_down_delay_after_add=180s
5scale_down_delay_after_delete=180s
6scale_down_unneeded_time=300s
7scale_down_utilization_threshold=0.4
8
9
10

4.2 配置OverprovisionAutoscaler

OverprovisionAutoscaler的配置有线性配置和阶梯配置两种方式，两种配置方式只能选择一种.

1 线性配置（ladder）

线性配置，通过配置总体CPU核数以及节点数量和空载应用数量的比例实现线性资源预留，空载应用数量总是和CPU总量以及节点数量成正比，精度会根据空载应用CPU资源request变化，request值越小，精度月高，当配置发生冲突时，取符合线性关系的空载应用数量最大值.

节点数量满足配置中min和max的区间

preventSinglePointFailure，当为true时，Running状态的空载应用分片数满足线性关系；当为false时，Failer/Running状态的空载应用分片数满足线性关系

includeUnschedulableNodes，是否考虑不可调度节点

1kind: ConfigMap
2apiVersion: v1
3metadata:
4  name: overprovisioning-autoscaler-linear
5  namespace: default
6data:
7  linear: |-
8    {
9      "coresPerReplica": 2,
10      "nodesPerReplica": 1,
11      "min": 1,
12      "max": 100,
13      "includeUnschedulableNodes": false,
14      "preventSinglePointFailure": true
15    }
16
17
18

2 阶梯配置(linear)

阶梯配置，通过配置总体CPU核数或者节点数量和空载应用数量的矩阵实现阶梯状资源预留，空载应用数量符合CPU总量以及节点数量的分布状态，当配置发生冲突时，取符合区间分布的空载应用数量最大值

1kind: ConfigMap
2apiVersion: v1
3metadata:
4  name: overprovisioning-autoscaler-ladder
5  namespace: default
6data:
7  ladder: |-
8    {
9      "coresToReplicas":
10      [
11        [ 1,1 ],
12        [ 50,3 ],
13        [ 200,5 ],
14        [ 500,7 ]
15      ],
16      "nodesToReplicas":
17      [
18        [ 1,1 ],
19        [ 3,4 ],
20        [ 10,5 ],
21        [ 50,20 ],
22        [ 100,120 ],
23        [ 150,120 ]
24      ]
25    }
26
27
28

Kubernetes集群调度增强之超容量扩容