Schedule a POD to specific node

nodeSelector.config

https://access.redhat.com/solutions/2178611


### How to Force a pod to schedule to a specific node using nodeSelector in OCP

Pods get scheduled to nodes based on the node labels. NodeSelector will get set either for the cluster, project, or pod to determine which node or group of nodes the pod will be scheduled to.

The easiest way to test and ensure a pod is scheduled to a node is by setting it at the project level. This can only be done by cluster-admins or users with elevated privileges.

# oc adm project <NAME> --node-selector='foo=bar'
# oc project <NAME>
# oc new-app --template cakephp-example
To make force a single pod to schedule to a node make changes in the Deployment Configuration PodSpec. This can be set

This example shows how to schedule a pod to a specific node using node label and the nodeSelector field in a pod specification.

Step One
Login to OpenShift using the Command Line Interface with a user that has authorization to make changes to the project.

$ oc login -u system:admin
Logged into "https://openshift-cluster.example.com:8443" as "system:admin" using existing credentials.

You have access to the following projects and can switch between them with 'oc project <projectname>':

  * default
  * management-infra
  * openshift
  * openshift-infra
  * helloworld (current)

Using project "helloworld"

Step Two
Pull information on the node, the following command will show all labels attached. Make note of the label as we will use this later.

$ oc get nodes
oc get nodes
NAME                 LABELS                                                                        STATUS                     AGE
master1.example.com   kubernetes.io/hostname=master1.example.com,region=master,zone=master         Ready,SchedulingDisabled   1d
node1.example.com    kubernetes.io/hostname=node1.example.com,region=node,zone=node                Ready                      1d
node2.example.com    kubernetes.io/hostname=node2.example.com,region=node,zone=node                Ready                      1d
Labels can be added to nodes and then used to schedule a pod to a group of nodes or single node. See of documentation on how to add labels to nodes. In this example we will be using an existing label added to the node during the install that is specific to a single node.
We are going to schedule a pod to "node1.example.com" using label "kubernetes.io/hostname=node1.example.com"

Step Three
Edit either the deployment configuration, replication controller, or the pod object. It is recommended to edit the deployment configuration as this will pass the changes to all other object on next deploy.
Method 1 - oc patch command

Raw
#  oc patch dc  ruby-hello-world -p '{"spec":{"template":{"spec":{"nodeSelector":{"kubernetes.io/hostname": "node1.example.com"}}}}}'
Method 2 - manually edit object

Edit the Deployment Configuration adding "nodeselector" with the value of the label under the PodSpec

nodeSelector:                                  
  kubernetes.io/hostname: node1.example.com      
Note that the label had to be change to fit the yaml format, we change the "=" to a ":"

In this example some data has been removed to shorten the output.

$ oc edit dc ruby-hello-world

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: ruby-hello-world
spec:
  replicas: 1
  selector:
   ...
  strategy:
   ...
  template:
    ...
    spec:
      containers:
      - image: 172.30.22.186:5000/test/ruby-hello-world
        imagePullPolicy: Always
        name: ruby-hello-world
        ports:
        - containerPort: 8080
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      nodeSelector:                                    ### ADD
        kubernetes.io/hostname: node1.example.com      ### ADD
      securityContext: {}
      terminationGracePeriodSeconds: 30
  triggers:
  - type: ConfigChange
    ...
status:
  ...
  latestVersion: 1

Step Four
Make sure the pod has redeployed automatically, the example above will redeploy because it's triggers is equal to "ConfigChange"
If the pod does not redeploy run the following:

$ oc get pods -o wide

  ruby-hello-world-1-xdfs3   1/1       Running     0          1hr        node2.example.com

$ oc deploy --latest  ruby-hello-world

Step Five
After the deployer finishes the pod should be running and scheduled to "node1.example.com".

Raw
$ oc get pods -o wide

ruby-hello-world-2-d8ub8   1/1       Running     0          9m        node1.example.com