diff options
| author | Taoge <wenter.wu@gmail.com> | 2018-02-08 11:13:12 +0800 |
|---|---|---|
| committer | Taoge <wenter.wu@gmail.com> | 2018-02-08 11:13:12 +0800 |
| commit | f73479d17b4060145c13b3b0d41732dc1064d097 (patch) | |
| tree | be6e328e362def3a8a6cd63af09d9c10687dc63b /keps | |
| parent | b69895b10a06f933037200de52910b5320d08013 (diff) | |
> fix some typos
Diffstat (limited to 'keps')
| -rw-r--r-- | keps/sig-cluster-lifecycle/0003-cluster-api.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/keps/sig-cluster-lifecycle/0003-cluster-api.md b/keps/sig-cluster-lifecycle/0003-cluster-api.md index da899d99..c14a949e 100644 --- a/keps/sig-cluster-lifecycle/0003-cluster-api.md +++ b/keps/sig-cluster-lifecycle/0003-cluster-api.md @@ -133,7 +133,7 @@ This level of the Cluster Management API describes the global configuration of a Given the recent efforts of SIG Cluster Lifecycle to make kubeadm the de facto standard toolkit for cloud- and vendor-agnostic cluster initialization, and because kubeadm has [an existing API](https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/kubeadm/v1alpha1/types.go) to define the global configuration for a cluster, it makes sense to coalesce the global portion of the Cluster API with the API used by “kubeadm init” to configure a cluster master. -A current goal is to make these APIs as cloud-agnostic as possible, so that the entire definition of a Cluster could remain reasonably in-sync across different deployments potentially in different cloud providers, which would help enable hybrid usecases where it’s desirable to have key configuration stay in sync across different clusters potentially in different clouds/environments. However, this goal is balanced against making the APIs coherent and useable, which strict separation may harm. +A current goal is to make these APIs as cloud-agnostic as possible, so that the entire definition of a Cluster could remain reasonably in-sync across different deployments potentially in different cloud providers, which would help enable hybrid usecases where it’s desirable to have key configuration stay in sync across different clusters potentially in different clouds/environments. However, this goal is balanced against making the APIs coherent and usable, which strict separation may harm. The full types for this API can be seen and were initially discussed in [kube-deploy#306](https://github.com/kubernetes/kube-deploy/pull/306). |
