4 ms·

> This allows one to take one physical Kubernetes cluster and chop it up into smaller virtual clusters. What is the benefit, or difference of this over namespa

> This allows one to take one physical Kubernetes cluster and chop it up into smaller virtual clusters. What is the benefit, or difference of this over namespaces in Kubernetes? Namespaces provide resource quotas, and they work with RBAC too, the benefits listed in the README and their descriptions, they sound exactly what namespaces already provide.

jayvanguard 7y ago
That was my question as well.
sz4kerto 7y ago
Possibly: testing and learning environments.
rtempaccount1 7y ago
(IMO) this isn't intended to be a product, it's an experiment in different ways to run Kubernetes workloads
- alexellisuk 7y ago
  k3s is on the way to becoming "production-ready", this appears to use k3s in the code. Perhaps it could be once it's proven out as something the community can use?
p932 7y ago
Currently if you have only access to a namepsace on a shared Kubernetes cluster without cluster wide admin control you won't be able to: - Create cluster wide RBAC ClusterRole or ClusterRoleBinding - Create or get access to cluster-scoped resources (nodes, CRD) - Use custom webhooks for example using sidecar injection Many of the things that complex Kubernetes deployments are doing nowadays.
- alexellisuk 7y ago
  The point is that it's unsafe to allow tenants ClusterRole / admin on a shared cluster, but this is needed for many CRDs and Operators. The Operator pattern is getting more and more popular, and most of then need ClusterRole. As the service provider (internal team, or SaaS provider), this is a liability. The aim, from reading the README.md, is to provide the ability for each tenant to be ClusterRole / admin within their own cluster, hosted in a larger real cluster. Jessie Frazelle has talked about this before, I'm not sure if this is the exact blog link, but it's related: Kubernetes in Kubernetes - https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/ https://blog.jessfraz.com/post/hard-multi-tenancy-in-kuberne...

jayvanguard 7y ago

That was my question as well.

sz4kerto 7y ago

Possibly: testing and learning environments.

rtempaccount1 7y ago

(IMO) this isn't intended to be a product, it's an experiment in different ways to run Kubernetes workloads

alexellisuk 7y ago
k3s is on the way to becoming "production-ready", this appears to use k3s in the code. Perhaps it could be once it's proven out as something the community can use?

p932 7y ago

Currently if you have only access to a namepsace on a shared Kubernetes cluster without cluster wide admin control you won't be able to: - Create cluster wide RBAC ClusterRole or ClusterRoleBinding - Create or get access to cluster-scoped resources (nodes, CRD) - Use custom webhooks for example using sidecar injection Many of the things that complex Kubernetes deployments are doing nowadays.

alexellisuk 7y ago
The point is that it's unsafe to allow tenants ClusterRole / admin on a shared cluster, but this is needed for many CRDs and Operators. The Operator pattern is getting more and more popular, and most of then need ClusterRole. As the service provider (internal team, or SaaS provider), this is a liability. The aim, from reading the README.md, is to provide the ability for each tenant to be ClusterRole / admin within their own cluster, hosted in a larger real cluster. Jessie Frazelle has talked about this before, I'm not sure if this is the exact blog link, but it's related: Kubernetes in Kubernetes - https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/ https://blog.jessfraz.com/post/hard-multi-tenancy-in-kuberne...