Chapter 5. Working with nodes

Procedure

1. Mark the nodes unschedulable before performing the pod evacuation.

   1. Mark the node as unschedulable:

      $ oc adm cordon <node1>

      Copy to Clipboard Toggle word wrap

      Example output

      node/<node1> cordoned

      Copy to Clipboard Toggle word wrap

   2. Check that the node status is Ready,SchedulingDisabled:

      $ oc get node <node1>

      Copy to Clipboard Toggle word wrap

      Example output

      NAME        STATUS                     ROLES     AGE       VERSION
      <node1>     Ready,SchedulingDisabled   worker    1d        v1.24.0

      Copy to Clipboard Toggle word wrap

2. Evacuate the pods using one of the following methods:

   • Evacuate all or selected pods on one or more nodes:

     $ oc adm drain <node1> <node2> [--pod-selector=<pod_selector>]

     Copy to Clipboard Toggle word wrap

   • Force the deletion of bare pods using the --force option. When set to true, deletion continues even if there are pods not managed by a replication controller, replica set, job, daemon set, or stateful set:

     $ oc adm drain <node1> <node2> --force=true

     Copy to Clipboard Toggle word wrap

   • Set a period of time in seconds for each pod to terminate gracefully, use --grace-period. If negative, the default value specified in the pod will be used:

     $ oc adm drain <node1> <node2> --grace-period=-1

     Copy to Clipboard Toggle word wrap

   • Ignore pods managed by daemon sets using the --ignore-daemonsets flag set to true:

     $ oc adm drain <node1> <node2> --ignore-daemonsets=true

     Copy to Clipboard Toggle word wrap

   • Set the length of time to wait before giving up using the --timeout flag. A value of 0 sets an infinite length of time:

     $ oc adm drain <node1> <node2> --timeout=5s

     Copy to Clipboard Toggle word wrap

   • Delete pods even if there are pods using emptyDir volumes by setting the --delete-emptydir-data flag to true. Local data is deleted when the node is drained:

     $ oc adm drain <node1> <node2> --delete-emptydir-data=true

     Copy to Clipboard Toggle word wrap

   • List objects that will be migrated without actually performing the evacuation, using the --dry-run option set to true:

     $ oc adm drain <node1> <node2>  --dry-run=true

     Copy to Clipboard Toggle word wrap

     Instead of specifying specific node names (for example, <node1> <node2>), you can use the --selector=<node_selector> option to evacuate pods on selected nodes.

3. Mark the node as schedulable when done.

   $ oc adm uncordon <node1>

   Copy to Clipboard Toggle word wrap

Procedure

1. Obtain the label associated with the static CRD, Machine Config Pool, for the type of node you want to configure. Perform one of the following steps:

   1. Check current labels of the desired machine config pool.

      For example:

      $  oc get machineconfigpool  --show-labels

      Copy to Clipboard Toggle word wrap

      Example output

      NAME      CONFIG                                             UPDATED   UPDATING   DEGRADED   LABELS
      master    rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd   True      False      False      operator.machineconfiguration.openshift.io/required-for-upgrade=
      worker    rendered-worker-f50e78e1bc06d8e82327763145bfcf62   True      False      False

      Copy to Clipboard Toggle word wrap

   2. Add a custom label to the desired machine config pool.

      For example:

      $ oc label machineconfigpool worker custom-kubelet=enabled

      Copy to Clipboard Toggle word wrap

2. Create a kubeletconfig custom resource (CR) for your configuration change.

   For example:

   Sample configuration for a custom-config CR

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: custom-config 

   1

   
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: enabled 

   2

   
     kubeletConfig: 

   3

   
       podsPerCore: 10
       maxPods: 250
       systemReserved:
         cpu: 2000m
         memory: 1Gi

   Copy to Clipboard Toggle word wrap

   1

   Assign a name to CR.

   2

   Specify the label to apply the configuration change, this is the label you added to the machine config pool.

   3

   Specify the new value(s) you want to change.

3. Create the CR object.

   $ oc create -f <file-name>

   Copy to Clipboard Toggle word wrap

   For example:

   $ oc create -f master-kube-config.yaml

   Copy to Clipboard Toggle word wrap

Procedure

1. Edit the schedulers.config.openshift.io resource.

   $ oc edit schedulers.config.openshift.io cluster

   Copy to Clipboard Toggle word wrap

