Kubernetes supports multiple virtual clusters within the same physical cluster using namespaces. Namespaces are intended for use in environments with many users, spread across teams and projects. Namespaces provide a scope for names, which must be unique within a given namespace, but not across them. They provide a primitive to divide a cluster's resources between multiple users. Objects within the same namespace will have the same access control policies by default. In most cases, labels are a sufficient way to distinguish resources within the same namespace.

Interacting with Namespaces

Viewing Namespaces

You can list cluster namespaces by running

$ kubectl get namespaces
NAME          STATUS    AGE
default       Active    1d
kube-system   Active    1d
kube-public   Active    1d

By default, Kubernetes starts with three namespaces:

  • default - the default namespace for objects without a namespace
  • kube-system - namespace for objects created by the Kubernetes system
  • kube-public - automatically created namespace readable by all users, including those who are unauthenticated. It is reserved for resources that should be publicly visible throughout the cluster. The public nature of this namespace is a convention and not a requirement.

Setting Request Namespace

To set the namespace for a request, use the --namespace  flag.

For example:

$ kubectl --namespace=my-namespace run nginx --image=nginx
$ kubectl --namespace=my-namespace get pods

Setting a Namespace Preference

You can permanently save the namespace used for subsequent kubectl commands in that context.

$ kubectl config set-context $(kubectl config current-context) --namespace=my-namespace
$ kubectl config view | grep namespace

Namespaces & DNS

When a service is created, a corresponding DNS entry is also created. The entry takes the form ${service-name}.${namespace-name}.svc.cluster.local, meaning that if a container just uses ${service-name} , it will resolve to the service local to the namespace. This is useful when using the same configuration across multiple namespaces, such as Development, Staging, and Production. To make requests across namespaces, simply use the fully qualified domain name (FQDN).

Not all Objects are in a Namespace

Most Kubernetes resources in a namespace; however, namespace resources themselves are not in a namespace. Similarly, low-level resources such as nodes and persistent volumes are not in a namespace. Events are an exception: they may or may not belong to a namespace, depending on the object the event references.

Did this answer your question?