A working day on OpenShift: the translation table

Your kubectl muscle memory, translated

Day one on a work OpenShift cluster: someone asks you to "deploy the new image, give Ana edit rights in the project and check why the route is down". You know how to do each of those in Kubernetes. This lesson is the cheat sheet that turns each habit into its OpenShift form, plus the few commands that only exist here.

What you need to know already: kubectl and kubeconfig (15.1, 15.3), Deployments, Services and Ingress (15.16, 16.1, 16.19), RBAC role bindings (17.30), Helm (25.19); from this chapter: oc login and projects (30.2, 30.4), SCCs (30.7, 30.9), Routes (30.13, 30.15), builds and ImageStreams (30.18), operators (30.23) and cluster operations (30.26).

Most of what you type is still kubectl - through oc, which contains all of kubectl. The table below is the part that changes. Left column: the job; middle: how you did it in chapters 15-19 and 22-24; right: the OpenShift way.

Everything in the right column that is not an OpenShift API (the kubectl verbs, jsonpath, --dry-run=client -o yaml, auth can-i, rollout, top) works exactly as in chapters 15-19. A few right-column commands are new here:

• oc rsh pod - "remote shell": opens sh in the pod's first container, the same as kubectl exec -it pod -- sh with less typing.
• oc policy add-role-to-user edit alice - creates a RoleBinding (17.30) giving user alice the built-in edit ClusterRole in the current project.
• oc adm policy scc-subject-review -f pod.yaml - asks "which SCC would admit this pod?" without creating it.
• The service CA: annotate a Service with service.beta.openshift.io/serving-cert-secret-name=<name> and OpenShift writes a TLS certificate (9.15) for it into that Secret, signed by a cluster-internal CA.

oc status

The fastest overview of a project. Where kubectl get all prints flat lists, oc status draws the chain Route -> Service -> Deployment -> BuildConfig, and lists what is broken:

$ oc status
In project shop on server https://api.ocp.lab:6443

https://web-shop.apps.ocp.lab (redirects) to pod port http (svc/web)
  deployment/web deploys istag/web:latest <-
    bc/web source builds https://github.com/sclorg/nodejs-ex.git on openshift/nodejs:22-ubi9
  deployment #3 running for 2m - 2 pods

svc/legacy - 10.96.141.22:80
  deployment/legacy deploys docker.io/library/nginx:1.27
  deployment #1 running for 12m - 0/2 pods growing to 2

1 error, 0 warnings, 1 info identified, use 'oc status --suggest' to see details.

Reading it: line 1 is the project and API server. Then one block per app: the Route URL ((redirects) = edge TLS with HTTP redirected to HTTPS, 30.15) pointing at svc/web; the Deployment it feeds, which deploys the ImageStreamTag web:latest (<- = an image change trigger, 30.18); the BuildConfig that builds that tag from a repository on a Node.js builder image; and "deployment #3 ... 2 pods" (third rollout, healthy). legacy has no Route and is stuck at 0/2 pods. The last line counts the problems.

--suggest expands the errors. For a crash-looping image it prints the famous advice to grant anyuid - read it as "this image needs root" and fix the image (30.9).

oc get all is not all

$ oc get all

It looks like it lists everything in the project. It does not: all is a category (a group name some resource types sign up to): pods, services, deployments, replicasets, statefulsets, daemonsets, jobs, cronjobs, and on OpenShift also routes, buildconfigs, builds, imagestreams and deploymentconfigs. It never includes ConfigMaps, Secrets, PVCs, RoleBindings, NetworkPolicies, ServiceAccounts or operator CRs. When you clean up or copy a project, list those explicitly: oc get cm,secret,pvc,rolebinding,networkpolicy,sa.

Templates

Before Helm (25.19) and operators, OpenShift packaged apps as Templates (template.openshift.io): a list of objects with ${PARAMETER} placeholders.

The three commands below: list the templates the cluster ships (in the openshift namespace); render a template file, filling two parameters with -p NAME=value, and pipe the YAML into oc apply -f - (- = read stdin, 1.7); or let oc new-app do both in one step from a template already on the cluster.

$ oc get templates -n openshift | head -3
$ oc process -f postgres-template.yaml -p DATABASE_NAME=orders -p VOLUME_CAPACITY=5Gi | oc apply -f -
$ oc new-app --template=postgresql-persistent -p POSTGRESQL_DATABASE=orders

oc process renders a template to plain YAML (a poor man's helm template). You will find them in older projects and in the openshift namespace; new work uses Helm charts or operators. (simulator) Templates and oc process are not in the lab.

The console

Every cluster has a web console (oc whoami --show-console). Worth knowing its Developer perspective (topology view of your project, build logs, a pod terminal) and Administrator perspective (OperatorHub, cluster settings and upgrades, the Observe > Alerting and Metrics pages backed by the built-in Prometheus). Anything you click creates the same objects you would write as YAML - the YAML tab on every page shows them, which is a good way to learn the fields. Treat the console as a viewer and keep changes in Git.

Monitoring you get for free

openshift-monitoring runs Prometheus (27.2), Alertmanager (28.7), the node exporter and Thanos Querier (a front end that queries several Prometheus servers as one) for the platform. User workload monitoring (enabled by an admin in the cluster-monitoring-config ConfigMap) lets your ServiceMonitors (27.4) in your projects be scraped by a second Prometheus in openshift-user-workload-monitoring, and the console's Observe pages query both. Chapters 27-29's PromQL works there unchanged.

What to practise on a real cluster

The lab covers the behaviour; a real cluster adds the scale and the console. On the free Developer Sandbox (a project on a shared cluster - no admin rights) you can do:

1. oc login with the console's Copy login command, oc whoami -t, oc projects.
2. Deploy nginx:1.27 and watch it crash-loop; read the logs; redeploy nginxinc/nginx-unprivileged on 8080. See openshift.io/scc: restricted-v2 and your UID.
3. oc new-app nodejs~https://github.com/sclorg/nodejs-ex.git, follow the build, expose it, curl it, oc start-build again and watch the trigger.
4. Routes: edge with Redirect, a path route, a Route with a 503 you caused on purpose.
5. Read-only: oc get csv in your namespace (operators installed cluster-wide show up as copied CSVs), oc get clusterversion (often allowed read-only).

At work, ask for a project on the non-production cluster and repeat 2-4 there; then read the platform team's project template (oc get project <yours> -o yaml, oc get quota,limits)

• the ResourceQuota and LimitRange of 17.9 - and their SCC and Route policies: those are

the local rules this chapter's defaults get tightened with.

What you can now do

• Translate any kubectl habit into its oc form, and know which commands exist only on OpenShift (new-project, new-app, expose, rsh, policy, adm upgrade).
• Read oc status top to bottom, and list what oc get all leaves out.
• Recognise a Template and oc process in an older project.