Document cluster resilience around upgrade

**This is a Feature Request**

**What would you like to be added**
Add details about how to maintain resilience for your Kubernetes cluster during an upgrade.

**Why is this needed**
We have https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/#upgrade-other as a task-oriented guide but it doesn't tell you much about the design considerations and constraints.

_**For example**_ if you upgrade etcd then a 3-node etc cluster is briefly unable to tolerate some forms of partial outage (the surviving node cannot detect that it is the sole healthy survivor). You could set up a witness / fencing mechanism; a more cloud native approach is to scale it out to 5 nodes, do the upgrade and scale in.

**Comments**
Aim to cover the [mixed version proxy](https://kubernetes.io/docs/concepts/architecture/mixed-version-proxy/) concept; in fact, we could move that page to be a heading in a new page if we add one.

/sig cluster-lifecycle
/sig architecture

/language en
/kind feature

Start with the existing cluster upgrade task page and the mixed version proxy page named in the issue. Read how those pages describe upgrades, then outline the design considerations and constraints for maintaining cluster resilience, including the etcd example. Done means a documented page or section that covers these considerations and the mixed version proxy concept.

Written by the indexing model from the issue text.