Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-26T12:25:23.443Z
Answers: 2017-11-26T12:25:23.443Z
Answers: 030
Body: <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>
  
Tags: <kubernetes><high-availability>
Title: Is making kubernetes masters schedulable a really bad idea?
UserDisplayName: barrymac
ThreadText: # 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.
  
  
  ---
  
  