Kubernetes clusters can manage a huge amount of independent workloads simultaneously and organizations usually choose to deploy projects built by isolated teams to distributed clusters. Even with relatively light usage, the number of deployed objects may become awkward very fast. Moreover, they may also slow down operational responsiveness and enhance the chance of high-risk mistakes.
Kubernetes uses the namespaces concept to deal with the complex objects organizing within a cluster. Name spaces allow users to gather objects together to filter and control them as a unit. Learn Kubernetes online course more effectively.
A Kubernetes cluster can be isolated into various name spaces. If a container is built in a namespace includes the default CPU limit, and the container doesn’t mention its own CPU limit, then the container is given the default CPU limit. They also assign a default CPU request under certain conditions.
Moreover, the user needs a Kubernetes cluster, and the kubectl command-line tool must be arranged to contact the cluster.
Functionality of Namespace
The following are the few important functions of a Namespace within Kubernetes −
Default Namespace
By default, a cluster will represent a default namespace while setting up the cluster. This helps to hold the default pack of Pods, Services, and Deployments used by the cluster.
For example, you have a fresh cluster; and you can inspect the available namespaces by performing the following:
kubectl get namespaces
NAME STATUS AGE
Default Active 14m
Create a Namespace
Let us imagine a visual where an entity is using a shared Kubernetes cluster for building and producing use cases.
The development team may like to manage space within the cluster. Here, they could get a visual of the list of Pods, Services, and implements they use to build and run applications. In this space, many resources come and go, and the restrictions on who may not modify resources are relaxed to enable faster development.
The operations team would like to manage space within the cluster. Here they can implement strict protocols on who can or cannot alter the set of Pods, Services, and Deployments that run the production site.
It requires the creation of a namespace so that the resources we create in this exercise are separate from the rest of the cluster. The following is;
kubectl create namespace default-cpu-example
Create pods in each namespace
A Kubernetes namespace gives the opportunity for pods, services, and deployments within the cluster.
However, users interacting with one name space cannot see other namespace content.
kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https://130.211.122.180
name: lithe-cocoa-92103_kubernetes
contexts:
- context:
cluster: lithe-cocoa-92103_kubernetes
user: lithe-cocoa-92103_kubernetes
name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
user:
password: h5M0FtUUIflBSdI7
username: admin
kubectl config current-context
lithe-cocoa-92103_kubernetes
In this context, the next step defines a context for the kubectl client to work in each name space. Besides, the values of cluster and user fields are copied from the existing context.
kubectl config set-context dev --namespace=development \
--cluster=lithe-cocoa-92103_kubernetes \
--user=lithe-cocoa-92103_kubernetes
kubectl config set-context prod --namespace=production \
--cluster=lithe-cocoa-92103_kubernetes \
--user=lithe-cocoa-92103_kubernetes
As a default, the above commands/code adds two contexts that are saved into the file .kube/config
Create a LimitRange and a Pod
The following is the configuration file for a LimitRange object. The configuration states a default CPU request and a CPU limit.
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-limit-range
spec:
limits:
- default:
cpu: 1
defaultRequest:
cpu: 0.5
type: Container
Kubernetes namespace best practices
Namespaces within Kubernetes serve various purposes -- from allowing teams to share a single cluster to applying resource allocations. Kubernetes certification training along with real time projects.
For instance, with Kubernetes namespaces, many IT teams are able to logically separate build, test and production ecosystems. Moreover, name spaces also provide managerial control over resources, via resource allocations and limits.
When an IT admin sets up a cluster, four different name spaces are automatically created:
a) Default- All the resource implements without a namespace are deployed under this name.
b) kube-system-This name space holds Kubernetes system setups and deployments crucial to its cluster.
c) kube-public- This is open to all users with read-only access but hired for system usage.
d) kube-node-lease- Here, all nodes include a related Lease object in this namespace.
A Lease improves the rendition of the node heartbeats, messages that nodes pass to the node controller to show availability - as the cluster extends.
Let's dive in-depth and understand how to work with name spaces. As a pre-requirement, we should have a Kubernetes cluster up and running before trying the commands/code.
Run the below commands to get the list of all namespaces, or a relevant Kubernetes namespace:
kubectl get namespaces kubectl get namespaces <name of namespace>
Moreover, to get detail information about a name space, the describe command is useful:
kubectl describe namespaces <name of namespace>
Create resources in namespaces
To create a resource within a certain namespace that already exists, send the name of the name space as logic to the -n or -- namespace parameter in the command:
kubectl create deployment my-nginx --image nginx --namespace webserver
The --all-namespaces switch framework will register any resources within all the name spaces, like the below command:
kubectl get pods --all-namespaces
Nonetheless, this method doesn't provide the precise list of all the resources within-cluster, as all resources are not arranged within a namespace. For example, resources like nodes, cluster roles and persistent volumes, a low-level one, are not present in any namespace. To register all those resources without having a namespace, the following command is issued:
kubectl api-resources --namespaced=false
Set namespace preference
IT admins can set up a namespace preference to recall all the commands executed afterward. This removes the need to clearly define name space names with all kubectl commands.
Create a new namespace
The namespace creation is very simple: Run the following command –
kubectl create namespace <name of namespace>,
And place the name of the namespace you need to create.
Note: Namespaces are not hierarchical; so we cannot build a namespace within other namespaces.
Praveen Kumar
Praveen Kumar
Set namespace preference
Praveen Kumar
Delete a namespace
To delete a namespace we use the below command;
kubectl delete namespaces <name of namespace>
This will also erase any Kubernetes resources under the namespace held or exist.
Namespace granularity
There, a common question I got is how many Namespaces need to create and for what purpose? Create many Namespaces and they get in the way, but making too few and we miss out on the benefits.
Moreover, the creation of Namespace depends upon organization structure—from small teams to mature enterprise, each has its own structure. Depending on the situation, the business can adopt the relevant Namespace action plan.
Cross Namespace communication
Mostly namespaces are “hidden” from one another, but they are not completely separated as a default. Service within one Name-space can speak to another Name-space service well. Suppose, to get team service within our Namespace, we should contact another team’s service within another Name-space.
Moreover, The Kubernetes namespace is useful for a small team, rapidly growing teams, large companies, and big enterprises.
Conclusion
Namespaces can help notably with arranging the Kubernetes resources and can enhance the velocity of the teams working. That’s in this article for now. I hope you got a fundamental idea of namespace through this article. To get more updates and skills in this regard, one can opt for Kubernetes Online Training.
