K8S网络排障实录：从Calico Pod启动失败到发现kube-proxy的ipvs模式‘罢工’

K8S网络排障全记录当Calico遇上罢工的IPVS那是一个再普通不过的周五下午我正在为即将上线的Kubernetes集群做最后的网络配置。Calico作为CNI插件已经部署完毕master节点一切正常但node节点上的calico-node Pod却始终无法启动。日志里赫然显示着dial tcp 10.233.64.1:443: i/o timeout——这个ClusterIP正是kube-apiserver的服务地址。看似简单的网络连通性问题却引发了一场从Calico到kube-proxy的深度排障之旅。如果你也遇到过类似问题或是正在使用CalicoIPVS的组合这篇实战记录或许能帮你少走弯路。1. 问题现象与初步诊断当node节点上的calico-node Pod反复崩溃重启时第一反应自然是查看日志。关键错误信息指向了apiserver的连接超时kubectl logs -f calico-node-jv2qv -n kube-system 2022-06-18 04:56:15.613 [INFO][9] startup/startup.go 416: Hit error connecting to datastore - retry errorGet https://10.233.64.1:443/api/v1/nodes/foo: dial tcp 10.233.64.1:443: i/o timeout基础连通性测试是排障的第一步。在node节点上执行ping 10.233.64.1 # ClusterIP可以ping通 telnet 10.233.64.1 443 # 但端口连接失败这立刻排除了底层网络问题——如果连ping都不通问题可能出在路由或网卡配置上。而现在的现象表明网络层可达但传输层出了问题。此时需要思考Kubernetes服务代理的机制ClusterIP是虚拟IP由kube-proxy负责转发我们的集群使用的是ipvs模式请求应该在node节点被ipvs规则拦截并转发到真实后端2. 深入IPVS规则分析检查ipvs规则是接下来的关键步骤ipvsadm -Ln IP Virtual Server version 1.2.1 (size4096) Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.233.64.1:443 rr - 180.64.10.127:6443 Masq 1 2 0规则显示443端口的请求应该被转发到master节点的6443端口apiserver真实地址。手动测试这个真实地址telnet 180.64.10.127 6443 # 连接成功这说明node到master的网络是正常的。那么问题可能出在ipvs的转发过程中。查看连接状态ipvsadm -lnc IPVS connection entries pro expire state source virtual destination TCP 00:51 SYN_RECV 10.233.64.1:35336 10.233.64.1:443 180.64.10.127:6443发现大量连接卡在SYN_RECV状态——这是典型的TCP握手未完成表现。可能的原因包括内核参数配置问题conntrack表满安全组/防火墙拦截ipvs本身bug3. 关键转折切换为iptables模式在多次尝试调整内核参数无果后我决定临时切换kube-proxy模式作为验证kubectl edit cm kube-proxy -n kube-system # 将mode: ipvs改为mode: 删除kube-proxy Pod让其重建后奇迹发生了——calico-node Pod终于启动成功进一步测试发现ping 10.233.64.1 # 不通预期内 telnet 10.233.64.1 443 # 通这才是关键这引出了一个有趣的现象iptables模式下ClusterIP不可ping但服务可访问而ipvs模式下两者都应该通。下表对比了两种模式的特点特性ipvs模式iptables模式ClusterIP可ping是否服务访问通过ipvs规则转发通过iptables规则转发规则规模适合大规模服务规则多时性能下降明显连接状态维护完整连接状态无状态典型问题偶发转发异常规则爆炸4. 根因分析与解决方案虽然切换iptables临时解决了问题但生产环境我们更希望使用ipvs——它的连接跟踪和调度算法对大规模集群更友好。经过深入排查发现问题可能与ipvs和conntrack的交互有关某些内核版本存在ipvs转发异常conntrack表未正确更新导致握手失败安全策略可能干扰了包转发最终解决方案包括以下步骤升级内核到稳定版本建议4.19调整conntrack参数sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait30 sysctl -w net.netfilter.nf_conntrack_max1000000检查并优化kube-proxy配置apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: ipvs ipvs: strictARP: true scheduler: rr excludeCIDRs: []重启节点后ipvs模式工作正常。这次经历让我深刻认识到Kubernetes网络问题往往需要逐层剥离从Pod日志到网络策略从服务发现到代理机制。每个环节都可能成为瓶颈而系统化的排障思路比盲目尝试更重要。