<p><a href="https://kubernetes.io/docs/tasks/administer-cluster/highly-available-master/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/administer-cluster/highly-available-master/</a></p>

<blockquote>
  <p><strong>Best practices for replicating masters for HA clusters</strong></p>
  
  <p>Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail. To survive zone
  failure, also place nodes in multiple zones (see multiple-zones for
  details).</p>
  
  <p>Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing
  persistent state. As a result, both replicas are needed and a failure
  of any replica turns cluster into majority failure state. A
  two-replica cluster is thus inferior, in terms of HA, to a single
  replica cluster.</p>
  
  <p>When you add a master replica, cluster state (etcd) is copied to a new instance. If the cluster is large, it may take a long time to
  duplicate its state. This operation may be sped up by migrating etcd
  data directory, as described here (we are considering adding support
  for etcd data dir migration in future).</p>
</blockquote>

<p>I would like to emphasize the following quote</p>

<blockquote>
  <p>A
  two-replica cluster is thus inferior, in terms of HA, to a single
  replica cluster.</p>
</blockquote>

<p>If less then 3 nodes will be used then it is basically more safe to run 1 master, but if one goes down there will be an issue as well. So it is better to run at least three masters.</p>

CC BY-SA 3.0
2017-11-26T12:25:23.443Z
2017-11-26T12:25:23.443Z
030
<p>It's a cash strapped start-up. What are the worst consequences of running only three nodes, three schedulable masters? </p>

<p>Are there some ways can one mitigate against the risks? </p>

<kubernetes><high-availability>
Is making kubernetes masters schedulable a really bad idea?
barrymac
# Is making kubernetes masters schedulable a really bad idea?

(Asked by: username_0 on 2017-08-18)

It's a cash strapped start-up. What are the worst consequences of running only three nodes, three schedulable masters?

Are there some ways can one mitigate against the risks?

**Tags:** kubernetes, high-availability


---

## 1 answers

### Answer by username_1 on 2017-11-26. Score: 3 | Accepted answer

<https://kubernetes.io/docs/tasks/administer-cluster/highly-available-master/>

> **Best practices for replicating masters for HA clusters**
>
> Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail. To survive zone
> failure, also place nodes in multiple zones (see multiple-zones for
> details).
>
> Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing
> persistent state. As a result, both replicas are needed and a failure
> of any replica turns cluster into majority failure state. A
> two-replica cluster is thus inferior, in terms of HA, to a single
> replica cluster.
>
> When you add a master replica, cluster state (etcd) is copied to a new instance. If the cluster is large, it may take a long time to
> duplicate its state. This operation may be sped up by migrating etcd
> data directory, as described here (we are considering adding support
> for etcd data dir migration in future).

I would like to emphasize the following quote

> A
> two-replica cluster is thus inferior, in terms of HA, to a single
> replica cluster.

If less then 3 nodes will be used then it is basically more safe to run 1 master, but if one goes down there will be an issue as well. So it is better to run at least three masters.


---

