Scheduling Pods to CCI

Overview

This section describes how you can schedule workloads to CCI when needed.

There are two methods to manage pods in a CCE cluster so that the workloads can be scheduled to CCI.

• Method 1: Using a Label
• Method 2: Specifying a Profile

Constraints

• Only when native labels of a workload are matched by ScheduleProfile, you can use ScheduleProfile to manage the workload and schedule the workload to CCI. For example, the labels added to a workload through ExtensionProfile cannot be matched by ScheduleProfile. For this reason, the workload cannot be scheduled by ScheduleProfile.
• If resources fail to be scheduled to CCI, the bursting node will be locked and cannot be scheduled to CCI for half an hour. You can use kubectl to check the status of the bursting node on the CCE cluster console. If the node is locked, you can manually unlock it.

Scheduling Policies

Method 1: Using a Label

• Create the workload to be scheduled to CCI on the CCE cluster console. When creating the workload, select any policy for Workloads except Disable scheduling.
  

  When creating a workload on the CCE console, you can select either bursting-node or virtual-kubelet. If you use CCI 1.0, select virtual-kubelet. If you use CCI 2.0, select bursting-node. Currently, CCI 2.0 is available only to whitelisted users. To use the service, submit a service ticket.

• Editing the YAML file on a CCE cluster node to schedule the workloads to CCI. Install the bursting add-on. Log in to the CCE cluster node and add the virtual-kubelet.io/burst-to-cci label in the YAML file of the workload.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: test
    namespace: default
    labels:
      virtual-kubelet.io/burst-to-cci: 'auto'    # Schedules the workload to 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

Method 2: Specifying a Profile

1. Log in to a CCE cluster node to create a profile using the YAML file.

   vi profile.yaml

2. Configure maxNum and scaleDownPriority for local to limit the maximum number of pods in a CCE cluster. The following is an example:

   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 # maxNum can be configured either for local or cci.
         scaleDownPriority: 10
       cci: {}

3. Configure maxNum and scaleDownPriority for cci to limit the maximum number of pods in CCI. The following is an example:

   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 # maxNum can be configured either for local or cci.
         scaleDownPriority: 10

   

   • strategy: scheduling policy The value can be auto, enforce, or localPrefer. For details, see Scheduling Policies.
   • location: There are maxNum and scaleDownPriority. maxNum indicates the maximum number of pods on the on-premises infrastructure or cloud and its value ranges from 0 to 32. scaleDownPriority indicates the pod scale-in priority and its value ranges from -100 to 100.
   • maxNum can be configured either for local or cci.
   • Scale-in priority is optional. If it is not specified, the default value is set to nil.