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.
