Schedule an application pod to a specific node pool

Procedure

1. Add node labels to the node pool.

   1. Log on to the ACK console. In the left-side navigation pane, click Clusters.

   2. On the Clusters page, find the cluster that you want to manage and click its name. In the left-side navigation pane, choose Nodes > Node Pools.

   3. On the Node Pool page, click Create Node Pool.

   4. On the create node pool configuration page, click Show Advanced Options, then click Node Tags on the right side of to set node tags.

      In this example, the node label added is pod: nginx.

      You can click Edit on the right of the target node pool to update or add labels to the nodes.

2. Set a scheduling policy for the application.

   After the preceding step is completed, the pod: nginx label is added to the nodes in the node pool. You can use nodeSelector or nodeAffinity to ensure that your application runs only on the specified node pool. The procedure is as follows.

   • Set nodeSelector for the application.

     nodeSelector is a field in spec. You only need to fill the above pod: nginx label into nodeSelector. The example is as follows.

     apiVersion: apps/v1 
     kind: Deployment
     metadata:
       name: nginx-deployment-basic
       labels:
         app: nginx
     spec:
       replicas: 2
       selector:
         matchLabels:
           app: nginx
       template:
         metadata:
           labels:
             app: nginx
         spec:
           nodeSelector:
             pod: nginx      # Add the label from the node pool to ensure that your application can only run on the nodes in the node pool.
           containers:
           - name: nginx
             image: nginx:1.7.9
             ports:
             - containerPort: 80

   • Set nodeAffinity for the application.

     nodeAffinity includes the following scheduling policies:

     • - requiredDuringSchedulingIgnoredDuringExecution

       If this policy is used, a pod must be deployed to a node that meets the match rules. If no node meets the match rules, the scheduling operation will keep retrying. IgnoreDuringExecution indicates that after the pod is deployed, if the node label changes and no longer meets the conditions specified by the pod, the pod will continue to run.

     • - preferredDuringSchedulingIgnoredDuringExecution

       This policy indicates that the pod is preferably deployed to a node that meets the match rules. If no node meets the match rules, the conditions are ignored, and the pod is deployed according to the normal logic.

     This example uses the requiredDuringSchedulingIgnoredDuringExecution policy to ensure that the application always runs on the specified node pool.

     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: nginx-with-affinity
       labels:
         app: nginx-with-affinity
     spec:
       replicas: 2
       selector:
         matchLabels:
           app: nginx-with-affinity
       template:
         metadata:
           labels:
             app: nginx-with-affinity
         spec:
           affinity:
             nodeAffinity:
               requiredDuringSchedulingIgnoredDuringExecution:
                 nodeSelectorTerms:
                 - matchExpressions:
                   - key: pod         # The key of the node label. In this example, it is pod.
                     operator: In      # The application will run on nodes labeled with pod: nginx.
                     values:
                     - nginx        # The value of the node label. In this example, it is nginx.
           containers:
           - name: nginx-with-affinity
             image: nginx:1.7.9
             ports:
             - containerPort: 80

References

• For more information about nodeSelector and nodeAffinity, see Assigning Pods to Nodes.

• ResourcePolicy supports specifying the order in which applications are scheduled to different types of node resources to achieve sequential scale-out and reverse scale-in. For more information, see Custom Elastic Resource Priority Scheduling.

• In older clusters created before the node pool feature was released, there may be free worker nodes not managed by node pools. You can migrate free nodes to node pools.