2. Configure the mastersSchedulable field.

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     creationTimestamp: "2019-09-10T03:04:05Z"
     generation: 1
     name: cluster
     resourceVersion: "433"
     selfLink: /apis/config.openshift.io/v1/schedulers/cluster
     uid: a636d30a-d377-11e9-88d4-0a60097bee62
   spec:
     mastersSchedulable: false 

   1

   
     policy:
       name: ""
   status: {}

   Copy to Clipboard Toggle word wrap

   1

   Set to true to allow control plane nodes to be schedulable, or false to disallow control plane nodes to be schedulable.

3. Save the file to apply the changes.

Procedure

1. Create a new YAML file with a MachineConfig object, displayed in the following example:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 99-worker-setsebool
   spec:
     config:
       ignition:
         version: 2.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Set SELinux booleans
             Before=kubelet.service
   
             [Service]
             Type=oneshot
             ExecStart=/sbin/setsebool container_manage_cgroup=on
             RemainAfterExit=true
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: setsebool.service

   Copy to Clipboard Toggle word wrap

2. Create the new MachineConfig object by running the following command:

   $ oc create -f 99-worker-setsebool.yaml

   Copy to Clipboard Toggle word wrap

Procedure

1. List existing MachineConfig objects for your OpenShift Container Platform cluster to determine how to label your machine config:

   $ oc get MachineConfig

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

   Copy to Clipboard Toggle word wrap

2. Create a MachineConfig object file that identifies the kernel argument (for example, 05-worker-kernelarg-selinuxpermissive.yaml)

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker

   1

   
     name: 05-worker-kernelarg-selinuxpermissive

   2

   
   spec:
     config:
       ignition:
         version: 3.2.0
     kernelArguments:
       - enforcing=0

   3

   Copy to Clipboard Toggle word wrap

   1

   Applies the new kernel argument only to worker nodes.

   2

   Named to identify where it fits among the machine configs (05) and what it does (adds a kernel argument to configure SELinux permissive mode).

   3

   Identifies the exact kernel argument as enforcing=0.

3. Create the new machine config:

   $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

   Copy to Clipboard Toggle word wrap

4. Check the machine configs to see that the new one was added:

   $ oc get MachineConfig

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

   Copy to Clipboard Toggle word wrap

5. Check the nodes:

   $ oc get nodes

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.22.1
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.22.1
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.22.1
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.22.1
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.22.1
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.22.1

   Copy to Clipboard Toggle word wrap

   You can see that scheduling on each worker node is disabled as the change is being applied.

6. Check that the kernel argument worked by going to one of the worker nodes and listing the kernel command line arguments (in /proc/cmdline on the host):

   $ oc debug node/ip-10-0-141-105.ec2.internal

   Copy to Clipboard Toggle word wrap

   Example output

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
   rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
   coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
   
   sh-4.2# exit

   Copy to Clipboard Toggle word wrap

   You should see the enforcing=0 argument added to the other kernel arguments.

Prerequisites

1. Obtain the label associated with the static MachineConfigPool CRD for the type of node you want to configure by entering the following command:

   $ oc edit machineconfigpool <name>

   Copy to Clipboard Toggle word wrap

   For example:

   $ oc edit machineconfigpool worker

   Copy to Clipboard Toggle word wrap

   Example output

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     creationTimestamp: "2022-11-16T15:34:25Z"
     generation: 4
     labels:
       pools.operator.machineconfiguration.openshift.io/worker: "" 

   1

   
     name: worker

   Copy to Clipboard Toggle word wrap

   1

   The label appears under Labels.

   Tip

   If the label is not present, add a key/value pair such as:

   $ oc label machineconfigpool worker custom-kubelet=small-pods

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a custom resource (CR) for your configuration change.

   Sample configuration for a max-pods CR

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods 

   1

   
   spec:
     machineConfigPoolSelector:
       matchLabels:
         pools.operator.machineconfiguration.openshift.io/worker: "" 

   2

   
     kubeletConfig:
       podsPerCore: 10 

   3

   
       maxPods: 250 

   4

   Copy to Clipboard Toggle word wrap

   1

   Assign a name to CR.

   2

   Specify the label from the machine config pool.

   3

   Specify the number of pods the node can run based on the number of processor cores on the node.

   4

   Specify the number of pods the node can run to a fixed value, regardless of the properties of the node.

   Note

   Setting podsPerCore to 0 disables this limit.

   In the above example, the default value for podsPerCore is 10 and the default value for maxPods is 250. This means that unless the node has 25 cores or more, by default, podsPerCore will be the limiting factor.

