GCP现在为运作于Google Kubernetes Engine(GKE)的应用程序,以及安装在Compute Engine上的Kubernetes,提供原生容器负载均衡。
用户现在能使用网络端点组(Network Endpoint Groups,NEGs),以任意网络端点编写负载均衡器作为IP端口对,并且对容器直接进行负载均衡。通过这个GCP上新的数据模型抽象层,企业可以获得精确Pods的原生运作状况,甚至是负载均衡到Pods之间 。
最初负载均衡器是为支持虚拟机的资源分配而设计,但是这样的设计对于容器来说,并不能达到最佳效能,像是GKE这样的容器协调器( Container Orchestrator),没有一组为Pods定义的后端方法,所以负载均衡器会以实例分组作为后端。
像是GKE中的Ingress支持就以实例分组,使用HTTP/HTTPS负载均衡器对集群中的节点进行负载均衡,这些节点遵循IPTable的规则,将请求路由到Pods中,但由于虚拟机等级的负载均衡器,无法将Pods或是容器视为后端,导致负载不平衡,而且在节点之间还会发生次优路径大量数据流量跳跃的情况发生。
GCP为了解决这些问题,现在具备原生容器负载均衡能力的新网络端点组抽象层与Kubernetes Ingress控制器整合,当企业使用多层部署要在因特网公开一个或多个服务,现在可以创建一个Ingress对象,来负责提供HTTP/HTTPS负载均衡器,让企业可以配置基于路径或是主机的规则,以路由流量到后端服务。
与IPTables相比,原生容器负载均衡能为容器提供真正的最佳负载,由于之前的负载均衡系统并不了解后端容器,因此即使将流量平均分配到实例中,对容器来说也不见得是平均的,而原生容器负载均衡则能根据用户定义的负载均衡算法,将流量均匀分配到后端中。
另外,负载均衡系统具备掌握后端能力后,便能直接对容器进行执行状态检查,而不是将状态检查请求发送到节点上,再由节点转发到随机容器上,因此现在更能准确掌握后端系统运作的健康程度。而当后端的一个Pod被移除后,负载均衡器会原生的处理端点流量,并根据结束连结流量来设置后端服务。
由于负载均衡器可以直接对容器进行操作,负载均衡器到节点间将不会再有流量跳跃,因为负载均衡现在是一步而非两个步骤。原生容器负载均衡还能帮助用户排除Pod层级的故障,该服务保留来源IP,因此能轻易追踪到流量来源,而且由于容器收到的封包来自负载均衡器而非来自其他节点的NAT,因此用户可以使用节点等级的网络政策创建防火墙规则。
原文:https://www.ithome.com.tw/news/126449
登录后评论
立即登录 注册