 Hello, my name is Andrew Sullivan and I am with the Red Hat Cloud Platforms Business Unit. Today we're going to be discussing OpenShift 4 resource management, specifically affinity, anti-affinity, taints, and tolerations with pods and nodes. For this demo we're going to create a series of pods. Each of these pods will have a different set of labels. In addition to that the pods will have a series of selectors to help with the scheduling process. First when we review our nodes, we can see that they have a label attached to them. This label is used by some of the pods to help with scheduling processes. Seen here, the first and third nodes have a gluten free equals false node label. The middle one has a gluten free equals true label. The first pod that we'll look at has a number of labels associated with it. We're using an example of sandwiches here. We see meat type, cheese type, other condiments, as well as down below a node selector of gluten free equals true. Additionally notice that there are several tolerations here. No taints have been associated with the nodes yet, but this will become important later. When we create this pod the scheduler will look at all of the constraints and make a decision on where to schedule it. Because this has a node selector specifically for gluten free equals true, we are scheduled to node 2. Looking at the second pod we see an additional number of labels here. An anti-affinity rule has been defined for this pod. The rule expresses that the pod should not be scheduled to a location which already has a pod with a meat type label defined. Regardless of the value associated with the label. The topology key on line 18 indicates that this anti-affinity rule is applied at the host level and line 13 indicates that it is a mandatory rule. After creating the object, OpenShift schedules the pod against the cluster. We see here that it has been scheduled against node 3. The third pod that we'll look at in this example has a reduced number of labels, however we see a number of rules affecting the scheduling. In particular we see that there is a preferred pod affinity rule. This means that OpenShift will evaluate each one of the rules assigning a weight value to nodes that match. The nodes that have the highest weight at the end of scheduling are the ones where the pod is executed at. A required pod anti-affinity rule also exists. The pod will not be executed on a node which has another pod matching the nut type of peanut or almond defined. As a result of the preferred affinity rule for a pod with a cheese type label which has been defined, the scheduler chose node 3 which is hosting the turkey and cheese sandwich pod over node 1. We will now add a taint to one of the nodes. This taint will define a value of bread type equals wheat with an effect of no execute. The result of the effect is that any pods without a toleration will be terminated on the tainted node. A no schedule effect would allow an existing pod to persist but no new pods without a matching toleration will be allowed. After adding the taint if we review the pods we can see that the pod running on node 2 which did not have the toleration defined has been terminated. If we recreate the pod it is scheduled again against the cluster. Due to the taint the pod cannot execute on node 2 and due to the anti-affinity rule which is required the pod will not execute on node 3. Therefore it is scheduled to node 1. Thank you for joining me today. Please be sure to watch for more videos about OpenShift 4 functionality in the future.