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

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/