We have spent the whole module writing rutas-norte-dev in every manifest and every command without stopping to explain what that namespace actually is or what it gives us. And at the end of the previous lesson a very interesting property turned up: bookings-api's configuration points at redis-cache and bookings-postgres by their short names, without mentioning the environment, because DNS resolves them within the namespace the pod runs in. That property is what makes it possible to deploy the same manifest three times and get three independent platforms. In this lesson we set up Rutas Norte's three environments —rutas-norte-dev, rutas-norte-pre and rutas-norte-pro—, we will see what a namespace isolates and what it does not isolate at all (the part that causes the most incidents), we will tell namespaced resources apart from cluster-scoped ones, we will meet the system namespaces and why nothing is deployed to default, we will work comfortably with -n and with the context, we will resolve DNS names across namespaces, and we will finish with a very serious warning about what a kubectl delete namespace takes down with it.

1. What a namespace is and what it isolates
2. Namespaced and cluster-scoped resources
3. The system namespaces and why nothing is deployed to default
4. The three Rutas Norte environments
5. The same manifest in several environments
6. Working with namespaces without going mad
7. DNS across namespaces
8. What a namespace does NOT guarantee
9. Deleting a namespace: the most dangerous kubectl command
10. Namespaces versus separate clusters

A namespace is a logical partition of the cluster that groups resources. The operational definition, the one that really helps:

A namespace is, above all, a name space: inside it, every object's name must be unique; outside it, names can repeat freely.

That allows three objects called bookings-api to exist at the same time, one per environment, without colliding. And every other use follows from there.

What a namespace does provide:

And what it does not provide, which we will look at in detail in section 8: it does not isolate the network, it does not limit resources on its own, it does not prevent access and it does not separate the nodes.

Note the key detail of the diagram: objects with the same name coexist in different namespaces, but the nodes are shared. A pod from rutas-norte-dev and one from rutas-norte-pre can end up on the same machine.

Not every Kubernetes object lives inside a namespace. Some belong to the whole cluster, and confusing the two produces baffling errors.

The way to know for certain, without memorising anything:

The logic behind the split is coherent: anything representing physical infrastructure or global cluster configuration carries no namespace; anything representing a workload or application configuration does.

Two pairs deserve attention because they are a constant source of confusion:

• PersistentVolume (cluster-scoped) versus PersistentVolumeClaim (namespaced). The disk is a cluster resource; the claim on that disk belongs to a specific application in a namespace. Module 5.
• Role/RoleBinding (namespaced) versus ClusterRole/ClusterRoleBinding (cluster-scoped). The former grant permissions within a namespace; the latter, across the whole cluster. Module 8.

A practical mistake that follows from this:

The -n has been silently ignored. Nodes have no namespace, so the flag filters nothing. It is not an error, but it can make you believe you are seeing something filtered when you are not.

Every cluster is born with four namespaces:

Take a look at kube-system to see the cluster from the inside:

There they are, running as pods, all the components you studied in Kubernetes Architecture. Your minikube's control plane is visible and tangible.

kube-node-lease explains something you may have wondered about: how the control plane knows whether a node is still alive.

The kubelet renews that object every few seconds. If it stops doing so, the node is marked NotReady.

It is the namespace Kubernetes uses when you say nothing, and that is precisely why it is a bad place to work:

1. It is the cluster's dumping ground. Everything anybody applies without -n ends up there. Within a few months it is a junk drawer where nobody knows what belongs to whom.
2. It cannot be deleted. The system namespaces are indestructible, so you cannot clear it out in one go the way you would with rutas-norte-dev.
3. Accidents are easy. A kubectl delete deploy --all without -n, run in the belief you were somewhere else, takes down whatever is in default.
4. It makes isolation impossible. If everything is in default, you cannot apply per-team quotas, per-environment RBAC or differentiated network policies.
5. It prevents reusing names. With everything in one namespace, the development and production bookings-api cannot coexist.

The project rule is explicit:

At Rutas Norte, default is forbidden. Every object lives in a named namespace, declared in its own manifest.

The time has come to create the full structure. You already know rutas-norte-dev from module 1; we add preproduction and production, declaratively and in a single file.

In YAML, --- separates several documents within the same file. It is the usual way of grouping related objects:

Note two deliberate decisions:

• The namespaces carry labels. This is not decorative: in module 4, NetworkPolicies will select namespaces by the environment label, so a policy will be able to say "I only accept traffic from pods in the same environment".
• Production carries informative annotations. Anyone running kubectl describe ns rutas-norte-pro will know who to notify and what rules apply.

The repository structure we already defined fits naturally:

