A Kubernetes namespace groups resources within a cluster. Think of it as a dedicated virtual environment for those resources, not a separate cluster. The default namespace is available for deploying applications; the controller manager creates default accounts and API access tokens for new namespaces. section 1.5
Use `kubectl get ns` to list namespaces (`ns` is the shorthand). System components, including the API server, scheduler, CoreDNS, and etcd, have pods in `kube-system`. Do not confuse a Kubernetes namespace with the Linux namespaces used to isolate containers in a kind cluster. section 2.1.4 section 9.3.1
Create resources in a namespace
Run `kubectl create ns c01383`, then `kubectl -n c01383 create deploy nginx --image nginx` and `kubectl -n c01383 expose deploy nginx --name nginx-svc --port 80`. Verify the result with `kubectl -n c01383 get deploy,svc`. The `-n` flag selects the namespace for each resource command. section 6.2.4
Namespace scope also matters when resolving Service names. From a pod in `c01383`, `curl apache-svc` cannot resolve a Service in `default`, but `curl apache-svc.default` succeeds. Use the namespace-qualified name when checking cross-namespace Service access; the Service naming pattern is `<service-name>.<namespace-name>.svc.cluster.local`. section 6.2.4
root@nginx-76d6c9b8c-8lqgg:/# cat /etc/resolv.conf search c01383.svc.cluster.local svc.cluster.local cluster.local nameserver 100.96.0.10 options ndots:5
The pod’s `/etc/resolv.conf` lists `c01383.svc.cluster.local` in its DNS search path, helping explain why an unqualified Service name is looked up in the pod’s namespace. section 6.2.4
