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

调度负载到CCI

简介

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

bursting插件当前提供两种方式管理CCE集群的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

  1. 登录集群节点,配置profile资源。
    vi profile.yaml
  2. 限制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: {}
  3. 限制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。
    • 缩容优先级为非必填项参数,如果不配置缩容优先级,默认值将为空。
  1. 在CCE集群中创建profile资源。
    kubectl apply -f profile.yaml
  2. 创建无状态负载,使用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关联