Running Kubernetes in production means taking inventory. A LOT. Are any of our pods running that version of Ubuntu base image affected by the new CVE? Do we even Alpine Linux anywhere? What versions of MySQL are we currently running (and where)? The standard output of doesn't help to answer of these questions. use kubectl get pods any That's okay, though, because we have the output format! custom-columns $ kubectl pods -A -o \
  custom- =NAMESPACE:metadata.namespace, :metadata.name

NAMESPACE fail          fail f678c66-dn282
interactive   interactive dbc7d9-ch9bd
kube- calico-kube-controllers-dc6cb64cb-pfhqr
kube- calico-node-nk854
kube- coredns d7b6d9 g
kube- coredns d7b6d9-zccn5
kube- csi-linode-controller kube- csi-linode-node qgt
kube- kube-proxy-xxpvf get columns NAME NAME -856 -797 system system system -5644 -9776 system -5644 system -0 system -82 system Whew! That's a fingerful to type. If you'd like, you can put the details of the format in a file, and reference that file via the output format: custom-columns-file $ cat pods.fmt
NAMESPACE metadata.namespace   metadata.name

$ kubectl pods -A -o custom- -file=pods.fmt
NAMESPACE fail          fail f678c66-dn282
interactive   interactive dbc7d9-ch9bd
kube- calico-kube-controllers-dc6cb64cb-pfhqr
kube- calico-node-nk854
kube- coredns d7b6d9 g
kube- coredns d7b6d9-zccn5
kube- csi-linode-controller kube- csi-linode-node qgt
kube- kube-proxy-xxpvf NAME get columns NAME -856 -797 system system system -5644 -9776 system -5644 system -0 system -82 system Doing so allows you to swap out selectors, like namespace and label filters, while re-using the same format (and not having to retype it!) -l We can do so much more than just list off names and namespaces. We can go so far as to list out the images in use by the first container of each pod: $ cat images.fmt
NAMESPACE            NAME           IMAGE
metadata. metadata.name  spec.containers[ ].image

$ kubectl pods -A -o custom-columns-file=images.fmt
NAMESPACE     NAME                                      IMAGE
fail          fail 678c66-dn282                     huntprod/run eractive eractive dbc7d9-ch9bd               huntprod/run
kube-system   calico-kube-controllers-dc6cb64cb-pfhqr   calico/kube-controllers:v3 kube-system   calico-node-nk854                         calico/node:v3 kube-system   coredns d7b6d9 g                  k8s.gcr.io/coredns: kube-system   coredns d7b6d9-zccn5                  k8s.gcr.io/coredns: kube-system   csi-linode-controller quay.io/k8scsi/csi-provisioner:v1 kube-system   csi-linode-node qgt                     quay.io/k8scsi/driver-registrar:v1 -canary
kube-system   kube-proxy-xxpvf                          k8s.gcr.io/kube-proxy:v1 namespace 0 get -856f int int -797 .9 .2 .9 .2 -5644 -9776 1.6 .2 -5644 1.6 .2 -0 .0 .0 -82 .0 .16 .3 Now we're talkin'! Keep in mind that the tag reported is whatever was in the pod – if it is missing, you can assume , but that doesn't tell you much about the actual version . If you want anything more specific out of Kubernetes, you'll need to use the object, instead of . spec :latest in use status spec $ cat versions.fmt
NAMESPACE            NAME           IMAGE
metadata.namespace   metadata.name  status.containerStatuses[ ].imageID

