The namespaces in Kubernetes provides a way for separating groups of resources hosted within a single cluster.

While the default namespace where all the pods and applications get hosted is in the “default” namespace, the below command helps to add a new namespace.

[root@kubmaster01 ~]# kubectl create ns sv-ns1
namespace/sv-ns1 created

[root@kubmaster01 ~]# kubectl get ns

==== ===
NAME STATUS AGE
default Active 2d15h
kube-node-lease Active 2d15h
kube-public Active 2d15h
kube-system Active 2d15h
sv-ns1 Active 50s
==== ===

There are two ways to add a new Namespace:

• Imperative
• declarative

Imperative and declarative Kubernetes commands are the two different methods to configure a new namespace. The same applies to configuring several other features too that we will see later.

The method we used to create a new namespace in the above example is Imperative, where we set the namespace using a CLI. Below is a declarative method of creating a new namespace, using a yaml manifest file.

[root@kubmaster01 sample]# cat ns2.yml

====== ===
apiVersion: v1
kind: Namespace
metadata:
  name: sv-ns2
=====

[root@kubmaster01 sample]# kubectl create -f ns2.yml
namespace/sv-ns2 created

[root@kubmaster01 sample]# kubectl get ns

====== ===
NAME STATUS AGE
default Active 2d16h
kube-node-lease Active 2d16h
kube-public Active 2d16h
kube-system Active 2d16h
sv-ns1 Active 46m
sv-ns2 Active 27s

===== ===

The below command is used to explain the parameters used to create a namespace. It is very helpful when creating a namespace using declarative method.

[root@kubmaster01 sample]# kubectl explain ns

===== ==
KIND: Namespace
VERSION: v1

DESCRIPTION:
Namespace provides a scope for Names. Use of multiple namespaces is
optional.

FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas
===== ==

The below command helps to explain in detail the parameters used when configuring metadata section in namespace

[root@kubmaster01 sample]# kubectl explain ns.metadata

The below command explains the detail. But –recursive prints the same but with more deep details. It also marks the fields that are required and ones optional.

[root@kubmaster01 ~]# kubectl explain ns.metadata –recursive

====== ====
KIND: Namespace
VERSION: v1

FIELD: metadata <ObjectMeta>

DESCRIPTION:
Standard object’s metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
ObjectMeta is metadata that all persisted resources must have, which
includes all objects users must create.

FIELDS:
annotations <map[string]string>
creationTimestamp <string>
deletionGracePeriodSeconds <integer>
… ….
apiVersion <string> -required-

====== ====

[root@kubmaster01 ~]# kubectl explain ns.metadata –recursive

[root@kubmaster01 ~]# kubectl describe ns sv-ns1

===== ===
Name: sv-ns1
Labels: kubernetes.io/metadata.name=sv-ns1
Annotations: <none>
Status: Active
No resource quota.
No LimitRange resource.
===== ===

[root@kubmaster01 ~]# kubectl describe ns sv-ns2

==== ====
Name: sv-ns2
Labels: kubernetes.io/metadata.name=sv-ns2
Annotations: <none>
Status: Active
No resource quota.
No LimitRange resource.
===== ===

The below command prints the configuration of the namespace in yaml format.

[root@kubmaster01 ~]# kubectl get -o yaml ns sv-ns1

=== =========
apiVersion: v1
kind: Namespace
metadata:
     creationTimestamp: “2024-08-14T07:41:50Z”
     labels:
          kubernetes.io/metadata.name: sv-ns1
     name: sv-ns1
     resourceVersion: “57258”
     uid: 70bac5da-254d-4ab3-9ce2-b54d55985bcd
spec:
     finalizers:
     – kubernetes
status:
     phase: Active
=== =========

======== Context, Namespace and pods ========

In a Kubernetes cluster there are contexts, and namespaces in each “context”. The namespace in one “context” is entirely different the namespace on another “context”, though the names of the namespace may be similar. Same way, a pod associated to a namespace within a “context”.

Let us change the namepace used in the currect “context” to sv-sn01 using the below command

[root@kubmaster01 sample]# kubectl config set-context –current –namespace sv-ns01
Context “kubernetes-admin@kubernetes” modified.

[root@kubmaster01 sample]# kubectl config get-contexts

=== ===
CURRENT     NAME       CLUSTER      AUTHINFO      NAMESPACE
* kubernetes-admin@kubernetes     kubernetes      kubernetes-admin    sv-ns01

==== ===

 The above command alters the config file used by the user. This config file was initially copied to the users home folder when the below command was run on the master node when deploying the cluster

• kubeadm init

The below command displays the config file in a yaml format.

[root@kubmaster01 ~]# kubectl config view

===== ===
apiVersion: v1
clusters:
– cluster:
        certificate-authority-data: DATA+OMITTED
        server: https://192.168.146.129:6443
    name: kubernetes
contexts:
– context:
    cluster: kubernetes
        namespace: sv-ns01
    user: kubernetes-admin
        name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
    – name: kubernetes-admin
    user:
        client-certificate-data: DATA+OMITTED
        client-key-data: DATA+OMITTED

===== ===

The below command sets the default namespace back to “default”

[root@kubmaster01 ~]# kubectl config set-context –current –namespace default
Context “kubernetes-admin@kubernetes” modified.