Commands Kubernetes should adopt from Red Hat OpenShift

What is Kubernetes?

Kubernetes was created by Google developers more than a decade ago and has become the de-facto standard when it comes to container orchestration systems. It enables the operation of highly available applications across hybrid environments. Kubernetes is developed by an open-source community and is part of the Cloud Native Computing Foundation.

What is Red Hat OpenShift?

OpenShift is a product by the company Red Hat and is built on top of Kubernetes. It adds a lot of new functionality like improved security, easier application deployment, integrated building functionality, an image registry, and many more. Besides this functionality, it also adds some commands that make the usage of OpenShift way more efficient and easier for users.

So let's have a look at some of these commands offered by the OpenShift command line tool oc, which should be supported by the Kubernetes native command line tool kubectl in my opinion. I will only focus on commands that would work in the Kubernetes world as well. For example, there will be no oc create route, which makes an application publicly available in a very easy way, as the concept of Routes does not exist in Kubernetes.

Table of contents

You can jump directly to the commands:

• oc extract
• oc set data
• oc set volumes
• oc rsh
• oc adm node-logs
• oc project
• oc new-project

Interaction with Resources

Extracting data from ConfigMaps/Secrets using oc extract

Exporting data from a ConfigMap/Secret can be done with the jsonpath option of the kubectl command. But the syntax is quite complex and hard to remember. If we want to access the key foo from a ConfigMap my-cm we can type:

kubectl get configmap my-cm -o jsonpath="{.data.foo}" > extracted-data.txt

In OpenShift we have the command oc extract to achieve the same. With the --to flag we can define a destination for the extracted data and the --keys flag defines which keys to extract:

oc extract configmap/my-cm --to=extracted-data.txt --keys=foo

Updating keys in ConfigMaps/Secrets using oc set data

In Kubernetes updating values in a ConfigMap or Secret requires using kubectl edit, which opens an editor, with which you can change the values to their new value. OpenShift provides an easier way with oc set data. You simply specify the keys you want to update and provide the desired new value. This also works with referencing a file through the --from-file flag:

oc set data configmap/$CONFIGMAP_NAME key=value --from-file=key2=$FILEPATH

Adding and removing volumes with oc set volumes

When you want to define volumes for Pods you are required to add data to the volumes and volumeMounts section of the Pod specification. With OpenShift this action can be achieved with the oc set volumes command. If you want to add a PVC to a Pod simply type:

oc set volumes pod/<POD_NAME> --add --name=<VOLUME_NAME> --type=pvc \
--claim-size=2Gi --claim-mode=rwo --mount-path=<MOUNT_PATH>

This will create the PVC resource and add a reference to the Pod specification. But you're not limited to PVCs and can also use ConfigMaps or Secrets instead:

oc set volumes pod/$POD_NAME --add --name=$VOLUME_NAME --type=secret \
--secret-name=$SECRET_NAME --mount-path=$MOUNT_PATH

Removing a volume from a Pod is also possible using the --remove flag instead of the --add flag:

oc set volumes pod/$POD_NAME --remove --name=$VOLUME_NAME

Opening a shell in a Pod using oc rsh

Opening a shell in the namespace of a Container is possible in Kubernetes using kubectl exec <POD_NAME> -it -- /bin/bash. In OpenShift you can simply type oc rsh <POD_NAME> and specify the shell with the --shell flag if needed. This command wouldn't offer new functionality but would save us some time in the daily work.

Cluster management

Accessing logs on a node with oc adm node-logs

With kubectl you are only able to access logs of a container inside a Pod. Therefore if you need to debug problems with a node, you will need ssh access to the node. In general, you don't want humans to interact on the OS level in the cloud-native world, but especially with Managed Kubernetes, you don't even have any chance to access the control nodes as they are completely managed by your Platform provider.

With the oc adm node-logs command you are able to access the entries of the systemd logs from your workstation in the same way you would directly on the node with the journalctl command.

You can also add the -u flag to only access logs of specific systemd units, like the CRI-O container runtime or the kubelet.

oc adm node-logs -u [crio|kubelet] $NODE_NAME

Creating and changing namespaces

Creating a namespace is easy with kubectl create ns $NAMESPACE_NAME, but changing to a different namespace is quite complex - except you are using the kubectx plugin:

kubectl config set-context --current \
--namespace $NAMESPACE_NAME

But this becomes way easier in OpenShift. As namespace are call projects there, we have to use a command called oc project, but under the hood projects are simply namespaces.

oc project $NAMESPACE_NAME

For creating a namespace OpenShift provides the oc new-project command.

Further information

Checkout the complete command reference of the OpenShift CLI under this link:

OpenShift CLI developer command reference - OpenShift CLI (oc) | CLI tools | OpenShift Container Platform 4.11

OpenShift

There you will also find more flags and options for the commands shown in this blog article.