记一次kubernetes获取internal Ip错误流程

本文分享自华为云社区《记一次kubernetes获取internal Ip错误流程》,作者:张俭。

偶尔也回首一下处理的棘手问题吧。问题的现象是,通过kubernetes get node输出的ip不是期望的ip地址。大概如下所示

ip addr

eth0 ip1
eth0:xxx ip2

最终输出的不是预期的ip1地址,而是ip2地址。

按藤摸瓜,kubernetes把节点信息保存在/registry/minions/$node-name中的InternalIp 字段。

InternalIp是如何确定的呢,这段代码位于pkg/kubelet/nodestatus/setters.go

            // 1) Use nodeIP if set (and not "0.0.0.0"/"::")
            // 2) If the user has specified an IP to HostnameOverride, use it
            // 3) Lookup the IP from node name by DNS
            // 4) Try to get the IP from the network interface used as default gateway
            //
            // For steps 3 and 4, IPv4 addresses are preferred to IPv6 addresses
            // unless nodeIP is "::", in which case it is reversed.

我们的场景下没有手动设置nodeIp,如需设置通过kubelet命令行即可设置 –node-ip=localhost,最终通过如下的go函数获取ip地址

addrs, _ = net.LookupIP(node.Name)

对这行go函数进行strace追溯,最终调用了c函数,getaddrinfo函数。getaddrinfo底层是发起了netlink请求,开启netlink的抓包

modprobe nlmon
ip link add nlmon0 type nlmon
ip link set dev nlmon0 up
tcpdump -i nlmon0 -w netlinik.pcap
# 使用nlmon 驱动模块,这个nlmon 驱动模块会注册一个 netlink tap 口,用户态向内核发送 netlink 消息、内核向用户态发送 netlink 消息,报文都会经过这个 tap 口。

通过抓包我看到通过netlink报文请求返回的ip地址顺序都是合乎预期的,只能是getaddrinfo函数修改了返回的顺序

Google了一下发现是getaddrinfo支持了rfc3484导致了ip的重新排序,代码地址glibc/sysdeps/posix/getaddrinfo.c

RFC3484 总共有十个规则,比较关键的有

Rule9

   Rule 9:  Use longest matching prefix.
   When DA and DB belong to the same address family (both are IPv6 or
   both are IPv4): If CommonPrefixLen(DA, Source(DA)) >
   CommonPrefixLen(DB, Source(DB)), then prefer DA.  Similarly, if
   CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
   then prefer DB.

举个例子,假如机器的ip地址是 172.18.45.2/24,它会更青睐于172.18.45.6而不是172.31.80.8。这个RFC存在较大的争议,它与dns轮询策略不兼容,如:dns服务器轮询返回多个ip地址,客户端总是选择第一个ip连接。与这个策略存在很大的冲突。并且社区内也有投票试图停止对RFC3484 rule9的适配, 但是最终被拒绝了。

根据分析,认为是ip2的地址小于ip1的地址,最终glibc排序的时候把ip2放在了前面。最终我们给kubelet配置了eth0地址的–node-ip,解决了这个问题。

 

点击关注,第一时间了解华为云新鲜技术~

 

posted @ 2023-12-27 11:09  华为云开发者联盟  阅读(75)  评论(0编辑  收藏  举报