2. Run the following command to create the CR:

   $ oc create -f <file_name>.yaml

   Copy to Clipboard Toggle word wrap

Verification

1. List the MachineConfigPool CRDs to see if the change is applied. The UPDATING column reports True if the change is picked up by the Machine Config Controller:

   $ oc get machineconfigpools

   Copy to Clipboard Toggle word wrap

   Example output

   NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
   master   master-9cc2c72f205e103bb534   False     False      False
   worker   worker-8cecd1236b33ee3f8a5e   False     True       False

   Copy to Clipboard Toggle word wrap

   Once the change is complete, the UPDATED column reports True.

   $ oc get machineconfigpools

   Copy to Clipboard Toggle word wrap

   Example output

   NAME     CONFIG                        UPDATED   UPDATING   DEGRADED
   master   master-9cc2c72f205e103bb534   False     True       False
   worker   worker-8cecd1236b33ee3f8a5e   True      False      False

   Copy to Clipboard Toggle word wrap

Procedure

1. Run:

   $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

   Copy to Clipboard Toggle word wrap

Procedure

1. In the OpenShift Container Platform web console, navigate to Operators OperatorHub.
2. Search for the Poison Pill Operator from the list of available Operators, and then click Install.
3. Keep the default selection of Installation mode and namespace to ensure that the Operator is installed to the openshift-operators namespace.
4. Click Install.

1. Navigate to the Operators Installed Operators page.
2. Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded.

1. Navigate to the Operators Installed Operators page and inspect the Status column for any errors or failures.
2. Navigate to the Workloads Pods page and check the logs in any pods in the poison-pill-controller-manager project that are reporting issues.

Procedure

1. Create a Namespace custom resource (CR) for the Poison Pill Operator:

   1. Define the Namespace CR and save the YAML file, for example, poison-pill-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: poison-pill

      Copy to Clipboard Toggle word wrap

   2. To create the Namespace CR, run the following command:

      $ oc create -f poison-pill-namespace.yaml

      Copy to Clipboard Toggle word wrap

2. Create an OperatorGroup CR:

   1. Define the OperatorGroup CR and save the YAML file, for example, poison-pill-operator-group.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: poison-pill-manager
        namespace: poison-pill

      Copy to Clipboard Toggle word wrap

   2. To create the OperatorGroup CR, run the following command:

      $ oc create -f poison-pill-operator-group.yaml

      Copy to Clipboard Toggle word wrap

3. Create a Subscription CR:

   1. Define the Subscription CR and save the YAML file, for example, poison-pill-subscription.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: poison-pill-manager
          namespace: poison-pill 

      1

      
      spec:
          channel: stable
          installPlanApproval: Manual 

      2

      
          name: poison-pill-manager
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: poison-pill-manager

      Copy to Clipboard Toggle word wrap

      1

      Specify the Namespace where you want to install the Poison Pill Operator. To install the Poison Pill Operator in the openshift-operators namespace, specify openshift-operators in the Subscription CR.

      2

      Set the approval strategy to Manual in case your specified version is superseded by a later version in the catalog. This plan prevents an automatic upgrade to a later version and requires manual approval before the starting CSV can complete the installation.

   2. To create the Subscription CR, run the following command:

      $ oc create -f poison-pill-subscription.yaml

      Copy to Clipboard Toggle word wrap

Verification

1. Verify that the installation succeeded by inspecting the CSV resource:

   $ oc get csv -n poison-pill

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                   DISPLAY                 VERSION   REPLACES    PHASE
   poison-pill.v.0.2.0     Poison Pill Operator    0.2.0                 Succeeded

   Copy to Clipboard Toggle word wrap

2. Verify that the Poison Pill Operator is up and running:

   $ oc get deploy -n poison-pill

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
   poison-pill-controller-manager       1/1     1            1           10d

   Copy to Clipboard Toggle word wrap

3. Verify that the Poison Pill Operator created the PoisonPillConfig CR:

   $ oc get PoisonPillConfig -n poison-pill

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                 AGE
   poison-pill-config   10d

   Copy to Clipboard Toggle word wrap

4. Verify that each poison pill pod is scheduled and running on each worker node:

   $ oc get daemonset -n poison-pill

   Copy to Clipboard Toggle word wrap

   Example output

   NAME             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   poison-pill-ds   2         2         2       2            2           <none>          10d

   Copy to Clipboard Toggle word wrap

   Note

   This command is unsupported for the control plane nodes.

Procedure

1. Create a PoisonPillRemediationTemplate CR:

   1. Define the PoisonPillRemediationTemplate CR:

      apiVersion: poison-pill.medik8s.io/v1alpha1
      kind: PoisonPillRemediationTemplate
      metadata:
        namespace: openshift-machine-api
        name: poisonpillremediationtemplate-sample
      spec:
        template:
          spec: {}

      Copy to Clipboard Toggle word wrap

   2. To create the PoisonPillRemediationTemplate CR, run the following command:

      $ oc create -f <ppr-name>.yaml

      Copy to Clipboard Toggle word wrap

2. Create or update the MachineHealthCheck CR to point to the PoisonPillRemediationTemplate CR:

   1. Define or update the MachineHealthCheck CR:

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineHealthCheck
      metadata:
        name: machine-health-check
        namespace: openshift-machine-api
      spec:
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-machine-role: "worker"
            machine.openshift.io/cluster-api-machine-type: "worker"
        unhealthyConditions:
        - type:    "Ready"
          timeout: "300s"
          status: "False"
        - type:    "Ready"
          timeout: "300s"
          status: "Unknown"
        maxUnhealthy: "40%"
        nodeStartupTimeout: "10m"
        remediationTemplate: 

      1

      
          kind: PoisonPillRemediationTemplate
          apiVersion: poison-pill.medik8s.io/v1alpha1
          name: <poison-pill-remediation-template-sample>

      Copy to Clipboard Toggle word wrap

      1

      Specify the details for the remediation template.

   2. To create a MachineHealthCheck CR, run the following command:

      $ oc create -f <file-name>.yaml

      Copy to Clipboard Toggle word wrap

   3. To update a MachineHealthCheck CR, run the following command:

      $ oc apply -f <file-name>.yaml

      Copy to Clipboard Toggle word wrap

Procedure

1. In the OpenShift Container Platform web console, navigate to Operators OperatorHub.
2. Search for the Node Health Check Operator, then click Install.
3. Keep the default selection of Installation mode and namespace to ensure that the Operator will be installed to the openshift-operators namespace.
4. Click Install.

1. Navigate to the Operators Installed Operators page.
2. Check that the Operator is installed in the openshift-operators namespace and that its status is Succeeded.

1. Navigate to the Operators Installed Operators page and inspect the Status column for any errors or failures.
2. Navigate to the Workloads Pods page and check the logs in any pods in the openshift-operators project that are reporting issues.

Procedure

1. Create a Namespace custom resource (CR) for the Node Health Check Operator:

   1. Define the Namespace CR and save the YAML file, for example, node-health-check-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-operators

      Copy to Clipboard Toggle word wrap

   2. To create the Namespace CR, run the following command:

      $ oc create -f node-health-check-namespace.yaml

      Copy to Clipboard Toggle word wrap

2. Create an OperatorGroup CR:

   1. Define the OperatorGroup CR and save the YAML file, for example, node-health-check-operator-group.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-health-check-operator
        namespace: openshift-operators
      spec:
        targetNamespaces:
        - openshift-operators

      Copy to Clipboard Toggle word wrap

   2. To create the OperatorGroup CR, run the following command:

      $ oc create -f node-health-check-operator-group.yaml

      Copy to Clipboard Toggle word wrap

3. Create a Subscription CR:

   1. Define the Subscription CR and save the YAML file, for example, node-health-check-subscription.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: node-health-check-operator
          namespace: openshift-operators
      spec:
          channel: alpha
          name: node-healthcheck-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: node-health-check-operator

      Copy to Clipboard Toggle word wrap

   2. To create the Subscription CR, run the following command:

      $ oc create -f node-health-check-subscription.yaml

      Copy to Clipboard Toggle word wrap

Verification

1. Verify that the installation succeeded by inspecting the CSV resource:

   $ oc get csv -n openshift-operators

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                               DISPLAY                      VERSION   REPLACES   PHASE
   node-health-check-operator.v0.1.1  Node Health Check Operator   0.1.1                Succeeded

   Copy to Clipboard Toggle word wrap

2. Verify that the Node Health Check Operator is up and running:

   $ oc get deploy -n openshift-operators

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
   node-health-check-operator-controller-manager  1/1     1            1           10d

   Copy to Clipboard Toggle word wrap

