kubectl contexts and namespaces

A namespace is a name-scoping boundary inside a cluster. Two Deployments can both be called api as long as they live in different namespaces, and RBAC, quotas and network policy can all be applied per namespace.

What a namespace is not is a security boundary on its own. Pods in different namespaces can reach each other over the network by default, and they share the same nodes and kernel.

What is namespaced and what is not

kubectl api-resources --namespaced=true | head
kubectl api-resources --namespaced=false

The PV/PVC split is the one that catches people: a PersistentVolumeClaim is namespaced but the PersistentVolume it binds is not. So a claim can only be used by Pods in its own namespace, while the underlying volume is a cluster resource.

Secrets being namespaced is the other frequent surprise. A registry credential created in default does nothing for a Pod in payments.

The built-in namespaces

Avoid default for anything real. It has no quota, no network policy and no meaningful RBAC, and things accumulate there until nobody knows what is safe to delete.

Working with them

kubectl create namespace payments

# or declaratively, which is what you want in Git
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    team: payments
    environment: production
EOF

kubectl get pods -n payments
kubectl get pods -A                    # every namespace
kubectl get namespaces

Set a default so you stop typing -n:

kubectl config set-context --current --namespace=payments

Forgetting the namespace is the most common reason kubectl get pods reports "No resources found" when something is definitely running.

Label your namespaces. They are the handle for network policy selectors, quota reporting and cost allocation, and adding them later means reconstructing who owns what.

Cross-namespace DNS

A Service's short name only resolves within its own namespace. Across namespaces you need the namespace segment:

A call that works from one namespace and fails from another is nearly always this.

Where you genuinely want to alias a Service from elsewhere, an ExternalName Service does it without hardcoding the FQDN in application config:

apiVersion: v1
kind: Service
metadata:
  name: payments-api
  namespace: checkout
spec:
  type: ExternalName
  externalName: payments-api.payments.svc.cluster.local

What namespaces are actually good for

RBAC. A Role and RoleBinding grant permissions within one namespace, which is how you give a team full control of its own space and nothing else:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payments-team
  namespace: payments
subjects:
  - kind: Group
    name: payments-engineers
roleRef:
  kind: ClusterRole
  name: edit           # built-in: read/write most things, no RBAC changes
  apiGroup: rbac.authorization.k8s.io

Note the roleRef points at a ClusterRole while the binding itself is namespaced, that is the normal pattern for reusing the built-in view, edit and admin roles per namespace.

Resource quotas. Without one, any namespace can consume the whole cluster:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: payments-quota
  namespace: payments
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    pods: "50"

Pair it with a LimitRange, because once a quota constrains a resource every Pod must specify it or be rejected.

Network policy. This is what turns a namespace into an actual boundary. By default all Pods can reach all Pods; a default-deny policy plus explicit allows changes that:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress]

Network policies require a CNI that implements them. Calico, Cilium, and similar. On a CNI that does not, the policy is accepted and silently does nothing, which is a dangerous way to believe you are protected.

How to divide a cluster

Common patterns, with their trade-offs:

• Per team or service (payments, checkout). The usual choice. Clean RBAC and quota boundaries.
• Per environment in one cluster (dev, staging). Cheap, but a noisy dev workload shares nodes with staging and a cluster-wide incident hits both. Fine for non-production; separate clusters are better for production isolation.
• Per developer (dev-alice). Good for ephemeral preview environments, needs automated cleanup.

What does not work is one namespace for everything. You lose quotas, per-team RBAC and any meaningful network policy, and everything ends up in default.

Deleting, and the Terminating trap

kubectl delete namespace payments

This deletes everything inside it. Deployments, Services, Secrets, ConfigMaps, and PVCs. A PVC whose StorageClass has reclaimPolicy: Delete takes its data with it. Deleting a namespace is one of the most destructive single commands in Kubernetes.

Sometimes it hangs in Terminating indefinitely. The cause is virtually always a finalizer on a resource whose controller is gone, commonly a custom resource left behind after its operator was uninstalled:

kubectl get namespace payments -o json | jq '.status.conditions'

The correct fix is to remove the blocking resources or reinstall the operator so its finalizers can run:

kubectl get mycrds.example.com -n payments
kubectl patch mycrd my-instance -n payments -p '{"metadata":{"finalizers":null}}' --type=merge

Force-removing the namespace's own finalizer through the API is the widely-circulated trick, and it does work, but it orphans any resources that had not been cleaned up, including cloud load balancers and volumes that will keep billing. Treat it as a last resort and check for leftovers afterwards.

Quick reference

Key takeaways

• Namespaces scope names and policy, not the network. Without NetworkPolicy, everything can still reach everything.
• PVCs are namespaced; PersistentVolumes are not. So are Secrets. A registry credential must exist in the Pod's own namespace.
• Cross-namespace DNS needs the namespace segment in the name.
• Avoid default. No quota, no policy, no ownership.
• Label namespaces from the start: network policy, quotas and cost reporting all key on them.
• Pair a ResourceQuota with a LimitRange, or Pods without requests are rejected.
• Deleting a namespace deletes its PVCs, and a Delete reclaim policy destroys the data.
• A stuck Terminating namespace is a finalizer, usually from an uninstalled operator.

Check your understanding

<MCQExercise exercise={{ id: 'k8s-ns-not-security', title: 'How isolated is a namespace?', description: 'A team puts an internal admin service in its own namespace, assuming other teams cannot reach it. Is that assumption correct on a default cluster?', options: [ { id: 'a', text: 'No. Pods in any namespace can reach it over the network unless a NetworkPolicy denies it' }, { id: 'b', text: 'Yes, namespaces are isolated network boundaries by default' }, { id: 'c', text: 'Yes, but only if the Service is type ClusterIP' }, { id: 'd', text: 'No, but only because DNS resolves across namespaces' }, ], correctId: 'a', explanation: 'Kubernetes networking is flat by default: every Pod can reach every other Pod and Service in the cluster, whatever namespace they are in. Namespaces scope names and give RBAC and quotas something to attach to, but they do not filter traffic. Network isolation requires NetworkPolicy resources and a CNI that enforces them.', wrongExplanations: { b: 'This is the most common and most dangerous misconception about namespaces. Nothing about creating one changes packet flow.', c: 'ClusterIP restricts reachability to inside the cluster, not to inside a namespace. Any Pod in the cluster can still connect.', d: 'DNS makes it convenient, but blocking DNS would not help. The Service IP is routable regardless of whether a name resolves to it.', }, }} />

<MCQExercise exercise={{ id: 'k8s-ns-terminating', title: 'A namespace that will not delete', description: 'A namespace has been Terminating for an hour. Its conditions report "Some resources are remaining: widgets.example.com has 2 resource instances". What is the correct first action?', options: [ { id: 'a', text: 'Remove the blocking custom resources or reinstall the operator, so the finalizers can complete properly' }, { id: 'b', text: 'Force-remove the namespace finalizer through the API to make it disappear immediately' }, { id: 'c', text: 'Restart the kube-controller-manager to clear the stuck deletion' }, { id: 'd', text: 'Delete the CustomResourceDefinition, which cascades to the namespace' }, ], correctId: 'a', explanation: 'A namespace waits until every resource inside it is genuinely cleaned up. Custom resources carry finalizers that their operator is supposed to run, releasing a cloud load balancer, detaching a volume, and if the operator has been removed nothing completes them. Clearing the blocking resources, or restoring the controller so it can finish properly, lets the deletion proceed without leaving anything orphaned.', wrongExplanations: { b: 'It does make the namespace vanish, which is why the trick circulates widely, but it abandons whatever those finalizers were meant to clean up, including cloud resources that keep billing invisibly.', c: 'The controller manager is working correctly; it is waiting deliberately. Restarting it changes nothing about the outstanding finalizers.', d: 'Deleting the CRD removes the type definition while its instances are still pending cleanup, which generally makes the situation harder to unpick rather than easier.', }, }} />