1. 问题现象与初步排查
在Kubernetes高可用集群的日常运维中,我们经常会进行各种故障模拟测试。最近在进行master节点高可用测试时,遇到了一个有趣的现象:
- 当直接关机master-01、master-02、master-03时,所有节点都能正常显示
NotReady状态 - 当停用master-02和master-03的网卡时,这些节点也能正确显示
NotReady - 但停用master-01的网卡后,虽然VIP(Virtual IP)正常漂移到了master-02,master-01却一直保持
Ready状态
这个现象立即引起了我的警觉。在Kubernetes集群中,节点的Ready状态是调度和运行Pod的基础,如果状态显示不正确,可能会导致Pod被错误地调度到实际上不可用的节点上。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 深入分析与根因定位
2.1 进一步测试验证
为了更深入地理解这个问题,我设计了一系列测试:
- 首先关闭master-01上的keepalived服务,使VIP自动漂移到master-02
- 然后关闭master-01的网卡
- 观察发现,大约45秒后,master-01终于显示为
NotReady状态
这个测试结果表明,问题的出现与VIP的配置有密切关系。
2.2 根因分析
通过查阅Kubernetes相关文档和源码,我发现了问题的本质:
- master-01上的kubelet服务默认绑定的是VIP而非节点的真实IP
- 当master-01的网卡宕机时,VIP已经漂移到了master-02
- kube-controller-manager组件在检查节点状态时,发现VIP所在的kubelet(现在是master-02的kubelet)仍然在正常运行
- 因此,集群误认为master-01节点仍然健康,导致状态显示不正确
重要提示:在Kubernetes高可用集群中,kubelet不应该绑定VIP,而应该始终绑定节点的真实IP。这是保证节点状态准确性的关键配置。
3. 解决方案与实施步骤
3.1 修改kubelet配置
正确的做法是将kubelet绑定到节点的真实IP。以下是具体操作步骤:
bash复制# 登录到master-01节点
ssh ro
