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
baz, the k8s setup would include three namespaces
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:
- There’s no way to get all pods across several namespaces in a single command
- For each app I have in mind I need to type out its particular namespace
- I can’t use
kubectl config set-context --current --namespaceto 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!