Kubernetes上NodePort与ClusterIP和Headless服务的性能考虑

Question

我们在AWS EKS上运行两种类型的服务：

null

Answer 1

我在下面的标题中为我的答案提供了关于每种连接转发类型以及服务如何转发的更详细的信息。

如果我正确地理解了网络，无头服务似乎需要更少的跳数，因此会（稍微）更快？

不是更快。“额外跳”是数据包遍历本地查找表，它无论如何都要遍历这些表，所以没有明显的区别。目标吊舱仍将与实际网络跳数相同。

节点端口可能有从入口节点到运行POD的节点的额外网络跳转。假设ClusterIP范围被路由到正确的节点（并被路由）

如果您碰巧使用了服务类型:LoadBalancer，可以通过将[.spec.externaltrafficPolicy设置为local][https://kubernetes.io/docs/concepts/services-networking/service/#aws-nlb-support]来改变这种行为，这意味着通信量将只定向到本地pod。

最后，从集群外部使用内部服务的最优雅/性能最好的方式是什么

与集群kube-proxy重新配置相比，config到达ALB需要一点延迟。像滚动部署这样的事情可能不会像pod消失后更新那样无缝。ALB最终有能力自己处理停电。

每个节点上都运行着一个kube-proxy进程，它管理如何以及在哪里放弃连接。kube-proxy有3个选项：Userspace proxy、iptables或ipvs。大多数集群将在iptables上，这将满足绝大多数用例。

转发是通过在userspace中运行的进程来终止和转发连接。很慢。你不太可能用它，不要用它。

- rr: round-robin
- lc: least connection (smallest number of open connections)
- dh: destination hashing
- sh: source hashing
- sed: shortest expected delay
- nq: never queue

需要理解的基本内容是“Service ClusterIP”是集群中的一个虚拟结构，它只作为流量应该去哪里的规则而存在。每个节点都维护所有clusterIP/port到podip/port的规则映射（通过kube-proxy)

ALB路由到任何节点，节点/节点端口将连接转发到处理服务的pod。这可能是一个远程吊舱，涉及通过“电线”发送流量。

ALB>wire>节点>内核转发到SVC(>wire如果远程节点）>Pod

ALB>导线>节点>豆荚

我将此作为后缀，如果将连接转发到VPC中的节点，请求可能需要<1ms的额外延迟。增强的网络实例在低端。可用性区域间的通信可能比AZ内的高一点。如果您碰巧有一个地理上分开的集群，那么控制通信流的重要性可能会增加。例如，拥有一个隧道式印花布网络，它实际上跨越了许多真实的网络。