Organize your IBM Cloud Private cluster using Namespaces

IBM Cloud Private, a reliable, scalable, and integrated cloud platform that runs on a customer’s datacenter, is built on open-source, Kubernetes-based container architecture. Learn how you can use the Kubernetes namespace concept to organize your clusters so that you can easily take advantage of common IBM Cloud Private services, like self-service deployment, monitoring, logging, metering and security.

In this blog I will cover:

• Creating namespaces
• Organizing teams in namespaces
• Restricting quotas for the namespaces
• Enabling access control for the namespaces

Typically, enterprises are distributed or organized by departments, geography, line-of-business, or other categories. These groups operate independently, with some layer of control that is usually managed by the enterprise administrator. Operating IBM Cloud Private clusters in such an environment can be done effectively by efficient planning. With namespaces, you can partition a single IBM Cloud Private cluster into many virtual clusters that can be used by multiple users, or teams of users.

For instance, each team of users and application can exist within its own namespace in isolation, away from every other user of the cluster and operating as if it were the sole user of the cluster.

Create a namespace, or multiple namespaces

As a cluster administrator, creating namespaces is easy and can be done with a single command

kubectl create namespace dev-namespace

You can also use a .yaml file to create namespaces:

kind: Namespace
apiVersion: v1
metadata:
 name: dev-namespace
 labels:
   name: dev-namespace
kubectl apply -f testns.yaml

If you would rather use the IBM Cloud Private management console to create namespaces, you can do that, too! From the console, follow the procedure:

1. Log in as a cluster administrator.
2. From the navigation menu, click Manage > Namespaces.
3. Click Create Namespace.
4. See Create a Namespace in the product documentation for more information.

Organize teams into namespaces

IBM Cloud Private provides out-of-the-box capability that helps with organization. You can do the following:

• Configure your user repository in IBM Cloud Private
• Create teams and map roles that helps distribute responsibility across users and teams.
• Map namespace resource to users and teams

See details on setting up teams in the product documentation

Restrict Resource Quota for namespaces

Kubernetes provided by IBM Cloud Private provides capabilities that favors grouping by namespace. Most importantly, Kubernetes enables assignment of resource quota to the namespace. After a quota in a namespace for compute resources is set, the users are forced to set requests or limits for those values.

Note: Requests and limits can be set per container and are used by Kubernetes to control resources, such as CPU and memory for each container. Containers are guaranteed to get requests and limits are used to make sure the container never goes above a certain value.

The following example shows how you can specify compute resource on containers inside a .yaml file:

Resources:
 requests:
  memory: "64Mi"
  cpu: "200m"
 limits:
  memory: "64Mi"
  cpu: "200m"

Now let’s see how you as an administrators can use Resource Quota to control resources per namespace.

After creating a namespace, you can specify a quota for the namespace, as you can see in the following example for specifying resource quota:

kind: ResourceQuota
metadata:
  name: demo
spec:
  hard:
   requests.memory: 300Mib
   requests.cpu: 500m
   limit.memory: 500Mib
   limit.cpu: 700m

Here, requests.memory and requests.cpu specifies constraints towards aggregate resource requests for all the containers in the namespace.

Additionally, limits.memory and limits.cpu specifies maximum aggregate resource limits for all the containers in the namespace.

By default, a pod will run with unbounded CPU and memory requests/limits. Once the administrator enables quota in the namespace for compute resources like cpu and memory, users must specify requests or limits for those values or the quota system may reject pod creation.

Resource Quota is a very valuable tool to the administrators because they can control how much of the cluster resources can be consumed across all pods inside a namespace. In addition to compute resources, administrators can also control number of pods, services, secrets, resource quotas, persistent volume claim and replication controller for the namespaces.

See Kubernetes documentation for more information about Resource Quota.

Access control for namespace in IBM Cloud Private

IBM Cloud Private extends the grouping by namespace capability by providing role based access control scoped by namespace. Earlier in the article, I mentioned that IBM Cloud Private provides the capability to map users and teams to a role and namespace resources. Once that is done, only users and teams with permissions in a namespace can operate in the namespace they have access to bounded by their role, this includes the following:

• Operations like deploying helm charts, upgrade or deleting releases etc
• Accessing data including Helm releases, logging, monitoring and metering

See the product documentation for roles and permissions associated with each role.

Summary

In summary, use the following guidelines to take advantage of namespace organization:

• Think and design how you want to group your teams or sub-organizations that need to run in isolation, but inside the same cluster.
• Cluster administrator has access to entire cluster and can then create namespace per group.
• Based on needs of the teams, cluster administrator should set quotas per namespace.
• Cluster administrator can then create teams in IBM Cloud Private and map to relevant roles and namespace resources.

I hope the article helps you guide your teams to share IBM Cloud Private clusters across different teams using namespaces, resource quotas and role based access control.