Nodes

1. Change to the project:

   $ oc project <project-name>

2. Run the following command:

   $ oc get pods

   For example:

   $ oc get pods -n openshift-console

   Example output

   NAME                       READY   STATUS    RESTARTS   AGE
   console-698d866b78-bnshf   1/1     Running   2          165m
   console-698d866b78-m87pm   1/1     Running   2          165m

   Add the -o wide flags to view the pod IP address and the node where the pod is located.

   $ oc get pods -o wide

   Example output

   NAME                       READY   STATUS    RESTARTS   AGE    IP            NODE                           NOMINATED NODE
   console-698d866b78-bnshf   1/1     Running   2          166m   10.128.0.24   ip-10-0-152-71.ec2.internal    <none>
   console-698d866b78-m87pm   1/1     Running   2          166m   10.129.0.23   ip-10-0-173-237.ec2.internal   <none>

1. Run the following command:

   $ oc adm top pods

   For example:

   $ oc adm top pods -n openshift-console

   Example output

   NAME                         CPU(cores)   MEMORY(bytes)
   console-7f58c69899-q8c8k     0m           22Mi
   console-7f58c69899-xhbgg     0m           25Mi
   downloads-594fcccf94-bcxk8   3m           18Mi
   downloads-594fcccf94-kv4p6   2m           15Mi

2. Run the following command to view the usage statistics for pods with labels:

   $ oc adm top pod --selector=''

   You must choose the selector (label query) to filter on. Supports =, ==, and !=.

Procedure (UI)

1. In the OpenShift Container Platform console, navigate to Workloads → Pods or navigate to the pod through the resource you want to investigate.

   Note

   Some resources, such as builds, do not have pods to query directly. In such instances, you can locate the Logs link on the Details page for the resource.

2. Select a project from the drop-down menu.
3. Click the name of the pod you want to investigate.
4. Click Logs.

1. Write an object definition JSON file, and specify the data traffic speed using kubernetes.io/ingress-bandwidth and kubernetes.io/egress-bandwidth annotations. For example, to limit both pod egress and ingress bandwidth to 10M/s:

   Limited Pod object definition

   {
       "kind": "Pod",
       "spec": {
           "containers": [
               {
                   "image": "openshift/hello-openshift",
                   "name": "hello-openshift"
               }
           ]
       },
       "apiVersion": "v1",
       "metadata": {
           "name": "iperf-slow",
           "annotations": {
               "kubernetes.io/ingress-bandwidth": "10M",
               "kubernetes.io/egress-bandwidth": "10M"
           }
       }
   }

2. Create the pod using the object definition:

   $ oc create -f <file_or_dir_path>

1. Create a Pod spec or edit existing pods to include the system-cluster-critical priority class:

   spec:
     template:
       metadata:
         name: critical-pod
       priorityClassName: system-cluster-critical 1

   1

   Default priority class for pods that should never be evicted from a node.

   Alternatively, you can specify system-node-critical for pods that are important to the cluster but can be removed if necessary.

2. Create the pod:

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

1. In the Topology view, click the node to reveal the side pane.

2. From the Actions drop-down list, select Add HorizontalPodAutoscaler to open the Add HorizontalPodAutoscaler form.

   Figure 2.1. Add HorizontalPodAutoscaler

   

3. From the Add HorizontalPodAutoscaler form, define the name, minimum and maximum pod limits, the CPU and memory usage, and click Save.

   Note

   If any of the values for CPU and memory usage are missing, a warning is displayed.

1. In the Topology view, click the node to reveal the side pane.
2. From the Actions drop-down list, select Edit HorizontalPodAutoscaler to open the Edit Horizontal Pod Autoscaler form.
3. From the Edit Horizontal Pod Autoscaler form, edit the minimum and maximum pod limits and the CPU and memory usage, and click Save.

1. In the Topology view, click the node to reveal the side panel.
2. From the Actions drop-down list, select Remove HorizontalPodAutoscaler.
3. In the confirmation pop-up window, click Remove to remove the HPA.

1. Perform one of the following:

   • To scale based on the percent of CPU utilization, create a HorizontalPodAutoscaler object for an existing object:

     $ oc autoscale <object_type>/<name> \1
       --min <number> \2
       --max <number> \3
       --cpu-percent=<percent> 4

     1

     Specify the type and name of the object to autoscale. The object must exist and be a Deployment, DeploymentConfig/dc, ReplicaSet/rs, ReplicationController/rc, or StatefulSet.

     2

     Optionally, specify the minimum number of replicas when scaling down.

     3

     Specify the maximum number of replicas when scaling up.

     4

     Specify the target average CPU utilization over all the pods, represented as a percent of requested CPU. If not specified or negative, a default autoscaling policy is used.

     For example, the following command shows autoscaling for the image-registry Deployment object. The initial deployment requires 3 pods. The HPA object increases the minimum to 5. If CPU usage on the pods reaches 75%, the pods will increase to 7:

     $ oc autoscale deployment/image-registry --min=5 --max=7 --cpu-percent=75

   • To scale for a specific CPU value, create a YAML file similar to the following for an existing object:

     1. Create a YAML file similar to the following:

        apiVersion: autoscaling/v2beta2 1
        kind: HorizontalPodAutoscaler
        metadata:
          name: cpu-autoscale 2
          namespace: default
        spec:
          scaleTargetRef:
            apiVersion: apps/v1 3
            kind: Deployment 4
            name: example 5
          minReplicas: 1 6
          maxReplicas: 10 7
          metrics: 8
          - type: Resource
            resource:
              name: cpu 9
              target:
                type: AverageValue 10
                averageValue: 500m 11

        1

        Use the autoscaling/v2beta2 API.

        2

        Specify a name for this horizontal pod autoscaler object.

        3

        Specify the API version of the object to scale:

        • For a Deployment, ReplicaSet, Statefulset object, use apps/v1.
        • For a ReplicationController, use v1.
        • For a DeploymentConfig, use apps.openshift.io/v1.

        4

        Specify the type of object. The object must be a Deployment, DeploymentConfig/dc, ReplicaSet/rs, ReplicationController/rc, or StatefulSet.

        5

        Specify the name of the object to scale. The object must exist.

        6

        Specify the minimum number of replicas when scaling down.

        7

        Specify the maximum number of replicas when scaling up.

        8

        Use the metrics parameter for memory utilization.

        9

        Specify cpu for CPU utilization.

        10

        Set to AverageValue.

        11

        Set to averageValue with the targeted CPU value.

     2. Create the horizontal pod autoscaler:

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

2. Verify that the horizontal pod autoscaler was created:

   $ oc get hpa cpu-autoscale

   Example output

   NAME            REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
   cpu-autoscale   Deployment/example   173m/500m       1         10        1          20m

