Category Archives: 00 – Overview

00 - Overview, 000K8S

Kubernetes Overview

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

So, what exactly is Kubernetes? You might have seen it written as K8s, which is just a shorthand where the eight stands for the eight letters between the K and the s. At its core, Kubernetes is an open-source platform for container orchestration. That’s a fancy way of saying it automates the deployment, scaling, and management of containerised applications. Rather than you manually keeping track of which containers are running where, Kubernetes handles all of that on your behalf.

The way it works is by grouping containers into units called Pods, and then managing those pods across a cluster of machines called Nodes. Let’s talk about what Kubernetes actually does for you. First, it handles scheduling, which means it decides which pod gets placed on which node based on available resources. Second, it takes care of self-healing. If a container crashes or a node stops responding, Kubernetes automatically restarts or replaces it without you having to intervene. Third, it supports scaling. If your application suddenly needs to handle more traffic, Kubernetes can automatically spin up more instances based on things like CPU or memory usage. Fourth, it supports rolling updates, meaning you can push a new version of your application with zero downtime. Fifth, it provides service discovery, using internal DNS and load balancing so your services can find each other. And sixth, it manages secrets, storing sensitive information like passwords and API keys in encrypted storage.

Now let’s talk about how Kubernetes is actually structured. The architecture has two main sides: the Control Plane and the Worker Nodes.

The Control Plane is the brain of the operation. It contains four key components. The first is the API server, which is the central REST endpoint that every Kubernetes operation goes through. Think of it as the front door to the entire cluster. The second is etcd, which is a distributed key-value store that holds the entire state of your cluster. If Kubernetes needs to know what’s running and where, it looks here. The third is the scheduler, which is responsible for deciding where new pods should run based on what resources are available across your nodes. The fourth is the controller manager, which runs a collection of controllers that handle things like deployments, node management, and network endpoints, making sure the actual state of the cluster matches what you’ve asked for.

On the other side, you have the Worker Nodes. These are the machines where your actual application containers run. Each worker node has three components. The kubelet is an agent that sits on the node and makes sure the containers assigned to it are actually running properly. The kube-proxy manages the network rules on each node so that traffic gets routed correctly to the right services. And finally there’s the container runtime, which is the software that actually runs your containers, things like containerd or Docker.

So when you ask Kubernetes to run your application, your request goes through the API server, the scheduler figures out the best node for it, the controller manager keeps an eye on it, and the kubelet on the chosen node makes sure the container stays up and running.

Now, Kubernetes uses a set of objects to represent everything in your cluster. There are eight key ones worth knowing. A Pod is the smallest deployable unit and can contain one or more containers that share the same network and storage. A Deployment manages groups of pods and handles things like rolling updates and maintaining a certain number of running replicas. A Service gives you a stable network endpoint for a set of pods, so even if individual pods come and go, traffic can still reach your application reliably. An Ingress lets you define HTTP and HTTPS routing rules for traffic coming into the cluster from outside. A ConfigMap lets you store non-sensitive configuration data separately from your application code. A Secret is similar but designed for sensitive data like passwords, tokens, and keys. A Namespace gives you a way to create virtual clusters within your physical cluster, which is useful for separating teams, environments, or projects. And finally, a PersistentVolume represents a storage resource at the cluster level, so your data can survive beyond the life of any individual pod.

Together these objects give you a powerful, declarative way to describe exactly how your applications should run, and Kubernetes takes care of making that reality happen and keeping it that way.

If you want to go deeper, the NZRT wiki has a page on the specific cluster design used here at NZRT, a page on core concepts covering pods, deployments, services, and namespaces in more detail, and a kubectl cheatsheet with the most common commands you’ll reach for day to day.

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

00 - Overview, 000K8S

Nzrt K8S Architecture

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

So what is this page all about? It covers NZRT’s specific approach to running Kubernetes — that’s the container orchestration platform you might have heard of — including how the cluster is designed, how workloads are organised, and how deployments are automated.

Let’s start with the cluster overview. The platform itself is still being decided, and the version and node count will be confirmed once the cluster is actually provisioned. What is already locked in is the container runtime — NZRT will be using containerd, which is one of the most widely adopted and production-proven runtimes in the Kubernetes ecosystem.

Next, let’s talk about the namespace strategy. If you’re new to Kubernetes, namespaces are logical partitions inside the cluster — a way to separate different environments and concerns so they don’t interfere with each other. NZRT has five namespaces planned. The first is nzrt-prod, which is where all production workloads live. Then there’s nzrt-staging, the pre-production environment — also called UAT, or User Acceptance Testing — where things get validated before going live. After that you have nzrt-dev, the space for development and active testing work. Then there’s a namespace called monitoring, which hosts the observability stack — specifically Prometheus for metrics collection and Grafana for dashboards and visualisation, along with the logging stack. And finally there’s ingress-nginx, which runs the ingress controller — that’s the component responsible for routing external web traffic into the right services inside the cluster.

Now let’s look at workload placement — which specific services run where, and how they’re configured. There are four services mapped out so far. WordPress runs in the production namespace as a Deployment, and it connects to an external MySQL database rather than one running inside the cluster itself. Dolibarr, which is NZRT’s ERP and CRM platform, also runs in the production namespace as a Deployment. Nextcloud, the file and collaboration platform, runs in production as a StatefulSet. If you’re wondering what the difference is, StatefulSets are used when a workload needs stable storage that persists across restarts — which Nextcloud definitely requires. And finally, there’s a planned blockchain node for future use — also a StatefulSet in production — which will connect to the Base network once it’s brought online.

Now let’s cover the CI/CD integration. That stands for Continuous Integration and Continuous Deployment, and it’s the automated pipeline that takes your code changes and gets them running in the cluster without manual steps in between. The diagram in the documentation shows a flow that starts at GitHub, where all code repositories live under the NZRT source control setup. From there, a GitHub Actions workflow kicks in automatically. That workflow does two things: first it builds a Docker container image and pushes it to a container registry, and then it applies the updated configuration to the Kubernetes cluster — either directly or through a tool called Helm, which is a package manager for Kubernetes that simplifies managing complex deployments. The end result is a rolling deployment, meaning the update rolls out gradually so there’s zero downtime — your users stay connected while the new version comes up in the background.

The documentation also points to a few related resources if you want to go deeper. There’s a general Kubernetes Overview page, the Infrastructure Vault under the code 000INF, and the GitHub Vault under 000GIT.

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