K8s集群中NodePort服务在Master节点失效的排查与修复

1. 问题现象与初步分析最近在部署Kubernetes集群时遇到一个典型问题NodePort类型的服务在Worker节点可以正常访问但在Master节点却始终无法连通。具体表现为在Node1和Node2上可以通过telnet测试80端口连通性但在Master节点执行相同操作时却显示连接被拒绝。这个问题其实很常见特别是在混合部署生产环境和开发环境时。我刚开始也以为只是简单的防火墙配置问题但实际排查过程却发现了更深层次的原因。首先需要明确的是Kubernetes的NodePort服务默认会在所有节点包括Master上开放指定端口所以Master节点无法访问显然是不正常的。先说说我的测试环境使用的是Kubernetes 1.22.17版本三节点集群1个Master2个Worker。创建了一个简单的NodePort服务映射到80端口。按照官方文档说明这个端口应该在所有节点都可访问但实际情况却并非如此。2. 基础环境排查2.1 防火墙与SELinux检查遇到网络问题首先想到的当然是防火墙。我执行了以下命令确认防火墙状态systemctl status firewalld getenforce结果显示防火墙是关闭状态SELinux也处于Permissive模式。这排除了最基础的防火墙拦截可能性。网上有些方案建议执行iptables -P FORWARD ACCEPT我也尝试了但问题依旧。2.2 内核参数验证接着检查了内核网络参数特别是IP转发相关的配置cat /etc/sysctl.d/k8s.conf文件内容显示各项参数配置正确net.bridge.bridge-nf-call-ip6tables1 net.bridge.bridge-nf-call-iptables1 net.ipv4.ip_forward1 vm.swappiness0通过sysctl -p重新加载后sysctl net.ipv4.ip_forward确认IP转发确实已启用。这说明基础网络配置没有问题。3. 深入问题根源3.1 kube-proxy模式检测当基础排查无果后我开始怀疑kube-proxy的工作模式。通过以下命令检查当前模式curl 127.0.0.1:10249/proxyMode意外的是输出显示为iptables模式而我清楚地记得集群初始化时配置的是ipvs模式。这显然是个重要线索。3.2 日志分析查看kube-proxy的Pod日志发现了关键报错kubectl logs -n kube-system kube-proxy-xxxxx日志中大量出现cant set sysctl net/ipv4/vs/expire_nodest_conn等错误这表明ipvs模式所需的内核模块可能没有正确加载。虽然集群初始化时指定了--proxy-modeipvs但由于内核支持不完整kube-proxy自动回退到了iptables模式。4. 问题解决方案4.1 切换kube-proxy模式首先需要确保ipvs所需的内核模块已加载modprobe -- ip_vs modprobe -- ip_vs_rr modprobe -- ip_vs_wrr modprobe -- ip_vs_sh modprobe -- nf_conntrack然后修改kube-proxy的ConfigMapkubectl edit cm kube-proxy -n kube-system找到mode字段将其从空值默认iptables改为ipvs。保存退出后需要重建kube-proxy Pod使配置生效kubectl delete pod -n kube-system -l k8s-appkube-proxy4.2 验证修复效果等待新的kube-proxy Pod启动后再次检查代理模式curl 127.0.0.1:10249/proxyMode现在应该显示为ipvs。此时在Master节点执行telnet测试telnet MASTER_IP 80连接应该能够正常建立。如果仍有问题可以进一步检查ipvs规则ipvsadm -Ln5. 原理深度解析5.1 iptables与ipvs模式差异iptables模式是kube-proxy的默认工作方式它通过维护庞大的iptables规则链来实现服务发现和负载均衡。但随着服务数量增加规则列表会呈指数级增长导致性能下降。ipvs模式则利用了Linux内核的IP Virtual Server功能它专为负载均衡设计使用哈希表存储规则查询效率更高。特别是在大规模集群中ipvs的性能优势更为明显。5.2 Master节点特殊性Master节点默认带有node-role.kubernetes.io/master污点这导致常规工作负载不会调度到Master。但kube-proxy作为系统组件仍然会在Master上运行负责处理NodePort流量。当kube-proxy工作在iptables模式时由于某些安全策略限制可能导致Master节点的NodePort无法正常工作。6. 生产环境建议在实际运维中我总结了几个关键点集群初始化时确保所有节点加载了ipvs所需内核模块可以在/etc/modules-load.d/下创建配置文件实现开机自动加载。版本兼容性不同Kubernetes版本对ipvs的支持程度不同建议在1.18版本中使用ipvs模式。混合模式处理某些云厂商的定制化Kubernetes可能修改了默认网络行为需要查阅对应文档。健康检查将NodePort连通性检查纳入集群监控可以编写简单的HTTP探针定期测试。7. 常见问题补充7.1 为什么telnet能通但curl失败这种情况通常说明TCP层已连通但应用层存在问题。可能原因包括Pod内的应用没有监听指定端口网络策略(NetworkPolicy)拦截了流量服务selector与Pod标签不匹配7.2 如何永久保存ipvs内核模块创建/etc/modules-load.d/ipvs.conf文件内容为ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack然后执行systemctl restart systemd-modules-load使配置生效。7.3 多网卡环境下的特殊处理当节点有多个网络接口时需要明确指定--nodeport-addresses参数否则kube-proxy可能会监听错误的IP。例如args: - --nodeport-addresses192.168.1.0/24这个配置告诉kube-proxy只处理指定CIDR范围内的NodePort请求。