1. Create a YAML file for one of the following:

   • To scale for a specific memory value, create a HorizontalPodAutoscaler object similar to the following for an existing object:

     apiVersion: autoscaling/v2beta2 1
     kind: HorizontalPodAutoscaler
     metadata:
       name: hpa-resource-metrics-memory 2
       namespace: default
     spec:
       scaleTargetRef:
         apiVersion: apps/v1 3
         kind: Deployment 4
         name: example 5
       minReplicas: 1 6
       maxReplicas: 10 7
       metrics: 8
       - type: Resource
         resource:
           name: memory 9
           target:
             type: AverageValue 10
             averageValue: 500Mi 11
       behavior: 12
         scaleDown:
           stabilizationWindowSeconds: 300
           policies:
           - type: Pods
             value: 4
             periodSeconds: 60
           - type: Percent
             value: 10
             periodSeconds: 60
           selectPolicy: Max

     1

     Use the autoscaling/v2beta2 API.

     2

     Specify a name for this horizontal pod autoscaler object.

     3

     Specify the API version of the object to scale:

     • For a Deployment, ReplicaSet, or Statefulset object, use apps/v1.
     • For a ReplicationController, use v1.
     • For a DeploymentConfig, use apps.openshift.io/v1.

     4

     Specify the type of object. The object must be a Deployment, DeploymentConfig, ReplicaSet, ReplicationController, or StatefulSet.

     5

     Specify the name of the object to scale. The object must exist.

     6

     Specify the minimum number of replicas when scaling down.

     7

     Specify the maximum number of replicas when scaling up.

     8

     Use the metrics parameter for memory utilization.

     9

     Specify memory for memory utilization.

     10

     Set the type to AverageValue.

     11

     Specify averageValue and a specific memory value.

     12

     Optional: Specify a scaling policy to control the rate of scaling up or down.

   • To scale for a percentage, create a HorizontalPodAutoscaler object similar to the following for an existing object:

     apiVersion: autoscaling/v2beta2 1
     kind: HorizontalPodAutoscaler
     metadata:
       name: memory-autoscale 2
       namespace: default
     spec:
       scaleTargetRef:
         apiVersion: apps/v1 3
         kind: Deployment 4
         name: example 5
       minReplicas: 1 6
       maxReplicas: 10 7
       metrics: 8
       - type: Deployment
         resource:
           name: memory 9
           target:
             type: Utilization 10
             averageUtilization: 50 11
       behavior: 12
         scaleUp:
           stabilizationWindowSeconds: 180
           policies:
           - type: Pods
             value: 6
             periodSeconds: 120
           - type: Percent
             value: 10
             periodSeconds: 120
           selectPolicy: Max

     1

     Use the autoscaling/v2beta2 API.

     2

     Specify a name for this horizontal pod autoscaler object.

     3

     Specify the API version of the object to scale:

     • For a ReplicationController, use v1.
     • For a DeploymentConfig, use apps.openshift.io/v1.
     • For a Deployment, ReplicaSet, Statefulset object, use apps/v1.

     4

     Specify the type of object. The object must be a Deployment, DeploymentConfig, ReplicaSet, ReplicationController, or StatefulSet.

     5

     Specify the name of the object to scale. The object must exist.

     6

     Specify the minimum number of replicas when scaling down.

     7

     Specify the maximum number of replicas when scaling up.

     8

     Use the metrics parameter for memory utilization.

     9

     Specify memory for memory utilization.

     10

     Set to Utilization.

     11

     Specify averageUtilization and a target average memory utilization over all the pods, represented as a percent of requested memory. The target pods must have memory requests configured.

     12

     Optional: Specify a scaling policy to control the rate of scaling up or down.

2. Create the horizontal pod autoscaler:

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

   For example:

   $ oc create -f hpa.yaml

   Example output

   horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

3. Verify that the horizontal pod autoscaler was created:

   $ oc get hpa hpa-resource-metrics-memory

   Example output

   NAME                          REFERENCE            TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
   hpa-resource-metrics-memory   Deployment/example   2441216/500Mi   1         10        1          20m

   $ oc describe hpa hpa-resource-metrics-memory

   Example output

   Name:                        hpa-resource-metrics-memory
   Namespace:                   default
   Labels:                      <none>
   Annotations:                 <none>
   CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
   Reference:                   Deployment/example
   Metrics:                     ( current / target )
     resource memory on pods:   2441216 / 500Mi
   Min replicas:                1
   Max replicas:                10
   ReplicationController pods:  1 current / 1 desired
   Conditions:
     Type            Status  Reason              Message
     ----            ------  ------              -------
     AbleToScale     True    ReadyForNewScale    recommended size matches current size
     ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
     ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
   Events:
     Type     Reason                   Age                 From                       Message
     ----     ------                   ----                ----                       -------
     Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target

Procedure

1. In the OpenShift Container Platform web console, click Operators → OperatorHub.
2. Choose VerticalPodAutoscaler from the list of available Operators, and click Install.
3. On the Install Operator page, ensure that the Operator recommended namespace option is selected. This installs the Operator in the mandatory openshift-vertical-pod-autoscaler namespace, which is automatically created if it does not exist.
4. Click Install.

5. Verify the installation by listing the VPA Operator components:

   1. Navigate to Workloads → Pods.
   2. Select the openshift-vertical-pod-autoscaler project from the drop-down menu and verify that there are four pods running.
   3. Navigate to Workloads → Deployments to verify that there are four deployments running.

6. Optional. Verify the installation in the OpenShift Container Platform CLI using the following command:

   $ oc get all -n openshift-vertical-pod-autoscaler

   The output shows four pods and four deplyoments:

   Example output

   NAME                                                    READY   STATUS    RESTARTS   AGE
   pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
   pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
   pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
   pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s
   
   NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
   service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s
   
   NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
   deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
   deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
   deployment.apps/vpa-updater-default                1/1     1            1           2m56s
   
   NAME                                                          DESIRED   CURRENT   READY   AGE
   replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
   replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
   replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
   replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s

