Kubernetes服务:请求分配算法

Question

kubernets服务用于将请求分配给它公开的pod的逻辑算法是什么？这个算法可以定制吗？

谢谢。

Answer 1

用户空间模式下的

kube-proxy通过循环算法选择后端。iptables模式的kube-proxy会随机选择一个后端。IPVS为平衡到后端Pod的流量提供了更多选项；这些选项包括:rr:循环调度，lc:最少连接(最小打开连接数)，dh:目标散列，sh:源散列，sed:最短预期延迟，nq:从不排队

正如这里提到的：- Service

对于应用程序级路由，您将需要使用服务网格，如istio、envoy、kong。

Answer 2

您可以使用组件kube-proxy。那是什么？

Kubernetes proxy是一个网络代理，它运行在集群中的每个node上，实现了

Service概念的一部分。kube-proxy在节点上维护网络规则。这些网络规则允许从群集内部或外部的网络会话与Pod进行网络通信。kube-proxy使用操作系统包过滤层，如果有且可用的话。否则，kube-proxy会自行转发流量。

但是，既然有round-robin DNS algorithm，为什么还要使用代理呢？使用proxying for Services有几个原因：

DNS实现不尊重记录TTL的历史由来已久，在它们应该让expired.

• Some应用程序只执行一次DNS查找并缓存结果indefinitely.

• Even之后，缓存名称查找的结果如果应用程序和库进行了适当的重新解析，则
• 记录上的低TTL或零TTL可能会对DNS施加高负载，然后变得难以管理。

kube-proxy有许多模式：

• -在用户空间模式下，iptables规则转发到go二进制文件(kube-proxy)正在侦听连接的本地端口。二进制文件(在用户空间中运行)终止连接，建立到服务的后端的新连接，然后将请求转发到后端，并将响应返回给本地进程。用户空间模式的一个优点是，因为连接是从应用程序创建的，所以如果连接被拒绝，应用程序可以重试到不同的backend
• 。在iptables模式中，安装iptables规则以将目的地为服务的数据包直接转发到该服务的后端。这比将数据包从内核移动到kube-proxy，然后再返回到内核更有效，因此它可以带来更高的吞吐量和更好的尾部延迟。主要缺点是更难调试，因为您必须检查来自内核处理的日志，而不是本地二进制文件将日志写入/var/log/kube-proxy。iptables iptables- IPVS是专门为负载平衡设计的Linux内核特性。在IPVS模式下，kube-proxy对IPVS负载均衡器进行编程，而不是使用iptables。这是可行的，它还使用了成熟的内核功能，IPVS是为负载平衡大量服务而设计的；它具有优化的API和优化的查找例程，而不是顺序规则列表。

你可以阅读更多的here -关于StackOverflow代理模式的好问题，here -比较代理模式和here -关于代理模式的好文章。

就像他在回答中提到的rohatgisanat一样，您也可以使用service mesh。这里还有一篇关于Kubernetes service mesh comparsion的好文章。