$ kubectl hns create my-service -n my-team
$ kubectl hns tree my-team
my-team
└── my-service

Hierarchical namespaces make it easier to share your cluster by making namespaces more powerful. For example, you can create additional namespaces under your team's namespace, even if you don't have cluster-level permission to create namespaces, and easily apply policies like RBAC, Network Policies, and (beta in v1.1) hierarchical resource quotas across all namespaces in your team (e.g. a set of related microservices).

Learn more in the HNC User Guide or get started with the instructions below!

Lead developer: @adrianludwin (aludwin@google.com)

To install HNC on your cluster, and the kubectl-hns plugin on your workstation, follow the instructions on our release pages.

Once HNC is installed, you can try out the HNC quickstart to get an idea of what HNC can do. Or, feel free to dive right into the user guide instead.

Please file issues - the more the merrier! Bugs will be investigated ASAP, while feature requests will be prioritized and assigned to a milestone or backlog.

All HNC issues are assigned to an HNC milestone. So far, the following milestones are defined or planned:

• v1.2: HRQ to GA; server-side listing; stability improvements (ETA late 2023)
• v1.1: Hierarchical quotas; inclusive propagation (released June 23 2023)
• v1.0: HNC recommended for production use (released March 31 2022)

That versions of HNC prior to HNC v0.9 are available from our old repo.

HNC is overseen by the Working Group on Multi-Tenancy (wg-multitenancy). Please join us on Slack, mailing lists, and at our meeting at our community page.

If you use HNC, we recommend joining the kubernetes-hnc-announce mailing list, a low-volume list to receive updates such as new version of HNC and proposed changes or new features.

This project is governed by wg-multitenancy, and was originally located in that repo. It moved to this location after approval by sig-auth in KEP #1687.

The best way you can help contribute to bringing hierarchical namespaces to the Kubernetes ecosystem is to try out HNC and report the problems you have with either HNC itself or its documentation. Or, if it's working well for you, let us know on the #wg-multitenancy channel on Slack, or join a wg-multitenancy meeting. We'd love to hear from you!

But if you're looking for a deeper level of involvement, please check out our contributors guide!

HNC uses Prow to run tests, which is configured here. The presubmits run hack/ci-test.sh in this repo, and the postsubmits and periodics run hack/prow-run-e2e.sh. Results are displayed on testgrid and are configured here. For more information about Prow jobs (e.g. a reference for the configs), see here.

These config files should be inspected periodically (e.g. about once a release) to make sure they're fully up-to-date.

HNC uses Google Cloud Build for building some artifacts. We intend to fully automate our release process using this method over time. See docs/automated-builds.md for more information.

To release HNC, follow this guide.