How base and environments are combined without duplicating YAML is the job of Kustomize or Helm, in 10-04 and 10-03. In this module we will do it as simply as possible.

Here is the property that makes namespaces valuable. We are going to deploy web-store and its Service to preproduction using exactly the same files as in development.

Our manifests carry namespace: rutas-norte-dev written inside them, so there are two ways of taking them to another environment.

Option A: remove namespace from the manifest and decide it at apply time.

Option B: keep namespace in the manifest and substitute it at deploy time. This is what Kustomize or Helm will do for you; by hand it would look like this:

There is an important rule worth knowing: if a manifest declares metadata.namespace and you also pass -n with a different value, kubectl errors out instead of choosing on its own.

It is desirable behaviour: it prevents deploying to production by accident.

Let's do it with option B, which respects our current manifests:

Now look at the cluster's full situation:

Two complete Rutas Norte platforms, with the same Deployment and Service names, coexisting without the slightest collision. That is the namespace's core value.

And a check that illustrates the name isolation:

Same name, two different objects, two different virtual IPs.

Typing -n rutas-norte-dev a hundred times a day is tedious and, worse, forgetting it is the fast track to an accident.

-A is indispensable when you are looking for something and cannot remember where it is:

This is the option that saves the most time. It modifies your kubeconfig so that every command uses that namespace by default:

And the check that should become a reflex before any destructive command:

A highly recommended tip: configure your terminal prompt to show the context and the namespace. Tools such as kube-ps1 do it, and seeing (rutas-norte:rutas-norte-pro) on screen before typing delete has saved many an afternoon.

Part of the kubectx suite, kubens switches namespace interactively:

It is syntactic sugar over kubectl config set-context, but with an interactive listing and a quick jump back. It is installed as a standalone binary or through krew, the kubectl plugin manager we saw in The Kubernetes CLI.

Go back to development before moving on:

You already know a Service's full name: <service>.<namespace>.svc.cluster.local. Namespaces are the reason that structure exists.

When a pod resolves a name, the cluster DNS tries a series of search suffixes in order. Look at them in a real pod:

The first line explains the whole behaviour: when looking up redis-cache, the pod tries redis-cache.rutas-norte-dev.svc.cluster.local first. Since it exists, that is where it stops. A short name always resolves within its own namespace.

Check it:

There is good news and bad news here. The good: the same bookings-api manifest, with DATABASE_HOST: bookings-postgres, works in all three environments and each one talks to its own database, with no conditionals and no templating.

The bad, and it matters: a development pod has just resolved and could connect to a preproduction Service. Nothing stops it. That takes us straight to the next section.

This is the section that prevents incidents. The belief that "each team in its namespace and they are therefore isolated" is dangerously false.

By default, any pod in any namespace can connect to any pod or Service in any other namespace. Kubernetes' flat network model is explicit about this: every pod can see every other pod.

An uncomfortable demonstration: a development pod writing to the preproduction cache.

We have just set the available seats in the preproduction cache to zero from development. Had it been rutas-norte-pro, it would be a serious incident. And nobody needed special permissions: knowing the name was enough.

The solution is not the namespace, it is the NetworkPolicies of 04-06, which do let you declare rules of the kind "bookings-postgres only accepts connections from pods labelled app=bookings-api in the same namespace".

Creating a namespace does not restrict who can do what inside it. If your credentials have broad permissions over the cluster, you have them over every namespace, existing and future.

With an administrator user, the answer is yes for any namespace. Permission isolation comes from the Role and RoleBinding objects of RBAC. The namespace is only the scope those rules apply to: necessary, but not sufficient.

A namespace imposes no ceiling. A badly configured Deployment in rutas-norte-dev can consume all the cluster's CPU and memory and starve the pods in rutas-norte-pro, because they share the same nodes.

Those two final lines say it all: no quota and no limits. Setting them is the subject of Resource Quotas and Limits and LimitRanges and QoS.

Pods from every namespace are spread over the same nodes. A development pod and a production pod can be neighbours on the same machine, sharing CPU, memory and disk.

Separating workloads by node requires taints, tolerations and affinity (06-05).

The sentence that sums up the section: a namespace is the scope the isolation mechanisms apply to, not the isolation mechanism. Without quotas, RBAC and network policies on top, a namespace is just a folder.

That command deletes everything inside it: Deployments, ReplicaSets, Pods, Services, ConfigMaps, Secrets, PersistentVolumeClaims, ServiceAccounts, Roles... And with the PVCs go, depending on the reclaim policy, the data.

Traits that make it especially dangerous:

• It asks for no confirmation. None.
• There is no undo. There is no bin and no kubectl undelete.
• It is asynchronous. The namespace goes into Terminating while the contents are deleted, and in that state it accepts no new objects.
• A typo is catastrophic. rutas-norte-pro instead of rutas-norte-pre is three characters apart.

