You will learn how to change a default namespace in kubectl in this post. All of Kubernetes’ resources are organized into namespaces, and Namespaces let you separate concerns for resources shared by different projects. If the namespace is not specified, all resources are produced in the default namespace, and this applies to all instructions directed at your cluster. If the -n argument is not used for a namespace in a kubectl command, the Kubernetes will give output from resources in the default namespace.
Namespaces are a Kubernetes feature that lets you divide groupings of resources within a cluster. Within a namespace, resource names must be unique, but not between namespaces. Namespace-based scoping is only applicable to namespaced items (such as Deployments and Services), not to cluster-wide objects (e.g., StorageClass, Nodes, PersistentVolumes, etc.).
The “Default” Namespace
Out of the box, most Kubernetes releases include a Namespace called “default” in the cluster. There are three namespaces in Kubernetes: default, kube-system, and kube-public. Kube-public isn’t used very often right now, and kube-system is usually ignored, especially in a regulated system like Google Kubernetes Engine (GKE). As a result, the default Namespace will be used to create your services and apps. There’s nothing remarkable about this namespace other than that the Kubernetes tooling is configured to use it out of the box and that you can’t delete it. It’s excellent for getting started and for smaller production systems, but it’s not suitable for larger ones. This is due to the fact that it is quite easy for a team to inadvertently overwrite or disrupt another service without recognizing it. Instead, divide your services into digestible bits by creating multiple namespaces.
Before You Proceed:
To begin, launch the minikube cluster, which is already installed on your Ubuntu 20.04 LTS operating system. To run minikube, type the attached command in the command line:
View Namespaces
You may get a list of all the namespaces in a cluster by typing the following command.
If an item has no other namespace, this is the default namespace. The kube-system namespace includes objects specifically designed by the Kubernetes system. On the other hand, the kube-public namespace exists automatically and is available to all types of users. This namespace is for cluster use if some resources need to be publicly available and readable across the entire cluster. This namespace’s public aspect is merely a recommendation, not a mandate. Lease objects connected with each node are stored in the kube-node-lease namespace. The kubelet can broadcast heartbeats to the control plane via node leases, allowing the control plane to detect node failure.
Defining a Request’s Namespace
Keep in mind that the —namespace parameter is specifically used to set the namespace for a current request.
Using the command below, you may get a list of all pods from a certain namespace.
Choosing a Preferred Namespace
For any further kubectl commands in that context, you can save the namespace permanently.
This command will display the namespace that is currently being utilized.
Not Every Object Has a Namespace
Pods, services, replication controllers, and other Kubernetes resources are all organized into namespaces. Namespace resources, on the other hand, are not contained within a namespace. Nodes and persistentVolumes are low-level resources that are not in any namespace. To see which Kubernetes resources are used in a namespace, refer to the command below:
Make use of the following command to see which Kubernetes resources are not used in a namespace:
DNS Namespaces
A DNS entry is created for a Service when it is created. This entry’s format is <service-name. namespace-name>. If a container solely uses service-name>, it will resolve to a namespace-local service, according to svc.cluster.local. If you want to use the same configuration in multiple namespaces, such as Staging, Development, and Production, this would be critical. You must use the fully qualified domain name if you want to reach across namespaces.
When Should You Use Several Namespaces?
Namespaces are designed for situations with a large number of users spread across several teams or projects. You shouldn’t need to build or think about namespaces for clusters with a few to tens of users. When you require the functionalities that namespaces give, start using them.
Namespaces provide names for a place to go. Within a namespace, resource names must be unique, but not between namespaces. Namespaces are a means for numerous users to share cluster resources, and they separate resources that hold the same namespace.
Conclusion
You learned how to change the default Kubernetes namespace using the kubectl command line in this post. The default namespace is assigned to the default namespace when you create an AKS or local Kubernetes cluster. If all of your workloads aren’t in the default namespace, this can be a hassle.
