Added a new version of HA clusters guide.

[jszczepkowski]

Added a new version of HA clusters guide.

---

This change is 

[jszczepkowski]

cc @kubernetes/sig-cluster-lifecycle-misc

[jszczepkowski]

cc @fgrzadkowski

[pask81]

I was using the original guide as a reference to setup HA k8s masters on bare metal and while it was very outdated, it still could be considered a starting point for my use case.
I found your commit while looking for updates of the ha guide, but your guide is not useful for my use case.
Moreover, if I understood correctly, you changed even the basic idea of the old guide where master components were instantiated as static pods using yaml manifests, isn't anymore considered a valid choice?

[mikedanese]

@pask81 master components in this guide are started as static pods. See the apiserver setup. Any other major differences?

[pask81]

@mikedanese the apiserver setup you linked belongs to the "old" guide that this commit renames as kubernetes.github.io/docs/admin/high-availability/index-obsolete.md. The "new" guide added by this commit doesn't have any refernece to pods or yaml files.

[polettix]

I like the idea of a "technology agnostic" architecture document describing the general ideas under the HA for different components, but it seems that the new version is tossing away important parts that are probably still "technology agnostic" and also useful for doing things (as opposed to figuring things out).

This seems to be reflected in the non-trivial change in the document goals; compare the new:

This document describes generic architecture of highly-available (HA) kubernetes clusters.

against the old:

This document describes how to build a high-availability (HA) Kubernetes cluster.

I may be missing the bigger picture about HA here, but it seems to me that both kind of documents have a place.

[chenopis]

@jszczepkowski @polettix So how do we want to resolve this?

[jszczepkowski]

Maybe we should keep both documents, the old one and the new one?

[chenopis]

I'm fine w/ that so long as both docs are differentiated in both title and intro summary so that it's immediately clear to the reader which audience/scenario they are intended for.

[steveperry-53]

@jszczepkowski I'll start a docs review now.

[steveperry-53]

@jszczepkowski In the right column, do you have an Allow edits by maintainers box? If so, could you check it. If it's already checked, uncheck and then recheck.

[steveperry-53]

@jszczepkowski I have an edited doc ready to go. As soon as you check Allow edits by maintainers, I'll commit it for your review.

[steveperry-53]

cc @fgrzadkowski @pask81 @mikedanese @polettix @chenopis

Note: I agree with the idea of keeping both documents.

[steveperry-53]

We haven't heard from the author since June 2, 2017. Closing.
If you want to move forward with this, please reopen.