Posted on

Silly Kubectl Trick #6: Label It to Enable It

The building block of almost all Kubernetes deployments is the pod – 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.

However, we rarely create pods ourselves. Instead, we rely on higher level constructs like ReplicaSets and Deployments to create them for us.

Posted on

Silly Kubectl Trick #5: Waiting for Kubernetes

When you deploy stuff for a living, you find yourself waiting around, a lot.  Wait for Terraform to spin up the AWS VPCs.  Wait for the Kubernetes cluster node VMs to boot.  Wait for the Kubernetes cluster to coalesce.  Wait for the CNI pods, DNS pods, and kube-proxy bits to be happy.  Wait, wait, wait.

kubectl feels your pain there, and has some nifty ways of helping you wait (or not!) for the things you deploy or delete to coalesce.

Posted on

Silly Kubectl Trick #2: LIST RUNNING IMAGES

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 use Alpine Linux anywhere? What versions of MySQL are we currently running (and where)? The standard output of kubectl get pods doesn't help to answer any of these questions.

That's okay, though, because we have the custom-columns output format!