A Kubernetes namespace is a low-cost logical boundary for separating resources inside one cluster. It organizes environments or tenants without providing strong isolation. section 4.1.4 section 6.2.3
Use namespaces with supporting controls and recognize their operational limits:
- Pair namespaces with RBAC roles to restrict users’ visibility and with resource quotas to prevent one namespace consuming cluster resources. section 6.2.3
- Treat namespace-per-environment as a simple pipeline arrangement, while remembering that staging and production still share cluster resources. section 4.1.4
- Account for shared Kubernetes API endpoints and cluster-wide resources when multiple tenants require different controllers, extensions, or operating privileges. section 6.2.3
Environment pipeline
A team can create development environments as namespaces in a shared cluster, while keeping staging and production on separate clusters and configuration repositories. Promotion then follows the corresponding environment’s repository workflow. section 4.1.4
Figure 4.9 Different environment configurations, based on requirements. A more realistic approach can use the same cluster for multiple teams doing day-to-day work, while more sensitive environments like staging and production are separated on their own clusters and Git repositories to store their configurations. For a service to be promoted to a new environment, a pull request needs to be submitted to the corresponding Git repository.
Compare shared development namespaces with separate staging and production clusters, including repository boundaries and promotion flow. section 4.1.4