$ kubectl get pods -A -o custom-columns-file=versions.fmt
NAMESPACE     NAME                                      IMAGE
fail          fail f -dn docker-pullable://huntprod/run : d debb a fcc cd eb f fb d b fbbe fd ad a d
interactive   interactive dbc d -ch bd               docker-pullable://huntprod/run : d debb a fcc cd eb f fb d b fbbe fd ad a d
kube-system   calico-kube-controllers-dc cb cb-pfhqr   docker-pullable://calico/kube-controllers : d a cec f a b ffc f fd db dd kube-system   calico-node-nk docker-pullable://calico/node :ffbe b b f d f ce fc cdba f ae cae kube-system   coredns d b d g                  docker-pullable://k s.gcr.io/coredns : eb b b b a ecf bc fd b be ee kube-system   coredns d b d -zccn docker-pullable://k s.gcr.io/coredns : eb b b b a ecf bc fd b be ee kube-system   csi-linode-controller docker-pullable://quay.io/k scsi/csi-attacher :e bb abf d f d bdb ee ffe d a fb f afab a kube-system   csi-linode-node qgt                     docker-pullable://linode/linode-blockstorage-csi-driver : a fea f f d ff f bac fb f ee eaadb ee
kube-system   kube-proxy-xxpvf                          docker-pullable://k s.gcr.io/kube-proxy : bbee eb da fdfa adec f f b b f 0 -856 678 c 66 282 @sha256 1 8 90 76 434 5452e61 9 55 71 82 8 2 54 423e17 996 -797 7 9 9 @sha256 1 8 90 76 434 5452e61 9 55 71 82 8 2 54 423e17 996 6 64 @sha256 5 525 6 c 6 7 1e9 2 35723 63223 9 067619 cc 1 209339792927 02 854 @sha256 7 00344065007154 81 50 0 3960 35 790 0 c 2e2 0 60e08 2 -5644 7 6 9 -9776 8 @sha256 12 885 8685 1 13 04 5 c 23 809 c 2e57917252 7 0 9e9 c 00644e8 5 -5644 7 6 9 5 8 @sha256 12 885 8685 1 13 04 5 c 23 809 c 2e57917252 7 0 9e9 c 00644e8 5 -0 8 @sha256 57 6 0 78e638 70 38 07 30 42 423 14 2 910 c 11 3 5e01 -82 @sha256 6 466 4 597 274 646839 1 40363e6 c 5 5871 2 4e23 0 56 8 @sha256 6 c 09387 4e58 923695 4 3 c 37 632862e79 419 0 5 16865 34 Kubernetes tracks the raw SHA256 checksum of each image it executes, in , and the resolved image name and its tag in . We use those two, above, to get a more complete picture of our running image inventory. status.containerStatuses[n].imageID .image So far we've been using the -th index, which limits us to the container in any multi-container pods. We could instead use , and will separate multiple values with commas. This gets unwieldy fast, especially with the fields, but it is there when you need it. [0] first [*] kubectl imageID : Since we know that the only instance of a comma in our output will be to separate multiple image IDs, we can use (a POSIX utility) to reformat the table to ease readability: Pro Tip column $ kubectl pods -A -o \ | \
    column -t -s,
POD                                       IMAGE
fail 678c66-dn282                     huntprod/run eractive dbc7d9-ch9bd               huntprod/run
calico-kube-controllers-dc6cb64cb-pfhqr   calico/kube-controllers:v3 calico-node-nk854                         calico/node:v3 coredns d7b6d9 g                  k8s.gcr.io/coredns: coredns d7b6d9-zccn5                  k8s.gcr.io/coredns: csi-linode-controller quay.io/k8scsi/csi-provisioner:v1 quay.io/k8scsi/csi-attacher:v1 linode/linode-blockstorage-csi-driver:v0 csi-linode-node qgt                     quay.io/k8scsi/driver-registrar:v1 -canary  linode/linode-blockstorage-csi-driver:v0 kube-proxy-xxpvf                          k8s.gcr.io/kube-proxy:v1 get 'custom-columns=POD:metadata.name,IMAGE:spec.containers[*].image' -856f int -797 .9 .2 .9 .2 -5644 -9776 1.6 .2 -5644 1.6 .2 -0 .0 .0 .0 .0 .1 .3 -82 .0 .1 .3 .16 .3 It's also important to note that our above formats completely ignore any and all containers, in case those are important to you. init If you like that, check out this video adaptation, wherein I go a bit more in-depth, and touch on some stuff you can do with holding all your sweet, sweet custom output formats. files Previously published at https://starkandwayne.com/blog/silly-kubectl-trick-2-listing-images/

Too Long; Didn't Read

Making security fun one episode at a time

Kubernetes Explained Simply: #2 Kubectl Hack (List Running Images)

Too Long; Didn't Read

James Hunt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Kubernetes Explained Simply: #2 Kubectl Hack (List Running Images)

Too Long; Didn't Read

James Hunt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES