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

This wiki covers how NZRT configures and manages its Kubernetes cluster — from the initial namespace setup right through to workload deployment conventions. Let’s walk through it together.

First, a quick look at the cluster details. The provider, Kubernetes version, and node count are all still to be confirmed — they’ll be updated once the cluster is provisioned. What we do know is that if a cloud provider is used, the cluster will be hosted in New Zealand. And when it comes to access, the kubeconfig file — which is the credential file that lets you connect to the cluster — is stored securely in the Nextcloud vault under the 000NCL section.

Next up is namespace setup. In Kubernetes, namespaces let you divide a single cluster into logical sections, keeping different environments and concerns separated. NZRT sets up five namespaces when bringing a cluster online. You create one called nzrt-prod for production workloads, one called nzrt-staging for staging, and one called nzrt-dev for development. Then you add a monitoring namespace for observability tools, and finally an ingress-nginx namespace for the ingress controller. These five namespaces form the foundation of every NZRT cluster.

Now let’s talk about standard labels. Every resource you deploy in the NZRT cluster should carry a consistent set of labels. These labels are key-value pairs attached to Kubernetes objects that help you identify, filter, and manage resources at scale. The label set NZRT uses has five fields. First is app, which you set to the name of your application. Second is environment, which should be prod, staging, or dev depending on where the workload lives. Third is owner, which is always set to nzrt. Fourth is service-code, which carries the value 000K8S. And fifth is managed-by, which tells you whether the resource was deployed using Helm or kubectl directly. Applying these labels consistently across everything you deploy makes cluster management much easier down the line.

Moving on to ingress setup. NZRT uses nginx as its ingress controller — this is the component that routes external HTTP and HTTPS traffic into your cluster services. To install it, you first add the ingress-nginx Helm repository, then use Helm to install the chart into the ingress-nginx namespace. That one Helm command handles the full installation, and if the namespace doesn’t already exist, it creates it automatically.

After ingress, you’ll want to set up cert-manager. This is what handles automatic TLS certificate provisioning for your services — so your apps get HTTPS without you having to manually manage certificates. You install cert-manager by applying a single manifest directly from the cert-manager GitHub releases page. Once that’s done, you configure a ClusterIssuer resource. Think of a ClusterIssuer as a cluster-wide object that tells cert-manager where and how to request certificates. NZRT’s ClusterIssuer is named letsencrypt-prod and it points to the Let’s Encrypt production certificate authority. It uses the ACME protocol with an HTTP challenge — meaning Let’s Encrypt verifies domain ownership by making an HTTP request through your nginx ingress. The contact email registered with Let’s Encrypt for NZRT is nzrtnetwork at gmail dot com, and the private key generated during that registration is stored in a Kubernetes secret also named letsencrypt-prod.

Finally, let’s run through the NZRT workload checklist. Before you consider any workload ready for deployment, there are eight things you need to confirm. One — your namespace has been created and a ResourceQuota is in place to prevent any single namespace from consuming too many cluster resources. Two — RBAC roles have been applied, meaning the right permissions are granted to the right service accounts. Three — any secrets your app needs have been created directly in the cluster and are not committed to a Git repository. Four — liveness and readiness probes are configured so Kubernetes knows when your app is healthy and when it is ready to serve traffic. Five — resource requests and limits are set on your containers so the scheduler can place them correctly and prevent resource starvation. Six — your ingress is configured with TLS so traffic to your service is encrypted. Seven — if your workload needs persistent storage, that has been provisioned, typically using StatefulSets. And eight — your CI/CD pipeline in GitHub Actions is configured and connected to the cluster.

If you want to go deeper, the related pages to check out are the NZRT K8s Architecture doc and the GitHub vault under 000GIT for CI/CD pipeline details.

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