了解如何部署网关代理，以确保应用拥有正确的流量路由、安全性和隔离性。kgateway 具有高度的灵活性，你可以根据自己的环境选择最合适的部署方式。你可以参考以下推荐的部署模式，选择如何部署 gateway proxies。
API Gateway and ingress controller
你可以将 kgateway的Envoy gateway proxy用作快速、灵活、并且完全原生于 K8s的Ingress controller ，同时作为新一代API网关，用于聚合并统一访问你的所有 API。
Simple ingress
下图展示了一个场景：
一个gateway proxy作为整个K8S集群内工作负载的single ingress API gateway 。该gateway由kgateway控制面集中管理，并根据你定义的流量管理、弹性和安全规则进行配置，用来匹配并转发进入的流量。
这个架构非常适合作为使用kgateway的入门方式，也适用于规模较小的环境：在这些环境中，所有工作负载都运行在同一个集群里，并且流量只需要在服务之间进行均衡分发。但是在更大的环境中，或者在既包含高流量服务又包含低流量服务的环境里，你可能需要部署多个 gateway proxy，以更均匀地分配流量负载。
Sharded gateway
在大型环境中，或者在同时拥有高流量与低流量服务的环境里，你可以通过“分片网关”来实现服务之间的隔离，从而避免noisy neighbors问题。采用分片网关架构时，通常会部署多个gateway proxy，每个代理负责集群中不同服务的部分流量。下图展示了这种将流量按照服务进行拆分的方式。
所有gateway proxies都由kgateway控制面统一管理。不过，其中一个gateway proxy管理来自foo和bar两个命名空间中的工作负载的流量。
第二个gateway proxy 则是专门为 extra 命名空间中的工作负载提供服务的专用 API 网关。这两个 gateway proxies 都直接暴露在边缘（edge）上。
虽然这种架构非常适合在不同应用之间拆分流量、并进行负载均衡，但在某些情况下，你可能不希望这些 gateway proxies 直接暴露在边缘。
相反，你可能希望使用一个中心入口的 gateway proxy（central ingress gateway proxy），先对所有进入集群的流量应用统一的流量管理、弹性和安全规则，然后再将流量转发给专门针对某些应用、团队或命名空间的其他 gateway proxies。
要了解更多关于这种部署模式的信息，请参阅 “带中心入口的分片网关（Sharded gateway with central ingress）”。
Sharded gateway with central ingress
下图展示了一个gateway proxy，它作为所有流量的主要入口端点。该gateway proxy可以被配置为对所有进入集群的流量应用统一的流量管理、弹性和安全策略。例如，你可以在流量被转发到第二层gateway proxies之前，在这个入口网关上设置header操作策略。如果你需要一个统一的IP地址和DNS名称来作为所有流量的入口，这种方式会非常有用。
第二层 gateway proxies可以对进入特定应用的流量应用额外的流量管理、弹性和安全策略。你也可以对这一层的代理进行分片，以更好地处理高流量和低流量服务，避免“邻居噪声”问题。所有gateway proxies都由同一个kgateway控制面管理。
根据你现有的部署情况，你可能希望使用不同类型的代理作为中心入口端点。例如，你的环境中可能已经有一个HAProxy，或者 AWS NLB/ALB 实例，并且所有流量都必须先经过它们。kgateway 可以与这些类型的代理进行组合使用，如下图所示。
Service mesh gateway
kgateway 可以与你的 Istio 服务网格无缝集成，从而让你能够控制和管理入口流量（ingress）、出口流量（egress）以及网格内部的流量（mesh-internal traffic）。
Ambient mesh
你可以在Istio的ambient mesh中，将kgateway部署为入口网关（ingress）、出口网关（egress），或 waypoint 代理网关，用于服务对应的工作负载。
ambient mesh 会使用节点级别的ztunnel 来在Pod之间路由和保护四层流量（Layer 4），并通过双向 TLS（mTLS）进行加密。waypoint proxies 则会在需要时执行七层（Layer 7）的流量策略。
下图展示了一个暴露在边缘（edge）的 gateway proxy，它为 ambient mesh 提供流量服务。网格中的服务彼此之间通过 mTLS（双向 TLS）进行通信。
Sidecar mesh
你可以将 kgateway 与 Istio sidecar 一起部署，用于向 Istio sidecar mesh 中的服务路由流量。下图展示了一个暴露在边缘的 gateway proxy，它为 sidecar mesh 提供流量服务。
在此网格中，服务之间通过双向TLS（mTLS）进行通信，通信是通过注入到应用中的 istio-proxy sidecar 完成的。在图中，该 sidecar 使用 Envoy 的图标表示。
AI and Agentic Gateway
传统的API网关、反向代理，以及像Envoy这样的AI网关，都是为REST风格的微服务设计的。在这些系统中，一个网关接收来自客户端的短生命周期short-lived HTTP 请求，选择一个后端，然后将请求转发过去。
Agentic AI 的工作负载不同。它们保持长生命周期的long-lived状态，并进行双向消息交换。这类工作负载通常还非常消耗资源。因此，传统网关可能会遇到性能下降，甚至出现故障。
AI工作负载需要的，是能够在大规模环境下处理会话（sessions）和消息上下文（message context）的网关。Agentgateway是一个开源、高可用、高可扩展、企业级的数据面，专门为AI agents、MCP工具服务器以及LLM提供商提供AI连接能力。你可以使用kgateway作为控制面，在 Kubernetes环境中快速启动和管理 agentgateway 代理的生命周期。