See it in action, with a throwaway namespace:

The pod went with it, without asking anything.

A problem you will hit sooner or later: a namespace that stays in Terminating indefinitely. The cause is almost always a finalizer —those hooks we studied in Objects and Manifests— that cannot complete, typically one belonging to an extended API whose server no longer exists.

Before forcing anything, work out which resource is blocking it, because ripping the finalizer out leaves orphaned objects in etcd. The correct approach is to remove the offending resource or restore the service that is supposed to process it.

1. Label and annotate production, as we did in namespaces.yaml: describing the namespace shows the notice.
2. Restrictive RBAC: nobody has delete namespaces permission on rutas-norte-pro except a couple of people (08-01).
3. Verify the context before any deletion, with the reflex from section 6.
4. Backups: the only real safety net. Tools such as Velero can restore an entire namespace, and that is the subject of Backup and Restore.
5. Check before firing, always:

One extra good habit: use --dry-run=client mentally. Before deleting, ask yourself out loud which namespace you are looking at.

Leave preproduction standing, we will keep using it:

The strategic question: should Rutas Norte's three environments live in one cluster with three namespaces, or in three separate clusters?

Practical decision criteria:

Namespaces in one cluster when:

• The environments are of equivalent trust (dev and pre from the same team).
• The team is small and the budget limited.
• RBAC, quotas and network policies are well understood.

Separate clusters when:

• There is regulated data: personal, health or financial.
• Service is offered to customers who do not trust each other (real multi-tenancy).
• Different versions of Kubernetes or of cluster components are needed.
• A production failure cannot depend on the health of a test environment.

The company holds personal customer data —name, ID number, phone and email— in bookings-postgres. The decision, and its rationale:

In other words: two clusters, three namespaces. The rutas-norte-pro namespace also exists in the non-production cluster so the manifests are identical and the rollout can be rehearsed, but real production lives apart.

Throughout the course we will work with a single minikube and the three namespaces, which is the practical choice for learning. Managing several clusters at once, with their contexts and tooling, is covered in Multi-Cluster Management.

One last note on how to organise namespaces: by environment (what we do), by team (payments-team, routes-team) or by application (rutas-norte, intranet). The usual approach is to combine two axes: rutas-norte-pro, intranet-pro. What never works is one namespace per microservice: it multiplies the bureaucracy without providing useful isolation.

• Deploying to default by forgetting. The symptom is kubectl get pods returning nothing where you expected results. Check with kubectl get pods -A -l app=<component>.
• Believing a namespace isolates the network. It does not. Any pod can connect to any Service in another namespace if it knows its name.
• Believing a namespace isolates permissions or resources. RBAC and ResourceQuota are needed. The namespace is the scope, not the mechanism.
• Passing -n to a cluster-scoped resource. kubectl get nodes -n whatever silently ignores the flag and can mislead you.
• A mismatch between metadata.namespace and -n. kubectl errors out instead of deciding for you. It is a protection, not an annoyance.
• Searching in the wrong namespace and concluding something does not exist. When in doubt, -A.
• Deleting a namespace without looking at what it contains. There is no confirmation and no undo. kubectl get all -n <ns> first, always.
• Forcing the deletion of a stuck namespace by stripping its finalizers. It leaves orphaned objects in etcd. Investigate what is blocking it first.
• One namespace per microservice. It multiplies the administrative load without providing real isolation. Organise by environment, team or application.
• Tip: configure the prompt to show context and namespace (kube-ps1). Seeing (rutas-norte:rutas-norte-pro) before typing delete prevents accidents.
• Tip: declare metadata.namespace in the manifests that are specific to an environment and omit it in the generic ones. Ambiguity is what causes deployments in the wrong place.
• Tip: always label your namespaces. Module 4's NetworkPolicies will select namespaces by label, and without them you will have to go back and add them.

1. With a single command, count how many resource types are namespaced and how many are not.
2. Determine, without consulting tables, whether these resources are namespaced: PersistentVolume, PersistentVolumeClaim, Role, ClusterRole, Ingress, StorageClass.
3. List the kube-system pods and identify which are the five control plane components you studied in module 1.
4. Find out what is inside kube-public and explain what is special about that namespace.

1. Deploy web-store (Deployment and Service) to rutas-norte-pro, with the label environment: pro instead of dev.
2. Prove with a single command that three Deployments called web-store exist in the cluster, in different namespaces.
3. Check that the ClusterIPs of the three web-store Services are different.
4. From an ephemeral pod in rutas-norte-dev, make an HTTP request to the web-store in rutas-norte-pro using the full DNS name. Does it work? Explain what this implies and which object would have to be created to prevent it.

