Kubernetes Namespace: Create, Switch Context, and RBAC

A Kubernetes namespace is a cluster partition for resource isolation per the K8s docs. Namespaces are useful for multi-team clusters, environment separation (dev/staging/prod), or RBAC scoping. Most resources are namespace-scoped; some (nodes, persistent volumes, namespaces themselves) are cluster-scoped.

Create a namespace
Default namespaces
Switching namespace context
Listing namespaces
Resource scoping
RBAC per namespace
Resource quotas per namespace
Deleting namespaces
FAQ

Create a namespace

kubectl create namespace my-team

Or YAML:

apiVersion: v1
kind: Namespace
metadata:
  name: my-team

The team that uses namespaces has logical separation between teams, environments, or projects.

Default namespaces

default: where resources go without explicit namespace.
kube-system: K8s system components.
kube-public: readable by all users (rare).
kube-node-lease: node heartbeat objects.

The team that creates dedicated namespaces for apps keeps them out of default.

Switching namespace context

kubectl config set-context --current --namespace=my-team

All subsequent kubectl commands default to my-team. The team that uses this avoids -n my-team on every command.

Listing namespaces

kubectl get namespaces
kubectl get ns    # short

The team that uses kubens (a kubectl plugin) has interactive namespace switching.

Resource scoping

Most resources are namespace-scoped. Cluster-scoped:

Nodes
PersistentVolumes (PVs)
Namespaces
ClusterRoles (but RoleBindings are namespace-scoped)

The team that uses kubectl api-resources sees whether each resource is namespace-scoped or cluster-scoped.

RBAC per namespace

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-team
  name: developer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: my-team
subjects:
  - kind: User
    name: alice
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

The team that has per-namespace RBAC has team isolation.

Resource quotas per namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: my-team
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    persistentvolumeclaims: "10"
    pods: "50"

The team that uses quotas prevents one namespace from consuming all cluster resources.

Deleting namespaces

kubectl delete namespace my-team

Deletes the namespace and ALL resources in it. The team that has backup/migration before delete has recovery options.

FAQ

Can I rename a namespace?

No - K8s doesn’t support namespace rename. Create new, migrate resources, delete old.

What’s the difference between namespaces and contexts?

Contexts include cluster + user + namespace. Switching namespace context only changes the namespace part of the context.

Can I have a namespace with no resources?

Yes - empty namespaces are valid. Some teams create them as boundaries before resources are deployed.

Should I use namespaces for environment separation?

Yes for dev/staging/prod in the same cluster. The team that runs production in a separate cluster has stronger isolation but more ops work.

What’s the default namespace limit?

No hard limit, but ResourceQuota enforces limits per namespace. The team that sets quotas has controlled resource consumption.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: