When and why use multiple Kubernetes namespaces

Kubernetes best practices

Exequiel Barrirero

Published in

binbash

3 min readJun 13, 2019

Article based on our experience with dozens of K8s customers projects at https://www.binbash.com.ar

What is a Namespace?

You can think of a K8s Namespace as a “virtual cluster” inside your Kubernetes cluster. You can have multiple namespaces inside a single Kubernetes cluster, and they are all logically isolated from each other. They can help you and your teams with organization, security, and even performance!

Multiple K8s namespaces approaches

We’ve lately received some inquiries related to when and why Kubernetes namespaces should be used and which layout we’ll be recommended to logically segment our clusters. Based on that, we’ll share our thoughts based on our experience in order to help anyone facing this questions.

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.

Although, as mentioned in the K8s official doc: When to Use Multiple Namespaces, mentions that this is not strictly necessary and depends on your current scenario:

Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.

ref art.: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

Figure shows how to allow AWS users/groups to assume the AWS IAM role to interact with the K8s namespace via kubernetes-sigs/aws-iam-authenticator and K8s RBAC authorization.

Namespaces benefits and capabilities

Summarizing when the amount of microservices begins to grow this practice will help us with:

Default namespace: Avoiding to use it.
Resource Limits: CPU & memory limits per app/microservice (1 x ns) -> Nice to have in PROD to avoid buggy apps/process to use all of the cluster/namespace resources.
Monitoring: Prometheus + Grafana allow us to filter metrics and dashboard views per namespace.
Centralized Logs & Alert based on logs: Elastic Fluent Kibana (EFK) -> logs filters -> filter logs with more ease per app/microservice (1 x namespace).
Operations: Automation, maintenance and deployment (Jenkins / Spinnaker).
Incident Management: Simplifies troubleshooting issues and allows K8s dashboard segregated view per namespace.

Considering Cloud Native Computing Foundation (CNCF) K8s best practices

ref art.: https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/

Enable Role-Based Access Control (RBAC): Cluster-wide permissions should generally be avoided in favor of `namespace-specific` permissions.
Use Namespaces to Stablish Security Boundaries: Creating separate namespaces is an important first level of isolation between components. We find it’s much easier to apply security controls such as Network Policies when different types of workloads are deployed in separate namespaces.
Separate Sensitive Workloads: You can achieve this separation using node pools and pod affinity (in the cloud or on-premises) and Kubernetes namespaces, taints, tolerations, and other controls.
Network Policies and resources limits: This is key to the issue of `limits` having all dev, stage, or prod in a single namespace would make the pods of all microservices share resources, if a microservice with memory leak begins to demand more resources than expected would possibly drag all PROD to degradation of services.