容器服务 Kubernetes 版 ACK：多可用区同时快速弹性扩容

解决方案

为了解决同时扩容多可用区节点的问题，容器服务ACK引入了ack-autoscaling-placeholder组件，通过少量的资源冗余方式，将多可用区的弹性伸缩问题转变为并发节点池的定向伸缩问题。具体操作，请参见基于ack-autoscaling-placeholder实现容器秒级伸缩。

以下图两个可用区为例，介绍利用现有架构上能满足多可用区同时扩容的方法。

1. 利用ack-autoscaling-placeholder作为业务应用和节点自动伸缩组件之间的桥梁，为每个可用区创建占位Pod，占位Pod的调度优先级需要低于实际业务应用的调度优先级。

2. 应用Pod Pending后会迅速抢占占位Pod，并部署在各个可用区的已有节点上，同时被抢占的占位Pod会处于Pending状态。

3. 由于占位Pod是带有可用区nodeSelector调度策略的，节点自动伸缩组件就可以并发扩容到对应的可用区。

步骤一：为可用区创建节点池并配置自定义节点标签

1. 登录容器服务管理控制台，在左侧导航栏选择集群。

2. 在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择节点管理 > 节点池。

3. 在节点池页面右上角，单击创建节点池。

4. 在创建节点池页面，设置创建节点池的配置项。本文以在可用区I创建开启自动伸缩的节点池auto-zone-I为例。

   以下为重要配置项说明。其余配置项说明，请参见创建节点池。

   配置项	说明
   节点池名称	auto-zone-I
   虚拟交换机	选择可用区I的虚拟交换机。
   自动伸缩	开启自动弹性伸缩。
   节点标签	设置节点标签的键为avaliable_zone，值为i。

5. 单击确认配置。

   在节点池页面，查看节点池列表。当auto-zone-I节点池状态为已激活，表示该节点池创建成功。

6. 重复以上步骤，在每个需要扩容的可用区创建开启自动伸缩的节点池。

   

步骤二：部署Placeholder及占位Deployment

1. 在控制台左侧导航栏，选择市场 > 应用市场。

2. 在应用目录页签，搜索ack-autoscaling-placeholder，然后单击ack-autoscaling-placeholder。

3. 在ack-autoscaling-placeholder页面，单击一键部署。

4. 在创建面板，选择集群和命名空间，然后单击下一步。选择Chart版本，编辑参数，然后单击确定。

   创建成功后，在应用 > Helm页面，可查看到该应用状态为已部署。

5. 在集群管理页左侧导航栏，选择应用 > Helm。

6. 在Helm页面，单击ack-autoscaling-placeholder-defalut操作列的更新。

7. 在更新发布面板中，更新YAML，然后单击确定。将每个可用区都设置Placeholder，每个区域需要定义一个占位Deployment。

   本文以在可用区I、K、H创建占位Deployment为例，YAML示例如下：

   deployments:
   - affinity: {}
     annotations: {}
     containers:
     - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
       imagePullPolicy: IfNotPresent
       name: placeholder
       resources:
         requests:
           cpu: 3500m     # 调度单元CPU。
           memory: 6      # 调度单元内存。
     imagePullSecrets: {}
     labels: {}
     name: ack-place-holder-I             # 占位Deployment名称。
     nodeSelector: {"avaliable_zone":i}   # 可用区标签（需要与步骤一创建节点池中配置的标签一致）。
     replicaCount: 10                     # 每次扩容可快速弹出Pod数量。
     tolerations: []
   - affinity: {}
     annotations: {}
     containers:
     - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
       imagePullPolicy: IfNotPresent
       name: placeholder
       resources:
         requests:
           cpu: 3500m    # 调度单元CPU。
           memory: 6     # 调度单元内存。
     imagePullSecrets: {}
     labels: {}
     name: ack-place-holder-K            # 占位Deployment名称。
     nodeSelector: {"avaliable_zone":k}  # 可用区标签（需要与步骤一创建节点池中配置的标签一致）。
     replicaCount: 10                    # 每次扩容可快速弹出Pod数量。
     tolerations: []
   - affinity: {}
     annotations: {}
     containers:
     - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
       imagePullPolicy: IfNotPresent
       name: placeholder
       resources:
         requests:
           cpu: 3500m   # 调度单元CPU。
           memory: 6    # 调度单元内存。
     imagePullSecrets: {}
     labels: {}
     name: ack-place-holder-H           # 占位Deployment名称。
     nodeSelector: {"avaliable_zone":h} # 可用区标签（需要与步骤一创建节点池中配置的标签一致）。
     replicaCount: 10                   # 每次扩容可快速弹出Pod数量。
     tolerations: []
   fullnameOverride: ""
   nameOverride: ""
   podSecurityContext: {}
   priorityClassDefault:
     enabled: true
     name: default-priority-class
     value: -1

   更新成功后，在各个可用区可以查看到占位Deployment已创建。

步骤三：创建实际负载的PriorityClass

1. 使用以下YAML示例，创建名为priorityClass.yaml的文件。

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: high-priority
   value: 1000000              # 配置优先级,比步骤二的工作负载默认优先级高。
   globalDefault: false
   description: "This priority class should be used for XYZ service pods only."

   如果不希望在负载上配置PriorityClass，可以通过设置全局PriorityClass的方式进行全局默认设置，这样只需要下发默认配置后，抢占能力便自动生效。

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: global-high-priority
   value: 1                              # 配置优先级,比步骤二的工作负载默认优先级高。
   globalDefault: true
   description: "This priority class should be used for XYZ service pods only."

2. 执行以下命令，部署工作负载的PriorityClass。

   kubectl apply -f priorityClass.yaml

   预期输出：

   priorityclass.scheduling.k8s.io/high-priority created

步骤四：创建实际工作负载

以可用区I为例。

1. 使用以下YAML示例，创建名为workload.yaml的文件。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: placeholder-test
     labels:
       app: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:                        # 节点选择。
           avaliable_zone: "i"
         priorityClassName: high-priority     # 这里写入步骤三配置的PriorityClass名称，如果全局配置开启，则为非必填。
         containers:
         - name: nginx
           image: nginx:1.7.9
           ports:
           - containerPort: 80
           resources:
             requests:
               cpu: 3                         # 实际负载的资源需求。
               memory: 5

2. 执行以下命令，部署实际的工作负载。

   kubectl apply -f workload.yaml

   预期输出：

   deployment.apps/placeholder-test created

   结果验证

   部署后在工作负载 > 容器组页面可以发现，由于实际负载的PriorityClass比占位Pod的要高，在弹出节点上，抢占的占位Pod会运行起来。而被抢占的占位Pod会触发节点自动伸缩组件的并发扩容，为下次实际负载扩容做准备。

   在节点管理 > 节点页面，可以看到负载Pod运行在之前占位Pod的节点上。