5 ms·

Having run Kubernetes (GKE) in production and AKS/EKS in trials, that overhead is a fixed marginal cost, not one that grows with node size. When running a small

Having run Kubernetes (GKE) in production and AKS/EKS in trials, that overhead is a fixed marginal cost, not one that grows with node size. When running a small cluster with 1-3 nodes, there are reasons to scale out first (reliability), but margin will improve more quickly by scaling up nodes. GCP makes that conveniently pretty easy with their pricing model for CPU and memory, so it is possible to do this incrementally.

hinkley 5y ago
For capacity planning you have to look at worst case behaviors, and we have a lot of Pollyannas running around crowing about best and average case behaviors. A consensus protocol has O(logn) behavior on any network that displays any of the 8 fallacies of distributed computing. But the larger the cluster the more fallacies you're likely to have to deal with in a given day, and O(logn) is too optimistic. If the cost is ever 'marginal', it's in little islands of stability that won't last long. What I see over and over again is people expending huge opportunity costs trying to keep their brittle system in one of these local maxima as long as they can. I think because they fear that once they slip out of that comfy spot people will see they aren't some miracle worker, they're just slightly above average and really good at story telling.
- marcinzm 5y ago
  I'm honestly not sure what your point is. The cloud provider literally charges a fixed cost irrespective of the number of nodes for managed kubernetes. Sure they may need to deal with scaling issues and costs but that's not the concern of a user who pays a flat fee.
  - hinkley 5y ago
    If the hosting dollar figure for K8s is the only cost you can think of, you're down at the bottom of a well of magic thinking that I'm not qualified to hoist you out of.
    - marcinzm 5y ago
      Huh? This is a thread discussing the hosting costs of kubernetes. I get it, you've got an axe to grind and will apparently do so at any opportunity but I don't see how it's relevant to the discussion.
      - hinkley 5y ago
        The only axe I have in this story is people who downplay the costs of solutions as part of a discussion of pros and cons. We regularly call out pharmaceutical and petrochemical companies here for doing that. I don’t know why you would expect tech to get a free pass. The most important thing is that you don’t fool yourself, and you are the easiest person to fool.
        sealeck 5y ago
        https://m.youtube.com/watch?v=qTiQOaxR1VU https://m.youtube.com/watch?v=qTiQOaxR1VU
- AaronFriel 5y ago
  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%.
- a1369209993 5y ago
  To be fair, average case is useful. It's the reason probabalistic algorithms like quicksort (O(N^2)) and hash tables (O(N)) can work at all in practice. The catch is you have to know what distribution your average is being taken over (Hash tables can be assumed to be a uniform distribution if your hash function is good enough; quicksort can be a uniform distribution, but noone writes it that way until after it blows up in their face, if then.) You do have to know about worst case behaviors. There are no circumstances where best case behavior is worth even calculating for anything other than curiousity, unless you're trying to deny said behavior to a cryptographic adversary (so it's actually your worst case).

hinkley 5y ago

For capacity planning you have to look at worst case behaviors, and we have a lot of Pollyannas running around crowing about best and average case behaviors. A consensus protocol has O(logn) behavior on any network that displays any of the 8 fallacies of distributed computing. But the larger the cluster the more fallacies you're likely to have to deal with in a given day, and O(logn) is too optimistic. If the cost is ever 'marginal', it's in little islands of stability that won't last long. What I see over and over again is people expending huge opportunity costs trying to keep their brittle system in one of these local maxima as long as they can. I think because they fear that once they slip out of that comfy spot people will see they aren't some miracle worker, they're just slightly above average and really good at story telling.

marcinzm 5y ago
I'm honestly not sure what your point is. The cloud provider literally charges a fixed cost irrespective of the number of nodes for managed kubernetes. Sure they may need to deal with scaling issues and costs but that's not the concern of a user who pays a flat fee.
- hinkley 5y ago
  If the hosting dollar figure for K8s is the only cost you can think of, you're down at the bottom of a well of magic thinking that I'm not qualified to hoist you out of.
  - marcinzm 5y ago
    Huh? This is a thread discussing the hosting costs of kubernetes. I get it, you've got an axe to grind and will apparently do so at any opportunity but I don't see how it's relevant to the discussion.
    - hinkley 5y ago
      The only axe I have in this story is people who downplay the costs of solutions as part of a discussion of pros and cons. We regularly call out pharmaceutical and petrochemical companies here for doing that. I don’t know why you would expect tech to get a free pass. The most important thing is that you don’t fool yourself, and you are the easiest person to fool.
      - sealeck 5y ago
        https://m.youtube.com/watch?v=qTiQOaxR1VU https://m.youtube.com/watch?v=qTiQOaxR1VU
AaronFriel 5y ago
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%.
a1369209993 5y ago
To be fair, average case is useful. It's the reason probabalistic algorithms like quicksort (O(N^2)) and hash tables (O(N)) can work at all in practice. The catch is you have to know what distribution your average is being taken over (Hash tables can be assumed to be a uniform distribution if your hash function is good enough; quicksort can be a uniform distribution, but noone writes it that way until after it blows up in their face, if then.) You do have to know about worst case behaviors. There are no circumstances where best case behavior is worth even calculating for anything other than curiousity, unless you're trying to deny said behavior to a cryptographic adversary (so it's actually your worst case).