diff options
| author | Xingcai Zhang <zhangxingcai@ghostcloud.cn> | 2017-11-10 22:14:29 +0800 |
|---|---|---|
| committer | Xingcai Zhang <zhangxingcai@ghostcloud.cn> | 2017-11-10 22:14:29 +0800 |
| commit | 98d60cc0d29d7b1b6f2b03dc77045794a4962943 (patch) | |
| tree | dde33f40dd274d55151f9ce897ba4492a76c9ec8 | |
| parent | 58bd5ba03e5d98042793e4bf8069541058d8480f (diff) | |
update word accessible and unambiguous
| -rw-r--r-- | contributors/design-proposals/instrumentation/resource-metrics-api.md | 2 | ||||
| -rw-r--r-- | contributors/design-proposals/multicluster/federation-lite.md | 6 |
2 files changed, 4 insertions, 4 deletions
diff --git a/contributors/design-proposals/instrumentation/resource-metrics-api.md b/contributors/design-proposals/instrumentation/resource-metrics-api.md index b5840b75..075c6180 100644 --- a/contributors/design-proposals/instrumentation/resource-metrics-api.md +++ b/contributors/design-proposals/instrumentation/resource-metrics-api.md @@ -20,7 +20,7 @@ Use cases which are not listed below are out of the scope of MVP version of Reso HPA uses the latest value of cpu usage as an average aggregated across 1 minute (the window may change in the future). The data for a given set of pods -(defined either by pod list or label selector) should be accesible in one request +(defined either by pod list or label selector) should be accessible in one request due to performance issues. #### Scheduler diff --git a/contributors/design-proposals/multicluster/federation-lite.md b/contributors/design-proposals/multicluster/federation-lite.md index afdd6c02..3dd1f4d8 100644 --- a/contributors/design-proposals/multicluster/federation-lite.md +++ b/contributors/design-proposals/multicluster/federation-lite.md @@ -86,7 +86,7 @@ service of type LoadBalancer. The native cloud load-balancers on both AWS & GCE are region-level, and support load-balancing across instances in multiple zones (in the same region). For both clouds, the behaviour of the native cloud load-balancer is reasonable in the face of failures (indeed, this is why clouds -provide load-balancing as a primitve). +provide load-balancing as a primitive). For multi-AZ clusters we will therefore simply rely on the native cloud provider load balancer behaviour, and we do not anticipate substantial code changes. @@ -170,8 +170,8 @@ GCE. If you had two volumes both named `myvolume` in two different GCE zones, this would not be ambiguous when Kubernetes is operating only in a single zone. But, when operating a cluster across multiple zones, `myvolume` is no longer sufficient to specify a volume uniquely. Worse, the fact that a volume happens -to be unambigious at a particular time is no guarantee that it will continue to -be unambigious in future, because a volume with the same name could +to be unambiguous at a particular time is no guarantee that it will continue to +be unambiguous in future, because a volume with the same name could subsequently be created in a second zone. While perhaps unlikely in practice, we cannot automatically enable multi-AZ clusters for GCE users if this then causes volume mounts to stop working. |