Namespaces

Some namespaces in Kubernetes are immortal, they can never be deleted.

Most production systems implement custom immortal namespaces to protect critical workloads from accidental deletion and to guarantee cluster stability under operational errors.

Thus, each Kubernetes practitioner should be aware of why they exist and how to custom implement their own immortal namespaces for critical services. Before that, for someone who doesn’t know..

What a Namespace is?

In Kubernetes, a namespace is like a virtual cluster inside your actual cluster. It helps you:

Organize resources (Pods, Deployments, Services).

Avoid name collisions.

Apply access controls (RBAC, network policies).

Delegate cluster usage to multiple teams.

Think of it as a folder structure inside Kubernetes.

Types of Namespaces

1. System (Immortal) Namespaces

Kubernetes creates these by default in every cluster:

default: Where resources land if you don’t specify a namespace.

kube-system: Runs cluster components (DNS, CNI, controllers).

kube-public: Holds a public cluster-info ConfigMap, readable by anyone in the cluster.

kube-node-lease: Stores node lease objects for faster node heartbeat and failure detection.

So in a fresh cluster you always see at least these four:

Key Point

These are standard across all Kubernetes clusters (EKS, AKS, GKE, bare-metal, minikube, kind).

They are considered “immortal namespaces” because Kubernetes will not allow you to delete them.

2. User Created Namespaces

Useful for isolating environments or teams.

Example: dev, prod, logging, ingress-nginx

Platform Services like Monitoring, logging, ingress controllers should live in “immortal” namespaces.

If someone deletes these accidentally, you lose visibility or routing. Making them immortal prevents that.

How to Implement Immortal Namespaces

When a user attempts to delete a namespace, the request first passes through the admission webhook (like Kyverno or OPA).

Typically Kubernetes admins define custom policies that specify which namespaces should be protected.

The webhook checks the incoming request against the policy database.

If the target namespace is marked immortal, the request is denied and the namespace stays protected.

For non protected namespaces, the deletion is allowed and resources are removed.

This ensures only the namespaces you explicitly allow can ever be deleted, while critical ones remain immortal.

You can block the namespace deletion either by:

1. Kyverno Policy

Key Takeaways

Kubernetes ships with four standard immortal namespaces:

default, kube-system, kube-public, kube-node-lease.

They are undeletable to ensure cluster stability.

You can mark your own critical namespaces (monitoring, logging, ingress) as immortal.

Enforce protection using Kyverno or OPA Gatekeeper.

I hope this was an insightful edition. See you in the next edition on Tuesday.

Take care and have a nice weekend.