kugarocks

English

简体中文

English

简体中文

Appearance

VIP ​

背景 ​

在使用 Ansible 安装 K8s 集群的时候，配置了 192.168.88.48 作为 VIP 的地址。

Errors
bash
couldn't get current server API group list:
Get "https://kubernetes.foobar.local:6443/api?timeout=32s":
dial tcp 192.168.88.48:6443: i/o timeout

辉哥：RFC 那么多保留地址任选一个也比这个C类好

VIP 用 C 类地址会有概率出问题，是什么意思

ChatGPT said ​

这句话“VIP 用 C 类地址会有概率出问题”，通常是在讨论 高可用系统 或 负载均衡 场景下的。我们一点点拆开来说：

  1. VIP 是什么？

    VIP（Virtual IP，虚拟 IP）常用于 高可用（HA） 场景，比如 Keepalived、LVS、或者 Kubernetes 的一些负载机制，会用 VIP 把请求动态切换到不同的机器。

  2. C 类地址是什么？

    在传统 IP 分类里，C 类地址指的是：

  • IP 范围：192.0.0.0 ~ 223.255.255.255
  • 子网掩码默认是 /24（也就是 255 个主机地址可用） 但在今天，这种“C 类”讲法已经有点过时了，现在更多讲 CIDR（比如 192.168.1.0/24），但大家有时候口头上还会这么说。

  1. 问题在哪里？

    VIP 的漂移或者 ARP 通告，依赖于底层网络的正确处理，比如：

  • ARP（地址解析协议）：当 VIP 切到另一台机器，需要通过 ARP 通知交换机或者其他设备，告诉它 VIP 现在在哪台机器上。
  • 有些交换机/路由器/防火墙对 C 类小网段（特别是私网、局域网地址，比如 192.168.x.x）有特别的缓存策略、安全策略，比如 ARP 缓存更 aggressive，不及时刷新。
  • 或者 广播受限，比如在大网络中，为了减少广播风暴，交换机/VLAN 会限制广播传播，导致 VIP 更新延迟或者丢失。

简单说：

如果 VIP 是 C 类私网地址，比如 192.168.x.x，有可能因为交换机、路由器、甚至主机自身的网络堆栈策略，导致：

  • VIP 漂移后短时间内失效（ARP 缓存没刷新）
  • 某些客户端访问的是旧的 MAC 地址，连不到
  • 广播不通，导致 VIP 无法被及时发现

尤其在复杂网络（比如云上、或者有老旧设备的网络）这种概率会更高。

所以，总结一下这句话的意思是：

👉 “如果用 C 类地址作为 VIP，漂移时在某些网络环境下，有可能出现连接不上或者短暂中断的问题。”

要不要我顺便给你举个实际的例子，比如 Keepalived + C 类网段遇到 VIP 漂移失败的情况？很典型。要的话我可以继续。🚀

4o

You said: ​

bash
couldn't get current server API group list:
Get "https://kubernetes.foobar.local:6443/api?timeout=32s":
dial tcp 192.168.88.48:6443: i/o timeout

这个报错和上面讨论的有关吗

ChatGPT said: ​

是的，这个报错**很可能和前面讨论的“VIP 用 C 类地址会有概率出问题”**是有关联的。

来看你图里的具体错误信息：

🔍 这里可以看到几点：

  • 你在访问 kubernetes.foobar.local，解析到了 192.168.88.48，是个C 类私网 IP（192.168.x.x）。
  • 访问的是 6443 端口，标准的 Kubernetes API Server 端口。
  • dial tcp 报了 i/o timeout，也就是说 TCP 连接都打不通，连三次都是超时。

结合我们上面聊的，很可能的原因是：

  • 这个 192.168.88.48 是一个 VIP（Virtual IP），挂在某个 Kubernetes 控制节点上。
  • 这个 VIP 可能刚漂移了（比如主节点切换、网络波动导致 VIP 从一台机器漂到另一台机器）。
  • 但是因为是 C 类地址（192.168.88.x），而且局域网里交换机/ARP 刷新机制不及时，导致：
    • 客户端（比如 kubelet、kubectl、controller-manager）还缓存着旧的 ARP 表，MAC 地址不对。
      • 发包发到错误的主机或者根本找不到对应的 MAC，所以连接超时。

结果就是 i/o timeout。

🔵 小总结一下：

你的这个报错很可能是因为 VIP 漂移后 ARP 表未及时更新，导致基于 192.168.88.48:6443 的 TCP 连接失败，跟 VIP 用 C 类地址的那种偶发连接问题现象高度吻合。

要不要我顺便告诉你，怎么确认是不是 ARP 问题，以及怎么优化？

（比如抓一下 arp -a，或者直接用 tcpdump 验证漂移过程）

要的话我继续给你补充。⚡️

You said: ​

要不要我顺便告诉你，怎么确认是不是 ARP 问题，以及怎么优化？
（比如抓一下 arp -a，或者直接用 tcpdump 验证漂移过程）
要的话我继续给你补充。⚡️

让 VIP 在上面的例子中走 master 是什么意思

ChatGPT said: ​

好，明白你问的了！

你说的**“让 VIP 走 master”**，在我们上面讨论的场景里，大致是指：

让 VIP 永远绑在当前的主节点（master）上，不乱漂移，或者漂移时只在真正的 master 节点间切换。

结合你的场景（比如 Kubernetes 集群 + VIP），可以有两种理解：

