A namespace is a scope for names, quotas and access, not a security boundary by itself.

Teams, environments and apps share one cluster by living in separate namespaces. Your kubeconfig decides which cluster and namespace each command targets.

shop

checkout, catalog, payments

quota: 20 CPU, 50 pods
RBAC: team-shop

monitoring

prometheus, grafana

quota: 8 CPU
RBAC: platform

kube-system

CoreDNS, kube-proxy, CNI

managed by the platform
do not edit casually

Scopes names

Two Pods may both be called web in different namespaces.

Scopes policy

ResourceQuota, LimitRange and RBAC Roles are per namespace.

Not isolation

By default Pods in any namespace can still reach each other. Add NetworkPolicy.

kubeconfig contexts

$ kubectl config get-contexts
CURRENT  NAME             CLUSTER          NAMESPACE
*        gke-eu-prod      gke_shop_euw1    shop
         eks-eu-prod      eks-shop-euw1    shop
         rancher-wh-1     k3s-warehouse1   default
$ kubectl config use-context eks-eu-prod
$ kubectl get pods -n monitoring
$ kubectl get pods -A      # every namespace
$ kubectl config set-context --current \
    --namespace=shop

Always know your current context before running a write command: the same kubectl line is harmless on staging and an incident on production.

Namespaces partition one cluster; contexts choose where kubectl points

A namespace is a named scope inside one cluster. Object names are unique per namespace and kind, and several policy mechanisms attach to namespaces: ResourceQuota caps total consumption, LimitRange sets defaults, and RBAC Roles grant permissions inside one. A new cluster starts with default, kube-system (the platform's own components such as CoreDNS), kube-public and kube-node-lease.

Be precise about what a namespace is not. It is not a network boundary: unless you apply NetworkPolicies, a Pod in one namespace can reach Pods in every other. It is not a hard security boundary either; multi-tenant designs combine namespaces with RBAC, quotas, policies and sometimes separate clusters (Deck 5).

kubectl needs to know which cluster and which namespace to talk to. That information lives in kubeconfig as contexts, each pairing a cluster, a user and a default namespace. Shopwave's engineers hold contexts for GKE, EKS and a warehouse k3s cluster managed by Rancher, so context hygiene matters.

Gotcha: nearly every wrong-environment incident starts with a stale current-context. Show the context in your shell prompt and use tools such as kubectx and kubens to switch deliberately.