Question

我正在尝试使用kubeadm设置多个主设置，即k8的HA设置。我正在使用同一https://v1-10.docs.kubernetes.io/docs/setup/independent/high-availability/

的官方文档

在文档中提到的步骤中，有一个步骤说对apiserver使用故障转移，并显示了keepalived作为示例。我的用例是在3个裸机节点上部署k8s HA集群。在裸机场景中，我可能不得不在AWS和gcp实例上部署群集（不使用云功能）

我可以使用kvm在硬件上运行的虚拟机上实现ha设置。在这种情况下，keepalived会按预期工作。在执行此操作时，我指定了虚拟IP。执行kubeadm init命令时，我使用与--apiserver-advertise-address相同的虚拟ip。

在vms情况下，我可以看到在默认网络接口（即第一个虚拟机上的eth0）上配置了虚拟IP，如果我在第一个vm上停止了keepalived服务，则BACKUP keepalived节点将扮演Master角色并将虚拟IP配置为该虚拟IP。虚拟机eth0。

现在，我正在尝试在aws和gcp实例上实现相同的行为。为此，我浏览了一些博客来设置Keepalived。例如，https://icicimov.github.io/blog/high-availability/Keepalived-in-Amazon-VPC-across-availability-zones/ AWS不支持多播。我在keepalived conf中添加了与单播相关的更改，并尝试了，但是根据博客，我们需要使用aws cli为实例配置虚拟IP。如果我不使用aws cli，那么我将面临大脑分裂的情况，例如保持3个实例都配置了虚拟IP。即，如果我选中ip addr show，则可以看到在所有节点的默认接口上配置的虚拟IP。脑裂情况不是预期的行为，但可以达到目的。

它如何达到我的目的？假设我使用的是虚拟IP 10.0.1.100，并且我有3个AWS EC2实例。启动keepalived之后，我看到在所有节点上的eth0上配置了10.0.1.100 ip。请检查以下内容，

ip addr显示节点0的输出

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 12:8a:74:70:01:24 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.230/24 brd 10.0.1.255 scope global dynamic eth0
       valid_lft 2634sec preferred_lft 2634sec
    inet 10.0.1.100/32 scope global eth0
       valid_lft forever preferred_lft forever

ip addr显示节点1的输出

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 12:6a:54:70:12:54 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.231/24 brd 10.0.1.255 scope global dynamic eth0
       valid_lft 2634sec preferred_lft 2634sec
    inet 10.0.1.100/32 scope global eth0
       valid_lft forever preferred_lft forever

ip addr显示节点2的输出

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 12:bf:62:e1:d9:e4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.232/24 brd 10.0.1.255 scope global dynamic eth0
       valid_lft 2634sec preferred_lft 2634sec
    inet 10.0.1.100/32 scope global eth0
       valid_lft forever preferred_lft forever

如您所见，在上述情况下，我们存在脑裂的情况，需要保持活力。现在，如果我提供与--apiserver-advertise-address相同的虚拟ip 10.0.1.100，则可以使用10.0.1.100:6443解析apiserver api，如果一个节点出现故障，则可以访问此api。

尽管脑部情况分散，但我仍可以访问集群和kube系统吊舱，即kube-proxy，kube-dns，apiserver，控制器管理器，调度程序在一个节点出现故障的情况下也可以正常工作。有人看到这个有什么问题吗？请提出解决问题的方法。

使用kubeadm尝试Kubernetes HA时出现问题

0 个答案: