hierarchical-namespaces

README

The Hierarchical Namespace Controller (HNC)

$ 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 and Network Policies 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!

Credits:

• Lead developer: @adrianludwin (aludwin@google.com)
• Current contributors: @yiqigao217, @rjbez17, @GinnyJI
• Other contributors include @sophieliu15, @lafh, @shivi28, @danielSbastos and @entro-pi - thanks all!

Using HNC

Getting started and learning more

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

• Latest version (v0.8.0)
  • Note that this release is in a different repo since we are currently migrating to this new repo. HNC v0.9.0 will be released from this repo.
• Versions of HNC prior to HNC v0.9 are available from our old repo

HNC is also supported by the following vendors:

• GCP: as a part of Hierarchy Controller. Install via Config Sync on GKE or via ACM on Anthos.

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.

Roadmap and issues

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.

HNC is not yet GA, so please be cautious about using it on clusters with config objects you can't afford to lose (e.g. that aren't stored in a Git repository).

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

• v1.0 - Likely late Q2 or early Q3 2021: HNC recommended for production use.
• v0.9: move HNC to its own repo; continued stability improvements.
• v0.1-v0.8: see our old repo for details.

Contact and governance

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.

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

Contributing to HNC

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!

CI infrastructure and release

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.

To release HNC, follow this guide.