Namespaces & Labels: Multi-Tenancy, Organization, and Resource Selection
Namespaces partition a cluster into isolated logical units. Labels are metadata selectors that enable flexible resource organization and querying.
Namespaces & Labels: Multi-Tenancy, Organization, and Resource Selection
Namespaces partition a cluster into isolated logical units. Labels are metadata selectors that enable flexible resource organization and querying.
What you'll learn
- Namespaces provide logical isolation and enable multi-tenancy; use them even in single-team clusters
- Labels are flexible metadata for organization; Service selectors match labels dynamically
- Namespace isolation combined with RBAC, NetworkPolicies, and quotas enable secure multi-tenancy
- Default namespace should never be used for application workloads; enforce namespace requirements
Lesson outline
Namespaces: Logical Isolation
Namespace is a cluster partition. Most Kubernetes resources live in a namespace (Pods, Services, Deployments, etc.). Some are cluster-wide (Nodes, PersistentVolumes, ClusterRoles).
Default namespaces: default (user workloads), kube-system (K8s internals), kube-public (public data), kube-node-lease (node heartbeats).
Resource quotas and network policies can be applied per-namespace for multi-tenancy.
Labels and Selectors
Label: key-value pair attached to Kubernetes objects. E.g., app=myapp, tier=backend, env=prod.
Selector: query that matches labels. E.g., app=myapp,env=prod matches objects with both labels. Used by Services, Deployments, and queries.
Labels are arbitrary and used for organization, not by Kubernetes automatically (except node labels for scheduling).
Label Best Practices
Common labels (recommended by Kubernetes): app, instance, version, component, part-of, managed-by, created-by.
Example: app=myapp, app.kubernetes.io/name=myapp, app.kubernetes.io/version=v1.2.3, app.kubernetes.io/managed-by=helm.
Namespacing Strategies
By environment: dev, staging, prod. Each team has dedicated namespace(s). Isolation via RBAC and NetworkPolicies.
By team: each team owns a namespace. Limits resource allocation per team. Enables self-service deployments.
By application: one namespace per application, multiple environments (using labels). Reduces namespace count.
Key takeaways
- Namespaces provide logical isolation and enable multi-tenancy; use them even in single-team clusters
- Labels are flexible metadata for organization; Service selectors match labels dynamically
- Namespace isolation combined with RBAC, NetworkPolicies, and quotas enable secure multi-tenancy
- Default namespace should never be used for application workloads; enforce namespace requirements
💡 Analogy
Namespaces are like separate buildings in a city. Labels are like tags on buildings (color, purpose, size). A Service selector is like looking for "red buildings with "cafe" tag". Namespaces provide hard isolation; labels provide flexible organization within and across namespaces.
⚡ Core Idea
Namespaces provide logical partition and RBAC/quota boundaries. Labels are metadata for flexible organization and selection.
🎯 Why It Matters
In multi-tenant clusters, namespaces isolate teams and limit blast radius. Labels enable flexible resource organization without physical partitioning.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Discussion
Questions? Discuss in the community or start a thread below.
Join DiscordIn-app Q&A
Sign in to start or join a thread.