Kubernetes Namespace Controller
Namespace
Think of a Kubernetes Namespace as a way to divide a single big cluster into multiple smaller, virtual clusters. It helps you organize your resources (like pods, services, and deployments) so that different teams or projects don’t mess with each other. It provides scope for names meaning, you can have a “database” service in the Dev namespace and another “database” service in the Prod namespace, and they won’t clash.
Imagine a Large Office Building (The Kubernetes Cluster). Inside this building, you have different Departments like HR, IT, and Finance (The Namespaces).
- Isolation: People in the HR department (Pods in HR namespace) work in their own cabin. The noise they make doesn’t disturb the IT team.
- Resource Sharing: Everyone shares the same building electricity and water (Node Resources: CPU/RAM), but you can set rules so the IT team doesn’t use up all the coffee (ResourceQuotas).
- Naming: Both HR and IT can have a manager named “Ramesh” (Service Name). If you call “Ramesh” inside the HR cabin, the HR manager responds. If you call “Ramesh” in IT, the IT manager responds.
Key Characteristics to Remember
- Namespaces are “Virtual Clusters” backed by the same physical hardware.
- They provide a scope for names; names must be unique within a namespace, but can repeat across different namespaces.
- Not all resources are in a namespace (Nodes and PersistentVolumes are global!).
- DNS for a service looks like:
<service-name>.<namespace-name>.svc.cluster.local.
- Scope: Logical isolation.
- Multi-tenancy: Allows many users/teams to share one cluster.
- Resource Control: Can limit how much CPU/RAM a namespace uses.
- Security: Acts as a boundary for Access Control (RBAC).
| Feature | Description | Simple Trick to Remember |
| Isolation | Separates resources logically. | Like separate folders on a laptop. |
| Quota | Limits total CPU/Memory for the namespace. | Like a monthly pocket money limit. |
| RBAC | Controls who can access what inside. | Like an ID card for a specific lab. |
| DNS | automatic naming for discovery. | <service-name>.<namespace-name>.svc.cluster.local. |
The “Built-in” Namespaces
When you first set up Kubernetes, it comes with default namespaces. You should know them:
default: Where your stuff goes if you don’t specify a namespace.kube-system: For Kubernetes’ own components (like the scheduler, kube-dns). Warning: Don’t touch this unless you know exactly what you are doing!kube-public: Strictly for public data (rarely used by users).kube-node-lease: Used by nodes to send “heartbeats” to the master (to say “I am alive”).
As an Architect, namespaces are your first line of defense and organization. You don’t just “create” them; you govern them.
- ResourceQuotas: You must apply these to prevent a “noisy neighbor” issue where a Dev environment eats up all CPU, starving Production.
- LimitRanges: While Quota is for the whole namespace, LimitRange sets the default and max size for individual pods inside that namespace.
- Network Policies: By default, namespaces can talk to each other. To strictly isolate them (Security), you must implement NetworkPolicies (deny-all by default).
- Service Mesh Interaction: If using Istio, you can enforce mTLS strictly per namespace.