From 92137e89dc5d5f153224ee2d8c23817297105d1a Mon Sep 17 00:00:00 2001 From: Ben Harris Date: Fri, 9 Oct 2015 10:37:12 +1100 Subject: [PATCH] Correct number recommendations The mathematics of the current recommendations didn't seem to give the right outcomes. Especially with `U`, as you need at least `U+1` to keep availability in the face of `U` failures. --- docs/admin/multi-cluster.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/admin/multi-cluster.md b/docs/admin/multi-cluster.md index 046a1848668..d6bd06d701e 100644 --- a/docs/admin/multi-cluster.md +++ b/docs/admin/multi-cluster.md @@ -80,8 +80,9 @@ Second, decide how many clusters should be able to be unavailable at the same ti the number that can be unavailable `U`. If you are not sure, then 1 is a fine choice. If it is allowable for load-balancing to direct traffic to any region in the event of a cluster failure, then -you need `R + U` clusters. If it is not (e.g you want to ensure low latency for all users in the event of a -cluster failure), then you need to have `R * U` clusters (`U` in each of `R` regions). In any case, try to put each cluster in a different zone. +you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g you want to ensure low latency for all +users in the event of a cluster failure), then you need to have `R * (U + 1)` clusters +(`U + 1` in each of `R` regions). In any case, try to put each cluster in a different zone. Finally, if any of your clusters would need more than the maximum recommended number of nodes for a Kubernetes cluster, then you may need even more clusters. Kubernetes v1.0 currently supports clusters up to 100 nodes in size, but we are targeting