Tag Archives: kubernetes

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.

000K8S, 08 - NZRT Config

Nzrt Kubernetes Setup

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.