When should one use multiple Kubernetes namespaces?
Small teams or smaller organizations may be perfectly content using the default namespace. This is particularly relevant if there is no need to isolate developers or users from each other. However, there are many useful benefits to having multiple namespaces, including:
- Isolation. Large or growing teams can use namespaces to isolate their projects and microservices from each other. Teams can re-use the same resource names in different workspaces without a problem. Also, taking an action on items in one workspace never affects other workspaces.
- Organization. Organizations that use a single cluster for development, testing, and production can use namespaces to sandbox dev and test environments. This ensures production code is not affected by changes that developers or testers make in their own namespaces throughout the application lifecycle.
- Permissions. Namespaces enable the use of Kubernetes RBAC, so teams can define roles that group lists of permissions or abilities under a single name. This can ensure that only authorized users have access to resources in a given namespace.
- Resource Control. Policy-driven resource limits can be set on namespaces by defining resource quotas for CPU or memory utilization. This can ensure that every project or namespace has the resources it needs to run, and that no one namespace is hogging all available resources.
- Performance. Using namespaces can help improve performance of a given cluster. If a cluster is separated into multiple namespaces for different projects, the Kubernetes API will have fewer items to search when performing operations. This can reduce latency and speed overall application performance for each application running on the cluster.
When to use Multiple Namespace => clusters>10
What is namespace in k8s?
- Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
- Namespaces automatically separate resources in the cluster. So if you create a namespace A and B, then if you create a configmap in namespace A it will automatically be unavailable in namespace B.
- A resource quota, defined by a
ResourceQuotaobject, provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that namespace.
- Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource limits defined in a ResourceQuota.
- If creating or updating a resource violates a quota constraint, the request will fail with HTTP status code
403 FORBIDDENwith a message explaining the constraint that would have been violated.
- You can limit the total sum of compute resources that can be requested in a given namespace.
- Note that resource quota divides up aggregate cluster resources, but it creates no restrictions around nodes: pods from several namespaces may run on the same node.
- Enhancing role-based access controls (RBAC) by limiting users and processes to certain namespaces.