Been using Kubernetes for a while now and I keep a running list of kubectl commands that actually save time day-to-day. This is that list. No theoretical stuff, just things I find myself reaching for constantly on 1.5/1.6 clusters.
The alias you need immediately
alias k='kubectl'
alias kgp='kubectl get pods'
alias kgs='kubectl get services'
alias kgd='kubectl get deployments'
alias kns='kubectl config set-context $(kubectl config current-context) --namespace'
kns staging to switch namespaces without typing the whole thing every time. Put these in your .bashrc or .zshrc and never look back.
Getting into a pod
The Kubernetes equivalent of SSHing into a box:
$ kubectl exec -it my-pod-7d9f8b6c4-xkv2p -- /bin/bash
If there are multiple containers in the pod, specify which one:
$ kubectl exec -it my-pod-7d9f8b6c4-xkv2p -c sidecar-container -- /bin/sh
Use /bin/sh if the image doesn't have bash (Alpine-based images, for example).
Following logs
$ kubectl logs -f my-pod-7d9f8b6c4-xkv2p
Multi-container pod:
$ kubectl logs -f my-pod-7d9f8b6c4-xkv2p -c app-container
Follow logs for all pods matching a label selector — this one is really useful during deployments:
$ kubectl logs -f -l app=my-service
Port forwarding
Forward a pod's port to localhost without exposing anything publicly. Useful for hitting a service directly for debugging:
$ kubectl port-forward my-pod-7d9f8b6c4-xkv2p 8080:80
Forwarding from 127.0.0.1:8080 -> 80
You can also forward to a service:
$ kubectl port-forward svc/my-service 5432:5432
Then connect to localhost:5432 from your local machine. Way cleaner than temporarily editing a service type to LoadBalancer.
describe is your friend
When something's broken, describe gives you the full picture including events at the bottom:
$ kubectl describe pod my-pod-7d9f8b6c4-xkv2p
The Events section at the bottom of the output is usually where the actual error message lives. "ImagePullBackOff", "CrashLoopBackOff", failed volume mounts — it's all there.
$ kubectl describe node my-node-name
Check node capacity, allocatable resources, and which pods are running on it.
Get everything in a namespace
$ kubectl get all -n staging
Shows pods, services, deployments, replica sets, the works. Good for a quick sanity check.
Switching contexts
If you manage multiple clusters:
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* production prod-cluster prod-admin default
staging stg-cluster stg-admin default
$ kubectl config use-context staging
Switched to context "staging".
I have a function in my shell config for this:
kctx() {
kubectl config use-context "$1"
}
JSONPath output
-o json dumps everything, which is great for piping to jq. But if you just want one field, JSONPath is faster:
$ kubectl get pods -o jsonpath='{.items[*].metadata.name}'
my-pod-7d9f8b6c4-xkv2p my-pod-7d9f8b6c4-abc12
$ kubectl get pod my-pod-7d9f8b6c4-xkv2p -o jsonpath='{.status.podIP}'
10.0.1.45
Get the image currently running in a deployment:
$ kubectl get deployment my-service -o jsonpath='{.spec.template.spec.containers[0].image}'
my-registry/my-service:v1.2.3
Copying files to/from pods
# Copy from pod to local
$ kubectl cp my-pod-7d9f8b6c4-xkv2p:/app/logs/error.log ./error.log
# Copy from local to pod
$ kubectl cp ./config.json my-pod-7d9f8b6c4-xkv2p:/app/config.json
Useful for grabbing log files or dropping in a config for testing. Don't do this in production as a substitute for proper config management, obviously.
Watching resources
Add -w to watch a resource update in real time:
$ kubectl get pods -w
NAME READY STATUS RESTARTS AGE
my-pod-7d9f8b6c4-xkv2p 1/1 Running 0 5m
my-pod-7d9f8b6c4-newpd 0/1 ContainerCreating 0 3s
my-pod-7d9f8b6c4-newpd 1/1 Running 0 12s
my-pod-7d9f8b6c4-xkv2p 1/1 Terminating 0 5m
This is how I watch rolling deployments. Much better than mashing kubectl get pods repeatedly.
Quick rollout status and rollback
$ kubectl rollout status deployment/my-service
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "my-service" successfully rolled out
$ kubectl rollout undo deployment/my-service
The undo command rolls back to the previous revision. Saved me more than once after a bad deploy.
These probably cover 90% of what I do on any given day. The kubectl docs are decent once you know what you're looking for — the hard part is knowing what to look for.