初次使用keepalived应该注意的

本文详细解析了keepalived配置中容易忽略的关键点,包括vip配置、抢占式切换、接口共享IP功能、关闭SELinux、iptables规则、VIP生效问题等,帮助读者深入理解并有效配置keepalived实现高可用性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

http://www.07net01.com/linux/chucishiyongkeepalivedyinggaizhuyide_58436_1358909551.html

1.如果keepalived做HA的时候只需要配置全局配置 不需要配置lvs部分(废话 呵呵 提示下新手)

 


2.vip指定的时候 最好指定下子网掩码的位数否则可能为出错
example:
我在一次keepalived+haproxy的时候指定vip 没有为其制定子网掩码位数
我是用的事192.168.0.0网段24位子网掩码 结果用ip addr查看我指定的vip时发现其子网掩码位32位 具体原因我没去深究,估计是默认的。

 


3.master和backup需要指定不同的priority 以便于可以产生竞争

 


4.抢占式的master和backup之间的切换
example:
通常如果master服务死掉后backup会变成master但是当master服务又好了的时候 master此时
会抢占成为backup这样就会发生两次切换对业务繁忙的网站来说是不好的。
所以我们要在配置文件加入  nopreempt  非抢占 但是这个参数只能用于state 为backup 故我们在用HA的时候最好master 和backup的state都设置成backup 让其通过priority来竞争
假设在这里master和backup都加入了nopreempt 则此时我们要注意启动keepalived服务的顺序
假设我想让A成为backup那你就不能先启动A的keepalived服务。

 


5.开启接口共享IP功能
确保这个设置的值为1 至于为什么可以参考vrrp的原理一文
net.ipv4.ip_nonlocal_bind=1
 


6.关闭selinux
selinux可能会对实验结果产生影响

 


7.iptables的影响
iptables默认是阻止vrrp报文的 而且有的人可能iptables只开启了22 80 3306等端口
1.关闭iptables
2.在iptables 中加入对vrrp报文的允许  注意书写iptables的时候是-i插入 因为通常大家的iptables最后一条默认都是拒绝的。
iptables -A INPUT -d 224.0.0.18 -j ACCEPT
vrrp广播报文使用的地址是224.0.0.18

 


8.vip无法生效问题
example:可能是配置习惯问题吧,有些人这里一辈子不会出错,有些人就不一样了,
我主要是没太注意0.0.0.0:80和192.168.0.1:80这两者的区别 这两者的区别我知道,前者代表
在本机所有接口的80端口产生套接字监听 后者只是产生了192.168.0.1:80这个套接字 注意我的描述
前者是接口 后者没指定接口  假设我有eth0 eth0:1 那前者会产生两个套接字(什么是套接字? ip:端口->套接字)
后者只会产生192.168.0.1:80这个套接字不针对哪个接口(只要本机网卡接口有192.168.0.1这个IP). 这是这个问题产生的背景

一次我在做haproxy的HA的时候配置都做好了就是不起作用 telnet vip 80就是不产生结果 说明没产生套接字啊 没监听在80端口
找了好长时间没解决最后重新查看haproxy的配置文件 发现自己的fronted是这样写的bind 192.168.0.222:80 看到这里大家应该明白了吧
问题就出在这里 我这样写的话,当vip绑定在eth0口的时候并没有产生相应的套接字。如果这里改成0.0.0.0:80则会产生vip:80和192.168.0.222:80这
两个套接字。0.0.0.0:80这种写法会将所有网卡接口上的IP都产生套接字。这就是解决问题的关键地方。到此问题解决

