Category Archives: 09 – Reference

000K8S, 09 - Reference

Helm Reference

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

So, what is Helm? Put simply, Helm is the package manager for Kubernetes. If you’ve used something like npm for Node or pip for Python, Helm plays a similar role — but for Kubernetes applications. It takes all the Kubernetes manifest files your application needs and bundles them into a single versioned, configurable unit called a chart. That makes it much easier to deploy, upgrade, and manage complex applications on your cluster.

Before we jump into commands, let’s cover four core concepts you’ll hear come up again and again. First, there’s the chart itself — that’s the package containing all your Kubernetes manifest templates. Second is a release, which is what you get when you actually run a chart in a cluster — it’s the live, running instance. Third is a repository, which is just a collection of published charts you can browse and pull from, kind of like a package registry. And fourth are values — these are the configuration overrides you supply to customise how a chart behaves when it’s deployed. Those four — chart, release, repository, values — are the building blocks of everything Helm does.

Now let’s walk through the common commands you’ll use day to day. The first thing you typically do is add a repository and update it. Think of this as registering a source so Helm knows where to find charts. Once you’ve added a repo, you can search it to find specific charts by name.

When you’re ready to deploy something, you use the install command. You give your release a name, point it at the chart you want from your repo, tell it which namespace to deploy into, and optionally tell Helm to create that namespace if it doesn’t already exist. You can also pass in a values file at this point to customise the deployment.

Once something is running, you’ll eventually want to update it — that’s where the upgrade command comes in. The syntax is very similar to install: you reference the release name, the chart, the namespace, and your values file. Helm handles rolling out the changes.

To see what’s currently deployed, you use the list command. You can scope it to a specific namespace, or ask Helm to show releases across all namespaces at once.

When you need to remove something, uninstall does the job — just give it the release name and namespace and Helm tears it all down cleanly.

One of the most useful features Helm offers is rollback. If an upgrade goes wrong, you can roll back to a previous revision — just reference the release name and the revision number you want to return to. To find out what revision numbers are available, the history command shows you a full list of past deployments for any given release.

Finally, there’s the template command. This is a dry-run tool that renders all the Kubernetes manifests Helm would generate — but doesn’t actually apply them to the cluster. It’s incredibly useful for debugging or reviewing exactly what Helm is going to do before you commit to it.

Now let’s talk about the values file, because this is where a lot of the real configuration lives. A typical values file is written in YAML and covers several key areas. You set a replica count — for example, two — to control how many instances of your application run. You define your image settings: the repository to pull from, the specific tag or version you want, and the pull policy, such as only pulling if the image isn’t already present locally. You configure your service — specifying the type, like ClusterIP for internal-only access, and the port it listens on. And you set resource constraints, which is important for cluster stability. On the requests side you declare the minimum CPU and memory your container needs to start. On the limits side you set the ceiling — the maximum it’s allowed to consume. CPU is expressed in millicores, so one hundred m is a tenth of a CPU core, and memory is in mebibytes.

Together, these values give you fine-grained control over your deployment without ever touching the chart templates themselves. You just override what you need, and Helm does the rest.

If you want to go deeper on the cluster side of things, check out the related wiki pages on kubectl and the NZRT Kubernetes Setup — both will give you context that pairs well with what you’ve just heard.

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

000K8S, 09 - Reference

Kubectl Cheatsheet

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.