OpenShift - Run a pod on a specific node using podAffinity

If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

There are a few different ways to run a pod on a specific node.

  • Using nodeSelector (nodes are labeled with a key=value - if a pods "nodeSelector" is an exact match of a nodes key=value label, then the pod can be scheduled run on the node) 
  • Using nodeAffinity (nodes are labeled with a key=value - if a pods "nodeAffinity" regular expression matches a nodes key=value label, the pod can be scheduled to run on the node)
  • Using podAffinity (this article) (nodes are labeled with a key=value - if a pods "podAffinity" regular expression matches another pods key=value label, the pod can be scheduled to run on the same node as the other pod)
  • Using Taint and Toleration (nodes are labeled with a key=value:taint - if a pods "toleration" is an exact match of the key=value:taint, then the pod is allowed to run on the node)

The oc new-app command is used to deploy an application. There are various ways to deploy an app.

The scheduler is responsible for determining which worker node a resource should get created on. For example, when deploying a new application to OpenShift, the scheduler determines which worker node the pod should be created on, typically the worker node with the most available memory and CPU. Check out my article on the default scheduler.

With podAffinity, you will first label a pod with any key value pair that you would like. Let's say my-pod-c4v5h is labled region=east.

~]$ oc label pod my-pod-c4v5h region=east
pod/my-pod-c4v5h labeled

 

And get oc get pods --output wide command can be used to see that the node the pod in running on (worker-hsjrp in this example).

~]# oc get pods --output wide
NAME            READY   STATUS     RESTARTS  AGE  IP              NODE          NOMINATED MODE
my-pod-c4v5h    1/1     Running    0         8d   10.142.118.51   worker-hsjrp  <none>

 

Now let's say you have another pod (my-pod-zm7d6) that you want to ensure is run on the same node (worker-hsjrp). You could update the pods YAML to have the following podAffinity to have the pod run on the worker node that is labeled region=east.

With podAffinity, the scheduling of the pod on a node can either be preferred or required. Execution basically means "running pods" thus IgnoredDuringExecution means that nodeAffinity will have no impact on currently running pods. On the other hand, with Taint and Toleration, NoExecute can be used to terminate running pods.

  • preferredDuringSchedulingIgnoredDuringExecution
  • requiredDuringSchedulingIgnoredDuringExecution

The following operators can be used with matchExpression.

  • In (worker node label contains one of the listed key:value pairs)
  • NotIn (worker node label does not contain one of the listed key:value pairs)
  • Exists (worker node label is an exact made of the key, not the value)
  • DoesNotExist (worker node label is not an exact made of the key)
  • Lt (worker node label is less than)
  • Gt (worker node label is greater than)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-pod-zm7d6
spec:
  affinity:
    podAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution: 
        matchExpressions:
        - key: region 
          operator: In 
          values:
          - east

 

 




Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee

Add a Comment




We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.





Please enter 07246 in the box below so that we can be sure you are a human.




Comments

Web design by yours truely - me, myself, and I   |   jeremy.canfield@freekb.net   |