Namespaces permit separating a single Kubernetes cluster into virtual clusters. A simple use case is separate namespaces for
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:
Terminating. This is based on whether the namespace has a
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
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.
kubectl subcommands, you use
--namespace=foo to target the appropriate namespace.
kubens, the power tools for
kubectl: ahmetb/kubectx. These tools let you switch between contexts and namespaces respectively.