The building block of almost all Kubernetes deployments is – one or more containers sharing a network stack. Pods are where the magic happens, where we get our logs, and where we spend most of our time troubleshooting outages and malfunctions. the pod However, we rarely create pods ourselves. Instead, we rely on higher level constructs like ReplicaSets and Deployments to create them for us. Unfortunately, ReplicaSets (and by extension, Deployments) are just awful at naming pods. $ kubectl pods
NAME                           READY   STATUS    RESTARTS   AGE
admin-ui d87999cdf rdj / Running s
admin-ui d87999cdf pl64 / Running s
admin-ui d87999cdf n2rq / Running s
app-server d84f8 hkcc / Running s
app-server d84f8 kwxp / Running s
app-server d84f8 l5k / Running s
app-server d84f8-dhfq7 / Running s
app-server d84f8-q5x6m / Running s
app-server d84f8-t4t4r / Running s
app-server d84f8-tlk54 / Running s
db b649cbc68-vt9qh / Running s
db b649cbc68-zgz5p / Running s
redis-cache 54c47d4c rknd / Running s
redis-cache 54c47d4c mq7d / Running s
redis-cache 54c47d4c-crqfp / Running s
redis-cache 54c47d4c-xxdzq / Running s get -6 -27 1 1 0 43 -6 -4 1 1 0 43 -6 -8 1 1 0 43 -66487 -6 2 2 0 42 -66487 -6 2 2 0 42 -66487 -9f 2 2 0 42 -66487 2 2 0 42 -66487 2 2 0 42 -66487 2 2 0 42 -66487 2 2 0 42 -6 1 1 0 43 -6 1 1 0 43 -6f -4 1 1 0 44 -6f -9 1 1 0 44 -6f 1 1 0 44 -6f 1 1 0 44 Horrendous. This wouldn't matter too much if we never had to reference a pod by name. But that's exactly what we have to give for any command involving a pod, or one of its containers. If we want to review logs, execute arbitrary commands inside the container, or even see how the pod is doing, we're going to be constantly running and copying / pasting those names around. kubectl kubectl get pods ( : you can find a on the GitHub repository that accompanies this blog series, if you want to play along at home.) Note Kubernetes resource spec Unless we use labels! Labels are key+value pairs that we, as operators, get to assign to the things we deploy on Kubernetes. Here's how we specify pod labels in a Deployment definition: --- apiVersion: apps/v1 kind: Deployment spec: template: metadata: labels: env: prod role: frontend app: redis-cache service: redis-cache While labels used internally by other parts of Kubernetes (like Deployments, Services, and the like), we can also benefit from them with the command and its flag. Combine that with some data extraction, and we can do some pretty amazing things: are kubectl get -l $ kubectl -l =frontend -o custom- = :.metadata.name app- d84f8 hkcc
app- d84f8 kwxp
app- d84f8 fl5k
app- d84f8-dhfq7
app- d84f8-q5x6m
app- d84f8-t4t4r
app- d84f8-tlk54
redis- f54c47d4c rknd
redis- f54c47d4c mq7d
redis- f54c47d4c-crqfp
redis- f54c47d4c-xxdzq
app- d84f8
redis- f54c47d4c get all role columns NAME NAME server -66487 -6 server -66487 -6 server -66487 -9 server -66487 server -66487 server -66487 server -66487 cache -6 -4 cache -6 -9 cache -6 cache -6 server -66487 cache -6 The definitions that we're using define some labels that we can use to filter our queries: demo.yml - We set this to either prod (stuff that goes down and makes our lives unbearable) or admin (stuff that goes down and makes our lives ). env inconvenient - This is mostly a unique-per-deployment label that we use for selectors to wire up the Deployment object through its ReplicaSet to its constituent Pods. app - Like , we use this label to identify the pods that make up a named service, for wiring up Service definitions. service app - In a front-end / back-end paradigm, which does this piece belong to? role end Armed with these semantics, we can run some neat sub-queries against our Pods: Q: How is prod doing today? $ kubectl pod -l env=prod -o wide
NAME                           READY   STATUS    RESTARTS   AGE
app-server d84f8 hkcc / Running m54s
app-server d84f8 kwxp / Running m54s
app-server d84f8 l5k / Running m54s
app-server d84f8-dhfq7 / Running m54s
app-server d84f8-q5x6m / Running m54s
app-server d84f8-t4t4r / Running m54s
app-server d84f8-tlk54 / Running m54s
db b649cbc68-vt9qh / Running m55s
db b649cbc68-zgz5p / Running m55s
redis-cache 54c47d4c rknd / Running m56s
redis-cache 54c47d4c mq7d / Running m56s
redis-cache 54c47d4c-crqfp / Running m56s
redis-cache 54c47d4c-xxdzq / Running m56s get -66487 -6 2 2 0 8 -66487 -6 2 2 0 8 -66487 -9f 2 2 0 8 -66487 2 2 0 8 -66487 2 2 0 8 -66487 2 2 0 8 -66487 2 2 0 8 -6 1 1 0 8 -6 1 1 0 8 -6f -4 1 1 0 8 -6f -9 1 1 0 8 -6f 1 1 0 8 -6f 1 1 0 8 Q: What images are we running on the backend? Note: This one uses the image.fmt output format from Silly Kubectl Trick #2 . $ kubectl pod -l role=backend -o custom-columns-file=../trick2/images.fmt
NAMESPACE   NAME                        IMAGE
trick6      admin-ui d87999cdf rdj   nginx
trick6      admin-ui d87999cdf pl64   nginx
trick6      admin-ui d87999cdf n2rq   nginx
trick6      db b649cbc68-vt9qh         mariadb
trick6      db b649cbc68-zgz5p         mariadb get -6 -27 -6 -4 -6 -8 -6 -6 Using subshell expansion in Bash and Zsh, we can combine these calls with other commands that deal with individual pods: $ kubectl describe $ kubectl logs $( ) kubectl get pods ... $( ) kubectl get pods ... Powerful, but a little less convenient than I would like. On my machine, I put the common prefix command from the above subshells into a small script in my , called : $PATH kid $ kubectl describe $ kubectl logs $( ) kubectl get pods ... $( ) kubectl get pods ... That shortens my and calls to just: describe logs $ kubectl describe $ kubectl logs $( - ) kid pod l ... $( - ) kid pod l ... This also works for other resource objects, like Volumes, Services, etc. $ kubectl describe $( - = ) kid volume l env prod You can do more than just look. For example, if the admin-ui from our sample deployment is off in the weeds, and we want to delete / recreate all of the pods: $ kubectl delete $( - = ) kid pod l env admin Just remember: with great power, comes great responsibility. Previously published at https://starkandwayne.com/blog/silly-kubectl-trick-6-label-it-to-enable-it/

Kubernetes Tutorial: Merge all the Kubeconfigs! [Part 7]

Kubernetes Explained Simply: Waiting For Kubernetes [Part 5]

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Kubernetes Explained Simply: Label it to Enable it [Part 6]

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Kubernetes Explained Simply: #1 Kubectl Hack

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

Kubernetes Explained Simply: #1 Kubectl Hack

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps