diff options
| author | Pablo Carranza <pcarranza@gmail.com> | 2016-11-16 11:15:25 +0300 |
|---|---|---|
| committer | Pablo Carranza <pcarranza@gmail.com> | 2016-11-16 11:15:25 +0300 |
| commit | 7434c9a637d3e5a04088919562eaa3339011762e (patch) | |
| tree | be96c0d3b1af9a44a249bd1ad793c29e5f71f04b | |
| parent | 8ff4db5af6c4f914d20bb724cc320157e7fe9716 (diff) | |
Typos, more typos
| -rw-r--r-- | design/README.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/design/README.md b/design/README.md index 45a070e39..0f97d3426 100644 --- a/design/README.md +++ b/design/README.md @@ -226,7 +226,7 @@ With this we could start doing really neat things and optimize usage by segmenti #### Auto Scaling in Kubernetes -Once we have daemons that can come and go, are ephemeral, and provide an API upstream to access resources we could easily add spawn them as kubernetes pods. These pods would need to have filesystem access (CephFS and NFS can be mounted in a pod like any other filesystem). +Once we have daemons that can come and go, are ephemeral, and provide an API upstream to access resources we could easily spawn them as kubernetes pods. These pods would need to have filesystem access (CephFS and NFS can be mounted in a pod like any other filesystem). The interesting part of doing this is that we could easily auto scale up and down as load increases and decreases. Since these daemons can vanish at any time we could just set it to always keep 3 pods available, but scale them up as they are needed. Since the application load is only related to http requests we could detach web auto scaling from git auto scaling and let them roam free. |