The other day I came across this post about bash. If you are a pro bash user, you may already know all these tricks, but if you are a newbie or not such a pro user, it is very likely that the post made your day.
I thought it would be useful to create something similar for the oc command. The oc command is dope, everyone should know that. It’s well designed, consistent, flexible, and, as you will see, there are many hidden features worth trying.
If you are an OpenShift pro, you may already know most of what I’ll reveal here; otherwise, if you are just starting to work with OpenShift, or you are not an experienced user, this is gonna save you some precious time and pain.
1. First things first: debugging
When I don't know what is going on or I get an unfriendly error message, I always use the flag --loglevel
. It writes log level info to the stderr. Depending on the loglevel, you will get curl API Rest calls, API Rest body answers, or even more detailed info.
$ oc --loglevel 7 get pod
...
I0216 21:24:12.027793 973 cached_discovery.go:72] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/v1/serverresources.json
I0216 21:24:12.028046 973 round_trippers.go:383] GET https://192.168.42.77:8443/api/v1/namespaces/myproject/pods
I0216 21:24:12.028052 973 round_trippers.go:390] Request Headers:
I0216 21:24:12.028057 973 round_trippers.go:393] Accept: application/json
I0216 21:24:12.028061 973 round_trippers.go:393] User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff
I0216 21:24:12.053230 973 round_trippers.go:408] Response Status: 200 OK in 25 milliseconds
I0216 21:24:12.055143 973 cached_discovery.go:119] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/servergroups.json
I0216 21:24:12.055228 973 cached_discovery.go:72] returning cached discovery info from /home/jtudelag/.kube/192.168.42.77_8443/authentication.k8s.io/v1/serverresources.json
I0216 21:24:12.055288 973 cached_discovery.go:72]
...
loglevel 9 is pretty handy if you want to patch an OCP object, as it shows the patch (API request body) you would need to apply.
Let's say you want to change the label of a service object, in this case, the label "app: hello-jorge".
$ oc --loglevel 9 edit svc hello-openshift
...
I0216 21:33:15.786463 1389 request.go:994] Request Body: {"metadata":{"labels":{"app":"hello-jorge"}}}
I0216 21:33:15.786590 1389 round_trippers.go:386] curl -k -v -XPATCH -H "Accept: application/json" -H "Content-Type: application/strategic-merge-patch+json" -H "User-Agent: oc/v1.7.6+a08f5eeb62 (linux/amd64) kubernetes/c84beff" https://192.168.42.77:8443/api/v1/namespaces/myproject/services/hello-openshift
I0216 21:33:15.797185 1389 round_trippers.go:405] PATCH https://192.168.42.77:8443/api/v1/namespaces/myproject/services/hello-openshift 200 OK in 10 milliseconds
...
Note: In moments of despair you can always add as many 9s as you want, the result would be the same as just one 9, but you might feel relieved.
$ oc --loglevel 9999 get pod
2. su -
Yes, you are reading right. You can substitute the user who is running the oc command, or in OCP jargon, you can impersonate a user. If you have enough permissions to impersonate, obviously. You only need to use the flag --as
.
For example:
# run the command as jorge user
$ oc --as=jorge get pods
Also, a group impersonation can be done, instead of a user impersonation:
# run the command as the developers group
$ oc --as-group=developers get pods
It’s very handy and quick in many situations, for example, to check if a user can perform a specific action or to check the output a user would receive when running oc. It’s also useful when messing with roles and permissions.
3. Whoami ?
oc whoami
is widely known, especially the -t
flag used to get the bearer token of your current user/session. But what happens when you have a token and you don't who is the owner?
One thing you can do is log into OpenShift with the token, and then do an oc whoami
...but wait a second. oc whoami
gives you this information! Just pass the token in the command line as the 3rd arg, no flags needed.
Give it a try:
# save the token
$ token=$(oc whoami -t)
# get the owner of the token
$ oc whoami $token
jorge
4. oc debug
You can run a pod and get a shell. Sometimes it's useful to get an exact copy of a running pod configuration and troubleshoot it with a shell. This is the default behaviour.
Have a look at the oc debug
options, you can run the container as root, or any other user id, force it to run in a specific node or run a command different to a shell.
You have to run the command against a valid dc, for example:
# get a shell inside a pod for dc/jorge
$ oc debug dc/jorge
# same but as root user
$ oc debug --as-root=true dc/jorge
5. oc explain
OpenShift/k8s objects are sometimes complex, with many fields. Many times I end up looking for object definition examples in OCP docs or other sources. You can consider oc explain
the source of truth when it comes to OCP/k8s object definitions.
oc explain
gives you the documentation of a resource and its fields. It’s incredibly useful when declaring new OCP objects, or when you just don’t have access to the official OCP docs.
For example, you can get pod documentation and pod spec affinity field description:
# get pod explanation
$ oc explain pod
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.FIELDS:
metadata <Object>
Standard object's metadata. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#metadataspec <Object>
Specification of the desired behavior of the pod. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-statusstatus <Object>
Most recently observed status of the pod. This data may not be up to date.
Populated by the system. Read-only. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-statusapiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#resourceskind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#types-kinds# get pod spec affinity field
$ oc explain pod.spec.affinity
RESOURCE: affinity <Object>DESCRIPTION:
If specified, the pod's scheduling constraintsAffinity is a group of affinity scheduling rules.
FIELDS:
nodeAffinity <Object>
Describes node affinity scheduling rules for the pod.podAffinity <Object>
Describes pod affinity scheduling rules (e.g. co-locate this pod in the
same node, zone, etc. as some other pod(s)).
podAntiAffinity <Object>
Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod
in the same node, zone, etc. as some other pod(s)).
6. Forget about grep, awk, cut, etc.
One really cool thing about oc command is that it has built-in features to format the output. We all know about -o json
or -o yaml
, but the -o
flag gives you many other possibilities.
From all of these output options I find go-template
and jsonpath
the most powerful:
json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...
For example, let's say you want to get the service that is being exposed by a specific route (docker registry route):
# get the service being exposed by a route, only if the hostname matches my-docker-registry.example.com
$ oc get routes -o=go-template='{{range .items}}{{if eq .spec.host "my-docker-registry.example.com"}}{{.metadata.name}}{{end}}{{end}}'
docker-registry
Or that you want to know the deployment strategy for the router dc:
# get router deployment strategy
$ oc get dc router -o=go-template='{{ .spec.strategy.type }}'
Rolling
As you can see, the oc command is awesome. I encourage you to keep playing with it, because is one of the coolest things about OpenShift.
Author
Jorge Tudela Gonzalez de Riancho works for Red Hat Spain as a Cloud Consultant specialising in OpenShift and container-related technologies.
Über den Autor
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit