Namespaces

Kubernetes namespaces allow us to implement isolation of multiple virtual clusters. Objects in different namespaces are invisible to each other. This is useful when different teams or projects share the same cluster. Most resources come under a namespace (these are known as namespaced resources); however, some generic resources, such as nodes or namespaces themselves, don't belong to any namespace. Kubernetes has three namespaces:

• default
• kube-system
• kube-public

If we don't explicitly assign a namespace to a namespaced resource, it'll be located in the namespace of the current context. If we never add a new namespace, a default namespace will be used.

Kube-system namespaces are used by objects created by the Kubernetes system, such as addon, which are the pods or services that implement cluster features, such as dashboard. Kube-public namespace was introduced in Kubernetes version 1.6, which is used by a beta controller manager (BootstrapSigner: https://kubernetes.io/docs/admin/bootstrap-tokens), putting the signed cluster location information into the kube-public namespace. This information could be viewed by authenticated or unauthenticated users.

In the following sections, all of the namespaced resources are located in a default namespace. Namespaces are also very important for resource management and roles. We'll provide further information in Chapter 8, Resource Management and Scaling.

Let's see how to create a namespace. A namespace is a Kubernetes object. We can specify the type to be a namespace, just like other objects. An example of how to create a namespace called project1 follows:

// configuration file of namespace
# cat 3-2-1_ns1.yml
apiVersion: v1
kind: Namespace
metadata:
  name: project1

// create namespace for project1
# kubectl create -f 3-2-1_ns.yaml
namespace/project1 created


// list namespace, the abbreviation of namespaces is ns. We could use `kubectl get ns` to list it as well.
# kubectl get namespaces
NAME          STATUS    AGE
default       Active    1d
kube-public   Active    1d
kube-system   Active    1d
project1      Active    11s

Let's now try to start two nginx containers via deployment in the project1 namespace:

// run a nginx deployment in project1 ns
# kubectl run nginx --image=nginx:1.12.0 --replicas=2 --port=80 --namespace=project1

deployment.apps/nginx created

When we list pods by kubectl get pods, we'll see nothing in our cluster. This is because Kubernetes uses the current context to decide which namespace is current. If we don't explicitly specify namespaces in the context or the kubectl command line, the default namespace will be used:

// We'll see the Pods if we explicitly specify --namespace
# kubectl get pods --namespace=project1
NAME                  READY STATUS  RESTARTS AGE
nginx-8cdc99758-btgzj 1/1   Running 0        22s
nginx-8cdc99758-xpk58 1/1   Running 0        22s

Another way to do this is to change the current context to point to the desired namespace rather than the default namespace.