diff options
| author | Bob Wise <bob@bobsplanet.com> | 2017-06-16 14:24:27 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-06-16 14:24:27 -0700 |
| commit | bfed3e323e91ec90d2215ee3d1cf59b316f16e36 (patch) | |
| tree | 9adf91e84be09dde746ac75151330375c02d6152 | |
| parent | 33e8bbe548513d4a83950ffb020df613171b2fc3 (diff) | |
Update goals.md
| -rw-r--r-- | sig-scalability/goals.md | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/sig-scalability/goals.md b/sig-scalability/goals.md index 7866bde8..ae59340f 100644 --- a/sig-scalability/goals.md +++ b/sig-scalability/goals.md @@ -70,6 +70,10 @@ NOTES: * Goal: 90 minutes * Time to restore a fully saturated large cluster is important for cluster-wide failure recovery, and/or related emergency capacity provisioning (e.g. building and populating a new cluster to replace capacity in a failed one). This number also needs to correlate with max pods per cluster, and max scheduler throughput (500,000 pods / 100 pods per second ~ 90 minutes). We believe that this fulfills most real-world recovery requirements. The required time to recovery is usually driven primarily by trying to reduce the probability of multiple uncorrelated cluster failures (e.g. "one of our 3 clusters has failed. We're just fine unless another one fails before we've repaired/replaced the first failed one"). +## Control Plane Configurations for Testing + +Configuration of the control plane for cluster testing varies by provider, and there multiple reasonable configurations. Discussion and guideline of control plane configuration options and standards are documented [here](provider-configs.md). + ## Open Questions 1. **What, if any, reasonable use cases exist for very large numbers of very small nodes (e.g. for isolation reasons - multitenant)? Based on comments so far, it seems that the answer is yes, and needs to be addressed.**<br> |