diff options
| author | Kevin D <kevdowney@gmail.com> | 2018-03-15 15:00:51 -0700 |
|---|---|---|
| committer | Kevin Downey <Kevin_Downey@intuit.com> | 2018-04-04 09:50:58 -0700 |
| commit | 6a676f126432d40f8a01d32a8315d75e4d80bcf9 (patch) | |
| tree | 60ebee260fc4b4d2b9fa2f970aed1422c7477695 | |
| parent | 9a578e00a340d6071b4e5497ac7eb8aec19dc0a8 (diff) | |
Update ClusterRegistry API doc link
Google Doc is now deprecated in favor of the markdown format in the community repo.
Link: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multicluster/cluster-registry/api-design.md
| -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 588f34ac..bdf0ba3c 100644 --- a/keps/sig-cluster-lifecycle/0003-cluster-api.md +++ b/keps/sig-cluster-lifecycle/0003-cluster-api.md @@ -77,7 +77,7 @@ When another component needs to create or destroy virtual machines, like the nod * Should a single Kubernetes cluster only house definitions for itself? * If so, that removes the ability to have a single cluster control the reconciliation of infrastructure for other clusters. - * However, with the concurrent [Cluster Registry](https://docs.google.com/a/google.com/document/d/1Oi9EO3Jwtp69obakl-9YpLkP764GZzsz95XJlX1a960/edit) project, a good separation of responsibilities would be that the Cluster Registry API is responsible for indexing multiple clusters, each of which would only have to know about itself. In order to achieve cross-cluster reconciliation, a controller would need to integrate with a Cluster Registry for discovery. + * However, with the concurrent [Cluster Registry](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multicluster/cluster-registry/api-design.md) project, a good separation of responsibilities would be that the Cluster Registry API is responsible for indexing multiple clusters, each of which would only have to know about itself. In order to achieve cross-cluster reconciliation, a controller would need to integrate with a Cluster Registry for discovery. * Should a cluster’s control plane definition should be housed within that same cluster. * If the control plane becomes unhealthy, then it won’t be able to rectify itself without external intervention. If the control plane configuration lives elsewhere, and the controllers reconciling its state are able to act in the face of control plane failure, then this API could be used to fix a misconfigured control plane that is unresponsive. * Should our representation of Nodes allow declarative versioning of non-Kubernetes packages, like the container runtime, the Linux kernel, etc.? |