Kube-proxy 可以以若干模式之一运行。在上述日志中，Using iptables Proxier 行表示 kube-proxy 在 "iptables" 模式下运行。 最常见的另一种模式是 "ipvs"。先前的 "userspace" 模式已经被这些所代替。
Iptables 模式在 "iptables" 模式中, 你应该可以在节点上看到如下输出:
iptables-save | grep hostnames -A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 -A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376 -A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 -A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376 -A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000 -A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376 -A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3 -A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ -A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3 -A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR对于每个 Service 的每个端口，应有 1 条 KUBE-SERVICES 规则、一个 KUBE-SVC- 链。 对于每个 Pod 末端，在那个 KUBE-SVC- 链中应该有一些规则与之对应，还应该 有一个 KUBE-SEP- 链与之对应，其中包含为数不多的几条规则。 实际的规则数量可能会根据你实际的配置（包括 NodePort 和 LoadBalancer 服务）有所不同。
IPVS 模式在 "ipvs" 模式中, 你应该在节点下看到如下输出：
ipvsadm -ln Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn ... TCP 10.0.1.175:80 rr -> 10.244.0.5:9376 Masq 1 0 0 -> 10.244.0.6:9376 Masq 1 0 0 -> 10.244.0.7:9376 Masq 1 0 0 ...对于每个 Service 的每个端口，还有 NodePort，External IP 和 LoadBalancer 类型服务 的 IP，kube-proxy 将创建一个虚拟服务器。 对于每个 Pod 末端，它将创建相应的真实服务器。 在此示例中，服务主机名（10.0.1.175:80）拥有 3 个末端（10.244.0.5:9376、 10.244.0.6:9376 和 10.244.0.7:9376）。
Userspace 模式在极少数情况下，你可能会用到 "userspace" 模式。在你的节点上运行：
iptables-save | grep hostnames -A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577 -A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577对于 Service （本例中只有一个）的每个端口，应当有 2 条规则： 一条 "KUBE-PORTALS-CONTAINER" 和一条 "KUBE-PORTALS-HOST" 规则。
几乎没有人应该再使用 "userspace" 模式，因此你在这里不会花更多的时间。
kube-proxy 是否在运行?假设你确实遇到上述情况之一，请重试从节点上通过 IP 访问你的 Service ：
curl 10.0.1.175:80 hostnames-632524106-bbpiw如果失败，并且你正在使用用户空间代理，则可以尝试直接访问代理。 如果你使用的是 iptables 代理，请跳过本节。
回顾上面的 iptables-save 输出，并提取 kube-proxy 为你的 Service 所使用的端口号。 在上面的例子中，端口号是 “48577”。现在试着连接它：
curl localhost:48577 hostnames-632524106-tlaok如果这步操作仍然失败，请查看 kube-proxy 日志中的特定行，如：
Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376]如果你没有看到这些，请尝试将 -V 标志设置为 4 并重新启动 kube-proxy，然后再查看日志。
边缘案例: Pod 无法通过 Service IP 连接到它本身这听起来似乎不太可能，但是确实可能发生，并且应该可行。
如果网络没有为“发夹模式（Hairpin）”流量生成正确配置， 通常当 kube-proxy 以 iptables 模式运行，并且 Pod 与桥接网络连接时，就会发生这种情况。 kubelet 提供了 hairpin-mode 标志。 如果 Service 的末端尝试访问自己的 Service VIP，则该端点可以把流量负载均衡回来到它们自身。 hairpin-mode 标志必须被设置为 hairpin-veth 或者 promiscuous-bridge。