eks-anywhere VS gardener

I'd suggest move from rancher to EKS Anywhere and the respective Cluster API providers... Self-managed node pools on top of bottlerocket can be established using common terraform-aws-eks module, otherwise.

There are plenty of vendor specific bugs, like no EBS in [EKS Fargate](https://github.com/aws/containers-roadmap/issues/1113), and settling a Kubernetes cluster on top of Bottlerocket and [EKS Anywhere](https://github.com/aws/eks-anywhere), on your own is somewhat impossible.

To get started with Amazon EKS Anywhere on bare metal, visit the documentation site. To learn more about Amazon EKS Anywhere, visit the product page.

> It has no init system.

Apologies that I can't link directly to the "--init" flag but docker actually does have an init, it's just (err, was?) compiled into the binary: https://docs.docker.com/engine/reference/commandline/run/#op...

My recollection is that it either adopted, or inspired, https://github.com/Yelp/dumb-init#readme which folks used to put into their Dockerfile as the init system back in the day

Folks (ahem, I'm looking at you, eks-anywhere[0]) who bundle systemd into a docker container are gravely misguided, and the ones which do so for the ability to launch sshd alongside the actual container's main process are truly, truly lost

0: https://github.com/aws/eks-anywhere/issues/838#issuecomment-...

EKS anywhere looks like an adventure - https://anywhere.eks.amazonaws.com

That brings us to the end of this walkthrough. Thank you very much for reading and I hope you will give EKS Anywhere a spin. The complete documentation is available here. If you are interested in contributing, please open an issue or pull request on the EKS Anywhere GitHub repo. Let me know your thoughts in the comments below. If you have more questions, feel free to reach out to me on LinkedIn or Twitter.

First class integration and support by most of the cloud providers (DOKS, AKS (Which has been opensourced))

Now, if you want to dig further on how cloud providers operate, like I said, most are actually using Kubernetes to automate the client control plane management. There is a cloud-neutral project for this out there called Gardener, they have a few architecture documents which explain the concept a bit further. In their garden metaphor, the seed cluster hosts the client control planes, and the shoot clusters are the client clusters (which are only made of worker nodes, no control-plane node). Another more specialized implementation is Kubernikus for OpenStack.

Gardener: https://github.com/gardener/gardener RH HyperShift: https://github.com/openshift/hypershift

Gardener does exactly that. One global cluster manages smaller per-region/cloud provider management clusters and those will contain the control planes of your workload clusters. This way you can have like 10 000 clusters and not deal with multi-tenant issues. One workload = 1 cluster.

We had cluster of cluster style management managing 100s of cluster. Check out https://github.com/gardener/gardener for an inspiration

How does this compare against simply using Gardener [0]?

[0] https://github.com/gardener/gardener