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，因此用户可以使用节点等级的网络政策创建防火墙规则。
本文转自中文社区-GCP为Kubernetes引擎提供支持原生容器的负载均衡器
