1. 网关：将流量导入集群

流量首先被路由到一个入口点，该入口点是流量的守门人。

将域名映射到一个虚拟IP地址，该IP地址代表我们的服务，并将流量转发到实际服务实例，为我们提供了更高的可用性和更大的灵活性。
虚拟IP地址被绑定到一种称为反向代理的入口点类型。反向代理是一个负责将请求分发到后端服务的中间组件，它不对应任何特定的服务。反向代理还可以提供负载均衡等功能，这样请求就不会压垮任何一个后端。

在一个入口点托管多个不同的服务被称为虚拟主机托管。我们需要一种方法来决定将特定请求路由到哪个虚拟主机。

2. Istio 网关

创建网关

Gateway资源配置Envoy监听80端口并等待HTTP流量。

运行网关的Pod（无论是默认的istio-ingressgateway，还是自定义网关）必须能够监听集群外部公开的端口或IP地址。
如果部署在像Google Container Engine(GKE)这样的云服务上，要确保使用LoadBalancer类型的服务，该服务将获得一个外部可路由的IP地址。

当流量进入网关时，我们需要通过一种方法将流量路由到服务网格中特定的服务，为此，我们将使用VirtualService资源。

正如你在spec.gateways字段中所看到的，这些流量规则仅适用于来自coolstore-gateway网关的流量。

现在应该可以看到一个成功的响应。

Ingress规范只将80端口和443端口视为入口点。这严重限制了集群运营者允许进入服务网格的流量类型。例如，如果有Kafka或NATS.io工作负载，你可能希望向这些消息传递系统公开TCP连接，但Kubernetes Ingress不允许这样做。
Ingress只能支持最基本的HTTP路由，最终导致需要将代理的其他高级功能放入到注解（annotation）中，而注解的方式在多个代理之间是不兼容的，无法移植。如果Istio继续这一趋势，将会有更多的注解用来解释Envoy作为边缘网关的所有能力。
最终，Istio决定重新构建入口网关，并将第4层（传输层）和第5层（会话层）的属性从第7层（应用层）路由关注点中分离出来。Istio的Gateway处理第4层和第5层的问题，而VirtualService处理第7层的问题。

创建webapp-credential密钥，支持https

重定向配置

Istio的网关足够强大，不仅可以服务于HTTP/HTTPS流量，还可以服务于TCP流量。例如，我们可以通过入口网关公开数据库（如MongoDB）或消息队列（如Kafka）。
纯TCP流量不具备高级特性，例如重试、复杂的路由等。
Kubernetes Ingress 默认不支持TCP or UDP services，Ingress 可以使用--tcp-services-configmap和--udp-services-configmap这两个配置达到转发端口的目的。

在默认的istio-ingressgateway上公开31400端口。就像HTTP端口（80和443）一样，TCP端口31400必须作为一个NodePort或作为一个云LoadBalancer。