You join Rutas Norte's platform team and are asked for a quick audit of the cluster. Answer with commands and their output:

1. Which namespaces exist and which of them belong to the Rutas Norte platform?
2. Is there any object deployed in default? If there is, move it to the correct namespace.
3. Which namespaces have a ResourceQuota defined? What does it imply that they do not?
4. Can you delete the production namespace with your current credentials? What mechanism ought to prevent it and in which lesson is it studied?
5. Draw up a table with the three environments showing: number of pods, number of Services and whether they have a quota.

Solution 1

The numbers vary with the CRDs and addons installed in your cluster.

2. The reasoning, before checking it: anything belonging to a specific application is namespaced; anything that is infrastructure or global configuration is not.

The five: kube-apiserver (the only door to the API), etcd (the state store), kube-scheduler (assigns pods to nodes), kube-controller-manager (where the ReplicaSet, Deployment and endpoints controllers live) and CoreDNS (which resolves the Service names we used in the previous lesson).

kube-public is the only namespace readable without authenticating: anybody who can reach the apiserver can read its contents. It holds cluster-info, with the data a node needs to join the cluster during the kubeadm join process. That is why nothing sensitive must ever be kept there.

Solution 2

It works. A development pod has reached a production service without the slightest obstacle. The direct implication: a namespace is not a network boundary. In Kubernetes' default model, every pod can see every other pod, and knowing the DNS name is enough to connect.

To prevent it you need a NetworkPolicy in rutas-norte-pro that rejects all inbound traffic except what comes from namespaces labelled environment: pro (which is why we labelled the namespaces when creating them). That is the content of Network Policies and Network Security.

Solution 3

The shared label makes it possible to tell the platform namespaces from the system ones at a glance.

Only service/kubernetes shows up, which is the apiserver's own Service and must be there: it is what lets pods talk to the API. If there were anything else, the procedure would be to export it, correct its namespace and apply it again:

No namespace has a quota. Implication: any Deployment in rutas-norte-dev can consume all the cluster's CPU and memory and starve the pods in rutas-norte-pro, because they share nodes. A badly written loop in development can bring production down. It is fixed with ResourceQuota and LimitRange in 03-04 and 03-05.

Yes, I can delete it, and with it all of production, with no confirmation and no undo. What ought to prevent it is RBAC: a Role/ClusterRole that does not include the delete verb on namespaces for everyday credentials, leaving that permission to an emergency role used by two people. It is studied in Role-Based Access Control. As a complementary safety net, backups with Velero (05-06).

Namespaces have stopped being that word we repeated in every command. You know their native function is name uniqueness, and that from it follow the scope of queries, of selectors, of short DNS names, of quotas, of RBAC and of network policies. You tell namespaced resources —pods, Deployments, Services, ConfigMaps, Secrets, PVCs— apart from those belonging to the whole cluster —nodes, PersistentVolumes, StorageClasses, ClusterRoles—, and you know how to find out at any moment with kubectl api-resources --namespaced. You know the four system namespaces, you have seen the control plane running as pods in kube-system, and you are clear about why default is a dumping ground where Rutas Norte deploys nothing.

You have set up the project's three environments declaratively and with labels the NetworkPolicies will exploit later, and you have deployed the same manifests to several of them, confirming that web-store and bookings-api coexist under identical names in different namespaces, each with its own ClusterIP and talking to its own database thanks to short DNS names. You work with -n, with -A and by pinning the context's namespace, with the reflex of checking where you are before any destructive command.

And you take away the two warnings that prevent the most incidents. The first: a namespace isolates nothing on its own. It is not a network boundary —you proved it by writing to the preproduction cache from development and calling production from a dev pod—, it is not a permissions boundary, it does not limit resources and it does not separate nodes. It is the scope that quotas, RBAC and network policies apply to, and those arrive in modules 3, 4 and 8. The second: kubectl delete namespace takes everything with it, with no confirmation and no way back, which is why Rutas Norte's real production lives in a separate cluster.

One loose thread has run through the whole module. The ReplicaSets' selectors, the Services' selectors, the namespaces' environment label, the kubernetes.io/change-cause annotation in the revision history, the pod-template-hash the Deployment adds by itself, the -l queries we have been using since the first lesson... All of those are labels and annotations, and so far we have been using them without any system. In Labels, Selectors and Annotations, the lesson that closes the module, we will put them in order: syntax and constraints, the labels Kubernetes recommends, the definitive labelling scheme for the six Rutas Norte components across their three environments, equality- and set-based selectors, and the everyday queries that turn a large cluster into something navigable.