search

lentil1016 / kubeadm-ha

Deprecated! Boot a ha kubernetes 1.11.0/1.12.1/1.13.0/1.14.0 cluster with kubeadm.
GNU General Public License v3.0
214 stars 128 forks source link

3台k8s组ha挂了两台是否会有影响 #21

Closed ppabc closed 6 years ago

ppabc commented 6 years ago

按ha kubernetes 1.11.0/1.12.1 cluster架构图，3台master,如果挂了两台，不会有影响，我测试发现dashboard页面会报Bad Gateway，不会全部切换到正常的节点吗？ VIP是有切换到正常的节点

lentil1016 commented 6 years ago

没影响，Pod漂移属于Kubernetes的行为，请移步Kubernetes Documentation，我将关闭此问题 关于影响请移步https://github.com/Lentil1016/kubeadm-ha/issues/21#issuecomment-442949456

lentil1016 commented 6 years ago

3个master挂掉一个是没有影响的，挂掉两个节点的话，就有影响

我没能成功复现你说的问题 tim 20181128174722

lentil1016 commented 6 years ago

这和单网卡双网卡有任何关系么？你的两个master都已经挂了，它们在网络上就不存在了，只剩下一个孤立的master，它就相当于单点，它的包从哪个网卡出去不都是一样的么？你一台没有连外网的机器要找公网IP，它就是有一万张网卡，结果不还是找不到么？

lentil1016 commented 6 years ago

而且这问题究竟和这个项目有什么关系呢？RTFM好么？

ppabc commented 6 years ago

[root@test111 kubeadm-ha]# cat cluster-info

CP0_IP=192.168.56.104 CP0_HOSTNAME=test111 CP1_IP=192.168.56.105 CP1_HOSTNAME=test222 CP2_IP=192.168.56.107 CP2_HOSTNAME=test333 VIP=192.168.56.199 NET_IF=enp0s3 CIDR=192.168.0.0/16 g20181129144355 g20181129144431

lentil1016 commented 6 years ago

kubectl读取的是~/.kube/config文件获知IP，~/.kube/config来自/etc/kubernetes/admin.conf，该文件由kubeadm在建立集群时生成，出现这个报错说明你的集群本身就有问题，和你有没有关节点都是没关系的。 在默认路由配置正确的情况下，双网卡的集群使用该脚本部署不会出现问题。 本项目只提供最简单的HA方案，首先请确认你的默认路由配置在enp0s3上，如果不能配置默认路由到enp0s3，请自行修改和验证kubeadm-config.yaml，为apiserver, controller, scheduler指定绑定的IP和adviced IP。

ppabc commented 6 years ago

谢谢

opcache commented 6 years ago

我测试1.12.1的，三台都是单网卡，也会出现挂了两个节点，是无法访问dashboard页面 查看 `

docker ps -a |grep api

e31947bd9e2c dcb029b5e3ad "kube-apiserver --au…" 3 minutes ago Exited (255) 3 minutes ago k8s_kube-apiserver_kube-apiserver-test111_kube-system_cee492f53c81e1f41d1e1b9b3a3df4eb_29 7eecac62669a k8s.gcr.io/pause:3.1 "/pause" 25 minutes ago Up 25 minutes

docker ps -a |grep etc

eaa8c7da97c5 3cab8e1b9802 "etcd --advertise-cl…" 6 minutes ago Exited (2) 4 minutes ago k8s_etcd_etcd-test111_kube-system_8f9893457b90d19100028c9ba921788a_27 99468919a853 367cdc8433a4 "/coredns -conf /etc…" 35 minutes ago Up 35 minutes k8s_coredns_coredns-576cbf47c7-z9647_kube-system_b97cf849-f051-11e8-952b-0800273fa07f_5 745e35f66259 367cdc8433a4 "/coredns -conf /etc…" 35 minutes ago Up 35 minutes k8s_coredns_coredns-576cbf47c7-rfzsx_kube-system_b97b7b24-f051-11e8-952b-0800273fa07f_6 c92e3d555233 k8s.gcr.io/pause:3.1 "/pause" 36 minutes ago Up 36 minutes ` 只有一个ETC容器，也是挂了的，启动不了 所以导致kube-apiserver挂了

kubectl get nodes

The connection to the server 192.168.16.166:6443 was refused - did you specify the right host or port? 三个节点，如果挂一个节点，就正常，挂两个就不行了

lentil1016 commented 6 years ago

@opcache 查了一下，ETCD挂掉是一个正常现象，3节点的ETCD集群失去两个节点即为majority loss，将导致ETCD停止服务，直到另两个节点中的某一个恢复连接。如果不想经历该问题，请保证始终只有单点故障，或增加HA集群中的主机数量。

关于Majority Failure

opcache commented 6 years ago

@Lentil1016 感谢回复，为什么ETC挂了的两个容器不能自动迁移到正常的主机？如果可以就能保证ETC高可用了

lentil1016 commented 6 years ago

一方面是做不到，一方面是没必要

首先来说为什么做不到

因为严格的意义上由kubeadm部署的ETCD不属于K8s标准部署，它应该属于所谓的Self-Hosted，也就是在自己的基础上部署自己。如果你观察kubeadm的安装过程，会发现，早在kubectl get pods -n kube-system中出现etcd之前数分钟，etcd的容器就已经在docker中启动了。另外如果你有一些k8s的基本知识你大概会知道，标准部署的manifest是和K8s中所有有状态数据一起由apiserver存放进分布式etcd集群中的。但etcd/apiserver/controller/scheduler这四个组件是例外，在一个节点上，它们启动成功前甚至还没有K8s的基本功能可以用，所以它们并不由K8s负责调度和启动，它们的manifest存放在/etc/kubernetes/manifests文件夹下，由所在机器的kubelet负责启动。那么如果某一台机器挂掉，这些manifest也就变的不可以访问了。所以不可以漂移。

再说为什么没必要

因为对于较为稳定的基础组件来说，高可用的意义主要是规避硬件问题造成的服务中断，就这一点而言，将etcd的多个实例运行在同一台机器上没有太大的意义。