Cluster Ingress Gateway
这些类型的ingress实现的示例包括：Envoy Proxy 及其基础上的项目包括：
- Datawire Ambassador
- Solo.io Gloo
- Heptio Contour
基于其他反向代理/负载均衡器构建的其它组件：
- HAProxy
- OpenShift’s Router (based on HAProxy)
- NGINX
- Traefik
- Kong
此层级的集群入口控制器由平台团队操作，但是，这部分基础架构通常与更加去中心化的、自助服务工作流相关联（正如您对云原生平台所期望的那样）。参见The “GitOps” workflow as described by the good folks at Weaveworks
API网关模式关于“ API网关”一词的另一种扩展是我在听到该术语时通常想到的，它是与API网关模式最相似的。Chris Richardson在其“微服务模式”一书第8章很好地介绍了这种用法。我强烈建议您将此书用于此模式和其他微服务模式学习资料。可在他的microservices.io网站API Gatway Pattern可以进行快速浏览。简而言之，API网关模式是针对不同类别的消费者来优化API的使用。这个优化涉及一个API间接访问。您可能会听到另一个代表API网关模式的术语是“前端的后端”，其中“前端”可以是字符终端（UI）、移动客户端、IoT客户端甚至其它服务/应用程序开发人员。
在API网关模式中，我们明显简化了一组API的调用，以模拟针对特定用户、客户端或使用者的“应用程序”内聚API。回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API网关模式有助于恢复此概念。这里的关键是API网关，一旦实现，它将成为客户端和应用程序的API，并负责与任何后端API和其他应用程序网络端点（不满足上述API定义的端点）进行通信。
与上一节中的Ingress控制器不同，此API网关更接近开发人员的视角，而较少关注哪些端口或服务暴露以供集群外使用的方面。此“ API网关”也不同于我们管理现有API的API管理视角。此API网关将对后端的调用聚合在一起，这可能会公开API，但也可能是与API描述较少的东西，例如对旧系统的RPC调用，使用不符合“ REST”的协议的调用（如通过HTTP但不使用JSON），gRPC，SOAP，GraphQL、websockets和消息队列。这种类型的网关也可用来进行消息级转换、复杂的路由、网络弹性/回退以及响应的聚合。
如果您熟悉REST API的Richardson Maturity模型，就会发现相比Level 1–3，实现了API网关模式的API网关来集成了更多的Level 0请求（及其之间的所有内容）。
https://martinfowler.com/articles/richardsonMaturityModel.html
这些类型的网关实现仍需要解决速率限制、身份验证/授权、断路、度量收集、流量路由等问题。这些类型的网关可以在集群边缘用作集群入口控制器，也可以在集群内部用作应用程序网关。
