Namespaces permit separating a single Kubernetes cluster into virtual clusters. A simple use case is separate namespaces for development and production.
Resource names must be unique within a namespace but needn’t be unique across namespaces.
Q: When should you use namespaces? A: When you need them.
It may be possible to us labels to distinguish resources within the same namespace. Avoid creating namespaces that start with kube-; leave those for Kubernetes. The docs say start using namespaces when they start providing value.
Phases of a namespace are: Active and Terminating. This is based on whether the namespace has a ObjectMeta.DeletionTimestamp.
Cross Namespace communication is possible:
Namespaces are “hidden” from each other, but they are not fully isolated by default.
Network policies should be used in order to isolate namespaces.
default Active 57d
kube-node-lease Active 57d
kube-public Active 57d
kube-system Active 57d
The Namespaces walkthrough has some more useful notes on this. Namespaces provide:
A mechanism to attach authorization and policy to a subsection of the cluster
You can have development and production namespaces in the same cluster. The dev and ops teams can have separate Pods, Services and Deployments. (See note above about cross namespace communication.)
The Namespace granularity section of Google’s Organizing with Namespaces has a nice quick response on this note.
With various kubectl subcommands, you use --namespace=foo to target the appropriate namespace.
Try kubectx + kubens, the power tools for kubectl: ahmetb/kubectx. These tools let you switch between contexts and namespaces respectively.