HNC has been archived
#SRGThe Service Reliability Group mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
Hierarchical Namespaces Controller(HNC)
IntroductionWhat is HNC?History of the archiveTechnical impactsAlternatives and future responsesShort-term solution: Transition to ECRMid- to long-term measures: Consider transition to alternative technologiesConclusion
Introduction
Hierarchical Namespaces Controller(以下、HNC)

HNC is a convenient controller that realizes hierarchical management of Namespaces, and we also used it for tenant isolation, etc. It was a very useful tool in the context of platform engineering, so many people may be surprised.
gcr.io
What is HNC?
HNC is a tool for hierarchical management of Namespaces in a Kubernetes cluster. It can propagate various policies such as RBAC and NetworkPolicy from parent to child between Namespaces, and is widely used to efficiently manage large-scale multi-tenant environments and complex microservice configurations.
for example:
team-a-stg
- RBAC and NetworkPolicy set in the parent can be automatically applied to child Namespaces.
It can be used like this.
At our company
- Manages common components for ArgoCD and cert-manager
- Create and separate namespaces for each product
- Delegating Namespace Administration to Developers
It was a convenient mechanism for managing multi-tenant configurations easily and safely.
Our use cases
History of the archive
Further discussion on the HNC archive took place in the following GitHub issue:
Here we will introduce some key points from the content.
- At the SIG Auth meeting on February 26, 2025, it was officially decided to archive the HNC project.
- The main reasons are a lack of maintainers and few adoption cases.
- SIG Auth Meeting Note:
Conclusion: Archive HNC and start a new project
Reason: It seems impractical to revive existing HNC projects and hand them over to new maintainers.
- Q&A
- Will HNC be integrated into Kubernetes core?
- There are no such plans.
- Why didn't you join the core?
- To be included in the core, it would have had to be an order of magnitude more prevalent than it is now.
- alternative plan
- Kubernetes multitenancy functionality varies by vendor
- Kubernetes core prioritizes providing extension points over contentious features like multitenancy.
As of now, no official forks have been confirmed.
However, there is a possibility that it may be restarted as an unofficial fork or a separate project by volunteers, so we should continue to keep an eye on it.
Technical impacts
As is the case with many OSS projects, archived does not necessarily mean that it will no longer be usable.
However, there is another problem with HNC this time.
Google Container Registry
Google Container Registry
- March 18, 2025: Stop writing new images
- April 22, 2025: Stop reading existing images← This is important!
Artifact Registry
hnc-manager
Alternatives and future responses
Short-term solution: Transition to ECR
hnc-manager
Mid- to long-term measures: Consider transitioning to alternative technologies
Accurate
Capsule
Another option is to create in-house tools or use original scripts, but the balance with maintenance costs needs to be considered.
Conclusion
This article covers the following points:
- HNC will be officially archived on April 17, 2025
- The latest version of HNC depends on GCR, but GCR itself will become unreadable from next Tuesday (April 22, 2025).
- As a short-term measure, we recommend that you immediately switch to a separate registry such as ECR.
- As a mid- to long-term measure, we recommend adopting alternative technologies such as Accurate or considering a unique operating method.
We ask that those who use HNC take action and share information.
SRG is looking for people to work with us. If you are interested, please contact us here.