2016-02-24 21:47:57 +00:00
---
2016-07-29 17:36:25 +00:00
assignees:
- derekwaynecarr
- janetkuo
2016-12-15 20:16:54 +00:00
title: Sharing a Cluster with Namespaces
2016-02-24 21:47:57 +00:00
---
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
A Namespace is a mechanism to partition resources created by users into
a logically named group.
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
## Motivation
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
A single cluster should be able to satisfy the needs of multiple users or groups of users (henceforth a 'user community').
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Each user community wants to be able to work in isolation from other communities.
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Each user community has its own:
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
1. resources (pods, services, replication controllers, etc.)
2. policies (who can or cannot perform actions in their community)
3. constraints (this community is allowed this much quota, etc.)
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
A cluster operator may create a Namespace for each unique user community.
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
The Namespace provides a unique scope for:
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
1. named resources (to avoid basic naming collisions)
2. delegated management authority to trusted users
3. ability to limit community resource consumption
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
## Use cases
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
1. As a cluster operator, I want to support multiple user communities on a single cluster.
2. As a cluster operator, I want to delegate authority to partitions of the cluster to trusted users
in those communities.
3. As a cluster operator, I want to limit the amount of resources each community can consume in order
to limit the impact to other communities using the cluster.
4. As a cluster user, I want to interact with resources that are pertinent to my user community in
isolation of what other user communities are doing on the cluster.
2016-02-26 11:54:48 +00:00
2016-04-27 12:31:16 +00:00
## Viewing namespaces
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
You can list the current namespaces in a cluster using:
2016-02-26 11:54:48 +00:00
```shell
2016-03-29 23:45:37 +00:00
$ kubectl get namespaces
NAME LABELS STATUS
default < none > Active
kube-system < none > Active
2016-02-26 11:54:48 +00:00
```
2016-03-29 23:45:37 +00:00
Kubernetes starts with two initial namespaces:
2016-05-29 11:53:21 +00:00
2016-03-29 23:45:37 +00:00
* `default` The default namespace for objects with no other namespace
* `kube-system` The namespace for objects created by the Kubernetes system
You can also get the summary of a specific namespace using:
2016-02-26 11:54:48 +00:00
2016-03-29 21:58:48 +00:00
```shell
2016-03-29 23:45:37 +00:00
$ kubectl get namespaces < name >
2016-03-29 01:08:58 +00:00
```
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Or you can get detailed information with:
2016-02-26 11:54:48 +00:00
2016-03-29 01:08:58 +00:00
```shell
2016-03-29 23:45:37 +00:00
$ kubectl describe namespaces < name >
Name: default
Labels: < none >
Status: Active
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
No resource quota.
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Resource Limits
Type Resource Min Max Default
---- -------- --- --- ---
Container cpu - - 100m
```
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Note that these details show both resource quota (if present) as well as resource limit ranges.
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Resource quota tracks aggregate usage of resources in the *Namespace* and allows cluster operators
to define *Hard* resource usage limits that a *Namespace* may consume.
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
A limit range defines min/max constraints on the amount of resources a single entity can consume in
a *Namespace* .
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
See [Admission control: Limit Range ](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md )
2016-03-29 21:58:48 +00:00
2016-03-29 23:45:37 +00:00
A namespace can be in one of two phases:
2017-01-24 08:44:00 +00:00
2016-03-29 23:45:37 +00:00
* `Active` the namespace is in use
* `Terminating` the namespace is being deleted, and can not be used for new objects
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
See the [design doc ](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#phases ) for more details.
2016-02-26 11:54:48 +00:00
2016-04-27 12:31:16 +00:00
## Creating a new namespace
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
To create a new namespace, first create a new YAML file called `my-namespace.yaml` with the contents:
2016-03-29 01:08:58 +00:00
2016-03-29 23:45:37 +00:00
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: < insert-namespace-name-here >
2016-03-29 01:08:58 +00:00
```
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Then run:
2016-02-26 11:54:48 +00:00
2016-03-29 01:08:58 +00:00
```shell
2016-03-29 23:45:37 +00:00
$ kubectl create -f ./my-namespace.yaml
2016-03-29 01:08:58 +00:00
```
2016-02-26 11:54:48 +00:00
2016-04-27 18:13:23 +00:00
Note that the name of your namespace must be a DNS compatible label.
There's an optional field `finalizers` , which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
More information on `finalizers` can be found in the namespace [design doc ](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#finalizers ).
### Working in namespaces
2016-03-29 01:08:58 +00:00
2016-03-29 23:45:37 +00:00
See [Setting the namespace for a request ](/docs/user-guide/namespaces/#setting-the-namespace-for-a-request )
and [Setting the namespace preference ](/docs/user-guide/namespaces/#setting-the-namespace-preference ).
2016-03-29 01:08:58 +00:00
2016-04-27 12:31:16 +00:00
## Deleting a namespace
2016-03-29 23:45:37 +00:00
You can delete a namespace with
2016-02-26 11:54:48 +00:00
```shell
2016-03-29 23:45:37 +00:00
$ kubectl delete namespaces < insert-some-namespace-name >
2016-02-26 11:54:48 +00:00
```
2016-03-29 23:45:37 +00:00
**WARNING, this deletes _everything_ under the namespace!**
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state.
2016-03-29 21:58:48 +00:00
2016-03-29 23:45:37 +00:00
## Namespaces and DNS
2016-03-29 21:58:48 +00:00
2016-03-29 23:45:37 +00:00
When you create a [Service ](/docs/user-guide/services ), it creates a corresponding [DNS entry ](/docs/admin/dns ).
This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local` , which means
that if a container just uses `<service-name>` it will resolve to the service which
is local to a namespace. This is useful for using the same configuration across
multiple namespaces such as Development, Staging and Production. If you want to reach
across namespaces, you need to use the fully qualified domain name (FQDN).
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
## Design
2016-02-26 11:54:48 +00:00
2016-03-29 23:45:37 +00:00
Details of the design of namespaces in Kubernetes, including a [detailed example ](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace )
can be found in the [namespaces design doc ](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md )