Commands Kubernetes should adopt from Red Hat OpenShift
Working with Kubernetes would become easier and more efficient with support for these handy OpenShift commands.
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:
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.txtIn 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=fooUpdating 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=$FILEPATHAdding 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_PATHRemoving 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_NAMEOpening 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_NAMECreating 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_NAMEBut 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_NAMEFor creating a namespace OpenShift provides the oc new-project command.
Further information
Checkout the complete command reference of the OpenShift CLI under this link:
There you will also find more flags and options for the commands shown in this blog article.
