GCP为Kubernetes引擎提供支援原生容器的负载平衡器

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，因此使用者可以使用节点等级的网路政策创建防火墙规则。