Create Kubernetes Namespace With `kubectl`

In Kubernetes, namespaces provide a logical way to separate resources within an application, forming isolated virtual clusters within the Kubernetes cluster. For example, you can create namespaces for the [.inline-code]development[.inline-code] and [.inline-code]production[.inline-code] environments and manage their resources independently.

The operations performed in one namespace do not affect the other namespaces. Thus, it is an ideal option for managing resources separately, especially when working on large projects where every resource has different needs, authorization controls, and varied resource consumption limits.

The short answer

By default, Kubernetes allocates all resources to the [.inline-code]default[.inline-code] namespace, allowing you to utilize your cluster without the initial step of manually creating a namespace.

To create a custom namespace, you can use the [.inline-code]kubectl create namespace[.inline-code] command followed by the name of your namespace:

 $ kubectl create namespace <namespace_name>

For example:

 $ kubectl create namespace development
namespace/development created.

Upon execution, the above command will output the name of the newly created namespace in the terminal to confirm its successful creation.

Note that you can use the [.inline-code]kubectl get namespaces[.inline-code] command to view all available namespaces in your cluster. You can read more about this command by consulting the official documentation page.

[#easily-recall-with-ai]Easily retrieve this command using Warp’s AI Command Search [#easily-recall-with-ai]

If you’re using Warp as your terminal, you can easily retrieve this command using the Warp AI Command Search feature:

Entering [.inline-code]k8 namespace[.inline-code] in the AI Command Search will prompt a [.inline-code]kubectl[.inline-code] command, which can be inserted quickly into your shell by doing [.inline-code]CMD+ENTER[.inline-code].

[#adding-labels-to-namespaces]Adding labels to existing namespaces[#adding-labels-to-namespaces]

In Kubernetes, labels are key-value pairs that can be attached to various resources, including namespaces. Labels are beneficial to identify and organize namespaces in larger Kubernetes environments.

To label an existing namespace, you can use the [.inline-code]kubectl label[.inline-code] command as follows:

 $ kubectl label namespace <key>=<value>

[.inline-code]key[.inline-code] is the label key.
[.inline-code]value[.inline-code] is the value of the label key.

For example:

 $ kubectl label namespace <key>=<value>

You can learn more about this command on the official documentation page. Note that, by applying labels strategically, you can implement pod security standards, implement access control and organize your resources better.

[#simulate-namespace-creation]Simulating namespace creation[#simulate-namespace-creation]

Simulating namespace creation helps validate the creation before directly applying it to your live Kubernetes cluster. This simulation will help you avoid unintended changes, such as misconfigurations or potential errors causing instability within the live cluster.

To simulate the creation of a namespace, you can use the [.inline-code]kubectl create namespace[.inline-code] command followed by the [.inline-code]--dry-run[.inline-code] flag:

 $ kubectl create namespace <namespace> --dry-run=[client|server|none]

The[.inline-code]--dry-run[.inline-code] flag offers three possible values:

• [.inline-code]client[.inline-code] specifies a dry run on the client side, meaning it validates the request locally without sending server requests. This is helpful for quickly verifying the correctness of the command and ensuring it won't trigger any errors.
• [.inline-code]server[.inline-code] specifies a dry run on the server side, where the request is sent to the server for validation, but any changes are not persisted. The response from the server indicates whether the creation of the namespace would have been successful or not without actually creating the namespace.
• [.inline-code]none[.inline-code] specifies that no dry run is performed, and the namespace creation request is directly applied to the server, resulting in the actual creation of the namespace. This is the default behavior of the [.inline-code]kubectl create namespace[.inline-code] command without the [.inline-code]--dry-run[.inline-code] flag.

For example:

 $ kubectl create namespace production --dry-run=server
namespace/production created (server dry run)

The above command performs a dry run on the server side to create a new namespace named [.inline-code]production[.inline-code], and the [.inline-code]--dry-run=server[.inline-code] flag ensures that the server processes the request as if it were a real creation attempt, providing a response indicating success or failure without actually creating the namespace.

[#create-namespace-using-yaml]Creating a namespace using a YAML file [#create-namespace-using-yaml]

To create a namespace using a YAML file, you can define the configurations as follows:

 apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.28

Where:

• [.inline-code]apiVersion[.inline-code] specifies the version of the Kubernetes API.
• [.inline-code]kind[.inline-code] specifies the type of Kubernetes resource.
• [.inline-code]metadata[.inline-code] specifies metadata about the resource.
• [.inline-code]name[.inline-code] specifies the name of the resource.
• [.inline-code]labels[.inline-code] specifies the key-value pairs which you want to assign to the resource.

Then use the [.inline-code]kubectl create[.inline-code] command with the [.inline-code]-f[.inline-code] flag to create the namespace defined in the YAML file:

 $ kubectl create -f ./my-namespace-file.yaml

This command reads the configurations from the file and creates a new namespace accordingly.

Note that using a YAML file for namespace creation is beneficial as storing it in repositories enables easy tracking of namespace configurations. This also aids in versioning and automating namespace creation.

[#create-multiple-namespaces]Creating multiple namespaces at once[#create-multiple-namespaces]

To create multiple namespaces at once using a single [.inline-code]YAML[.inline-code] file, you can define the configurations as follows:

 apiVersion: v1
kind: Namespace
metadata:
   name: development
---
apiVersion: v1
kind: Namespace
metadata:
   name: production

Where each section represents a separate namespace configuration.

Note that the three dashes ([.inline-code]---[.inline-code]) are used as a document separator, allowing you to define multiple resources at once using a single [.inline-code]YAML[.inline-code] file.

Alternatively, you can use the [.inline-code]List[.inline-code] resource with the following syntax to achieve the same result:

For example:

 apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: Namespace
  metadata:
      name: mynamespace1
- apiVersion: v1
  kind: Namespace
  metadata:
      name: mynamespace2
- apiVersion: v1
  kind: Namespace
  metadata:
      name: mynamespace3

[#create-namespace-using-json]Creating a namespace using a JSON file[#create-namespace-using-json]

To create a namespace using a JSON file, you can define the configurations as follows:

 {
    "apiVersion": "v1",
    "kind": "Namespace",
    "metadata": {
      "name": "development",
      "labels": {
        "pod-security.kubernetes.io/enforce": "baseline",
        "pod-security.kubernetes.io/enforce-version": "v1.28"
      }
    }
  }

And run the [.inline-code]kubectl create[.inline-code] command with the [.inline-code]-f[.inline-code] flag to create this namespace:

 $ kubectl create -f ./my-namespace-file.json

Creating namespaces using either YAML or JSON files is beneficial when orchestrating complex deployments or managing configurations across various environments. These structured files offer a clear and concise way to define Kubernetes resources, aiding in better management and automation of your applications within Kubernetes.

[#namespace-naming-best-practices]Best practices when choosing a namespace [#namespace-naming-best-practices]

In Kubernetes, namespaces must be defined according to the following rules:

• It must be unique in a cluster and should not clash with existing ones. If you attempt to create an existing namespace, the command will result in an error (indicating that the namespace already exists), and the creation of the namespace will fail.
• It must be a valid DNS label (i.e. it can only contain lowercase characters, numbers, dash ([.inline-code]-[.inline-code]), underscore ([.inline-code]_[.inline-code]), or period ([.inline-code].[.inline-code]).
• It must start and end with an alphanumeric character.  

It should not use prefixes like [.inline-code]kube-[.inline-code], as they are reserved for system namespaces (such as [.inline-code]kube-public[.inline-code] and [.inline-code]kube-system[.inline-code]).