mgianluc

Disclaimer: while I did not work on those scale tests, I am one of the maintainers of one of the open source projects used in those scale tests.

While the largest fleet I have observed under a single hub managed was fewer than 500 clusters, reviewing those performance results provided good insights.

Thought of sharing here as well since on Linkedin a post by the author on those scale tests went viral (almost 700 likes and 50 plus comments)

Its addictive :-) Well done

love it

I have written one tutorial on kubernetes controller myself, and I enjoyed reading this one.

Very nice. My kid is going to love this. Thank you!

First of all, kudos for the work.

Personally I dont care if it is written in Rust or anything else. What I do care is stability, security and features.

I would have enhanced the dashboard a little bit. I understand most of the work was done in the backend. But dashboard is what folks see first. and might lead someone incorrectly judging the work just by looking at that.

Thank you! Appreciate you taking the time to respond and explain. Thanks

great explanation. And cool animations. Might I ask what tool did you use for those?

Thats good honestly and a big relief

Sorry about that. Just out of curiosity, was there any problem/limitation or client just decided a new cluster was needed for any reason (maybe its own ego)?

In that case I would use it in DryRun mode and have it generate a report. Then look at the report and if it makes sense, fix the terraform or ArgoCD configuration.

More on report: https://gianlucam76.github.io/k8s-cleaner/reports/k8s-cleane...

one more thing. It comes with a huge library of use cases already covered. So you don't necessarily need to write any new instance.

You would need to do that only if you have your own proprietary CRDs or some use case that is not already covered.

Agree ability to run also as a binary would be helpful.

It has a DryRun that generates a report on which resources would be affected. So you can see what resources identifies as unused before asking it to remove those. I would be scared as well otherwise. Agree.

Thanks.

Would you'd mind expanding more on "An operator permission granting is a great fundamental layer to add here"

I am not sure I understood correctly (apologies in case).

If I am tenant admin, and I have been given by platform admin full permissions, but only in a namespace/cluster. Then if I install an operator in this namespace/cluster, at most this operator can only have same permissions I have, not more. If operator requires more, tenant admin has posting operator itself will fail (pure Kubernetes RBAC)

Presenting a Kubernetes multi-tenancy solution offered by Sveltos.

Sveltos is an open source project. If you like the idea, be aware contributions are more welcome Thank you

Thank you. I will take a look. Thanks

I have been using ClusterAPI for an internal project at work. One problem I saw when creating tens of clusters per day with ClusterAPI, was that all cluster addons had to be manually installed/upgraded (there are solutions like Flux, which is a solid one, but I did not like the amount of user interaction that was still required). I wanted something capable of automatically discovering clusters and understanding their state.

So I started working on an open source project called projectsveltos https://github.com/projectsveltos .

The main idea of Sveltos is to allow users to programmatically list which addons need to be deployed where (where is expressed using a ClusterSelector which selects all ClusterAPI powered clusters with labels matching the selector).

Helm values can be passed directly. Or Sveltos can be instructed to fetch those from the management cluster.

Having worked in the past in a different startup doing policy distribution in a distributed system, I know visibility is important. So sveltos provides user with DryRun mode as well where user can see the effect of a change before committing it https://github.com/projectsveltos/sveltosctl#display-outcome...

But I was still not happy. Main reason, users still had to go and manage cluster labels. I wanted clusters' labels to change as cluster runtime state was changing. So I can express my intent and then forget about it.

So I introduced a second concept in Sveltos. Classifier CRD (https://github.com/projectsveltos/demos/blob/main/classifier...) which allows users to classify clusters based on cluster runtime state (currently kubernetes version and/or resources deployed, but I am working on adding more).

Doing so I can easily now say: - any cluster running Kubernetes version v1.25.2 needs this version of calico as CNI - as clusters are upgraded to Kubernetes version v1.25.2 the right labels are added on cluster so that right version of calico is deployed.

Sveltos is an open source project. Contributions are more welcome.

If you would like to know more about it or would like to see a new feature added to sveltos, please reach to us on slack. Any feedback is very much appreciated.