<p>So I just started kubernetes and wanted to know if I create multiple masters then how the scheduling of pods is done and if the master goes down what happens to the worker nodes connected to it?</p>

<blockquote>
  <p>How is High Availability Master selected?</p>
</blockquote>

<p>The <strong>etcd</strong> database underneath is where most of the high availability comes from. It uses an <a href="https://github.com/etcd-io/etcd/tree/master/raft" rel="nofollow noreferrer">implementation</a> of the <a href="https://raft.github.io/raft.pdf" rel="nofollow noreferrer">raft protocol</a> for consensus.
etcd requires a quorum of <code>N/2 + 1</code> instances to be available for kubernetes to be able to write updates to the cluster. If you have less than 1/2 available, etcd will go into "read" only mode which means nothing new can be scheduled. </p>

<p><strong>kube-apiserver</strong> will run on multiple nodes in active/active mode. All instances use the same etcd cluster so present the same data. The worker nodes will need some way to load balance / failover to the available apiservers. The failover requires a component outside of kubernetes, like HAProxy or a load balancer device (like AWS provides).</p>

<p><strong>kube-scheduler</strong> will run on multiple master nodes and should access the local instance of kube-apiserver.  The scheduler will elect a leader that locks the data it manages. The current leader information can be found in the endpoint:</p>

<pre><code>kubectl -n kube-system get endpoints kube-scheduler \
  -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
</code></pre>

<p><strong>kube-controller-manager</strong> will run on multiple master nodes and should access the local instance of kube-apiserver.  The controllers will elect a leader that locks the data it manages.  Leader information can be found in the endpoint:</p>

<pre><code>kubectl -n kube-system get endpoints kube-controller-manager \
 -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
</code></pre>

<blockquote>
  <p>if the master goes down what happens to the worker nodes connected to it?</p>
</blockquote>

<p>They continue running in their current state. No new pods will be scheduled and no changes to the existing state of the cluster will be pushed out. Your pods will continue to run until they fail in a way the local kubelet can't recover. </p>
