HA-2x

[kubeasz]

[currycan]

2.x之后就不需要keepalived做虚IP了吗？

[kubeasz]

2.x之后就不需要keepalived做虚IP了吗？

对于k8s本身高可用来说，确实不需要keepalived的vip了；这个也是我修改ha架构的主要原因之一；

[weichunshen89]

2.x的架构规划中，如果增加一个master节点，所有node节点的haproxy配置文件都需要调整？

[currycan]

2.x 之后就不需要 keepalived 做虚 IP 了吗？

对于 k8s 本身高可用来说，确实不需要 keepalived 的 vip 了；这个也是我修改 ha 架构的主要原因之一；

master节点不再是standby，而是多活吗？这样会不会资源变更的时候，两个master节点的scheduler和controller同时工作进行调度，从而出现问题？比如，一个pod资源挂了，两个master节点的controller都监测到了，两个同时创建pod，然后又发现多创建了又同时去删除。。。 循环往复。

[kubeasz]

2.x的架构规划中，如果增加一个master节点，所有node节点的haproxy配置文件都需要调整？

是的，在增加master的脚本中包含所有node节点haproxy配置调整

[kubeasz]

@currycan 你说的情况不存在，无论有多少master节点，controller和scheduler永远通过选举只会有一个工作

[diandiankou]

群主,2.0这种架构，比如我们开发paas平台，需要一个统一的入口访问apiserver，那么是不是还是需要一个vip ，或者说自己的平台跟这个node一样，在自己内部弄一个haproxy？ 如果采用vip 整个集群就一个keepalive+haproxy就行了，现在2.0这种,那不是节点或者需要访问apiserver的平台都需要一个haproxy?

[kubeasz]

@diandiankou 昨天好像在群里已经回答你了，2.x架构对于集群内部来说不需要vip；而对于集群外部访问 apiserver 依然可以选择部署 keepalived+haproxy： ansible-playbook roles/ex-lb/ex-lb.yml，只不过

• ex-lb 是可选的
• 即便安装ex-lb以后，集群内部访问 apiserver和外部访问 apiserver 使用了不同的负载均衡；这样更安全可靠

[diandiankou]

@diandiankou 昨天好像在群里已经回答你了，2.x架构对于集群内部来说不需要vip；而对于集群外部访问 apiserver 依然可以选择部署 keepalived+haproxy： ansible-playbook roles/ex-lb/ex-lb.yml，只不过

• ex-lb 是可选的
• 即便安装ex-lb以后，集群内部访问 apiserver和外部访问 apiserver 使用了不同的负载均衡；这样更安全可靠

@kubeasz 群主，这是在群里问之前发的，不好意思。另外我还想了解的是，基于2.0架构，nodeport方式暴露的服务，由于可以使用任意一台node的ip+port方式进行访问，要对外做统一入口，那也还是需要一个vip对吧。谢谢。

[ffxgamer]

请问, 对于三机部署方案(master与node共用服务器)的话,keepalived不能被支持部署,这个有什么讲究,为什么要这样设置,导致无法使用ex-lb

[gjmzj]

请问, 对于三机部署方案(master与node共用服务器)的话,keepalived不能被支持部署,这个有什么讲究,为什么要这样设置,导致无法使用ex-lb

master/node 共用服务器，本来不是一个好的方式；
kubeasz 2.x 时每个node节点会运行一个haproxy，而ex-lb也需要运行haproxy+keepalived；好想haproxy配置有冲突，所以禁用了node节点运行 ex-lb；具体可以在roles/ex-lb/tasks/main.yml开头放开限制测试下

[yananshiwo]

kubeasz 2.0.3部署，4台服务器，master3个，node1个，选择部署了ex-lb，但是查看状态发现每个MASTER显示的依然是自己的地址，不是VIP
[root@yanan-master01 ~]# kubectl cluster-info
Kubernetes master is running at https://10.1.200.185:6443
CoreDNS is running at https://10.1.200.185:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://10.1.200.185:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://10.1.200.185:6443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

[zhangqingwen]

请问, 对于三机部署方案(master与node共用服务器)的话,keepalived不能被支持部署,这个有什么讲究,为什么要这样设置,导致无法使用ex-lb

master/node 共用服务器，本来不是一个好的方式；
kubeasz 2.x 时每个node节点会运行一个haproxy，而ex-lb也需要运行haproxy+keepalived；好想haproxy配置有冲突，所以禁用了node节点运行 ex-lb；具体可以在roles/ex-lb/tasks/main.yml开头放开限制测试下

是否可以启用ex-lb，而不在每个节点上都运行haproxy呢？

[yushengyin]

kubeasz 2.0.3部署，4台服务器，master3个，node1个，选择部署了ex-lb，但是查看状态发现每个MASTER显示的依然是自己的地址，不是VIP
[root@yanan-master01 ~]# kubectl cluster-info
Kubernetes master is running at https://10.1.200.185:6443
CoreDNS is running at https://10.1.200.185:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://10.1.200.185:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://10.1.200.185:6443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

我这边也是这样，请问您那边有什么解决方案吗

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.