Welcome to the NZRT Wiki Podcast. Today we’re looking at Cluster Overview.

This episode covers the day-to-day management of the NZRT Kubernetes cluster — how you access it, how you check on its health, and how you handle common maintenance tasks. Whether you’re new to the cluster or just need a quick refresher, this should give you a solid grounding.

Let’s start with cluster access. Before you can do anything useful, you need to know which cluster you’re talking to. Kubernetes uses something called contexts to keep track of this. Think of a context as a saved profile — it knows which cluster, which user, and which namespace you want to work with.

To see all the contexts you have available, you run a command that lists them out for you. Once you know the name of the context you want, you can switch to it with a single command — you just tell kubectl, which is the main Kubernetes command-line tool, to use that context by name. If you want to double-check which context is currently active, there’s a command for that too — it simply prints the name of the one you’re on right now.

One more handy access tip: you can set a default namespace so you don’t have to keep specifying it on every command. For NZRT’s setup, the main production namespace is called nzrt-prod, and you can lock your current context to that namespace with a config command. After that, any kubectl command you run will automatically target nzrt-prod unless you say otherwise.

Now let’s talk about health checks, because knowing whether your cluster is actually healthy is one of the most important things you’ll do as an operator.

First, you’ll want to check on your nodes. Nodes are the machines that actually run your workloads — think of them as the physical or virtual servers underneath Kubernetes. A quick command gives you a summary list of all nodes and whether they’re in a ready state. If you need more detail on a specific node — things like resource capacity, conditions, and recent events — you can describe that node by name to get a full breakdown.

Next, you can check the health of the core Kubernetes components themselves, like the scheduler and the controller manager. There’s a command that queries the component statuses and gives you a simple healthy or unhealthy result for each one.

If you want a broad picture of everything running across all namespaces at once, there’s a command that pulls all resources cluster-wide — pods, services, deployments, the works. This is great for a quick sanity check.

And when something seems off, events are your best friend. Kubernetes logs events whenever something notable happens — a pod fails to schedule, a container crashes, a resource limit is hit. You can pull the events from nzrt-prod sorted by the most recent timestamp, which means the freshest and most relevant information floats to the top.

Moving on to cluster info. There are three quick commands worth knowing here. The first gives you a summary of where the key cluster endpoints are running — your API server, your DNS service. The second tells you the version of both the kubectl client and the server-side Kubernetes API, which matters a lot when you’re thinking about upgrades or compatibility. The third lists all the API resource types your cluster supports — handy when you’re trying to figure out what kinds of objects you can create or query.

Now let’s go through the common management tasks. There are five main ones you’ll reach for regularly.

First is draining a node. When you need to take a node offline for maintenance — maybe to patch the operating system or swap out hardware — you drain it first. Draining safely evicts all the pods running on that node and marks it as unschedulable, so nothing new lands on it while you’re working. You use a flag to tell Kubernetes to ignore daemonsets, which are special system pods that run on every node and don’t need to be moved.

Second is uncordoning a node. Once your maintenance is done and the node is back in service, you uncordon it. This removes the unschedulable mark and lets the scheduler start placing pods on it again.

Third is cordoning a node. This is like a softer version of draining — it marks the node unschedulable so no new pods get assigned to it, but it doesn’t touch the pods that are already running there. Useful if you want to quietly wind down a node over time.

Fourth and fifth are resource monitoring commands. You can check the live CPU and memory usage of pods in nzrt-prod, or check the same metrics at the node level across the whole cluster. These are invaluable for spotting which workloads are running hot or which nodes are under pressure before things become a problem.

That covers the essentials of your cluster day-to-day — getting in, checking the health, pulling the right info, and handling maintenance safely. If you want to go deeper, the related wiki pages on Nodes, the kubectl Reference, and the NZRT Kubernetes Architecture are great next steps.

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