A namespace is a unit of organization that brings with it some management implications. If you put time into a designing a good namespace configuration, you get a lot of administrative functions for free, such as RBAC policies.
RBAC role bindings are done at the namespace scope, which means a user will generally have the same access permissions to each type of object in the namespace. For this reason, it is useful to group objects together based on what sort of access permissions user’s may have to them.
Another administrative aspect is resource quotas. Quotas are administered on a Project-level. While quotas can be adjusted as needed, it does often require an administrator to make the change. If you can define sensible quotas based on expected needs, you get some benefits.
Here is an example. If your organization uses a microservice architecture and teams often own services that are related to each other, it can be beneficial to have a namespace per environment, per team. For example, if the team’s name is “Phoenix” then you might have namespaces like this:
Inside each namespace then you may deploy the services that the team owns.
If you have a strict security posture and want a more “whitelist” approach to permissions, you can use a different namespace for each service such that permissions can be strictly tailored. A namespace scheme may look more like this:
It is worth putting in some thought about the optimal approach, as your decision can become either an asset or a liability. The optimal namespace policies will vary depending on both technical organization as well as administrative organization.
Once you have decided on your approach, you may want to take the next steps of setting a default quota in the project template, or possibly adopting an operator to help such as the Namespace Configuration Controller.
If you would like a guide, I have published a guide on adding default limits and quotas to the new project template here.