<think>好的,我现在需要回答用户关于Kubernetes高可用部署的问题。用户提到使用两台NG(可能是Nginx)加Keepalived,并且kubeconfig中的api-server地址是Keepalived的VIP。用户想知道NG是部署在虚拟机还是容器中。 首先,我要确认用户提到的NG是什么。通常在高可用Kubernetes集群中,Nginx作为反向代理或负载均衡器,用于将流量分发到多个API Server实例。Keepalived则用于管理虚拟IP(VIP),确保VIP在某个节点故障时转移到另一个节点。 用户的问题核心在于NG的部署位置。我需要考虑两种可能性:虚拟机或容器。需要分析各自的优缺点,并给出建议。 1. **虚拟机部署**: - 优点:稳定性高,资源独立,管理简单,与物理网络集成更直接。 - 缺点:扩展性较差,需要手动维护。 2. **容器部署**: - 优点:快速部署,易于扩展,符合云原生实践。 - 缺点:网络配置可能复杂,依赖Kubernetes网络策略,如果集群尚未稳定可能引入循环依赖。 用户当前使用Keepalived管理VIP,这可能意味着他们更倾向于传统的高可用方式,通常与虚拟机或物理机配合使用。此外,如果NG部署在容器中,而Kubernetes控制平面尚未完全运行,可能导致启动依赖问题。因此,更常见的做法是将NG和Keepalived部署在虚拟机或物理机上,作为基础设施的一部分,独立于Kubernetes集群。 还需要考虑网络架构。Keepalived需要ARP广播来管理VIP,这在容器网络(尤其是Overlay网络)中可能无法正常工作,因此更适合虚拟机或物理机环境。 最后,给出建议时,应强调根据具体情况选择,但通常推荐虚拟机部署,特别是在初期阶段或对稳定性要求较高的环境中。容器部署适合已经稳定的集群,并需要更动态的管理。</think>这是典型的Kubernetes高可用架构部署问题,让我们通过架构图来解析: ```mermaid graph LR subgraph 物理层 VM1[物理机/虚拟机1] -->|VRRP| VM2[物理机/虚拟机2] end subgraph 服务层 VM1 --> NG1[Nginx] VM2 --> NG2[Nginx] VIP(VIP: 172.20.2.220) end subgraph Kubernetes API1[API Server] API2[API Server] API3[API Server] end NG1 -->|代理| API1 NG1 -->|代理| API2 NG1 -->|代理| API3 NG2 -->|代理| API1 NG2 -->|代理| API2 NG2 -->|代理| API3 ``` **关键点解析**: 1. **部署位置选择原则**: - ✅ **推荐虚拟机部署**的情况: ```bash # 查看keepalived日志示例(需在宿主机操作) journalctl -u keepalived -f ``` - 需要直接管理物理网络(VRRP协议依赖二层广播) - 避免"先有鸡还是先有蛋"问题(控制平面尚未启动时仍需访问API Server) - 对稳定性要求极高的生产环境 - ⚠️ **容器化部署条件**: ```yaml # 需要配置的特殊参数示例 hostNetwork: true # 使用宿主机网络 dnsPolicy: ClusterFirstWithHostNet ``` - Kubernetes集群已稳定运行 - 使用hostNetwork模式绕过CNI插件 - 有成熟的Operator管理方案(如kube-keepalived) 2. **配置示例对比**: **虚拟机部署目录结构**: ``` /etc/keepalived/ ├── keepalived.conf # VIP配置 ├── check_nginx.sh # 健康检查脚本 └── nginx/ └── nginx.conf # 反向代理配置 ``` **容器部署编排差异**: ```dockerfile # Dockerfile特殊要求 RUN apt-get install -y iproute2 keepalived CMD ["sh", "-c", "echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind"] ``` 3. **网络流量走向**: ``` 用户请求VIP:6443 → Keepalived选主 → 主节点Nginx:6443 → 负载均衡到API Server1/2/3:6443 ``` 4. **运维注意事项**: - **脑裂问题检测**: ```bash # 同时检查多个节点的VIP状态 ip addr show | grep 172.20.2.220 ``` - **滚动升级策略**: ```mermaid gantt title Nginx+Keepalived升级流程 section 主节点 停止keepalived :a1, 2023-08-01, 10m 升级软件包 :a2, after a1, 20m 重启服务 :a3, after a2, 5m section 备节点 自动接管VIP :b1, 2023-08-01, parallel a1 重复主流程 :b2, after b1, 25m ``` 5. **性能监控指标**: | 监控项 | 虚拟机部署采集方式 | 容器部署采集方式 | |-----------------|--------------------------|---------------------------| | Nginx连接数 | netstat -antp \| grep 6443 | cAdvisor容器指标 | | VIP漂移次数 | keepalived日志分析 | 需额外暴露keepalived状态 | | 请求延迟 | 节点级Prometheus监控 | ServiceMonitor自动发现 | **最终建议**:对于首次实施Kubernetes高可用方案的用户,建议先在虚拟机部署Nginx+Keepalived组合。待集群稳定运行后,可逐步尝试将部分组件容器化,但需特别注意解决网络命名空间和健康检查的时序问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值