Cloud-Native Microservices With Kubernetes - 2nd Edition

Namespaces: Pitfalls and Best Practices

How many clusters do you have right now in the context of our learning project? Just one? In reality, you have more than one. Kubernetes allows you to create multiple virtual clusters within a single physical cluster. These virtual clusters are called Namespaces.

Think of Namespaces as folders on your computer. Just as you can create different folders to organize your files, you can create different Namespaces to organize your workloads and resources in a Kubernetes cluster. Is there a recommended way to use Namespaces? It depends, just like there's no one-size-fits-all way to organize files on your computer. Everyone has their own way of organizing things. However, good sense suggests that you can use some core patterns, including:

• Per-environment split: prod, staging, dev.
• Team or domain namespaces: team-ml, team-payments, for multi-tenant clusters.
• App-scoped namespaces (prod): prod-orders, prod-billing (one app per namespace to tighten policies).
• App-scoped namespaces (non-prod): dev-orders, staging-orders (multiple apps per namespace to save resources).
• Per-customer namespaces: customer-a, customer-b (for SaaS platforms and consulting companies).
• Per-project namespaces: project-x, project-y (for temporary projects or demos).
• Special-purpose namespaces: kube-system, kube-public (these are reserved by Kubernetes).