Optional: Configuring dedicated OpenShift worker nodes for Watson Query
You can provision Watson Query on dedicated Red Hat® OpenShift® worker nodes.
About this task
Do this advanced configuration only when it is necessary. Constraining Watson Query to a specific set of nodes can complicate activities, including upgrades and maintenance at the OpenShift level. In general, it is recommended that you allow Watson Query to be scheduled across all available Watson Query worker nodes.
Procedure
To run Watson Query instance pods on specific OpenShift worker nodes where the nodes also can run pods from other services
- Log in to Red Hat OpenShift Container Platform as an instance
administrator:
oc login ${OCP_URL}
- Retrieve the name of the worker node that you want to dedicate to Watson
Query:
oc get nodes
- Choose one of the following options to label the nodes. If you are running Db2U with elevated privileges, the
podantiaffinity
rules are disabled in the Watson Query engine pods and the head and worker pods can be scheduled on the same nodes.-
- Label the nodes with the
podantiaffinity
rule enabled: - Label at least two nodes because the head pod and worker pod cannot be added to same nodes due
to the default
podantiaffinity
rules that are in place on the head and worker nodes.
- Label the nodes with the
-
- Label the node with the
podantiaffinity
rule disabled: - If you want to schedule all Watson
Query pods to one node, the
podantiaffinity
rules must be disabled to allow the scheduling of head and worker pods on the same node.
- Label the node with the
-
-
Change to the project where the Cloud Pak for Data control plane is installed:
This command uses an environment variable so that you can run the command exactly as written. For information about sourcing environment variables, see Setting up installation environment variables.oc project ${PROJECT_CPD_INST_OPERANDS}
- Add the
nodeAffinity
field to the pod specification so that the pods are assigned to nodes that have the labelicp4data=dv
. Edit the Db2® Big SQL CR to add the details from the example spec section:oc edit bigsql db2u-dv
spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: icp4data operator: In values: - dv
- Wait for the Watson
Query pods to restart. If the pods do not restart, run the following
command to restart them:
oc delete po 'dv-podname'
- Run the following command to confirm that the pods are created on the right
nodes:
oc describe pod 'dv-podname' | grep -i Node
Note: When you add
nodeaffinity
to schedule pods to specific nodes, the pods might
not be able to find a node if the node does not meet the Watson
Query instance provisioning
requirements for clusters and resources (CPU or memory).To run Watson Query instance pods on specific OpenShift worker nodes that are dedicated only to Watson Query
Pods from other services cannot run on the nodes.
- Log in to Red Hat OpenShift Container Platform as an instance
administrator:
oc login ${OCP_URL}
- Retrieve the name of the worker node that you want to dedicate to Watson
Query:
oc get nodes
- Label and taint the nodes. Tainted nodes try to repel pods that do not tolerate the taints on
the node. As a result, the nodes try to place only Watson
Query pods in the nodes. Pods that
exist in the nodes do not get evicted. Newly created pods that do not tolerate the taints do not get
scheduled to the node.
Choose one of the following options. If you are running Db2U with elevated privileges, the
podantiaffinity
rules are disabled in the Watson Query engine pods and head and worker pods can be scheduled on the same nodes.-
- Label and taint the nodes with the
podantiaffinity
rule enabled: - Label and taint at least two nodes because the head pod and worker pod cannot be added to same
nodes due to the default
podantiaffinity
rules that are in place on the head and worker nodes.oc label node 'node1-name' icp4data=dv oc label node 'node2-name' icp4data=dv oc adm taint node 'node1-name' icp4data=dv:PreferNoSchedule oc adm taint node 'node2-name' icp4data=dv:PreferNoSchedule
- Label and taint the nodes with the
-
- Label and taint the nodes with the
podantiaffinity
rule disabled: - If you want to schedule all Watson
Query pods to one node, the
podantiaffinity
rules must be disabled to allow the scheduling of head and worker pods on the same node.
- Label and taint the nodes with the
-
-
Change to the project where the Cloud Pak for Data control plane is installed:
This command uses an environment variable so that you can run the command exactly as written. For information about sourcing environment variables, see Setting up installation environment variables.oc project ${PROJECT_CPD_INST_OPERANDS}
- Add
tolerations
to the pod spec in the Db2 Big SQL CR:oc edit bigsql db2u-dv
spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: icp4data operator: In values: - dv tolerations: - key: "icp4data" operator: "Equal" value: "dv" effect: "PreferNoSchedule"
- Wait for the Watson
Query pods to restart. If the pods do not restart, run the following
command to restart them:
oc delete po 'dv-podname'
- Run the following command to confirm that the pods are created on the right
nodes:
oc describe pod 'dv-podname' | grep -i Node
Note: When you add
tolerations
to schedule pods to specific nodes, the pods might
not be able to find a node if the node does not meet the Watson
Query instance provisioning
requirements for clusters and resources (CPU or memory).