本文分享自华为云社区《记一次kubernetes获取int服务器托管网ernal 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))举个例子,假如机器的ip地址是
172.18.45.2/24
,它会更青睐于172.18.45.6
而不是172.31.80.8
。这个RFC存在较大的争议,它与dns轮询策略不兼容,如:dns服务器轮询返回多个ip地址,客户端总是选择第一个ip连接。与这个策略存在很大的冲突。并且社区内也有投票试图停止对RFC3484rule9的适配, 但是最终被拒绝了。根据分析,认为是ip2的地址小于ip1的地址,最终glibc排序的时候把ip2放在了前面。最终我们给kubelet配置了eth0地址的–node-ip,解决了这个问题。
点击关注,第一时间了解华为云新鲜技术~
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
作者:vivo 互联网服务器团队 – Chen Han 容器平台针对业务资源申请值偏大的运营问题,通过静态超卖和动态超卖两种技术方案,使业务资源申请值趋于合理化,提高平台资源装箱率和资源利用率。 一、背景 在Kubernetes中,容器申请资源有request…