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.

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

If you’re working with the NZRT Kubernetes cluster, kubectl is your main command-line tool. It’s how you talk to the cluster — listing what’s running, checking logs, deploying changes, and fixing problems. This episode walks you through the key commands grouped by what you’re trying to do.

Let’s start with getting and listing resources. This is probably the first thing you do when you sit down to check on the cluster. You can list pods, deployments, services, ingresses, config maps, secrets, persistent volume claims, and nodes — all within the nzrt-prod namespace. There’s also a shortcut to get everything in that namespace in one go, or if you need a full picture, you can pull everything across all namespaces at once. Think of these commands as your dashboard — a quick way to see what’s alive and what’s there.

Once you spot something you want to know more about, you move into the describe commands. Describing a resource gives you the detailed view — events, conditions, configuration specifics. You can describe a pod by name, a deployment, a node, or a service. This is especially useful when something isn’t behaving as expected and you need to dig past the surface-level status.

Next up is logs. When something goes wrong, logs are usually your first port of call. The basic version pulls logs from a named pod in nzrt-prod. If your pod is running multiple containers, you can specify which container you want logs from. If you want to watch logs live as they come in, there’s a follow mode — it streams new output to your terminal in real time, similar to tailing a file. And if a pod has already crashed, there’s a flag to pull the logs from the previous run, which is invaluable for diagnosing what went wrong before a restart.

Now for applying and deleting resources. When you have a manifest file — that’s a YAML file describing your Kubernetes resources — you can apply it to the cluster. Kubernetes will create or update whatever the file describes. You can also point at an entire directory of manifest files and apply them all at once. On the flip side, you can delete resources using the same manifest file, or delete a specific pod or deployment by name directly. Be careful with deletes — there’s no confirmation prompt, so make sure you know what you’re targeting.

The exec and port-forward commands are your tools for getting hands-on with a running pod. Exec lets you open an interactive shell session directly inside a container — either a basic shell or bash, depending on what the container has available. This is handy for inspecting files, running quick diagnostics, or testing connectivity from inside the cluster. Port-forward is different — it creates a tunnel from your local machine into the cluster. So if you specify local port 8080 mapping to port 80 on a pod or service, you can open your browser and hit that service directly from your laptop without exposing it externally. Really useful for testing.

Rollouts are how you manage deployments over time. You can check the status of a rollout to see if a deployment is progressing or stuck. You can view the rollout history to see previous versions. If something goes wrong after a deploy, you can undo it — this rolls the deployment back to its previous state. And if you want to update which container image a deployment is running, you can set that directly by specifying the deployment name, the container name, and the new image and tag.

Finally, output formats. By default kubectl gives you a summarised table view, but sometimes you need more. You can output a pod’s full configuration as YAML or JSON — useful if you want to inspect every field or save a copy. The wide output format adds extra columns to the default table, like which node a pod is running on. And you can show labels on your pods, which is helpful when you’re working with selectors or trying to understand how services are routing traffic.

That covers the full kubectl reference for NZRT cluster management. If you want to go deeper, the related wiki pages on the kubectl Cheatsheet and Cluster Overview are good next reads.

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

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

So, what is a node? In a Kubernetes cluster, a node is essentially a worker machine. Think of the cluster as a factory, and nodes are the individual workstations where the actual work gets done. Every node runs three key pieces of software to make that happen.

The first is the kubelet. This is an agent that sits on the node and keeps in constant communication with the Kubernetes API server. Its main job is managing the lifecycle of pods — making sure the right containers are running, healthy, and doing what they’re supposed to be doing.

The second component is kube-proxy. This one handles networking. It maintains the rules that allow network traffic to flow correctly to your services — so when something inside the cluster needs to talk to something else, kube-proxy makes sure that traffic lands in the right place.

The third component is the container runtime. For most setups you’ll see at NZRT, that’s containerd. This is what actually pulls and runs your containers at the low level.

Now, how do you check on your nodes? There are a few commands worth knowing. The first lets you list all nodes in your cluster — you get a quick overview of their names and current status. If you want more detail, you can run a wider version of that command, which also shows you IP addresses and operating system information. And if you really need to dig into a specific node — say you’re troubleshooting or checking recent events — you can describe that node by name and get a full breakdown of everything happening on it.

When you look at node status, you’ll see what are called conditions. There are five to be aware of. Ready is the one you want to see — it means the node is healthy and able to accept new pods. If you see MemoryPressure, the node is running low on memory. DiskPressure means disk space is getting tight. PIDPressure tells you there are too many processes running on that node. And NetworkUnavailable means the network isn’t configured correctly on that node. Any condition other than Ready being active is worth investigating.

The last area covered in this doc is labels and taints — two ways you can control how pods get scheduled onto nodes.

Labels are straightforward. You can tag a node with a key-value pair — for example, marking a node as belonging to a production environment. Once a node has a label, you can use that label in your pod configurations to tell Kubernetes where you want things to run.

Taints are a bit more powerful. When you taint a node, you’re essentially putting up a sign that says “pods can’t schedule here unless they explicitly say they’re okay with this.” You set a taint with a key, a value, and an effect. The effect used in this example is NoSchedule, which means Kubernetes will not place any new pods onto that node unless those pods have a matching toleration defined. This is useful for reserving nodes for specific workloads — for example, keeping a node dedicated to production traffic.

And when you’re done with a taint and want to remove it, you run the same command but add a minus sign at the end to strip it off.

So to recap — nodes are your worker machines, made up of the kubelet, kube-proxy, and a container runtime. You can inspect them with a handful of commands, watch their conditions to catch health issues early, and use labels and taints to control exactly what runs where.

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