如果主节点发生故障，会发生什么情况

Question

我有一个关于主工作节点服务路由的基本查询

我浏览了好几个帖子，但我找不到答案

让我们假设以下设置

10.10.10.32   - Master Node (only-one master node)
10.10.10.1    - Worker Node #1
10.10.10.2    - Worker Node #2

nginx conf

upstream example {
server 10.10.10.1:30001;  #worker-node1
server 10.10.10.2:30001;  #worker-node2
}
server {
server_name domainname.com
location / {
proxy_pass http://example
}
}

当我点击domainname.com时，请求将发送到上游，客户端将接收响应

如果我理解正确，在'master node failure'的情况下，我们仍然可以到达'upstream servers'，客户将收到响应编辑

问题#1

why not we schedule the pods as 'static pods'?

如果请求能够到达上游服务器，即使是在'master node failure'的情况下

注意：我知道静态吊舱由kubelet维护，无法通过控制平面到达

问题#2

关于上述设置，当服务被击中时，是否与主节点有任何关系？

or in other words

主节点是否只需要控制调度、维护复制集等，而不是在服务受到攻击时？

Answer 1

即使主服务器在前几周关闭，我们也能提供服务

当主节点出现故障时，在工作节点上运行的任何pod仍将运行，但在主节点恢复联机之前无法修改。它们可能仍然可以访问，这取决于您的Ingress设置。

主节点做两件事：为接收传入请求的API提供服务，并将集群的当前状态写入etcd数据库。

一个节点总是使用RAFT共识协议被选为"领导者"。你需要奇数的选民才能防止票数相等。因此，如果两个主节点中的一个发生故障，集群将变得无头。至少需要3个主节点。或者使用一个节点并严格备份etcd。这里有一个有用的链接