06 - Namespaces¶

What this session is¶

About 20 minutes. Namespaces - Kubernetes' way to group resources. Used for environment isolation (dev/staging/prod in one cluster), team boundaries, and avoiding name collisions.

What a namespace is¶

A virtual partition within a cluster. Resources (pods, services, etc.) live in a namespace; they only see other resources in their own namespace by default.

By default everything lives in the default namespace. Production clusters use namespaces for organization.

List namespaces¶

kubectl get namespaces
# or short:
kubectl get ns

A fresh cluster has:

default - your default working namespace.
kube-system - Kubernetes' own internals (DNS, kube-proxy, etc.). Don't touch.
kube-public - publicly readable data. Rarely used.
kube-node-lease - node heartbeats. Don't touch.

Create a namespace¶

kubectl create namespace dev

Or in YAML:

apiVersion: v1
kind: Namespace
metadata:
  name: dev

Run things in a namespace¶

Two ways: per-command, or set context.

Per-command:

kubectl get pods -n dev
kubectl apply -f deployment.yaml -n dev

Set context (so subsequent commands use it without -n):

kubectl config set-context --current --namespace=dev
kubectl get pods           # now in dev by default

To see your current namespace:

kubectl config view --minify --output 'jsonpath={..namespace}'

The kubens tool (part of kubectx) makes this fast: kubens dev switches; kubens lists. Install: brew install kubectx.

Cross-namespace DNS¶

When pods talk to services in another namespace, use the full DNS name:

http://<service>.<namespace>             # e.g. http://nginx.dev
http://<service>.<namespace>.svc.cluster.local

Within the same namespace, the short name works: http://nginx.

Resource quotas (briefly)¶

A ResourceQuota limits how much a namespace can consume:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"

Apply to enforce. Useful for multi-team clusters where one team shouldn't starve others.

When to use namespaces¶

Real patterns: - Per-environment: dev, staging, prod namespaces in one cluster (small orgs). Bigger orgs use separate clusters per env. - Per-team: team-platform, team-ml, team-frontend. - Per-tenant: SaaS apps that need data isolation per customer. - Per-application bundle: monitoring, logging, ingress-nginx.

A typical pattern: install a Helm chart into its own namespace (helm install grafana grafana/grafana --namespace monitoring --create-namespace).

Some things are NOT namespaced¶

A few resources are cluster-wide: - Namespace itself (obviously). - Node. - PersistentVolume. - ClusterRole, ClusterRoleBinding. - CustomResourceDefinition.

You can check whether a resource type is namespaced:

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

Exercise¶

Create a namespace and run a Deployment in it:

kubectl create namespace dev
kubectl apply -f deployment.yaml -n dev
kubectl get all -n dev          # 'all' shows pods, services, deployments

List across all namespaces:
```
kubectl get pods -A
```

Switch context to dev:

kubectl config set-context --current --namespace=dev
kubectl get pods         # now defaults to dev

Switch back: kubectl config set-context --current --namespace=default.

Cross-namespace DNS test:
In default, apply the nginx Deployment + Service (page 03/04).

In dev, run a debug pod:

kubectl run -n dev debug --rm -it --image=alpine -- sh
wget -qO- http://nginx.default        # should work
wget -qO- http://nginx                 # should NOT find (no nginx in dev)

Cleanup:
```
kubectl delete namespace dev    # removes EVERYTHING inside
```
Deleting a namespace cascades to everything inside it. Powerful and dangerous.

What you might wonder¶

"Are namespaces a security boundary?" Soft yes, hard no. By default, pods in different namespaces can still reach each other over the network. RBAC limits who can edit what across namespaces. For real isolation (untrusted workloads), separate clusters.

"What about kube-system?" Hands-off. Kubernetes' own components live there. Modifying them can break the cluster. Read-only.

"Should I namespace everything?" For small projects, default is fine. For anything beyond ~10 services or multi-environment in one cluster, use namespaces.

Done¶

Create and switch namespaces.
Run resources in specific namespaces.
Use cross-namespace DNS.
Know which resources are namespaced.

Next: Labels and selectors →