Kubernetes高可用集群Flannel报SubnetManager错误求助

我来帮你分析下这个问题，看起来你在基于CoreOS 1688.5.3搭建Kubernetes 1.10高可用集群时，遇到了Flannel DaemonSet Pod进入CrashLoopBackoff的情况，核心问题是Pod无法通过ClusterIP（10.96.0.1）访问API Server，直接访问Master节点IP却正常。结合你提供的信息，我整理了可能的原因和对应的解决步骤：

核心问题分析 #

从你的描述来看，虽然Service的Endpoints配置正确，iptables中也存在Kubernetes Service的规则，但这些规则并未实际触发流量转发，导致Flannel Pod访问超时。这通常和kube-proxy的运行状态、iptables链的规则完整性/顺序或者节点网络配置有关。

具体排查与解决步骤 #

1. 检查kube-proxy的运行状态 #

kube-proxy是负责维护Service对应的iptables规则的核心组件，如果它未正常运行或规则生成不完整，就会导致ClusterIP无法转发流量。

• 首先查看所有节点上的kube-proxy Pod状态：

  kubectl get pods -n kube-system | grep kube-proxy
  

  确保所有Pod都处于Running状态，如果有CrashLoopBackoff或Pending的情况，查看Pod日志定位问题：

  kubectl logs <kube-proxy-pod-name> -n kube-system
  

• 如果kube-proxy运行异常，直接删除Pod让DaemonSet重新创建：

  kubectl delete pod <kube-proxy-pod-name> -n kube-system
  

2. 验证kube-proxy生成的iptables规则完整性 #

你提到KUBE-SVC-NPX46M4PTMTKRN6Y链的规则存在，但未触发，需要检查对应的后端转发链（KUBE-SEP-*）是否有正确的DNAT规则：

• 查看具体的SEP链规则：

  iptables -t nat -S KUBE-SEP-SIIK55AX7MK5ONR7
  

  正常情况下应该包含类似以下的规则：

  -A KUBE-SEP-SIIK55AX7MK5ONR7 -s 10.106.73.226/32 -j KUBE-MARK-MASQ
  -A KUBE-SEP-SIIK55AX7MK5ONR7 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.106.73.226:6443
  

  如果缺少这些规则，说明kube-proxy未正确生成规则，重启kube-proxy Pod即可。

3. 修复iptables链顺序问题 #

你手动添加的DNAT规则放在了KUBE-SERVICES链之后，而PREROUTING链是按顺序执行规则的，先触发KUBE-SERVICES，如果里面的规则未匹配才会执行后面的手动规则，这会导致手动规则无法生效。建议删除手动添加的规则，让kube-proxy自动维护：

iptables -t nat -D PREROUTING -d 10.96.0.1/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.106.73.226:6443

4. 检查节点的IP转发配置 #

Kubernetes节点需要开启IPv4转发才能实现流量的跨节点转发，如果未开启，会导致ClusterIP的流量无法正确路由：

• 检查当前配置：

  sysctl net.ipv4.ip_forward
  

• 如果输出为net.ipv4.ip_forward = 0，临时开启：

  sysctl -w net.ipv4.ip_forward=1
  

• 为了确保重启后依然生效，编辑/etc/sysctl.conf文件，添加或修改：

  net.ipv4.ip_forward=1
  

  然后执行sysctl -p生效。

5. 验证本地访问ClusterIP的规则 #

在Master节点上直接访问10.96.0.1时，流量走的是OUTPUT链，需要确保OUTPUT链中的KUBE-SERVICES规则正确触发：

• 查看OUTPUT链的规则顺序：

  iptables -t nat -S OUTPUT
  

  确保-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES规则在其他可能拦截流量的规则之前。

最后验证 #

完成上述步骤后，重启Flannel Pod：

kubectl delete pod <flannel-pod-name> -n kube-system

然后查看Pod状态：

kubectl get pods -n kube-system | grep flannel

如果Pod进入Running状态，并且能正常访问API Server，问题就解决了。

内容的提问来源于stack exchange，提问作者Rxth