典型的服务网格具有一个或多个负载均衡器，也称为网关（Gateway），它们从外部网络终止TLS并允许流量进入网格。然后，流量通过边车网关（Sidecar gateway）流经内部服务。应用程序使用外部服务的场景也很常见，可以直接调用外部服务，或者在某些部署中强制通过专用出口网关（Egress Gateway）离开网格的所有流量。图5-2描绘了网关在网格中的使用情况。
Istio具有入口网关的概念，它扮演网络入口点的角色，负责保护和控制来自集群外部的流量对集群的访问。
图5-2 网关在网格中的使用情况
此外，Istio的网关还扮演负载均衡和虚拟主机路由的角色。如图5-3所示，可以看到默认情况下Istio使用Envoy代理作为入口代理。我们在前面的章节中看到，Envoy是一个功能强大的服务到服务代理，但它也有负载均衡和路由的功能，可代理的流量包括从服务网格外部到其内部运行的服务，或者从集群内部服务到外部服务。在前面章节中介绍的Envoy的所有功能也可以在入口网关中使用。
图5-3 Istio的入口网关服务
对于入口流量管理，你可能会问：为什么不直接使用Kubernetes Ingress API？
第一个原因，Kubernetes Ingress是一个面向HTTP工作负载的非常简单的规范。有Kubernetes Ingress的实现（如Nginx、Heptio Contour等），但每个都适用于HTTP流量。实际上，Ingress规范只将端口80和端口443视为入口点。这严重限制了集群运维人员可以允许进入服务网格的流量类型。例如，如果你有Kafka工作负载，则可能希望向这些消息代理公开直接TCP连接。
第二个原因，Kubernetes Ingress API无法表达Istio的路由需求。Ingress没有通用的方法来指定复杂的流量路由规则，如流量拆分或流量镜像等。这个领域缺乏规范会导致每个供应商重新设想如何更好地为每种类型的Ingress实现（如HAProxy、Nginx等）做好配置管理。Ingress试图在不同的HTTP代理之间取一个公共的交集，因此只能支持最基本的HTTP路由。
最后一个原因，由于事前没有明确规定，大多数供应商的选择是通过部署上的定制注释来做配置。供应商之间的注释各不相同，并且不可移植，如果Istio继续延续这种趋势，那么就会有更多的注释来解释Envoy作为边缘网关的所有功能。
Istio网关通过将L4-L6配置与L7配置分离克服了Ingress的这些缺点。Istio网关只用于配置L4-L6功能（例如，对外公开的端口、TLS配置），所有主流的L7代理均以统一的方式实现了这些功能。然后，通过在Gateway上绑定VirtualService的方式，可以使用标准的Istio规则来控制进入Gateway的HTTP和TCP流量。
负载均衡器可以手动配置或通过服务自动配置其类型，例如type：LoadBalancer。在这种情况下，由于并非所有云都支持自动配置，假设手动配置负载均衡器以将流量转发到IngressGateway Service正在侦听的端口。例如如下的负载均衡器正在监听以下端口：
·HTTP：端口80，将流量转发到端口30080。
·HTTPS：端口443，将流量转发到端口30443。
·MySQL：端口3306，将流量转发到端口30306。
确保负载均衡器配置转发到所有工作节点。这将确保即使某些节点关闭也会转发流量。