我的不负责任的K8s网络故障排查经历与分享
作者 | 骆冰利
来源 | Erda 公众号
某天晚上,客户碰到了这样的问题:K8s 集群一直扩容失败,所有节点都无法正常加入集群。在经过多番折腾无解后,客户将问题反馈到我们这里,希望得到技术支持。该问题的整个排查过程比较有意思,本文对其中的排查思路及所用的方法进行了归纳整理并分享给大家,希望能够对大家在排查此类问题时有些帮助和参考。
问题现象
运维同学在对客户的 K8s 集群进行节点扩容时,发现新增的节点一直添加失败。初步排查结果如下:
- 在新增节点上,访问 K8s master service vip 网络不通。
- 在新增节点上,直接访问 K8s master hostIP + 6443 网络正常。
- 在新增节点上,访问其他节点的容器 IP 可以正常 ping 通。
- 在新增节点上,访问 coredns service vip 网络正常。
该客户使用的 Kubernetes 版本是 1.13.10,宿主机的内核版本是 4.18(centos 8.2)。
问题排查过程
收到该一线同事的反馈,我们已经初步怀疑是 ipvs 的问题。根据以往网络问题排查的经验,我们先对现场做了些常规排查:
- 确认内核模块 ip_tables 是否加载(正常)
- 确认 iptable forward 是否默认 accpet (正常)
- 确认宿主机网络是否正常(正常)
- 确认容器网络是否正常(正常)
- ...
排除了常规问题后,基本可以缩小范围,下面我们再继续基于 ipvs 相关层面进行排查。
1. 通过 ipvsadm 命令排查
10.96.0.1 是客户集群 K8s master service vip。
如上图所示,我们可以发现存在异常连接,处于 SYN_RECV 的状态,并且可以观察到,启动时 kubelet + kube-proxy 是有正常建连的,说明是在启动之后,K8s service 网络出现了异常。
2. tcpdump 抓包分析
两端进行抓包,并通过 telnet 10.96.0.1 443 命令进行确认。
结论:发现 SYN 包在本机没有发送出去。
3. 初步总结
通过上面的排查,我们可以再次缩小范围:问题基本就在 kube-proxy 身上。我们采用了 ipvs 模式,也依赖了 iptables 配置实现一些网络的转发、snat、drop 等。
根据上面的排查过程,我们又一次缩小了范围,开始分析怀疑对象 kube-proxy。
4. 查看 kube-proxy 日志
如上图所示:发现异常日志,iptables-restore 命令执行异常。通过 Google、社区查看,确认问题。
相关 issue 链接可参考:
- https://github.com/kubernetes/kubernetes/issues/73360
- https://github.com/kubernetes/kubernetes/pull/84422/files
- https://github.com/kubernetes/kubernetes/pull/82214/files
5. 继续深入
通过代码查看(1.13.10 版本 pkg/proxy/ipvs/proxier.go:1427),可以发现该版本确实没有判断 KUBE-MARK-DROP 是否存在并创建的逻辑。当出现该链不存在时,会出现逻辑缺陷,导致 iptable 命令执行失败。
K8s master service vip 不通,实际容器相关的 ip 是通的,这种情况出现的原因,与下面的 iptable 规则有关:
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
6. 根因探究
前面我们已经知道了 kube-proxy 1.13.10 版本存在缺陷,在没有创建 KUBE-MARK-DROP 链的情况下,执行 iptables-restore 命令配置规则。但是为什么 K8s 1.13.10 版本跑在 centos8.2 4.18 内核的操作系统上会报错,跑在 centos7.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,继续撸下 K8s 代码。
结论:发现确实除了 kube-proxy,还有 kubelet 也会修改 iptables 规则。具体代码可以查看:pkg/kubelet/kubelet_network_linux.go
第二个疑惑,继续凭感觉······Google 一发捞一下为何 kube-proxy 容器挂载了宿主机 /run/xtables.lock 文件的情况下,宿主机和容器 iptables 查看的规则不一致。
结论:CentOS 8 在网络方面摒弃 iptables,采用 nftables 框架作为默认的网络包过滤工具。
至此,所有的谜团都解开了。
团队完成过大量的客户项目交付,这里有些问题可以再解答下:
- 问题一:为什么这么多客户环境第一次碰到该情况?
因为需要 K8s 1.13.10 + centos 8.2 的操作系统,这个组合罕见,且问题必现。升级 K8s 1.16.0+ 就不出现该问题。
- 问题二:为什么使用 K8s 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+ 版本没有该问题。
以上是我们在进行 Kubernetes 网络故障排查中的一点经验,希望能够对大家高效排查,定位原因有所帮助。
如果对于 Erda 项目你有其它想要了解的内容,欢迎添加小助手微信(Erda202106)加入交流群!
欢迎参与开源
Erda 作为开源的一站式云原生 PaaS 平台,具备 DevOps、微服务观测治理、多云管理以及快数据治理等平台级能力。点击下方链接即可参与开源,和众多开发者一起探讨、交流,共建开源社区。欢迎大家关注、贡献代码和 Star!
- Erda Github 地址:https://github.com/erda-project/erda
- Erda Cloud 官网:https://www.erda.cloud/
原文地址:https://www.cnblogs.com/erda/p/14923192.html
上一篇: 如何在 Mac 上设置阿里云服务器?
下一篇: 深入理解IPVS在集群内部的负载均衡技术
推荐阅读
-
我的不负责任的K8s网络故障排查经历与分享
-
分享一下我兼职经历的一些内心感悟与体会
-
小红书大产品部架构 小红书产品概览--经过性能、稳定性、成本等多个维度的详细评估,小红书最终决定选择基于腾讯云星海自研硬件的SA2云服务器作为主力机型使用。结合其秒级的快速扩缩、超强兼容和平滑迁移能力,小红书在抵御上亿次用户访问、保证系统稳定运行的同时,也实现了成本的大幅降低。 星海SA2云服务器是基于腾讯云星海的首款自研服务器。腾讯云星海作为自研硬件品牌,通过创新的高兼容性架构、简洁可靠的自主设计,结合腾讯自身业务以及百万客户上云需求的特点,致力于为云计算时代提供安全、稳定、性能领先的基础架构产品和服务。如今,星海SA2云服务器也正在为越来越多的企业提供低成本、高效率、更安全的弹性计算服务。 以下是与小红书SRE总监陈敖翔的对话实录。 问:请您介绍一下小红书及其主要商业模式? 小红书是一个面向年轻人的生活方式平台,在这里,他们发现了向上、多元的真实世界。小红书日活超过 3500 万,月活跃用户超过 1 亿,日均笔记曝光量达 80 亿。小红书由社交平台和在线购物两大部分组成。与其他线上平台相比,小红书的内容基于真实的口碑分享,播种不止于线上,还为线下实体店赋能。 问:围绕业务发展,小红书的系统架构经历了怎样的变革和演进? 系统架构变化不大,影响最深的是资源开销。过去三年,资源开销大幅增加,同比增长约 10 倍。在此背景下,我们努力进行优化,包括很早就开始使用 K8S 进行资源调度。到 18 年年中,绝大多数服务已经完全实现了容器化。 问:目前小红书系统架构中的计算基础设施建设和布局是怎样的? 我们目前的建设方式可以简单描述为星型结构。腾讯云在上海的一个区是我们的计算中心,承载着我们的核心数据和在线业务。在外围,我们还有两个数据中心进行计算分流,同时承担灾备和线上业务双活的角色。 与其他新兴电子商务互联网公司类似,小红书的大部分计算能力主要用于线下数据分析、模型训练和在线推荐等平台。随着业务的发展,对算力的需求也在加速增长。