Kubernetes NameSpace

  • You can think of a Namespace as a virtual cluster inside your Kubernetes cluster.
  • Kubernetes namespace allows you logically organize your resources into groups.
  • You can have multiple namespaces inside a single Kubernetes cluster, and they are all logically isolated from each other.
  • The objects part of this namespace will be part of no other namespaces.

Why do you need namespaces?

  • When we have a large set of Kubernetes resources running on our cluster Kubernetes namespaces helps in organizing them and allows you to group them together based on the nature of the project.
  • By doing so you have more control over them and can effectively manage them by using unit filters.
  • This will also allow the teams or projects to exist in their own virtual clusters without fear of impacting each other’s work
  • For example, you can have separate namespaces created for different environments such as development, staging, production, etc. for a project or an application.

4 different default NameSpace

  • When you provision a Kubernetes cluster it will create a different namespace to hold the default set of Pods, Services, and Deployments used by the cluster.
  • By default, Kubernetes provides four namespaces.

kube-system:

  • kube-system is the namespace for objects created by the Kubernetes system.
  • We should avoid putting anything personal in that namespace.
  • It would contain pods like kube-dns, kube-proxy, kube-API, and others controllers.
  • We can check resources under the kube-system namespace.

kube-public:

  • Used for public resources and readable by all users (including those not authenticated).
  • This namespace is mostly reserved for cluster usage not recommended for other Kubernetes users.
  • It contains the configmap that has cluster information.
  • We can check the configmap by running the following command.

kube-node-lease:

  • This namespace holds the heartbeats of nodes and each node is associated to lease object in the namespace.
  • Node leases allow the kubelet to send heartbeats so that the control plane can detect node failure.
  • It determines node availability.

default:

  • The default namespace is the namespace where your resources are created in the beginning if you do not specify any namespace while creating your cluster.
  • The objects part of this namespace will be part of no other namespaces.

Scenario, when to use namespace?

Team NameSpace

  • Namespaces are to assign different teams with their own namespace.
  • This lets each team manage their own application without interfering with the work of other teams.
  • Team A can't access any resource for Team B, Team C, and this will avoid conflict or override between the resources.
  • Cluster admin can limit the authority of the Team A user only to access the Team-A-namespace, Team-B user to Team-B-namespace only, and Team-C user to Team-C namespace only.

Different Environment

  • Another scenario would be that you want to create a different environment for your application, development, staging, and production env.
  • we may do coding, testing, and deployment in dev env and this will not impact stable env such as staging and prod.

Logically breakdown the application

  • If you have all your resources in the default namespace, it will very difficult to manage all the different versions of the different components.
  • It is better to logically group the resource into different namespaces.
  • We can logically group different components into different namespace as the database contain all the resources related to databases, Redis rabbitMQ, etc.
  • monitoring will contain all the resources like Prometheus, grafana, etc, application-service will contain the different services, etc.

--

--

--

DevOps Engineer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to Factory Reset Realme 5i

How to start with React Native

How To Keep A Running Backup Of Your Reddit Account Using Zapier

VunHub: Kioptrix Level 4

Dive into Firebase Auth on Flutter: Third-Party Authentication

The Moving Average RSI Trading Strategy.

Protofire Releases Infrastructure Templates for Gnosis Beacon Chain

Deployment of React.JS, using AWS S3, CircleCI and Terraform.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Bikram

Bikram

DevOps Engineer

More from Medium

Kubernetes Pods

Kubernetes Labels, Selectors & Annotations — Chapter 10

Kubernetes Application High-Availability — Part 1 (The Very-Basic Basics)

[Workaround] Let's solve the Jenkins slave connection issue with the Jenkins Kubernetes plugin