Welcome to the NZRT Wiki Podcast. Today we’re looking at kubectl Cheatsheet.

This episode is your quick-reference guide for daily kubectl usage in the NZRT cluster. Whether you’re just getting started or need a fast reminder of the commands you reach for most often, we’re going to walk through everything section by section.

Let’s start with context and namespace. Before you do anything else in kubectl, you need to make sure you’re talking to the right cluster and working in the right namespace. There’s a command that lists all the contexts you have configured, so you can see what’s available. Then there’s a command to switch to a specific context by name. Finally, you can pin your current context to a specific namespace — in NZRT’s case, that’s the nzrt-prod namespace — so you don’t have to type it out every single time. Getting these three things right at the start saves you a lot of headaches later.

Next up is getting resources. Once you’re in the right context, you’ll want to see what’s running. You can pull a combined view of your pods, services, deployments, and ingresses all in one go, scoped to nzrt-prod. If you want everything in that namespace, there’s a command that literally gets all resources at once. You can also go wider and get everything across all namespaces in the cluster. And if you want to see your nodes with extra detail like IP addresses and which zone they’re in, there’s a wide-output option for that too.

Now let’s talk about inspecting things more deeply. This is where you go when something looks off. You can describe a specific pod by name, which gives you a detailed breakdown of its current state, events, and configuration — really useful for diagnosing problems. You can also stream the live logs from a pod, which is handy when you’re watching something in real time. If you need to actually get inside a running container and poke around, there’s an interactive shell command that drops you straight into a shell session inside the pod. And if you need to hit a service locally without exposing it externally, port forwarding lets you map a local port on your machine to a port on the service.

Moving on to applying and deleting resources. The bread and butter of day-to-day Kubernetes work. You can apply a manifest file to create or update resources defined in it. The same file can be used to delete those resources cleanly. And if you need to force-delete a pod immediately without waiting for a graceful shutdown, there’s a variant of the delete command that skips the grace period entirely — useful when a pod is stuck terminating.

Now for scaling and updating deployments. If you need to scale a deployment up or down, you specify the deployment name and the number of replicas you want, and Kubernetes handles the rest. Updating the container image inside a deployment is just as straightforward — you name the deployment, the container, and the new image with its tag. After triggering a rollout, you can watch its progress with the rollout status command, which tells you when it’s done or if something went wrong. And if the new version causes problems, there’s a rollout undo command that takes you straight back to the previous version with a single command. That one’s a lifesaver.

Let’s cover debugging next, because things do go wrong. The events command gives you a chronological list of what’s been happening in the namespace, sorted by the most recent timestamp — great for piecing together what just broke and when. You can also check resource consumption with the top commands, which show you CPU and memory usage for pods and nodes respectively. If you’re unsure whether your current permissions allow a certain action, there’s a command to check whether you’re allowed to do something like create pods in a namespace. And finally, you can spin up a temporary debug pod running a minimal image, drop into a shell, do your troubleshooting, and have it automatically cleaned up when you exit. That one’s great for checking network connectivity or DNS from inside the cluster.

The last section is about output formatting. Sometimes you need the raw data in a specific format. You can get the full YAML definition of any pod, which is useful when you want to see exactly how it’s configured or copy it as a base for a new manifest. You can also extract a specific field — like just the pod’s IP address — using a path expression that navigates the JSON structure. If you want to see which labels are attached to your pods, there’s a flag that adds a labels column to the output. And you can filter pods by label too, so for example you could list only the pods belonging to the WordPress app.

That covers the full kubectl cheatsheet for the NZRT cluster. Context first, then inspect, apply, scale, debug, and format your output. Keep these patterns in mind and you’ll move through cluster work quickly and confidently.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.