调度负载到CCI

更新时间：2024-10-15 GMT+08:00

查看PDF

简介

对于使用CCE集群和CCI的使用场景，用户可以按需将工作负载调度到CCE集群节点或者对接CCI的虚拟节点，本文详细介绍如何将CCE集群的工作负载调度到CCI上。

bursting插件当前提供两种方式管理CCE集群的pod，使其能够调度到CCI：

方式一：通过配置labels控制pod调度到CCI
方式二：使用profile控制pod调度到CCI

约束与限制

当前只有负载的原生标签能够被ScheduleProfile匹配，使负载能够被ScheduleProfile管理，将CCE集群的Pod调度到CCI。例如通过ExtensionProfile加到负载上的标签不能够被ScheduleProfile匹配，因此不会被ScheduleProfile管理调度功能。
当弹性到CCI的资源调度失败时，bursting节点会被锁定半小时，期间无法调度至CCI。用户可通过CCE集群控制台，使用kubectl工具查看bursting节点状态，若节点被锁定，可手动解锁bursting。

调度策略

CCE集群工作负载弹性调度到CCI策略有如下三种：

调度策略	策略图解	适用场景
强制调度策略（enforce）		CCE工作负载强制弹性到CCI。
本地优先调度策略（localPrefer）		工作负载优先调度到CCE集群，集群资源不足时工作负载弹性到CCI。
不开启（off）		工作负载不会弹性到CCI。

方式一：通过配置labels控制pod调度到CCI

通过CCE集群控制台（console）创建pod调度到CCI。通过CCE集群创建工作负载时，选择CCI弹性承载策略配置，选择“不开启”以外的任意策略。
说明：

在CCE集群控制台（console）创建工作负载时，CCI弹性承载支持勾选“bursting-node”或者“virtual-kubelet”，如果使用CCI 1.0请勾选“virtual-kubelet”，如果使用CCI 2.0请勾选“bursting-node”。目前CCI 2.0仅对白名单用户开放，如需使用CCI 2.0服务，请提交工单申请开启CCI 2.0服务。

通过yaml文件在CCE集群节点创建pod调度CCI。成功安装bursting插件后，登录CCE集群节点，在工作负载的yaml文件中添加virtual-kubelet.io/burst-to-cci标签。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  namespace: default
  labels:
    virtual-kubelet.io/burst-to-cci: 'auto'    # 弹性到CCI
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - image: 'nginx:perl'
          name: container-0
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: 250m
              memory: 512Mi
          volumeMounts: []
      imagePullSecrets:
        - name: default-secret

方式二：使用profile控制pod调度到CCI

登录集群节点，配置profile资源。
```
vi profile.yaml
```

限制CCE集群最大负载数，配置local maxNum和scaleDownPriority的profile模板示例如下：

apiVersion: scheduling.cci.io/v1
kind: ScheduleProfile
metadata:
  name: test-cci-profile
  namespace: default
spec:
  objectLabels:
    matchLabels:
      app: nginx
  strategy: localPrefer
  location:
    local: 
      maxNum: 20 # 当前暂不支持local/cci同时配置maxNum
      scaleDownPriority: 10
    cci: {}

限制CCI集群最大负载数，配置cci maxNum和scaleDownPriority的profile的模板示例如下：
```
apiVersion: scheduling.cci.io/v1
kind: ScheduleProfile
metadata:
  name: test-cci-profile
  namespace: default
spec:
  objectLabels:
    matchLabels:
      app: nginx
  strategy: localPrefer
  location:
    local: {}
    cci:
      maxNum: 20 # 当前暂不支持local/cci同时配置maxNum
      scaleDownPriority: 10
```
说明：
- strategy：调度策略选择。可配置策略值：auto、enforce、localPrefer。详情请参见调度策略。
- location内可配置线下IDC和云上pod限制数量maxNum和pod缩容优先级scaleDownPriority，maxNum取值范围[0~int32]，scaleDownPriority取值范围[-100, 100]。
- local字段和cci字段不可以同时设置maxNum。
- 缩容优先级为非必填项参数，如果不配置缩容优先级，默认值将为空。

在CCE集群中创建profile资源。
```
kubectl apply -f profile.yaml
```

创建无状态负载，使用selector方式选择含有“app：nginx”的pod，关联上文创建的profile。

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: container-1
          image: nginx:latest
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: 250m
              memory: 512Mi
      imagePullSecrets:
        - name: default-secret

表1 特殊场景使用说明
特殊使用场景	使用说明
pod同时使用label和profile控制调度CCI	使用label控制调度CCI的方式优先级高于使用profile控制调度CCI的方式。例如label中策略为off，profile的策略为enforce，最终pod不会调度到CCI。
pod同时被多个profile关联	pod有且仅有一个关联profile。当pod被多个profile关联，根据profile匹配pod的label的数量，选出最大关联profile，存在多个时，选择字典序小的profile关联。 pod最终被profileA关联