1. Change to the project where the workload object you want to scale is located.

   1. Create a VPA CR YAML file:

      apiVersion: autoscaling.k8s.io/v1
      kind: VerticalPodAutoscaler
      metadata:
        name: vpa-recommender
      spec:
        targetRef:
          apiVersion: "apps/v1"
          kind:       Deployment 1
          name:       frontend 2
        updatePolicy:
          updateMode: "Auto" 3
        resourcePolicy: 4
          containerPolicies:
          - containerName: my-opt-sidecar
            mode: "Off"

      1

      Specify the type of workload object you want this VPA to manage: Deployment, StatefulSet, Job, DaemonSet, ReplicaSet, or ReplicationController.

      2

      Specify the name of an existing workload object you want this VPA to manage.

      3

      Specify the VPA mode:

      • auto to automatically apply the recommended resources on pods associated with the controller. The VPA terminates existing pods and creates new pods with the recommended resource limits and requests.
      • recreate to automatically apply the recommended resources on pods associated with the workload object. The VPA terminates existing pods and creates new pods with the recommended resource limits and requests. The recreate mode should be used rarely, only if you need to ensure that the pods are restarted whenever the resource request changes.
      • initial to automatically apply the recommended resources when pods associated with the workload object are created. The VPA does not update the pods as it learns new resource recommendations.
      • off to only generate resource recommendations for the pods associated with the workload object. The VPA does not update the pods as it learns new resource recommendations and does not apply the recommendations to new pods.

      4

      Optional. Specify the containers you want to opt-out and set the mode to Off.

   2. Create the VPA CR:

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

      After a few moments, the VPA learns the resource usage of the containers in the pods associated with the workload object.

      You can view the VPA recommendations using the following command:

      $ oc get vpa <vpa-name> --output yaml

      The output shows the recommendations for CPU and memory requests, similar to the following:

      Example output

      ...
      status:
      
      ...
      
        recommendation:
          containerRecommendations:
          - containerName: frontend
            lowerBound: 1
              cpu: 25m
              memory: 262144k
            target: 2
              cpu: 25m
              memory: 262144k
            uncappedTarget: 3
              cpu: 25m
              memory: 262144k
            upperBound: 4
              cpu: 262m
              memory: "274357142"
          - containerName: backend
            lowerBound:
              cpu: 12m
              memory: 131072k
            target:
              cpu: 12m
              memory: 131072k
            uncappedTarget:
              cpu: 12m
              memory: 131072k
            upperBound:
              cpu: 476m
              memory: "498558823"
      
      ...

      1

      lowerBound is the minimum recommended resource levels.

      2

      target is the recommended resource levels.

      3

      upperBound is the highest recommended resource levels.

      4

      uncappedTarget is the most recent resource recommendations.

Procedure

1. In the OpenShift Container Platform web console, click Operators → Installed Operators.
2. Switch to the openshift-vertical-pod-autoscaler project.
3. For the VerticalPodAutoscaler Operator, click the Options menu and select Uninstall Operator.
4. In the dialog box, click Uninstall.
5. Optional: To remove all operands associated with the Operator, in the dialog box, select Delete all operand instances for this operator checkbox.
6. Click Uninstall.

7. Optional: Use the OpenShift CLI to remove the VPA components:

   1. Delete the VPA namespace:

      $ oc delete namespace openshift-vertical-pod-autoscaler

   2. Delete the VPA custom resource definition (CRD) objects:

      $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io

      $ oc delete crd verticalpodautoscalercontrollers.autoscaling.openshift.io

      $ oc delete crd verticalpodautoscalers.autoscaling.k8s.io

      Deleting the CRDs removes the associated roles, cluster roles, and role bindings.

      Note

      This action removes from the cluster all user-created VPA CRs. If you re-install the VPA, you must create these objects again.

   3. Delete the VPA Operator:

      $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler

1. Create a secret object that contains the data you want to keep secret. The specific data required for each secret type is descibed in the following sections.

   Example YAML object that creates an opaque secret

   apiVersion: v1
   kind: Secret
   metadata:
     name: test-secret
   type: Opaque 1
   data: 2
     username: dmFsdWUtMQ0K
     password: dmFsdWUtMQ0KDQo=
   stringData: 3
     hostname: myapp.mydomain.com
     secret.properties: |
       property1=valueA
       property2=valueB

   1

   Specifies the type of secret.

   2

   Specifies encoded string and data.

   3

   Specifies decoded string and data.

   Use either the data or stringdata fields, not both.

2. Update the pod’s service account to reference the secret:

   YAML of a service account that uses a secret

   apiVersion: v1
   kind: ServiceAccount
    ...
   secrets:
   - name: test-secret

3. Create a pod, which consumes the secret as an environment variable or as a file (using a secret volume):

   YAML of a pod populating files in a volume with secret data

   apiVersion: v1
   kind: Pod
   metadata:
     name: secret-example-pod
   spec:
     containers:
       - name: secret-test-container
         image: busybox
         command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
         volumeMounts: 1
             - name: secret-volume
               mountPath: /etc/secret-volume 2
               readOnly: true 3
     volumes:
       - name: secret-volume
         secret:
           secretName: test-secret 4
     restartPolicy: Never

   1

   Add a volumeMounts field to each container that needs the secret.

   2

   Specifies an unused directory name where you would like the secret to appear. Each key in the secret data map becomes the filename under mountPath.

   3

   Set to true. If true, this instructs the driver to provide a read-only volume.

   4

   Specifies the name of the secret.

   YAML of a pod populating environment variables with secret data

   apiVersion: v1
   kind: Pod
   metadata:
     name: secret-example-pod
   spec:
     containers:
       - name: secret-test-container
         image: busybox
         command: [ "/bin/sh", "-c", "export" ]
         env:
           - name: TEST_SECRET_USERNAME_ENV_VAR
             valueFrom:
               secretKeyRef: 1
                 name: test-secret
                 key: username
     restartPolicy: Never

   1

   Specifies the environment variable that consumes the secret key.

   YAML of a build config populating environment variables with secret data

   apiVersion: build.openshift.io/v1
   kind: BuildConfig
   metadata:
     name: secret-example-bc
   spec:
     strategy:
       sourceStrategy:
         env:
         - name: TEST_SECRET_USERNAME_ENV_VAR
           valueFrom:
             secretKeyRef: 1
               name: test-secret
               key: username

   1

   Specifies the environment variable that consumes the secret key.

1. Delete the secret:

   $ oc delete secret <secret_name>

2. Clear the annotations:

   $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

   $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

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

   1. View the machine config:

      # oc describe machineconfig <name>

      For example:

      # oc describe machineconfig 00-worker

      Example output

      Name:         00-worker
      Namespace:
      Labels:       machineconfiguration.openshift.io/role=worker 1

      1

      Label required for the Device Manager.

Procedure

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

   Sample configuration for a Device Manager CR

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: devicemgr 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
          machineconfiguration.openshift.io: devicemgr 2
     kubeletConfig:
       feature-gates:
         - DevicePlugins=true 3

   1

   Assign a name to CR.

   2

   Enter the label from the Machine Config Pool.

   3

   Set DevicePlugins to 'true`.

