kubectlkubectl$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64d9f4f776-9fzp8   3/3     Running   0          14s
frontend-64d9f4f776-flx58   3/3     Running   0          15s
frontend-64d9f4f776-lftdc   3/3     Running   0          15s
frontend-64d9f4f776-mrhq6   3/3     Running   0          15sAh yes, I see the pod is now called "... FIXME ..."
In my experience, the very next command that I run  needs that auto-generated Pod ID, something like 
kubectl logskubectl execCmd-CThis is UNIX, right?  World-famous for its text processing capabilities?  We got this covered.
$ kubectl get pods
$ kubectl get pods | awk '{print $1}'
$ kubectl get pods | awk '{print $1}' | grep -v ^NAMEWell, it does work, even if it is a bit awkward, and a lot to type.
kubectl-ojq$ kubectl get pods -o json | \
      jq -r '.items[0].metadata.name'
frontend-64d9f4f776-9fzp8What happens if we don't have 
jqkubectlkubectlIt's called JSON Path, and it essentially lets you embed simple 
jqkubectl$ kubectl get pods -o jsonpath='{.items[0].metadata.name}'
frontend-64d9f4f776-9fzp8(Just remember to enclose the variable reference in balanced curly braces.)
JSON Path has its fair share of fanciness, including filters.  For example, if you have a pod with lots of constituent containers, you can extract information about a subset like this:
$ kubectl get pods -o jsonpath='{.items[0].spec.containers[?(@.image == "redis")].name}'
kv-store
session-cacheHere we're identifying which containers in our pod are running the upstream 
redisAlso published here.
