Per-application namespaces: a de facto standard?

General Discussions
1

Hi, folks. My company is in the process of moving to k8s and there’s a separate team of people handling this k8s-specific work. I’m an application developer myself, however I’m not afraid of dipping my toes into DevOps waters. In any case, I’m new to k8s for the moment, so I’m learning it on the go.

My question relates to one of the things that I noticed in the setup of our clusters, namely that each application has its own namespace, named after the application itself. So if I have three application foo, bar and baz, the k8s setup would include three namespaces foo, bar and baz, and each app (pod+service+deployment) would reside in the eponymous namespace. I find this to be a bit cumbersome since every time I issue a command like kubectl get pods I also need to append the application name in the form of a namespace: kubectl get pods -n foo, which obviously returns the pods for a single application. I see several issues with this:

  1. There’s no way to get all pods across several namespaces in a single command
  2. For each app I have in mind I need to type out its particular namespace
  3. I can’t use kubectl config set-context --current --namespace to alleviate some of the typing

Now, I asked the folks that have configured this why they did it like that, because it seemed non-standard to me (as far as my Google searching skills go). The motivation I got was a curt: “it’s the de facto standard”.

My questions to you are: 1) is this indeed a de facto usage of namespaces and 2) are there advantages to this approach that I’m missing? All the materials I’ve been using to study about k8s don’t talk about anything like that; most of the examples use namespaces as a means of hosting multiple environments in the same cluster. In any case, from my experience with the concept of namespaces in other settings (programming languages, XML), they’re usually used to hold more than one name, as opposed to this situation where each namespace contains a single pod/service/deployment name.

Thanks for reading so far!

2

Hi there, @igstan! I’m pretty new to k8s myself and while I’d normally think having single deployments per namespace isn’t the best practice, it actually depends on how your applications work.
Here’s a short article I found by someone with more experience that may help a lot:

As you can see he says :

So, from our experience we’ve choose to adopt the practice of using 1 namespace x microservice . But it has a lot to do and directly related with the amount of microservices, dev teams and the use of Spinnaker (https://www.spinnaker.io/) for K8s CD (Deployment) among some other reasons that we mention below.

Also the division of namespaces by Service tier → Using Namespaces to partition development landscapes (dev, qa, stg, prod) or for Teams → Roles and Responsibilities in an Enterprise (teamA, teamB, …, teamN) are understood also within the good practices.

He then talks about some namespaces benefits and capabilities you should read.

That’s what I found so far, I hope this helps! Good luck :wave:

3

Hi! We took a stab at this question on office hours, about 13 minutes in, hope it helps!

4

Thanks, Emiliano. It seems I wasn’t using the right keywords in my Google searches, cause I didn’t come across that blog post before. I wish he went more into the reasoning for that choice, but overall the points he lists are useful for taking my own decisions.

1 Like
5

Whoa, folks… this is next-level community involvement. I’m positively shocked :slight_smile:

There were some very useful tips and suggestions there. In any case, it seems that one namespace per microservice is hardly a de facto standard. And I’ve got some useful perspectives from that discussion that will help me think about this problem now, so thanks for that.

2 Likes
6

How you have configured the Microservice?
Is it something one namespace per Microservice for the Springboot ?