关于NodePort服务如何路由流量似乎有两个相互矛盾的解释。服务可以将流量路由到两者之一,而不是两者:
kubectl explain Service.spec.externalTrafficPolicy
和this article,路由进入Service.spec.externalTrafficPolicy=Local
的NodePort服务的数据包到kube-proxy,然后kube-proxy将数据包路由到其运行的相应pod。
endpoints
更新其IP表,其中包含它们可以路由到的豆荚的IP地址。此外,如果您删除服务的标签选择器和edit endpoints,则可以更改流量路由到的位置。如果其中之一是正确的,那我一定是误会了。
endpoints
? Service.spec.externalTrafficPolicy
时服务会遇到路由到节点的麻烦?答案 0 :(得分:3)
Service是由kube-proxy
管理的虚拟地址/端口。服务将流量转发到其关联的终结点,这些终结点通常是Pod,但是正如您所提到的,可以将其设置为任何目标IP /端口。
NodePort Service不会更改服务的端点,NodePort允许外部流量通过节点上的端口进入Service。
kube-proxy
可以使用3 methods来实现服务从节点到目的地的转发。
大多数集群都使用iptables,下面将对此进行介绍。我使用术语“转发”代替“路由”,因为服务使用Network Address Translation(或代理)来“转发”流量,而不是标准网络路由。
服务ClusterIP
是由kube-proxy
管理的虚拟实体。此地址/端口组合在群集中的每个节点上都可用,并将任何本地(pod)服务流量转发到端点IP和端口。
/ Pod (remote node)
Pod -- ClusterIP/Port -- KUBE-SVC-NAT -- Pod
\ Pod (remote node)
带有NodePort
的服务与上面的服务相同,只是增加了一种通过节点将外部流量转发到群集中的方法。 kube-proxy
管理一条附加规则,以监视外部流量并将其转发到相同的服务规则中。
Ext -- NodePort \ / Pod (remote node)
KUBE-SVC-NAT -- Pod
Pod -- ClusterIP/Port / \ Pod (remote node)
externalTrafficPolicy=Local
设置使NodePort服务仅使用 本地Pod服务传入的流量。这避免了网络跃点,而无需再重写数据包的源(通过NAT)。这导致实际网络IP到达为连接提供服务的Pod,而不是群集节点之一成为源IP。
Ext -- NodePort \ Pod (remote node)
KUBE-SVC-NAT -- Pod (local)
Pod -- ClusterIP/Port / Pod (remote node)
我建议尝试跟踪主机上服务或节点端口从源到目标的连接。它需要一些iptables知识,但是我认为这很值得
列出将要转发的所有服务ip /端口:
iptables -vnL -t nat KUBE-SERVICES
列出所有将转发的节点端口:
iptables -vnL -t nat KUBE-NODEPORTS
一旦有了规则,就可以在完整输出中跳过KUBE-SVC-XXX
个“目标”规则。
iptables -vnL -t nat | less
答案 1 :(得分:0)
externalTrafficPolicy: Cluster 不会在 ClusterIP 上使用,尝试删除并应用它,它会工作