1. Edit the node specification to configure pod anti-affinity:

   apiVersion: v1
   kind: Pod
   metadata:
     name: with-pod-antiaffinity
   spec:
     affinity:
       podAntiAffinity: 

   1

   
         preferredDuringSchedulingIgnoredDuringExecution: 

   2

   
         - weight: 100 

   3

   
           podAffinityTerm:
             labelSelector:
               matchExpressions:
               - key: registry 

   4

   
                 operator: In 

   5

   
                 values:
                 - default
             topologyKey: kubernetes.io/hostname

   Copy to Clipboard Toggle word wrap

   1

   Stanza to configure pod anti-affinity.

   2

   Defines a preferred rule.

   3

   Specifies a weight for a preferred rule. The node with the highest weight is preferred.

   4

   Description of the pod label that determines when the anti-affinity rule applies. Specify a key and value for the label.

   5

   The operator represents the relationship between the label on the existing pod and the set of values in the matchExpression parameters in the specification for the new pod. Can be In, NotIn, Exists, or DoesNotExist.

   This example assumes the container image registry pod has a label of registry=default. Pod anti-affinity can use any Kubernetes match expression.

2. Enable the MatchInterPodAffinity scheduler predicate in the scheduling policy file.
3. Perform a graceful restart of the node.

1. Mark the node as unschedulable:

   $ oc adm cordon <node1>

   Copy to Clipboard Toggle word wrap

2. Drain the node to remove all the running pods:

   $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

   Copy to Clipboard Toggle word wrap

   You might receive errors that pods associated with custom pod disruption budgets (PDB) cannot be evicted.

   Example error

   error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

   Copy to Clipboard Toggle word wrap

   In this case, run the drain command again, adding the disable-eviction flag, which bypasses the PDB checks:

   $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction

   Copy to Clipboard Toggle word wrap

3. Access the node in debug mode:

   $ oc debug node/<node1>

   Copy to Clipboard Toggle word wrap

4. Change your root directory to /host:

   $ chroot /host

   Copy to Clipboard Toggle word wrap

5. Restart the node:

   $ systemctl reboot

   Copy to Clipboard Toggle word wrap

   In a moment, the node enters the NotReady state.

   Note

   With some single-node OpenShift clusters, the oc commands might not be available after you cordon and drain the node because the openshift-oauth-apiserver pod is not running. You can use SSH to connect to the node and perform the reboot.

   $ ssh core@<master-node>.<cluster_name>.<base_domain>

   Copy to Clipboard Toggle word wrap

   $ sudo systemctl reboot

   Copy to Clipboard Toggle word wrap

6. After the reboot is complete, mark the node as schedulable by running the following command:

   $ oc adm uncordon <node1>

   Copy to Clipboard Toggle word wrap
   Note

   With some single-node OpenShift clusters, the oc commands might not be available after you cordon and drain the node because the openshift-oauth-apiserver pod is not running. You can use SSH to connect to the node and uncordon it.

   $ ssh core@<target_node>

   Copy to Clipboard Toggle word wrap

   $ sudo oc adm uncordon <node> --kubeconfig /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost.kubeconfig

   Copy to Clipboard Toggle word wrap

7. Verify that the node is ready:

   $ oc get node <node1>

   Copy to Clipboard Toggle word wrap

   Example output

   NAME    STATUS  ROLES    AGE     VERSION
   <node1> Ready   worker   6d22h   v1.18.3+b0068a8

   Copy to Clipboard Toggle word wrap

1. A list of images currently running in at least one pod.
2. A list of images available on a host.

Prerequisites

1. Obtain the label associated with the static MachineConfigPool CRD for the type of node you want to configure by entering the following command:

   $ oc edit machineconfigpool <name>

   Copy to Clipboard Toggle word wrap

   For example:

   $ oc edit machineconfigpool worker

   Copy to Clipboard Toggle word wrap

   Example output

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     creationTimestamp: "2022-11-16T15:34:25Z"
     generation: 4
     labels:
       pools.operator.machineconfiguration.openshift.io/worker: "" 

   1

   
     name: worker

   Copy to Clipboard Toggle word wrap

   1

   The label appears under Labels.

   Tip

   If the label is not present, add a key/value pair such as:

   $ oc label machineconfigpool worker custom-kubelet=small-pods

   Copy to Clipboard Toggle word wrap

Procedure