It is expected to be faster when using the NodePort since the request does not rely on the kube-proxy to forward the traffic to the target. It also depends on the way the kube-proxy is configured.
User space: This mode gets its name because the service routing takes place in kube-proxy in the user process space instead of in the kernel network stack. It is not commonly used as it is slow and outdated. iptables: This mode uses Linux kernel-level Netfilter rules to configure all routing for Kubernetes Services. This mode is the default for kube-proxy on most platforms. When load balancing for multiple backend pods, it uses unweighted round-robin scheduling. IPVS (IP Virtual Server): Built on the Netfilter framework, IPVS implements Layer-4 load balancing in the Linux kernel, supporting multiple load-balancing algorithms, including least connections and shortest expected delay. This kube-proxy mode became generally available in Kubernetes 1.11, but it requires the Linux kernel to have the IPVS modules loaded. It is also not as widely supported by various Kubernetes networking projects as the iptables mode.
ref: https://www.stackrox.io/blog/kubernetes-networking-demystified/#kube-proxy On a side note, recently a new feature gate was introduced local service-traffic-policy . While it's still going through the kube-proxy, it will also reduce roundtrips since it routes traffic only to the same node. Maybe you want to test this as an experiment.
1条答案
按热度按时间dbf7pr2w1#
It is expected to be faster when using the
NodePortsince the request does not rely on the kube-proxy to forward the traffic to the target.It also depends on the way the kube-proxy is configured.
User space: This mode gets its name because the service routing takes place in kube-proxy in the user process space instead of in the kernel network stack. It is not commonly used as it is slow and outdated.
iptables: This mode uses Linux kernel-level Netfilter rules to configure all routing for Kubernetes Services. This mode is the default for kube-proxy on most platforms. When load balancing for multiple backend pods, it uses unweighted round-robin scheduling.
IPVS (IP Virtual Server): Built on the Netfilter framework, IPVS implements Layer-4 load balancing in the Linux kernel, supporting multiple load-balancing algorithms, including least connections and shortest expected delay. This kube-proxy mode became generally available in Kubernetes 1.11, but it requires the Linux kernel to have the IPVS modules loaded. It is also not as widely supported by various Kubernetes networking projects as the iptables mode.
ref: https://www.stackrox.io/blog/kubernetes-networking-demystified/#kube-proxy
On a side note, recently a new feature gate was introduced local service-traffic-policy . While it's still going through the kube-proxy, it will also reduce roundtrips since it routes traffic only to the same node. Maybe you want to test this as an experiment.