Chapter 2. Deploying workloads on bare metal

Procedure

1. Create an nfd.yaml manifest file according to the following example:

   apiVersion: nfd.openshift.io/v1
   kind: NodeFeatureDiscovery
   metadata:
     name: nfd-kata
     namespace: openshift-nfd
   spec:
     workerConfig:
       configData: |
         sources:
           custom:
             - name: "feature.node.kubernetes.io/runtime.kata"
               matchOn:
                 - cpuId: ["SSE4", "VMX"]
                   loadedKMod: ["kvm", "kvm_intel"]
                 - cpuId: ["SSE4", "SVM"]
                   loadedKMod: ["kvm", "kvm_amd"]
   # ...

2. Create the NodeFeatureDiscovery CR:

   $ oc create -f nfd.yaml

   The NodeFeatureDiscovery CR applies the feature.node.kubernetes.io/runtime.kata=true label to all qualifying worker nodes.

1. Create a kata-config.yaml manifest file according to the following example:

   apiVersion: kataconfiguration.openshift.io/v1
   kind: KataConfig
   metadata:
     name: example-kataconfig
   spec:
     checkNodeEligibility: true

2. Create the KataConfig CR:

   $ oc create -f kata-config.yaml

Procedure

1. In the OpenShift Container Platform web console, navigate to Operators Installed Operators.
2. Select the OpenShift sandboxed containers Operator.
3. On the KataConfig tab, click Create KataConfig.

4. Enter the following details:

   • Name: Optional: The default name is example-kataconfig.
   • Labels: Optional: Enter any relevant, identifying attributes to the KataConfig resource. Each label represents a key-value pair.
   • checkNodeEligibility: Optional: Select to use the Node Feature Discovery Operator (NFD) to detect node eligibility.

   • kataConfigPoolSelector. Optional: To install kata on selected nodes, add a match expression for the labels on the selected nodes:

     1. Expand the kataConfigPoolSelector area.
     2. In the kataConfigPoolSelector area, expand matchExpressions. This is a list of label selector requirements.
     3. Click Add matchExpressions.
     4. In the Key field, enter the label key the selector applies to.
     5. In the Operator field, enter the key’s relationship to the label values. Valid operators are In, NotIn, Exists, and DoesNotExist.
     6. Expand the Values area and then click Add value.
     7. In the Value field, enter true or false for key label value.
   • logLevel: Define the level of log data retrieved for nodes with the kata runtime class.

5. Click Create. The KataConfig CR is created and installs the kata runtime class on the worker nodes.

   Wait for the kata installation to complete and the worker nodes to reboot before verifying the installation.

Verification

1. On the KataConfig tab, click the KataConfig CR to view its details.

2. Click the YAML tab to view the status stanza.

   The status stanza contains the conditions and kataNodes keys. The value of status.kataNodes is an array of nodes, each of which lists nodes in a particular state of kata installation. A message appears each time there is an update.

3. Click Reload to refresh the YAML.

   When all workers in the status.kataNodes array display the values installed and conditions.InProgress: False with no specified reason, the kata is installed on the cluster.

Procedure

1. In the OpenShift Container Platform web console, navigate to Workloads workload type, for example, Pods.
2. On the workload type page, click an object to view its details.
3. Click the YAML tab.

4. Add spec.runtimeClassName: kata to the manifest of each pod-templated workload object as in the following example:

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata
   # ...

   OpenShift Container Platform creates the workload object and begins scheduling it.

Procedure

1. Create the local volume resource. This resource must define the nodes and paths to the local volumes.

   Note

   Do not use different storage class names for the same device. Doing so will create multiple persistent volumes (PVs).

   Example: Block

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "openshift-local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-136-143
             - ip-10-0-140-255
             - ip-10-0-144-180
     storageClassDevices:
       - storageClassName: "local-sc" 3
         forceWipeDevicesAndDestroyAllData: false 4
         volumeMode: Block
         devicePaths: 5
           - /path/to/device 6

   1

   The namespace where the Local Storage Operator is installed.

   2

   Optional: A node selector containing a list of nodes where the local storage volumes are attached. This example uses the node hostnames, obtained from oc get node. If a value is not defined, then the Local Storage Operator will attempt to find matching disks on all available nodes.

   3

   The name of the storage class to use when creating persistent volume objects.

   4

   This setting defines whether or not to call wipefs, which removes partition table signatures (magic strings) making the disk ready to use for Local Storage Operator provisioning. No other data besides signatures is erased. The default is "false" (wipefs is not invoked). Setting forceWipeDevicesAndDestroyAllData to "true" can be useful in scenarios where previous data can remain on disks that need to be re-used. In these scenarios, setting this field to true eliminates the need for administrators to erase the disks manually.

   5

   The path containing a list of local storage devices to choose from. You must use this path when deploying sandboxed container nodes on a block device.

   6

   Replace this value with your actual local disks filepath to the LocalVolume resource by-id, such as /dev/disk/by-id/wwn. PVs are created for these local disks when the provisioner is deployed successfully.

2. Create the local volume resource in your OpenShift Container Platform cluster. Specify the file you just created:

   $ oc create -f <local-volume>.yaml

3. Verify that the provisioner was created and that the corresponding daemon sets were created:

   $ oc get all -n openshift-local-storage

   Example output

   NAME                                          READY   STATUS    RESTARTS   AGE
   pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
   pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
   pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
   pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
   
   NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
   service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
   
   NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
   
   NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/local-storage-operator   1/1     1            1           14m
   
   NAME                                                DESIRED   CURRENT   READY   AGE
   replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

   Note the desired and current number of daemon set processes. A desired count of 0 indicates that the label selectors were invalid.

4. Verify that the persistent volumes were created:

   $ oc get pv

   Example output

   NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
   local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
   local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
   local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

Procedure

1. Create a cluster-kataconfig.yaml manifest file according to the following example:

   apiVersion: kataconfiguration.openshift.io/v1
   kind: KataConfig
   metadata:
     name: cluster-kataconfig
   spec:
     checkNodeEligibility: false 1
     logLevel: info

   1

   Optional: Set`checkNodeEligibility` to true to run node eligibility checks.

2. Optional: To install kata on selected nodes, specify the node labels according to the following example:

   apiVersion: kataconfiguration.openshift.io/v1
   kind: KataConfig
   metadata:
     name: cluster-kataconfig
   spec:
     kataConfigPoolSelector:
       matchLabels:
         <label_key>: '<label_value>' 1
   # ...

   1

   Specify the labels of the selected nodes.

3. Create the KataConfig CR:

   $ oc create -f cluster-kataconfig.yaml

   The new KataConfig CR is created and installs kata as a runtime class on the worker nodes.

   Wait for the kata installation to complete and the worker nodes to reboot before verifying the installation.

Procedure

1. Obtain the RuntimeClass object by running the following command:

   $ oc describe runtimeclass kata

2. Update the overhead.podFixed.memory and cpu values and save as RuntimeClass.yaml:

   kind: RuntimeClass
   apiVersion: node.k8s.io/v1
   metadata:
     name: kata
   overhead:
     podFixed:
       memory: "500Mi"
       cpu: "500m"

Procedure

1. Add spec.runtimeClassName: kata to the manifest of each pod-templated workload object as in the following example:

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata
   # ...

   OpenShift Container Platform creates the workload object and begins scheduling it.