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.