Imagine a warehouse with 10,000 boxes and no labels, no sections, and no organization system. Finding what you need would be impossible. That’s exactly what a Kubernetes cluster would be like without namespaces and labels. In this module, we’ll learn how to bring order to the chaos.
Namespaces and labels are how Kubernetes organizes resources. Labels enable Services to find Pods, Deployments to manage ReplicaSets, and operators to select resources. KCNA tests your understanding of these organizational primitives.
A namespace is a way to divide cluster resources between multiple users or teams. Think of them as virtual clusters backed by the same physical cluster:
Pause and predict: Two teams share the same Kubernetes cluster. Team A accidentally deploys a Pod named “backend” that conflicts with Team B’s “backend” Pod. How could namespaces have prevented this, and what other isolation benefits would they provide?
Not everything lives inside a namespace. Some resources are cluster-scoped (they exist globally across the entire cluster):
Cluster-Scoped
Why
Nodes
Physical/virtual machines are shared infrastructure.
PersistentVolumes
Storage assets represent cluster-wide capacity.
Namespaces
A namespace cannot contain another namespace.
ClusterRoles
Permissions that apply across all namespaces.
StorageClasses
Configurations for how storage is provisioned globally.
Pause and predict: List which of these 8 resources are cluster-scoped vs namespace-scoped: 1) Pod, 2) Node, 3) PersistentVolume, 4) ConfigMap, 5) Secret, 6) Namespace, 7) Service, 8) StorageClass.
Check your answerNamespace-scoped: Pod, ConfigMap, Secret, Service. These belong to specific applications or teams. Cluster-scoped: Node, PersistentVolume, Namespace, StorageClass. These represent fundamental cluster infrastructure.
Now that we have rooms (namespaces), we need a way to categorize the individual boxes inside them. That’s where labels come in. Think of labels as sticky notes, and label selectors as a database WHERE clause asking for all boxes with specific sticky notes.
Labels are key-value pairs attached to resources for identification:
metadata:
labels:
app: frontend
environment: production
team: platform
version: v2.1.0
Labels can be any key-value pair, you can attach multiple labels per resource, and most importantly, they are used by Kubernetes to select and group resources.
Services, Deployments, and NetworkPolicies don’t track Pods by their IP addresses or exact names (since Pods are ephemeral). Instead, they track them by labels.
There are two ways to query these labels. We’ll start with the simplest: equality-based.
# EQUALITY-BASED (Simple exact match)
# Give me Pods where the 'app' label exactly equals 'frontend'
selector:
app: frontend
# Or using the formal matchLabels syntax:
selector:
matchLabels:
app: frontend
env: production# Must match BOTH (Logical AND)
Sometimes you need more complex logic. What if you want Pods from multiple environments, or want to exclude a specific environment? That requires set-based selectors.
# SET-BASED (More powerful expressions)
selector:
matchExpressions:
- key: app
operator: In
values: [frontend, backend] # App is EITHER frontend OR backend
- key: env
operator: NotIn
values: [development] # Env is NOT development
Operators available for set-based selectors are In, NotIn, Exists (key exists, regardless of value), and DoesNotExist.
Stop and think: Write a matchExpressions selector that selects Pods where the tier is cache and the environment is NOT production.
Pause and predict: Label or annotation? Classify these 6 pieces of metadata: 1) app=web, 2) git-commit=8a3f9b, 3) environment=staging, 4) build-date=2023-10-25, 5) tier=backend, 6) on-call-slack=#team-alpha.
Check your answerLabels: 1, 3, 5. These are short, identifiable categories you would likely want to query or filter by. Annotations: 2, 4, 6. These are longer, highly specific pieces of metadata useful for tooling or humans, but you would never use a Kubernetes selector to say "route traffic to the pod built on 2023-10-25".
Kubernetes recommends a standard set of labels to keep things consistent across tools. Here is what a well-labeled Deployment looks like in the real world:
Stop and think: A Service uses the selector app: frontend to find its Pods. If you add a new label version: v2 to some Pods but not others, will the Service still route traffic to all of them? What would happen if you changed the Service selector to require both app: frontend AND version: v2?
It’s 2 AM on a Friday. The production payment Service suddenly stops routing traffic. The Pods are running, the nodes are healthy, but zero requests are getting through. What happened?
A junior developer updated the Payment Deployment. They wanted to signify that it was a new release, so they changed the Pod template label from app: payment to app: payment-v2.
The impact: The existing Payment Service was still strictly looking for app: payment. Because the labels no longer matched, the Service instantly dropped all the Pods from its endpoints list. The Service was empty. A single label typo caused a 30-minute total outage. Labels are the glue of Kubernetes; if the glue fails, the pieces fall apart.
Worked Example: Labeling a Microservices App End-to-End
Your company has three teams sharing one Kubernetes cluster. Team A complains that Team B accidentally deleted their ConfigMap because both teams named it “app-config” in the default namespace. How would you restructure the cluster to prevent this, and what additional protections could namespaces provide?
Answer
Create separate namespaces for each team (e.g., `team-a`, `team-b`, `team-c`). Namespaces provide name scoping, so both teams can have a ConfigMap called "app-config" without conflict. Additionally, apply RBAC so each team can only access their own namespace, and set ResourceQuotas to prevent any single team from consuming all cluster resources. Namespaces are the primary organizational unit for multi-team clusters.
A new engineer wants to set resource quotas on Nodes to limit how much CPU each physical server can allocate. Why won’t this work with namespace-level ResourceQuotas, and what type of resource are Nodes?
Answer
Nodes are cluster-scoped resources, not namespace-scoped. ResourceQuotas only apply within namespaces and control resources like Pods, Services, ConfigMaps, and compute requests/limits. Since Nodes exist outside of any namespace (they are physical or virtual machines shared by the entire cluster), they cannot be managed by namespace-level quotas. Other cluster-scoped resources include PersistentVolumes, ClusterRoles, and Namespaces themselves.
You need to create a NetworkPolicy that selects Pods from either the ‘frontend’ or ‘api’ tier, but strictly excludes any Pods marked as ‘experimental’. Which selector mechanism is required for this scenario?
Answer
You must use a set-based selector with `matchExpressions`. An equality-based selector (`matchLabels`) only supports exact logical AND matches. To satisfy "EITHER frontend OR api" and "NOT experimental", you would write an expression using the `In` operator for `[frontend, api]` and the `NotIn` operator for `[experimental]`.
Your team stores build timestamps, Git commit hashes, and team contact emails on Kubernetes resources. A colleague puts all of these as labels. What problem might this cause, and what should they use instead for some of this metadata?
Answer
Labels have a 63-character value limit and are indexed by the API server, so using them for long or frequently changing metadata wastes resources and can hit length limits (Git commit hashes are 40+ characters). More importantly, labels are meant for identification and selection by Kubernetes -- using them for metadata that no selector will ever query is wasteful. Git commit hashes, build timestamps, and contact emails should be stored as annotations, which can hold longer values and are designed for tool and human metadata rather than selection.
A security engineer says “we put our teams in separate namespaces, so they are isolated from each other.” Is this statement fully correct? What critical piece might be missing?
Answer
This is only partially correct. Namespaces provide name scoping and can be used with RBAC for access control and ResourceQuotas for resource limits, but they do NOT provide network isolation by default. Pods in different namespaces can still communicate freely over the network. To achieve true network isolation, you must apply NetworkPolicies that restrict cross-namespace traffic. Without NetworkPolicies, a compromised Pod in one namespace can reach any Pod in any other namespace.