记一次 Kubernetes 网络故障深度追踪

云计算
某天晚上,客户碰到了 Kubernetes 集群一直扩容失败,所有的节点都无法正常加入集群。在经过多番折腾无解后,反馈到我们这里进行技术支持。这个问题的整个排查过程比较有意思,所以对其中的排查思路和用到的方法进行整理分享。

某天晚上,客户碰到了 Kubernetes 集群一直扩容失败,所有的节点都无法正常加入集群。在经过多番折腾无解后,反馈到我们这里进行技术支持。这个问题的整个排查过程比较有意思,所以对其中的排查思路和用到的方法进行整理分享。

[[401640]]

问题现象

运维同学在对客户的 Kubernetes 集群进行节点扩容时,发现新增的节点一直添加失败。该同学进行了初步的排查如下:

  • 在新增节点上,访问 Kubernetes master service vip 网络不通
  • 在新增节点上,直接访问 Kubernetes master hostIP + 6443 网络正常
  • 在新增节点上,访问其他节点的容器 IP 可以正常 ping 通
  • 在新增节点上,访问 coredns service vip 网络正常

该客户使用的 Kubernetes 版本是 1.13.10,宿主机的内核版本是 4.18(CentOS 8.2)。

问题排查过程

收到该一线同事的反馈,我们已经初步怀疑是 IPVS 的问题。根据以往网络问题排查的经验,先对现场做了些常规排查:

  • 确认内核模块 ip_tables 是否加载(正常)
  • 确认 iptable forward 是否默认 accpet (正常)
  • 确认宿主机网络是否正常(正常)
  • 确认容器网络是否正常(正常)
  • ……

排除了常规的问题之后,基本可以缩小范围,再继续基于 IPVS 相关层面进行排查。

通过 ipvsadm 命令排查

10.96.0.1 是客户集群 Kubernetes master service vip。

可以发现有异常连接,处于 SYN_RECV 的状态,并且可以观察到,启动时 kubelet + kube-proxy 是有正常建连的,说明是在启动之后,Kubernetes service 网络出现异常。

tcpdump 抓包分析

两端进行抓包,并通过 telnet 10.96.0.1 443 命令进行确认。

结论:发现 SYN 包在本机没有发送出去。

初步总结

通过上面的排查,可以再次缩小范围,问题基本就在 kube-proxy 身上。我们采用了 IPVS 模式,也会依赖了 iptables 配置实现一些网络的转发、SNAT、drop 等等。

根据上面的排查过程,我们又缩小了范围,开始分析怀疑对象 kube-proxy。

查看 kube-proxy 日志

发现异常日志,iptables-restore 命令执行异常。通过 Google、社区查看,确认问题。

继续深入

通过代码查看(1.13.10 版本 pkg/proxy/ipvs/proxier.go:1427),可以发现该版本确实没有判断 KUBE-MARK-DROP 是否存在并创建的逻辑。当出现该链不存在时,会出现逻辑缺陷,导致 iptable 命令执行失败。

Kubernetes master service vip 不通,但是实际容器相关的 IP 是通的原因,与下面这条 iptable 规则有关:

  1. iptable -t nat -A KUBE-SERVICES ! -s 9.0.0.0/8 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ 

根因探究

前面我们已经知道了 kube-proxy 1.13.10 版本存在缺陷,在没有创建 KUBE-MARK-DROP 链的情况下,执行 iptables-restore 命令配置规则。但是为何 Kubernetes 1.13.10 版本跑在 CentOS 8.2 4.18 内核的操作系统上会报错,跑在 CentOS 7.6 3.10 内核的操作系统上却正常呢?

查看下 kube-proxy 的源码,可以发现 kube-proxy 其实也就是执行 iptables 命令进行规则配置。那既然 kube-proxy 报错 iptables-restore 命令失败,我们就找一台 4.18 内核的机器,进入 kube-proxy 容器看下情况。

到容器内执行下 iptables-save 命令,可以发现 kube-proxy 容器内确实没有创建 KUBE-MARK-DROP 链(符合代码预期)。继续在宿主机上执行下 iptables-save 命令,却发现是有 KUBE-MARK-DROP 链。

这里有两个疑问:

  • 为何 4.18 内核宿主机的 iptables 有 KUBE-MARK-DROP 链?
  • 为何 4.18 内核宿主机的 iptables 规则和 kube-proxy 容器内的规则不一致?

第一个疑惑,凭感觉怀疑除了 kube-proxy,还会有别的程序在操作 iptables,继续撸下 Kubernetes 代码。

结论:发现确实除了 kube-proxy,还有 kubelet 也会修改 iptables 规则。具体代码可以查看 pkg/kubelet/kubelet_network_linux.go

第二个疑惑,继续凭感觉吧。Google 一发捞一下为何 kube-proxy 容器挂载了宿主机 /run/xtables.lock 文件的情况下,宿主机和容器 iptables 查看的规则不一致。

结论:CentOS 8 在网络方面摒弃 iptables 采用 nftables 框架作为默认的网络包过滤工具。

至此,所有的谜团都解开了。

团队完成过大量的客户项目交付,还是有些问题可以再解答下:

  • 问题一:为何这么多客户环境第一次碰到该情况?因为需要 Kubernetes 1.13.10 + centos 8.2 的操作系统,这个组合罕见,且问题是必现。升级 Kubernetes 1.16.0+ 就不会有该问题。
  • 问题二:为何使用 Kubernetes 1.13.10 + 5.5 内核却没有该问题?

因为那是与 CentOS 8 操作系统有关,我们手动升级 5.5 版本后,默认还是使用的 iptables 框架。

可以通过 iptables -v 命令来确认,是否使用了 nftables。

nftables 是何方神圣?比 iptables 好么?这是另一个值得进一步学习的点,这里就不再深入了。

解决方法

针对以上的排查问题,我们总结下解决方法:

  • 调整内核版本到 3.10(CentOS 7.6+),或者手动升级内核版本到 5.0 +;
  • 升级 Kubernetes 版本,当前确认 1.16.10+ 版本没有该问题。

 

 

责任编辑:未丽燕 来源: 知乎
相关推荐

2021-11-11 16:14:04

Kubernetes

2021-01-08 13:52:15

Consul微服务服务注册中心

2021-12-02 07:50:30

NFS故障内存

2023-11-10 07:23:57

Kubernetes集群网络

2021-03-29 12:35:04

Kubernetes环境TCP

2011-01-24 13:42:27

网络故障网络故障修复

2009-05-19 16:40:41

TTL网络故障科来软件

2021-12-06 17:21:05

异常报错故障

2020-08-24 07:34:39

网络超时请求

2023-10-06 20:52:47

2022-12-17 19:49:37

GCJVM故障

2022-06-01 06:17:42

微服务Kafka

2011-03-14 14:13:28

网络故障

2022-01-10 10:26:30

Kubernetes抓包环境

2011-04-13 09:21:30

死锁SQL Server

2022-02-17 11:19:33

Kubernetes服务器运维

2022-01-07 11:48:59

RabbitMQGolang 项目

2017-07-07 16:07:41

2014-08-11 09:31:52

2023-04-06 07:53:56

Redis连接问题K8s
点赞
收藏

51CTO技术栈公众号