How to organize Namespaces in Kubernetes

There are two main objectives:

  1. Users are able to do their job with the highest velocity possible
  2. Users organized by groups in multi tenant setup 

Multi tenancy

Kubernetes namespaces help to setup boundaries between groups of users and applications in a cluster.
To make it more pleasant and secure for your users to work in shared cluster Kubernetes has a number of policies and controls.

Access policies

RBAC primary objective is authorize users and applications to do specific operations in the namespace or in whole cluster. Use RBAC to give your users enough permissions in the namespace, so they can do day to day operations on their own.
Network Policy control how pods can communicate with each other. Use it to firewall traffic between namespaces or inside namespace to critical components like Databases.

Resource controls

By default Pod can utilize as many compute resources as available.
Resource Quotas control the amount of compute and storage resources which Pod can use in namespace.
Limit Range help to prevent one Pod from utilize of all resources in namespace. LimitRange set minimum and maximum boundaries for compute and storage resource per Pod.

Application Security

Pod security policy control security sensitive aspects of container. Examples are privileged containers, use of host namespace and many other.
Open Policy Agent is very powerful policy framework which help to create custom policies for applications and users in a cluster. For example:

  • force users to use a specific label in Kubernetes objects like Service or Deployment
  • deny access to pull :latest images tag
  • allow to pull images only from specific docker registry

Namespaces


Following examples could help you to decide on namespaces boundaries and naming:

  • Namespace per team
  • Namespace per team and project
  • Namespace per application
  • Namespace per git branch name

Namespace should provide enough self managing autonomy for users and be in sync with applications requirements.
The bigger namespace the harder to tune up it’s boundaries, at the same time many small namespaces could create additional operational work for cluster administrators.

Namespace per team and project is optimal start which should work for most organizations.

Let me know your experience in comments and have a great day!

Leave a Reply

Your email address will not be published. Required fields are marked *

*