I have a messy notes file full of kubectl one-liners I’ve collected over the years. Some of them I use weekly, others saved me in the middle of an incident at 2am. These are the commands I actually reach for — not the tutorial basics, but the ones that make working with Kubernetes faster on a daily basis.

Context and Access

Before doing anything, I need to know where I am. When you manage multiple clusters (production, staging, homelab), running a command against the wrong one is a real risk.

Check your current context:

kubectl config current-context

I run this almost reflexively before any destructive operation. It takes half a second and has saved me from mistakes more than once.

Get a quick summary of your current context:

kubectl config view --minify

This shows only the active context — the cluster, user, and namespace you’re pointed at right now. Way more readable than the full kubeconfig dump.

Change your default namespace:

kubectl config set-context --current --namespace=monitoring

I use this constantly. Instead of adding -n monitoring to every single command, just set the default for your session. When I’m deep in debugging something in a specific namespace, this saves a lot of typing.

Check what permissions you have:

kubectl auth can-i --list

This one is essential when you’re working in a cluster you didn’t set up. Maybe you’re onboarding, or you’ve been given a service account with limited RBAC. This tells you exactly what you can and can’t do. I’ve also used it to verify that RBAC policies I wrote are actually working correctly.

Watching and Inspecting

Watch pods in real time:

watch -n 1 kubectl get pods -n default

During a rollout or when something is crashing, I keep this running in a terminal. The 1-second refresh gives you a near-real-time view of pod status without flooding your terminal with repeated commands.

List all container images running in the cluster:

kubectl get pods --all-namespaces \
  -o jsonpath="{.items[*].spec.containers[*].image}" | \
  tr -s '[[:space:]]' '\n' | \
  sort | \
  uniq -c

This one is gold. I use it for security audits, checking for outdated images, or just getting a bird’s-eye view of what’s actually running across all namespaces. The uniq -c at the end gives you a count per image, so you can quickly spot if something unexpected is deployed or if an old version is still hanging around.

Generating Manifests

Writing YAML from scratch is slow and error-prone. I almost never do it anymore — I let kubectl generate the boilerplate for me.

Generate a pod manifest:

kubectl run postgres-test --image=postgres:13.2 \
  --dry-run=client -o yaml > /tmp/pod.yaml

Generate a deployment manifest:

kubectl create deploy my-app --image=nginx \
  --dry-run=client -o yaml > deploy.yaml

The --dry-run=client -o yaml combo is one of the most useful patterns in kubectl. It creates a valid manifest without actually sending anything to the cluster. I pipe it to a file, tweak what I need, and apply it. This is also incredibly useful during CKA/CKAD exams if you’re going that route — it saves a ton of time when you can’t afford to write YAML from memory under pressure.

Working with Secrets

Secrets in Kubernetes are base64-encoded, not encrypted. Decoding them from the command line is something I do regularly when debugging.

Decode a specific key from a secret:

kubectl get secret postgres-secret \
  -o jsonpath="{.data.superUserPassword}" | base64 --decode

The jsonpath expression lets you pull out exactly the key you need without dumping the entire secret. I use this when debugging connection issues — “is the password in the secret actually what I think it is?” Nine times out of ten, it’s a mismatch somewhere.

Create secrets using stringData:

When creating secrets in manifests, you don’t have to base64-encode values yourself. Use stringData instead of data:

apiVersion: v1
kind: Secret
metadata:
  name: my-app-secret
type: Opaque
stringData:
  APP_SLACK_WEBHOOK: "https://hooks.slack.com/..."
  DB_PASSWORD: "my-password"

Kubernetes handles the encoding for you on apply. I always use stringData in my local manifests because it’s readable and less error-prone than manually encoding things. Just be careful not to commit plain-text secrets to Git — use something like Sealed Secrets or SOPS to encrypt them before they hit the repo.

Jobs and CronJobs

Trigger a CronJob manually:

kubectl create job --from=cronjob/my-backup-job manual-backup-run -n databases

This is the command I always forget the syntax for and always need. When a CronJob fails or you need to test it outside its schedule, this creates a one-off Job from the CronJob’s spec. You give it a custom name so it’s easy to find in logs and clean up later. Way better than editing the CronJob’s schedule to trigger it sooner.

Exec into a Pod

Get a shell in a running container:

kubectl -n data exec -it postgres-database-0 -- sh

Nothing fancy here, but the details matter. The -it gives you an interactive terminal, and the -- separates kubectl arguments from the command you want to run inside the container. I reach for sh instead of bash because most Alpine-based images don’t have bash installed, and sh works everywhere.

Wrapping Up

None of these commands are particularly complicated on their own. The real value is in having them ready when you need them — building muscle memory for the one-liners that save you 30 seconds, fifty times a day. That adds up fast.

I keep a running list in my notes and update it whenever I find a new trick worth remembering. If you have kubectl commands you reach for daily that I didn’t cover here, I’d genuinely like to hear about them.