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

So, what is a namespace? Think of it as a virtual cluster living inside your actual Kubernetes cluster. Instead of one big shared space where all your workloads, configs, and resources sit together, namespaces let you carve things up into isolated sections. Each section can have its own access controls, its own resource limits, and its own set of rules. It’s a clean way to separate concerns — especially when you’re running multiple environments on the same cluster.

Let’s talk about how NZRT uses namespaces specifically. There are six you need to know about. First is nzrt-prod, which is your production environment. This one is locked down — only xc and dan have access, so treat it with care. Then there’s nzrt-staging, which mirrors the production config and is used for pre-production testing and UAT work. Below that sits nzrt-dev, a more relaxed space for development and experimentation — resource limits are looser here, so you’ve got room to move.

Beyond those three environment namespaces, there are a few infrastructure ones. The monitoring namespace is home to the shared observability stack — that’s Prometheus, Grafana, and Loki all running together. Then there’s ingress-nginx, which handles the Nginx ingress controller for the whole cluster. And finally, kube-system — this is where Kubernetes puts its own system components. Leave this one alone. Don’t modify it.

Now, Kubernetes also comes with a set of default namespaces out of the box. The one simply called default catches any resource that doesn’t have a namespace explicitly assigned to it. Kube-system, as mentioned, is for the core Kubernetes internals. Kube-public is readable by everyone in the cluster and holds general cluster information. And kube-node-lease is used internally for node heartbeat tracking — you won’t need to touch that one directly either.

Let’s walk through some of the common commands you’ll use day to day. If you want to see all the namespaces currently in your cluster, you run a get namespaces command with kubectl. To create a new namespace — say, nzrt-staging — you use kubectl create namespace followed by the name. If you want to see all pods running across every namespace at once, you pass the all-namespaces flag to a get pods command. To narrow it down to just one namespace, like nzrt-prod, you use the n flag followed by the namespace name. And if you want to set a default namespace for your current context so you don’t have to type it every time, there’s a config set-context command where you pass the current flag and then specify the namespace you want to default to.

Now let’s look at resource quotas, because this is where namespaces really earn their keep in a shared cluster. A resource quota is a Kubernetes object that caps how much compute a namespace can consume. In the example for nzrt-prod, the quota is named nzrt-prod-quota and it’s scoped to the nzrt-prod namespace. It sets a minimum CPU request of four cores, a minimum memory request of four gigabytes, a maximum CPU limit of eight cores, a maximum memory limit of eight gigabytes, and a hard cap of twenty pods running at any one time. This means no matter what gets deployed into production, it can never exceed those boundaries — which protects the rest of the cluster from being starved of resources by a runaway workload.

If you want to go deeper on access control within namespaces, check out the RBAC wiki page, which covers role-based access policies. And for the broader picture of how all of this fits together, the NZRT Kubernetes Architecture page is your next stop.

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