2. Create the Device Manager:

   $ oc create -f devicemgr.yaml

   Example output

   kubeletconfig.machineconfiguration.openshift.io/devicemgr created

3. Ensure that Device Manager was actually enabled by confirming that /var/lib/kubelet/device-plugins/kubelet.sock is created on the node. This is the UNIX domain socket on which the Device Manager gRPC server listens for new plugin registrations. This sock file is created when the Kubelet is started only if Device Manager is enabled.

1. Create one or more priority classes:

   1. Specify a name and value for the priority.
   2. Optionally specify the globalDefault field in the priority class and a description.

2. Create a Pod spec or edit existing pods to include the name of a priority class, similar to the following:

   Sample Pod spec with priority class name

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
     labels:
       env: test
   spec:
     containers:
     - name: nginx
       image: nginx
       imagePullPolicy: IfNotPresent
     priorityClassName: high-priority 1

   1

   Specify the priority class to use with this pod.

3. Create the pod:

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

   You can add the priority name directly to the pod configuration or to a pod template.

Procedure

1. Add labels to a node by using a machine set or editing the node directly:

   • Use a MachineSet object to add labels to nodes managed by the machine set when a node is created:

     1. Run the following command to add labels to a MachineSet object:

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

        For example:

        $ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        Tip

        You can alternatively apply the following YAML to add labels to a machine set:

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. Verify that the labels are added to the MachineSet object by using the oc edit command:

        For example:

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        Example MachineSet object

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        
        ....
        
        spec:
        ...
          template:
            metadata:
        ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
        ....

   • Add labels directly to a node:

     1. Edit the Node object for the node:

        $ oc label nodes <name> <key>=<value>

        For example, to label a node:

        $ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

        Tip

        You can alternatively apply the following YAML to add labels to a node:

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. Verify that the labels are added to the node:

        $ oc get nodes -l type=user-node,region=east

        Example output

        NAME                          STATUS   ROLES    AGE   VERSION
        ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.18.3+002a51f

2. Add the matching node selector to a pod:

   • To add a node selector to existing and future pods, add a node selector to the controlling object for the pods:

     Example ReplicaSet object with labels

     kind: ReplicaSet
     
     ....
     
     spec:
     
     ....
     
       template:
         metadata:
           creationTimestamp: null
           labels:
             ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
             pod-template-hash: 66d5cf9464
         spec:
           nodeSelector:
             kubernetes.io/os: linux
             node-role.kubernetes.io/worker: ''
             type: user-node 1

     1

     Add the node selector.

   • To add a node selector to a specific, new pod, add the selector to the Pod object directly:

     Example Pod object with a node selector

     apiVersion: v1
     kind: Pod
     
     ....
     
     spec:
       nodeSelector:
         region: east
         type: user-node

     Note

     You cannot add a node selector directly to an existing scheduled pod.

