in the API reference.

## Creating a new namespace

{{< note >}}
Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
{{< /note >}}

Create a new YAML file called `my-namespace.yaml` with the contents:

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: <insert-namespace-name-here>
```
Then run:

```shell
kubectl create -f ./my-namespace.yaml
```

Alternatively, you can create namespace using below command:

```shell
kubectl create namespace <insert-namespace-name-here>
``` 

The name of your namespace must be a valid
[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).

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://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers).

## Deleting a namespace

Delete a namespace with

```shell
kubectl delete namespaces <insert-some-namespace-name>
```

{{< warning >}}
This deletes _everything_ under the namespace!
{{< /warning >}}

This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state.

## Subdividing your cluster using Kubernetes namespaces

By default, a Kubernetes cluster will instantiate a default namespace when provisioning the
cluster to hold the default set of Pods, Services, and Deployments used by the cluster.

Assuming you have a fresh cluster, you can introspect the available namespaces by doing the following:

```shell
kubectl get namespaces
```
```console
NAME      STATUS    AGE
default   Active    13m
```

### Create new namespaces

For this exercise, we will create two additional Kubernetes namespaces to hold our content.

In a scenario where an organization is using a shared Kubernetes cluster for development and
production use cases:

- The development team would like to maintain a space in the cluster where they can get a view on
  the list of Pods, Services, and Deployments they use to build and run their application.
  In this space, Kubernetes resources come and go, and the restrictions on who can or cannot modify
  resources are relaxed to enable agile development.

- The operations team would like to maintain a space in the cluster where they can enforce strict
  procedures on who can or cannot manipulate the set of Pods, Services, and Deployments that run
  the production site.

One pattern this organization could follow is to partition the Kubernetes cluster into two
namespaces: `development` and `production`. Let's create two new namespaces to hold our work.

Create the `development` namespace using kubectl:

```shell
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
```

And then let's create the `production` namespace using kubectl:

```shell
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
```

To be sure things are right, list all of the namespaces in our cluster.

```shell
kubectl get namespaces --show-labels
```

```console
NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production
```

### Create pods in each namespace

A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
Users interacting with one namespace do not see the content in another namespace.
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.

```shell
kubectl create deployment snowflake \
  --image=registry.k8s.io/serve_hostname \
  -n=development --replicas=2
```

We have created a deployment whose replica size is 2 that is running the pod called `snowflake`
with a basic container that serves the hostname.