Hierarchical Namespace Controller (HNC): Exploring Kubernetes Multi‑Tenant Model and Practical Use Cases

Hierarchical Namespace Controller (HNC) is a Google‑driven project that adds hierarchical namespaces to Kubernetes, enabling a more flexible multi‑tenant model by propagating configuration from a parent namespace to its child namespaces.

To try HNC you need a Kubernetes cluster with kubectl . The article shows how to install the HNC manager and the kubectl‑hns plugin, for example:

$ kubectl apply -f https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-v0.5.1/hnc-manager.yaml

$ curl -L https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-v0.5.1/kubectl-hns -o ./kubectl-hns

$ chmod +x ./kubectl-hns

$ export PATH=${PWD}:${PATH}

After installation you can create a parent namespace and child namespaces, then link them with HNC:

$ kubectl create ns hnc-parent
$ kubectl create ns hnc-child-1
$ kubectl create ns hnc-child-2
$ kubectl hns set hnc-child-1 -p hnc-parent
$ kubectl hns set hnc-child-2 -p hnc-parent
$ kubectl hns tree -A

By default, Role and RoleBinding objects defined in the parent are inherited by the children. The article demonstrates this with a pod-reader role:

$ kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods -n hnc-parent
$ kubectl get role -n hnc-child-1 --show-labels
$ kubectl get role -n hnc-child-2 --show-labels

Two practical use cases are presented:

Self‑provisioning: Developers can create child namespaces without needing cluster‑level permissions, while the parent supplies default NetworkPolicies, Roles, ResourceQuotas, etc.

Application template: A parent namespace defines shared backend, DB, and frontend services; a child namespace can host a modified frontend deployment for isolated testing.

The conclusion notes that HNC fills a missing multi‑tenant capability in Kubernetes, but it is still experimental and requires more community feedback. Open issues include making HNCConfiguration namespace‑scoped, handling name collisions between parent and child objects, and fixing inheritance of cluster‑level resources such as Services.

Readers are encouraged to follow the project’s GitHub repositories, join the Kubernetes multi‑tenancy working group, and stay updated on future developments.