On Namespaces

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 Namespaces

default                Active   57d
kube-node-lease        Active   57d
kube-public            Active   57d
kube-system            Active   57d

When are namespaces useful?

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.

Using namespaces

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.

Docs