More details around leader election / failure case (kubernetes#1056)

Author: alexbrand

docs/admin/high-availability/index.md

@@ -185,6 +185,10 @@ cluster state, such as the controller manager and scheduler.  To achieve this re
 instances of these actors, in case a machine dies.  To achieve this, we are going to use a lease-lock in the API to perform
 master election.  We will use the `--leader-elect` flag for each scheduler and controller-manager, using a lease in the API will ensure that only 1 instance of the scheduler and controller-manager are running at once.
 
+The scheduler and controller-manager can be configured to talk to the API server that is on the same node (i.e. 127.0.0.1), or it can be configured to communicate using the load balanced IP address of the API servers. Regardless of how they are configured, the scheduler and controller-manager will complete the leader election process mentioned above when using the `--leader-elect` flag. 
+
+In case of a failure accessing the API server, the elected leader will not be able to renew the lease, causing a new leader to be elected. This is especially relevant when configuring the scheduler and controller-manager to access the API server via 127.0.0.1, and the API server on the same node is unavailable. 
+
 ### Installing configuration files
 
 First, create empty log files on each node, so that Docker will mount the files not make new directories: