据我所知,Istio目标规则可以定义负载平衡策略,以达到服务的子集,例如,基于不同版本的服务的子集。因此,目标规则是负载平衡的第一级。
请求最终将到达K8s服务,该服务通常由kube-proxy实现。Kube-proxy使用其后端的pod执行简单的负载均衡。这里是负载平衡的第二个级别。
有没有办法删除第二个负载均衡器?例如,我们是否可以创建许多提供相同服务的服务实例,并且可以通过目的地规则进行负载平衡,然后每个服务实例只有一个pod,这样kube-proxy就不会应用负载平衡?
发布于 2020-03-31 20:01:13
根据istio文档:
API的流量路由规则让您可以轻松控制服务之间的流量和
调用。Istio简化了断路器、超时和重试等服务级别属性的配置,并简化了A/B测试、金丝雀部署和基于百分比的流量拆分的分阶段部署等重要任务的设置。它还提供开箱即用的故障恢复功能,帮助您的应用程序在相关服务或网络故障时更加健壮。
Istio的流量管理模型依赖于随您的服务一起部署的特使代理。您的网格服务发送和接收的所有流量(数据平面流量)都通过特使进行代理,从而可以轻松地引导和控制网格周围的流量,而无需对您的服务进行任何更改。
如果您对本指南中描述的功能如何工作的详细信息感兴趣,您可以在architecture overview中找到有关Istio流量管理实现的更多信息。本指南的其余部分将介绍Istio的流量管理功能。
这意味着istio服务网格通过特使代理进行通信,而特使代理又依赖于kubernetes联网。
我们可以举一个例子,使用istio入口网关的VirtualService
根据标签将它的流量负载均衡到两个不同的服务。那么这些服务可以有多个pod。
在这种情况下,Istio负载平衡只在(第7层)上工作,这会导致路由到特定端点(其中一个服务),并依赖kubernetes来处理连接,其余的包括多个pod情况下的服务循环负载平衡(第4层)。
单服务多pods的优点是配置和管理明显更容易。在每个服务有1个pod的情况下,每个服务都需要单独重新配置,并失去其所有扩展功能的能力。
Youtube上有一个很棒的视频,它部分地涵盖了这个话题:Life of a packet through Istio by Matt Turner。
我强烈推荐观看它,因为它解释了istio是如何在基础水平上工作的。
https://stackoverflow.com/questions/60883424
复制相似问题