① 让 VIP 固定在主节点（不漂移） ​

如果你 VIP 漂移带来的 ARP 问题太烦，可以考虑直接把 VIP 固定到 Master 节点，也就是：

  • 让 VIP 永远挂在一台（或一组）固定的 Master 节点上。
  • 这样控制节点不会因为 VIP 漂移导致访问中断。
  • 客户端访问 kube-apiserver（如 192.168.88.48:6443）时，总是走同一台（或者控制在小范围内），减少 ARP/网络收敛问题。

典型做法比如：

  • Keepalived 配 priority，优先级固定。
  • 只有 master 角色的节点才有 VIP。
  • 非 master 节点即便检测到 VIP漂移条件，也不抢 VIP。

② VIP 只在 Master 节点之间漂移 ​

如果你仍然希望高可用（比如 Master 故障自动切换），可以设定：

  • VIP 只在 Master 节点们之间切换。
  • Worker 节点绝对不能抢 VIP。
  • 流量始终走 Master 节点，保证 API Server 的稳定性。

比如：

  • 用 Keepalived/HAProxy + VIP，只监听 Master 节点。
  • kube-proxy / kubelet 也只面向 Master 节点。

小总结 ​

你这个场景说的“让 VIP 走 master”，本质上就是想控制 VIP 的归属，避免：

  • VIP 漂移到不合适的节点
  • 导致 ARP 不刷新
  • 导致 kubelet/kubectl 连 kube-apiserver 超时

优化目标就是：VIP 稳定、连接稳定。

要不要我顺便也给你画一张简单的示意图？比如 VIP -> Master1/Master2 漂移的路径？

（很简单直观那种）要的话我给你补一张～⚡️要不要？

4o

You said: ​

如何配置和查看 VIP 只走 api server 的 master

ChatGPT said: ​

好，接下来我分 "配置" 和 "查看" 两部分告诉你，怎么保证 VIP 只在 API Server 的 Master 节点上。

你提到的是 Kubernetes 集群 + VIP（比如 Keepalived/LVS），那基本就是主控节点高可用方案。

🛠 配置：让 VIP 只在 API Server Master 节点上 ​

这里有两种常见方式（看你用的是什么组件）：

1. 使用 Keepalived 配 VIP 漂移（最常见） ​

Keepalived + VIP，直接挂在 Master 节点上。配置思路：

  • 每个 Master 节点都运行 Keepalived。
  • 只在 Master 节点配置 VIP，不在 Worker 节点跑。
  • 用 priority 参数控制主备关系。
  • 配 vrrp_script + track_script，检测 kube-apiserver 是否正常，如果挂了自动降优先级。

Keepalived 配置示例 ​

假设 VIP 是 192.168.88.48，你的 Master 节点有三个：

bash
! Configuration File for keepalived

vrrp_script check_apiserver {
  script "pidof kube-apiserver"  # 也可以 curl 探测 6443 端口
  interval 3
  timeout 5
  fall 2
  rise 2
}

vrrp_instance VI_1 {
    state MASTER  # 这里第一个节点是 MASTER，其他是 BACKUP
    interface eth0  # 根据你的网卡名字调整
    virtual_router_id 51
    priority 100  # 主节点优先级高，其他 90、80
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass 123456
    }

    virtual_ipaddress {
        192.168.88.48
    }

    track_script {
        check_apiserver
    }
}

然后其他 Master 节点把 state 改成 BACKUP，priority 稍微低一点，比如 90、80。

这样，VIP 只在 Master 节点间切来切去，不可能跑到 Worker 节点上。

2. 使用 LVS 或 HAProxy 代理 VIP ​

有时候不是直接用 VIP 漂移，而是用 LVS/HAProxy：

  • 前端是 VIP，比如 192.168.88.48。
  • 后端绑定的是各个 Master 的实际 IP（192.168.88.11:6443、192.168.88.12:6443 之类）。
  • 负载均衡（或健康探测）挂了某个 Master，就自动摘掉。

这种场景 VIP 是固定的，但后端跳转而已。

👀 查看：VIP 现在在哪个 Master 上 ​

你可以这样检查：

1. 在每台 Master 上执行 ​

bash
bash
CopyEdit
ip addr show

看有没有看到 VIP：

txt
sql
CopyEdit
inet 192.168.88.48/32 scope global eth0

哪个节点绑定了 VIP，哪个就是当前的 VIP 所在节点。

2. 通过 ARP 查看 ​

在一台客户端机器上（比如 Worker 节点）：

bash
bash
CopyEdit
arp -an | grep 192.168.88.48

可以看到 VIP 当前对应的 MAC 地址，配合交换机或者服务器上查 MAC，可以定位是哪个 Master 拿着。

3. 用 ping + tcpdump 直接抓包 ​

比如：

bash
bash
CopyEdit
tcpdump -i eth0 host 192.168.88.48

观察 ICMP/Ethernet 层的返回，确认是哪台机器。

🧠 小总结 ​

动作方法
配置 VIP 只在 Master 节点上用 Keepalived + 只在 Master 节点部署 + priority
确认 VIP 位置ip addr / arp / tcpdump

要不要我给你顺便补一版更完整的 Keepalived 配置？比如加上 apiserver 6443 探测的，挂了 VIP 自动漂移那种？⚡

如果要，我可以直接给你出一个可以用的生产版 config。要的话告诉我！🌟