This message was deleted.

it should scale up fine. It is definitely suitable for production use. The places you might be limited are when you’re dealing with very large clusters that, if using upstream Kubernetes, you might want dedicated hosts to run just specific control-plane components due to the cpu/memory requirements. If you don’t think you’ll ever get that large, you should be fine.

I see.. how large would you say is "very large"

you also need to know whether your workload is going to be fairly static, and just sit there running… or if there’s going to be a lot of churn with pods coming and going and such. Will you deploy an app that makes heavy use of Kubernetes resources and is going to create/update/destroy things all the time and create a bunch of work for the apiserver and datastore, or are you just using Kubernetes to orchestrate a more traditional app that won’t touch Kubernete itself?

no doubt. i recognized that as an unfair question. yet i've architected a variety of systems and there are bullets that can be highlighted relative to how one might think about the sizing. anyways I fully appreciate your point and will certainly be digging further as I drive towards such decisions

sqlite is good for small to medium clusters where you will only have a single server with moderate disk iops. external SQL is good if you have existing database infrastructure or a managed database service (RDS) that you can leverage for HA and backups. etcd is good if you want everything to be self-contained, use etcd snapshots for backup/restore, and can throw some reasonably performant SSD at the servers.

i see.. i've been driving towards an architecture where as much as possible is running on k8s.. for example though i started initially with services like ceph and docker and git external to the cluster.. i'm now running such services on the cluster.. i currently lean towards using etcd.. it seems like the default.. and it seems powerful.. but again i dont pretend to understand all the tradeoffs