1. Create a JSON file named policy.cfg with the desired predicates and priorities.

   Sample scheduler JSON file

   {
   "kind" : "Policy",
   "apiVersion" : "v1",
   "predicates" : [ 1
           {"name" : "MaxGCEPDVolumeCount"},
           {"name" : "GeneralPredicates"},
           {"name" : "MaxAzureDiskVolumeCount"},
           {"name" : "MaxCSIVolumeCountPred"},
           {"name" : "CheckVolumeBinding"},
           {"name" : "MaxEBSVolumeCount"},
           {"name" : "MatchInterPodAffinity"},
           {"name" : "CheckNodeUnschedulable"},
           {"name" : "NoDiskConflict"},
           {"name" : "NoVolumeZoneConflict"},
           {"name" : "PodToleratesNodeTaints"}
           ],
   "priorities" : [ 2
           {"name" : "LeastRequestedPriority", "weight" : 1},
           {"name" : "BalancedResourceAllocation", "weight" : 1},
           {"name" : "ServiceSpreadingPriority", "weight" : 1},
           {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
           {"name" : "NodeAffinityPriority", "weight" : 1},
           {"name" : "TaintTolerationPriority", "weight" : 1},
           {"name" : "ImageLocalityPriority", "weight" : 1},
           {"name" : "SelectorSpreadPriority", "weight" : 1},
           {"name" : "InterPodAffinityPriority", "weight" : 1},
           {"name" : "EqualPriority", "weight" : 1}
           ]
   }

   1

   Add the predicates as needed.

   2

   Add the priorities as needed.

2. Create a config map based on the scheduler JSON file:

   $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name> 1

   1

   Enter a name for the config map.

   For example:

   $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy

   Example output

   configmap/scheduler-policy created

   Tip

   You can alternatively apply the following YAML to create the config map:

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: scheduler-policy
     namespace: openshift-config
   data: 1
     policy.cfg: |
       {
       "kind": "Policy",
       "apiVersion": "v1",
       "predicates": [
           {
               "name": "RequireRegion",
               "argument": {
                   "labelPreference":
                       {"label": "region"},
                       {"presence": true}
               }
            }
         ],
       "priorities": [
           {
               "name":"ZonePreferred",
               "weight" : 1,
               "argument": {
                   "labelPreference":
                       {"label": "zone"},
                       {"presence": true}
                  }
              }
          ]
       }

   1

   The policy.cfg file in JSON format with predicates and priorities.

3. Edit the Scheduler Operator custom resource to add the config map:

   $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge 1

   1

   Specify the name of the config map.

   For example:

   $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=merge

   Tip

   You can alternatively apply the following YAML to add the config map:

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   spec:
     mastersSchedulable: false
     policy:
       name: scheduler-policy 1

   1

   Add the name of the scheduler policy config map.

   After making the change to the Scheduler config resource, wait for the openshift-kube-apiserver pods to redeploy. This can take several minutes. Until the pods redeploy, new scheduler does not take effect.

4. Verify the scheduler policy is configured by viewing the log of a scheduler pod in the openshift-kube-scheduler namespace. The following command checks for the predicates and priorities that are being registered by the scheduler:

   $ oc logs <scheduler-pod> | grep predicates

   For example:

   $ oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicates

   Example output

   Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'

Procedure

1. Edit the Scheduler object:

   $ oc edit scheduler cluster

2. Specify the profile to use in the spec.profile field:

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     ...
     name: cluster
     resourceVersion: "601"
     selfLink: /apis/config.openshift.io/v1/schedulers/cluster
     uid: b351d6d0-d06f-4a99-a26b-87af62e79f59
   spec:
     mastersSchedulable: false
     policy:
       name: ""
     profile: HighNodeUtilization 1

   1

   Set to LowNodeUtilization, HighNodeUtilization, or NoScoring.

3. Save the file to apply the changes.

Procedure

1. Create a pod with a specific label in the Pod spec:

   $ cat team4.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: security-s1
     labels:
       security: S1
   spec:
     containers:
     - name: security-s1
       image: docker.io/ocpqe/hello-pod

2. When creating other pods, edit the Pod spec as follows:

   1. Use the podAffinity stanza to configure the requiredDuringSchedulingIgnoredDuringExecution parameter or preferredDuringSchedulingIgnoredDuringExecution parameter:

   2. Specify the key and value that must be met. If you want the new pod to be scheduled with the other pod, use the same key and value parameters as the label on the first pod.

          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                - key: security
                  operator: In
                  values:
                  - S1
              topologyKey: failure-domain.beta.kubernetes.io/zone

   3. Specify an operator. The operator can be In, NotIn, Exists, or DoesNotExist. For example, use the operator In to require the label to be in the node.
   4. Specify a topologyKey, which is a prepopulated Kubernetes label that the system uses to denote such a topology domain.

3. Create the pod.

   $ oc create -f <pod-spec>.yaml

Procedure

1. Create a pod with a specific label in the Pod spec:

   $ cat team4.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: security-s2
     labels:
       security: S2
   spec:
     containers:
     - name: security-s2
       image: docker.io/ocpqe/hello-pod

2. When creating other pods, edit the Pod spec to set the following parameters:

3. Use the podAntiAffinity stanza to configure the requiredDuringSchedulingIgnoredDuringExecution parameter or preferredDuringSchedulingIgnoredDuringExecution parameter:

   1. Specify a weight for the node, 1-100. The node that with highest weight is preferred.

   2. Specify the key and values that must be met. If you want the new pod to not be scheduled with the other pod, use the same key and value parameters as the label on the first pod.

          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                  - key: security
                    operator: In
                    values:
                    - S2
                topologyKey: kubernetes.io/hostname

   3. For a preferred rule, specify a weight, 1-100.
   4. Specify an operator. The operator can be In, NotIn, Exists, or DoesNotExist. For example, use the operator In to require the label to be in the node.
4. Specify a topologyKey, which is a prepopulated Kubernetes label that the system uses to denote such a topology domain.

5. Create the pod.

   $ oc create -f <pod-spec>.yaml

1. Add a label to a node using the oc label node command:

   $ oc label node node1 e2e-az-name=e2e-az1

   Tip

   You can alternatively apply the following YAML to add the label:

   kind: Node
   apiVersion: v1
   metadata:
     name: <node_name>
     labels:
       e2e-az-name: e2e-az1

2. In the Pod spec, use the nodeAffinity stanza to configure the requiredDuringSchedulingIgnoredDuringExecution parameter:

   1. Specify the key and values that must be met. If you want the new pod to be scheduled on the node you edited, use the same key and value parameters as the label in the node.

   2. Specify an operator. The operator can be In, NotIn, Exists, DoesNotExist, Lt, or Gt. For example, use the operator In to require the label to be in the node:

      Example output

      spec:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: e2e-az-name
                  operator: In
                  values:
                  - e2e-az1
                  - e2e-az2

3. Create the pod:

   $ oc create -f e2e-az2.yaml

1. Add a label to a node using the oc label node command:

   $ oc label node node1 e2e-az-name=e2e-az3

2. In the Pod spec, use the nodeAffinity stanza to configure the preferredDuringSchedulingIgnoredDuringExecution parameter:

   1. Specify a weight for the node, as a number 1-100. The node with highest weight is preferred.

   2. Specify the key and values that must be met. If you want the new pod to be scheduled on the node you edited, use the same key and value parameters as the label in the node:

      spec:
        affinity:
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              preference:
                matchExpressions:
                - key: e2e-az-name
                  operator: In
                  values:
                  - e2e-az3

   3. Specify an operator. The operator can be In, NotIn, Exists, DoesNotExist, Lt, or Gt. For example, use the Operator In to require the label to be in the node.

3. Create the pod.

   $ oc create -f e2e-az3.yaml

1. If you add a NoSchedule taint to a control plane node (also known as the master node) the node must have the node-role.kubernetes.io/master=:NoSchedule taint, which is added by default.

   For example:

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

Procedure

1. Add a toleration to a pod by editing the Pod spec to include a tolerations stanza:

   Sample pod configuration file with an Equal operator

   spec:
     tolerations:
     - key: "key1" 1
       value: "value1"
       operator: "Equal"
       effect: "NoExecute"
       tolerationSeconds: 3600 2

   1

   The toleration parameters, as described in the Taint and toleration components table.

   2

   The tolerationSeconds parameter specifies how long a pod can remain bound to a node before being evicted.

   For example:

   Sample pod configuration file with an Exists operator

   spec:
      tolerations:
       - key: "key1"
         operator: "Exists" 1
         effect: "NoExecute"
         tolerationSeconds: 3600

   1

   The Exists operator does not take a value.

   This example places a taint on node1 that has key key1, value value1, and taint effect NoExecute.

2. Add a taint to a node by using the following command with the parameters described in the Taint and toleration components table:

   $ oc adm taint nodes <node_name> <key>=<value>:<effect>

   For example:

   $ oc adm taint nodes node1 key1=value1:NoExecute

   This command places a taint on node1 that has key key1, value value1, and effect NoExecute.

   Note

   If you add a NoSchedule taint to a control plane node (also known as the master node) the node must have the node-role.kubernetes.io/master=:NoSchedule taint, which is added by default.

   For example:

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

   The tolerations on the pod match the taint on the node. A pod with either toleration can be scheduled onto node1.

1. To remove a taint from a node:

   $ oc adm taint nodes <node-name> <key>-

   For example:

   $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

   Example output

   node/ip-10-0-132-248.ec2.internal untainted

2. To remove a toleration from a pod, edit the Pod spec to remove the toleration:

   spec:
     tolerations:
     - key: "key2"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

Procedure

1. Add labels to a node by using a machine set or editing the node directly:

   • Use a MachineSet object to add labels to nodes managed by the machine set when a node is created:

     1. Run the following command to add labels to a MachineSet object:

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

        For example:

        $ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        Tip

        You can alternatively apply the following YAML to add labels to a machine set:

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. Verify that the labels are added to the MachineSet object by using the oc edit command:

        For example:

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        Example MachineSet object

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        
        ....
        
        spec:
        ...
          template:
            metadata:
        ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
        ....

   • Add labels directly to a node:

     1. Edit the Node object for the node:

        $ oc label nodes <name> <key>=<value>

        For example, to label a node:

        $ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east

        Tip

        You can alternatively apply the following YAML to add labels to a node:

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. Verify that the labels are added to the node:

        $ oc get nodes -l type=user-node,region=east

        Example output

        NAME                          STATUS   ROLES    AGE   VERSION
        ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.18.3+002a51f

2. Add the matching node selector to a pod:

   • To add a node selector to existing and future pods, add a node selector to the controlling object for the pods:

     Example ReplicaSet object with labels

     kind: ReplicaSet
     
     ....
     
     spec:
     
     ....
     
       template:
         metadata:
           creationTimestamp: null
           labels:
             ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
             pod-template-hash: 66d5cf9464
         spec:
           nodeSelector:
             kubernetes.io/os: linux
             node-role.kubernetes.io/worker: ''
             type: user-node 1

     1

     Add the node selector.

   • To add a node selector to a specific, new pod, add the selector to the Pod object directly:

     Example Pod object with a node selector

     apiVersion: v1
     kind: Pod
     
     ....
     
     spec:
       nodeSelector:
         region: east
         type: user-node

     Note

     You cannot add a node selector directly to an existing scheduled pod.

1. Edit the Scheduler Operator CR to add the default cluster-wide node selectors:

   $ oc edit scheduler cluster

   Example Scheduler Operator CR with a node selector

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false
     policy:
       name: ""

   1

   Add a node selector with the appropriate <key>:<value> pairs.

   After making this change, wait for the pods in the openshift-kube-apiserver project to redeploy. This can take several minutes. The default cluster-wide node selector does not take effect until the pods redeploy.

2. Add labels to a node by using a machine set or editing the node directly:

   • Use a machine set to add labels to nodes managed by the machine set when a node is created:

     1. Run the following command to add labels to a MachineSet object:

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1

        1

        Add a <key>/<value> pair for each label.

        For example:

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        Tip

        You can alternatively apply the following YAML to add labels to a machine set:

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. Verify that the labels are added to the MachineSet object by using the oc edit command:

        For example:

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        Example MachineSet object

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        spec:
          ...
          template:
            metadata:
          ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
          ...

     3. Redeploy the nodes associated with that machine set by scaling down to 0 and scaling up the nodes:

        For example:

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. When the nodes are ready and available, verify that the label is added to the nodes by using the oc get command:

        $ oc get nodes -l <key>=<value>

        For example:

        $ oc get nodes -l type=user-node

        Example output

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

   • Add labels directly to a node:

     1. Edit the Node object for the node:

        $ oc label nodes <name> <key>=<value>

        For example, to label a node:

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

        Tip

        You can alternatively apply the following YAML to add labels to a node:

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. Verify that the labels are added to the node using the oc get command:

        $ oc get nodes -l <key>=<value>,<key>=<value>

        For example:

        $ oc get nodes -l type=user-node,region=east

        Example output

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

1. Create a namespace or edit an existing namespace to add the openshift.io/node-selector parameter:

   $ oc edit namespace <name>

   Example output

   apiVersion: v1
   kind: Namespace
   metadata:
     annotations:
       openshift.io/node-selector: "type=user-node,region=east" 1
       openshift.io/description: ""
       openshift.io/display-name: ""
       openshift.io/requester: kube:admin
       openshift.io/sa.scc.mcs: s0:c30,c5
       openshift.io/sa.scc.supplemental-groups: 1000880000/10000
       openshift.io/sa.scc.uid-range: 1000880000/10000
     creationTimestamp: "2021-05-10T12:35:04Z"
     labels:
       kubernetes.io/metadata.name: demo
     name: demo
     resourceVersion: "145537"
     uid: 3f8786e3-1fcb-42e3-a0e3-e2ac54d15001
   spec:
     finalizers:
     - kubernetes

   1

   Add the openshift.io/node-selector with the appropriate <key>:<value> pairs.

2. Add labels to a node by using a machine set or editing the node directly:

   • Use a MachineSet object to add labels to nodes managed by the machine set when a node is created:

     1. Run the following command to add labels to a MachineSet object:

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api

        For example:

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        Tip

        You can alternatively apply the following YAML to add labels to a machine set:

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. Verify that the labels are added to the MachineSet object by using the oc edit command:

        For example:

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        Example output

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
        ...
        spec:
        ...
          template:
            metadata:
        ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node

     3. Redeploy the nodes associated with that machine set:

        For example:

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. When the nodes are ready and available, verify that the label is added to the nodes by using the oc get command:

        $ oc get nodes -l <key>=<value>

        For example:

        $ oc get nodes -l type=user-node,region=east

        Example output

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.18.3+002a51f

   • Add labels directly to a node:

     1. Edit the Node object to add labels:

        $ oc label <resource> <name> <key>=<value>

        For example, to label a node:

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-c-tgq49 type=user-node region=east

        Tip

        You can alternatively apply the following YAML to add labels to a node:

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. Verify that the labels are added to the Node object using the oc get command:

        $ oc get nodes -l <key>=<value>

        For example:

        $ oc get nodes -l type=user-node,region=east

        Example output

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.18.3+002a51f

Procedure

1. Create a Pod spec and specify a pod topology spread constraint:

   Example pod-spec.yaml file

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
     labels:
       foo: bar
   spec:
     topologySpreadConstraints:
     - maxSkew: 1 1
       topologyKey: topology.kubernetes.io/zone 2
       whenUnsatisfiable: DoNotSchedule 3
       labelSelector: 4
         matchLabels:
           foo: bar 5
     containers:
     - image: "docker.io/ocpqe/hello-pod"
       name: hello-pod

   1

   The maximum difference in number of pods between any two topology domains. The default is 1, and you cannot specify a value of 0.

   2

   The key of a node label. Nodes with this key and identical value are considered to be in the same topology.

   3

   How to handle a pod if it does not satisfy the spread constraint. The default is DoNotSchedule, which tells the scheduler not to schedule the pod. Set to ScheduleAnyway to still schedule the pod, but the scheduler prioritizes honoring the skew to not make the cluster more imbalanced.

   4

   Pods that match this label selector are counted and recognized as a group when spreading to satisfy the constraint. Be sure to specify a label selector, otherwise no pods can be matched.

   5

   Be sure that this Pod spec also sets its labels to match this label selector if you want it to be counted properly in the future.

2. Create the pod:

   $ oc create -f pod-spec.yaml

Procedure

1. Create a file that contains a config map that holds the scheduler configuration file:

   Example scheduler-config-map.yaml

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: scheduler-config
     namespace: kube-system 1
   data:
     scheduler-config.yaml: | 2
       apiVersion: kubescheduler.config.k8s.io/v1beta2
       kind: KubeSchedulerConfiguration
       profiles:
         - schedulerName: custom-scheduler 3
       leaderElection:
         leaderElect: false

   1

   This procedure uses the kube-system namespace, but you can use the namespace of your choosing.

   2

   When you define your Deployment resource later in this procedure, you pass this file in to the scheduler command by using the --config argument.

   3

   Define a scheduler profile for your custom scheduler. This scheduler name is used when defining the schedulerName in the Pod configuration.

2. Create the config map:

   $ oc create -f scheduler-config-map.yaml

3. Create a file that contains the deployment resources for the custom scheduler:

   Example custom-scheduler.yaml file

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: custom-scheduler
     namespace: kube-system 1
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-scheduler-as-kube-scheduler
   subjects:
   - kind: ServiceAccount
     name: custom-scheduler
     namespace: kube-system 2
   roleRef:
     kind: ClusterRole
     name: system:kube-scheduler
     apiGroup: rbac.authorization.k8s.io
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-scheduler-as-volume-scheduler
   subjects:
   - kind: ServiceAccount
     name: custom-scheduler
     namespace: kube-system 3
   roleRef:
     kind: ClusterRole
     name: system:volume-scheduler
     apiGroup: rbac.authorization.k8s.io
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       component: scheduler
       tier: control-plane
     name: custom-scheduler
     namespace: kube-system 4
   spec:
     selector:
       matchLabels:
         component: scheduler
         tier: control-plane
     replicas: 1
     template:
       metadata:
         labels:
           component: scheduler
           tier: control-plane
           version: second
       spec:
         serviceAccountName: custom-scheduler
         containers:
         - command:
           - /usr/local/bin/kube-scheduler
           - --config=/etc/config/scheduler-config.yaml 5
           image: "<namespace>/<image_name>:<tag>" 6
           livenessProbe:
             httpGet:
               path: /healthz
               port: 10259
               scheme: HTTPS
             initialDelaySeconds: 15
           name: kube-second-scheduler
           readinessProbe:
             httpGet:
               path: /healthz
               port: 10259
               scheme: HTTPS
           resources:
             requests:
               cpu: '0.1'
           securityContext:
             privileged: false
           volumeMounts:
           - name: config-volume
             mountPath: /etc/config
         hostNetwork: false
         hostPID: false
         volumes:
           - name: config-volume
             configMap:
               name: scheduler-config

   1 2 3 4

   This procedure uses the kube-system namespace, but you can use the namespace of your choosing.

   5

   The command for your custom scheduler might require different arguments.

   6

   Specify the container image that you created for the custom scheduler.

4. Create the deployment resources in the cluster:

   $ oc create -f custom-scheduler.yaml

Procedure

1. If your cluster uses role-based access control (RBAC), add the custom scheduler name to the system:kube-scheduler cluster role.

   1. Edit the system:kube-scheduler cluster role:

      $ oc edit clusterrole system:kube-scheduler

   2. Add the name of the custom scheduler to the resourceNames lists for the leases and endpoints resources:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        annotations:
          rbac.authorization.kubernetes.io/autoupdate: "true"
        creationTimestamp: "2021-07-07T10:19:14Z"
        labels:
          kubernetes.io/bootstrapping: rbac-defaults
        name: system:kube-scheduler
        resourceVersion: "125"
        uid: 53896c70-b332-420a-b2a4-f72c822313f2
      rules:
      ...
      - apiGroups:
        - coordination.k8s.io
        resources:
        - leases
        verbs:
        - create
      - apiGroups:
        - coordination.k8s.io
        resourceNames:
        - kube-scheduler
        - custom-scheduler 1
        resources:
        - leases
        verbs:
        - get
        - update
      - apiGroups:
        - ""
        resources:
        - endpoints
        verbs:
        - create
      - apiGroups:
        - ""
        resourceNames:
        - kube-scheduler
        - custom-scheduler 2
        resources:
        - endpoints
        verbs:
        - get
        - update
      ...

      1 2

      This example uses custom-scheduler as the custom scheduler name.

2. Create a Pod configuration and specify the name of the custom scheduler in the schedulerName parameter:

   Example custom-scheduler-example.yaml file

   apiVersion: v1
   kind: Pod
   metadata:
     name: custom-scheduler-example
     labels:
       name: custom-scheduler-example
   spec:
     schedulerName: custom-scheduler 1
     containers:
     - name: pod-with-second-annotation-container
       image: docker.io/ocpqe/hello-pod

   1

   The name of the custom scheduler to use, which is custom-scheduler in this example. When no scheduler name is supplied, the pod is automatically scheduled using the default scheduler.

3. Create the pod:

   $ oc create -f custom-scheduler-example.yaml

Verification

1. Enter the following command to check that the pod was created:

   $ oc get pod custom-scheduler-example

   The custom-scheduler-example pod is listed in the output:

   NAME                       READY     STATUS    RESTARTS   AGE
   custom-scheduler-example   1/1       Running   0          4m

2. Enter the following command to check that the custom scheduler has scheduled the pod:

   $ oc describe pod custom-scheduler-example

   The scheduler, custom-scheduler, is listed as shown in the following truncated output:

   Events:
     Type    Reason          Age        From                                               Message
     ----    ------          ----       ----                                               -------
     Normal  Scheduled       <unknown>  custom-scheduler                                   Successfully assigned default/custom-scheduler-example to <node_name>

Procedure

1. Log in to the OpenShift Container Platform web console.

2. Create the required namespace for the Kube Descheduler Operator.

   1. Navigate to Administration → Namespaces and click Create Namespace.
   2. Enter openshift-kube-descheduler-operator in the Name field, enter openshift.io/cluster-monitoring=true in the Labels field to enable descheduler metrics, and click Create.

3. Install the Kube Descheduler Operator.

   1. Navigate to Operators → OperatorHub.
   2. Type Kube Descheduler Operator into the filter box.
   3. Select the Kube Descheduler Operator and click Install.
   4. On the Install Operator page, select A specific namespace on the cluster. Select openshift-kube-descheduler-operator from the drop-down menu.
   5. Adjust the values for the Update Channel and Approval Strategy to the desired values.
   6. Click Install.

4. Create a descheduler instance.

   1. From the Operators → Installed Operators page, click the Kube Descheduler Operator.
   2. Select the Kube Descheduler tab and click Create KubeDescheduler.

   3. Edit the settings as necessary.

      1. Expand the Profiles section to select one or more profiles to enable. The AffinityAndTaints profile is enabled by default. Click Add Profile to select additional profiles.
      2. Optional: Use the Descheduling Interval Seconds field to change the number of seconds between descheduler runs. The default is 3600 seconds.
   4. Click Create.

Procedure

1. Edit the KubeDescheduler object:

   $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

2. Specify one or more profiles in the spec.profiles section.

   apiVersion: operator.openshift.io/v1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600
     logLevel: Normal
     managementState: Managed
     operatorLogLevel: Normal
     profiles:
     - AffinityAndTaints       1
     - TopologyAndDuplicates   2
     - LifecycleAndUtilization 3

   1

   Enable the AffinityAndTaints profile, which evicts pods that violate inter-pod anti-affinity, node affinity, and node taints.

   2

   Enable the TopologyAndDuplicates profile, which evicts pods in an effort to evenly spread similar pods, or pods of the same topology domain, among nodes.

   3

   Enable the LifecycleAndUtilization profile, which evicts long-running pods and balances resource usage between nodes.

   You can enable multiple profiles; the order that the profiles are specified in is not important.

3. Save the file to apply the changes.

Procedure

1. Edit the KubeDescheduler object:

   $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

2. Update the deschedulingIntervalSeconds field to the desired value:

   apiVersion: operator.openshift.io/v1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600 1
   ...

   1

   Set the number of seconds between descheduler runs. A value of 0 in this field runs the descheduler once and exits.

3. Save the file to apply the changes.

Procedure

1. Log in to the OpenShift Container Platform web console.

2. Delete the descheduler instance.

   1. From the Operators → Installed Operators page, click Kube Descheduler Operator.
   2. Select the Kube Descheduler tab.
   3. Click the Options menu next to the cluster entry and select Delete KubeDescheduler.
   4. In the confirmation dialog, click Delete.

3. Uninstall the Kube Descheduler Operator.

   1. Navigate to Operators → Installed Operators,
   2. Click the Options menu next to the Kube Descheduler Operator entry and select Uninstall Operator.
   3. In the confirmation dialog, click Uninstall.

4. Delete the openshift-kube-descheduler-operator namespace.

   1. Navigate to Administration → Namespaces.
   2. Enter openshift-kube-descheduler-operator into the filter box.
   3. Click the Options menu next to the openshift-kube-descheduler-operator entry and select Delete Namespace.
   4. In the confirmation dialog, enter openshift-kube-descheduler-operator and click Delete.

5. Delete the KubeDescheduler CRD.

   1. Navigate to Administration → Custom Resource Definitions.
   2. Enter KubeDescheduler into the filter box.
   3. Click the Options menu next to the KubeDescheduler entry and select Delete CustomResourceDefinition.
   4. In the confirmation dialog, click Delete.

1. Define the daemon set yaml file:

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: hello-daemonset
   spec:
     selector:
         matchLabels:
           name: hello-daemonset 1
     template:
       metadata:
         labels:
           name: hello-daemonset 2
       spec:
         nodeSelector: 3
           role: worker
         containers:
         - image: openshift/hello-openshift
           imagePullPolicy: Always
           name: registry
           ports:
           - containerPort: 80
             protocol: TCP
           resources: {}
           terminationMessagePath: /dev/termination-log
         serviceAccount: default
         terminationGracePeriodSeconds: 10

   1

   The label selector that determines which pods belong to the daemon set.

   2

   The pod template’s label selector. Must match the label selector above.

   3

   The node selector that determines on which nodes pod replicas should be deployed. A matching label must be present on the node.

2. Create the daemon set object:

   $ oc create -f daemonset.yaml

3. To verify that the pods were created, and that each node has a pod replica:

   1. Find the daemonset pods:

      $ oc get pods

      Example output

      hello-daemonset-cx6md   1/1       Running   0          2m
      hello-daemonset-e3md9   1/1       Running   0          2m

   2. View the pods to verify the pod has been placed onto the node:

      $ oc describe pod/hello-daemonset-cx6md|grep Node

      Example output

      Node:        openshift-node01.hostname.com/10.14.20.134

      $ oc describe pod/hello-daemonset-e3md9|grep Node

      Example output

      Node:        openshift-node02.hostname.com/10.14.20.137

1. Create a YAML file similar to the following:

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: pi
   spec:
     parallelism: 1    1
     completions: 1    2
     activeDeadlineSeconds: 1800 3
     backoffLimit: 6   4
     template:         5
       metadata:
         name: pi
       spec:
         containers:
         - name: pi
           image: perl
           command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
         restartPolicy: OnFailure    6

   1

   Optional: Specify how many pod replicas a job should run in parallel; defaults to 1.

   • For non-parallel jobs, leave unset. When unset, defaults to 1.

   2

   Optional: Specify how many successful pod completions are needed to mark a job completed.

   • For non-parallel jobs, leave unset. When unset, defaults to 1.
   • For parallel jobs with a fixed completion count, specify the number of completions.
   • For parallel jobs with a work queue, leave unset. When unset defaults to the parallelism value.

   3

   Optional: Specify the maximum duration the job can run.

   4

   Optional: Specify the number of retries for a job. This field defaults to six.

   5

   Specify the template for the pod the controller creates.

   6

   Specify the restart policy of the pod:

   • Never. Do not restart the job.
   • OnFailure. Restart the job only if it fails.

   • Always. Always restart the job.

     For details on how OpenShift Container Platform uses restart policy with failed containers, see the Example States in the Kubernetes documentation.

2. Create the job:

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

1. Create a YAML file similar to the following:

   apiVersion: batch/v1
   kind: CronJob
   metadata:
     name: pi
   spec:
     schedule: "*/1 * * * *"  1
     concurrencyPolicy: "Replace" 2
     startingDeadlineSeconds: 200 3
     suspend: true            4
     successfulJobsHistoryLimit: 3 5
     failedJobsHistoryLimit: 1     6
     jobTemplate:             7
       spec:
         template:
           metadata:
             labels:          8
               parent: "cronjobpi"
           spec:
             containers:
             - name: pi
               image: perl
               command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
             restartPolicy: OnFailure 9

   1

   Schedule for the job specified in cron format. In this example, the job will run every minute.

   2

   An optional concurrency policy, specifying how to treat concurrent jobs within a cron job. Only one of the following concurrent policies may be specified. If not specified, this defaults to allowing concurrent executions.

   • Allow allows cron jobs to run concurrently.
   • Forbid forbids concurrent runs, skipping the next run if the previous has not finished yet.
   • Replace cancels the currently running job and replaces it with a new one.

   3

   An optional deadline (in seconds) for starting the job if it misses its scheduled time for any reason. Missed jobs executions will be counted as failed ones. If not specified, there is no deadline.

   4

   An optional flag allowing the suspension of a cron job. If set to true, all subsequent executions will be suspended.

   5

   The number of successful finished jobs to retain (defaults to 3).

   6

   The number of failed finished jobs to retain (defaults to 1).

   7

   Job template. This is similar to the job example.

   8

   Sets a label for jobs spawned by this cron job.

   9

   The restart policy of the pod. This does not apply to the job controller.

   Note

   The .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish.

2. Create the cron job:

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