某天晚上，客户碰到了 KubeRnetes 集群一直扩容失败，所有的节点都无法正常加入集群。在经过多番折腾无解后，反馈到我们这里进行技术支持。这个问题的整个排查过程比较有意思，所以对其中的排查思路和用到的方法进行整理分享。
问题现象
运维同学在对客户的 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 (正常) 确认宿主机网络是否正常(正常) 确认容器网络是否正常(正常) &hellIP;&hellIP;
排除了常规的问题之后，基本可以缩小范围，再继续基于 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 规则有关：
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+ 版本没有该问题。
