Hey, I think there may have been a misunderstanding. Definitely agree with you on the complexity of weighing O notation costs for distributed systems. What I'm

Hey, I think there may have been a misunderstanding. Definitely agree with you on the complexity of weighing O notation costs for distributed systems. What I'm talking about, and I think the OP I replied to is referring to, is the monetary and compute cost in CPU and memory overhead of the kubelet and it's associated processes on real-world deployments. There are plenty of other costs associated with Kubernetes, of course. GKE charges a fixed cost to operate the consensus protocol (etcd) and control plane (kube-apiserver) on their own systems. On the nodes the user operates, the costs then are relatively fixed, that is, there is some amount of CPU time and memory spent per node on logging, metrics, and so on, but as the node gets larger, that quantity does not increase. (It's definitely sublinear.) Or in other words: you can more greatly increase the capacity of a GKE cluster by doubling the size (CPU/memory) than doubling the number of nodes. Scaling up will increase gross capacity by 100% while increasing overhead by a few percent at most, scaling out will have the same increase in gross capacity, but also increase the amount spent on node overhead by 100%.