How Kubernetes namespaces manage cluster resources?

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
−

● Name spaces usually help in pod-to-pod contact using the same

namespace.
● These are virtual clusters that fit on top of the same cluster physically.
● Besides, they also provide logical separation between different teams and
their environments

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​.