🚀 Get ready for the official launch.
Buy an early adopter license now and get 50% off! Learn more →

Beginners

Best Practices for Kubernetes Namespaces

Kubernetes namespaces are essential to to organize objects in your clusters, but they're not without their challenges. Here are some best practices for using namespaces.

Last updated on
Cover image for "Best Practices for Kubernetes Namespaces" blog post.

If you're new to Kubernetes and still learning the basics, you might be wondering what namespaces are and why you should use them. Consider reading our article on Kubernetes namespaces first: What is a namespace?

Getting Started

Planning your namespaces is an important step in the design of your Kubernetes cluster. The earlier you start thinking about namespaces, the better. It is possible to change the structure of your namespaces, but time-consuming process, so it's best to get it right the first time when possible.

Here are a few questions to ask yourself when planning your namespaces:

  • How many applications will be deployed to the cluster?
  • How many teams will be deploying applications to the cluster?
  • How many environments will be deployed to the cluster?
  • What are the networking and security requirements for each app?

It's at the namespace level that Role-based access control (RBAC), Resource Quotas and Network Policies are created.

Answering the above questions will help you determine how many namespaces you need and how to structure them.

The Default namespace

If you put a group of Kubernetes experts in a room, if there is one thing they will all agree on, it's that the default namespace should never be used. The default namespace is one of the initial namespaces created in every Kubernetes cluster. You could use it as a sandbox for testing new Kinds and concepts when learning in Kubernetes, but just do not use it for production workloads 🙂

Popular strategies for namespaces

There are many ways to structure namespaces in your cluster. Here are a few common strategies:

  • Namespace per Application
  • Namespace per Team
  • Namespace per Project/Domain/System

They each have their pros and cons and it really is up to you to decide which one is best for your use case.

Having a namespace per application is likely the most flexible and easier to reason about. From a discoverability point of view, you'll always know where to find each application. While there is no limit on the number of namespaces, depending on the scale of your organization, you may end up with a lot of namespaces. This can make it difficult to manage and maintain. RBAC permissions can become a challenge as you'll likely have multiple teams with Read/Write access to the same namespaces.

Having a namespace per team is a good way to keep teams isolated from each other. It's common for teams to have complete ownership of their namespaces. This means they can create and manage their own resources within the boundaries of their namespace.

What about environments?

It's common to have multiple environments for each application. For example, you might have a development, staging, and production environment for each application. While Namespaces in Kubernetes cannot be nested in a hierarchy, you can use naming conventions to group namespaces by environment, something like:

  • dev-{app/team-name}
  • stg-{app/team-name}
  • prod-{app/team-name}

The solution above means that you could apply Resource Quotas to limit the CPU/Memory usage in development and staging environments, thus protecting the production environments. The same applies to Network Policies that can be applied to restrict access to production environments.

Namespace prefixes are not the only way to group namespaces by environment. It's also very popular in medium and large organizations to have multiple Kubernetes clusters. Each cluster can be dedicated to one or more environments. As you can imagine this is a more complex solution, but it can be very effective especially when you consider that having a separate cluster gives you a lot more options when it comes to security and networking.

Common questions about namespaces:

How many namespaces are too many?

There are never too many. As of November/2022, the SIG Scalability recommends having no more than 10.000 namespaces in a single cluster. This is a very high number and you're unlikely to hit it.

One thing to remember is that kubectl and other tools like Aptakube perform a lot better when working on a large number of small namespaces as you'd be working with a smaller number of objects.

Can applications in one namespace access resources in another namespace?

Yes. By default, all pods in a namespace can access all services in all namespaces through the internal DNS in Kubernetes. All that is needed is the name and the namespace of the service as the DNS follows a standard format: <service-name>.<namespace>.svc.cluster.local.

his is a very powerful feature of Kubernetes, but it can also be a security risk if not properly managed. If you want to restrict access between pods in different namespaces, you can use Network Policies.

Other relevant articles

Tired of using the CLI?

Aptakube is a modern and lightweight desktop client for Kubernetes. Connect to multiple clusters simultaneously!
Try free now!

Screenshot of Aptakube showing a list of pods from 2 clusters in a single view