Kubernetes · Orchestration under pressure
What are namespaces good for and what do they not isolate?
Short answer
Namespaces partition names and scoped resources for teams, environments or tenants. They support RBAC and quotas, but they are not a network or security boundary by themselves.
Most namespaced objects must have unique names within a namespace, not across the cluster. Namespaces are a natural scope for RoleBindings and ResourceQuotas, making them useful for team isolation and cost control. Some objects, such as Nodes and PersistentVolumes, are cluster-scoped.
- Use namespaces per team, environment or tenant, not per microservice by default
- Apply ResourceQuota and LimitRange to prevent noisy-neighbour problems
- Default network behaviour allows all pod-to-pod traffic unless NetworkPolicy is used
- Namespace deletion is asynchronous and can hang on finalizers
- Cross-namespace access requires explicit DNS names and policy
kubectl create namespace team-a
kubectl get pods -n team-a
kubectl config set-context --current --namespace=team-a
kubectl get resourcequota,limitrange -n team-aStrong multi-tenancy needs more than namespaces: network policies, admission control, pod security standards, quotas and often separate clusters for hostile tenants. Namespaces organize objects; they do not stop a compromised pod from reaching another namespace's service.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Are namespaces a security boundary?
- 2How do ResourceQuotas interact with pods?
- 3Which resources are cluster-scoped?
- 4How would you isolate two hostile tenants?
Say it in the interview
Namespaces give me scoping for names, RBAC and quotas, which is useful for teams and environments. They are not a network or security boundary, because pods can reach other namespaces unless NetworkPolicy blocks it. For real multi-tenancy I add admission control, pod security and sometimes separate clusters. I also set namespaces explicitly in manifests to avoid default-namespace mistakes.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.