Allow dots '.' in namespaces to help with name collisions and reflect pseudo-hierarchy
ElSamhaa opened this issue · 2 comments
Where I work, we are working on a multi-tenancy model that spans multiple tools. We use . as a level separator to avoid naming collisions and apply some kind of pseudo-namespacing -- similar to that of Java packages -- and it's allowed in many tools. However, when it comes to k8s, sadly . are not allowed in namespaces.
This project solves many multi-tenancy problems, but I think there is room for improvement in the name-uniqueness area.
What I would suggest is to work on either of the following features:
- allow dots in namespaces
- ensure namespace uniqueness only on a FQCN level.
Hi @ElSamhaa , unfortunately this would be a breaking change to the core Kubernetes API, and so it's highly unlikely to be approved. All existing Kubernetes clients assume that all namespace names are valid DNS Labels (63 alphanumeric characters, plus '-'), so allowing anything else would break existing clients.
As an example, Kubernetes currently names services after their namespaces (e.g. <service>.<namespaces>.svc.cluster.local, so any client that splits on dots and assumes there will be exactly 5 components will break.
Such breaking changes may not actually be impossible to make but would require an extremely high demonstration of need. I've never seen anything that would come close.
As an alternative, you could consider hashing your names (including the dots) and using those to enforce K8s namespace uniqueness, while taking your names (including the dots) and adding that as an annotation to your K8s namespaces. Alternatively, you could simply replate the dots with dashes, which would not guarantee uniqueness (e.g. "foo.bar-baz" and "foo-bar.baz" would both map to "foo-bar-baz") but hopefully such collisions would be rare.
Please feel free to join us on Slack or the mailing list to discuss any other concrete problems you're having, but I'm going to close this particular suggestion.
/close
@adrianludwin: Closing this issue.
In response to this:
Hi @ElSamhaa , unfortunately this would be a breaking change to the core Kubernetes API, and so it's highly unlikely to be approved. All existing Kubernetes clients assume that all namespace names are valid DNS Labels (63 alphanumeric characters, plus '-'), so allowing anything else would break existing clients.
As an example, Kubernetes currently names services after their namespaces (e.g.
<service>.<namespaces>.svc.cluster.local, so any client that splits on dots and assumes there will be exactly 5 components will break.Such breaking changes may not actually be impossible to make but would require an extremely high demonstration of need. I've never seen anything that would come close.
As an alternative, you could consider hashing your names (including the dots) and using those to enforce K8s namespace uniqueness, while taking your names (including the dots) and adding that as an annotation to your K8s namespaces. Alternatively, you could simply replate the dots with dashes, which would not guarantee uniqueness (e.g. "foo.bar-baz" and "foo-bar.baz" would both map to "foo-bar-baz") but hopefully such collisions would be rare.
Please feel free to join us on Slack or the mailing list to discuss any other concrete problems you're having, but I'm going to close this particular suggestion.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.