Envoy

在普通 HTTP API 中，我们通常只需要限制“每分钟请求数”。但对于大模型接口，仅限制请求数量远远不够：一次请求可能只消耗几十个 Token，也可能消耗数万个 Token。 因此，一个实用的 AI 网关通常需要同时支持： RPM（Requests Per Minute）：每分钟请求数。 TPM（Tokens Per Minute）：每分钟 Token 数。 按租户、API Key、模型或套餐分别计费。 多个 Envoy 实例共享同一份额度。 在高并发条件下避免各实例独立计数造成额度放大。 返回统一的 429 Too Many Requests 和剩余额度信息。 本文介绍如何使用 envoyproxy/ratelimit、Redis 和 Envoy 构建一套分布式 AI 限流系统。 为什么不能只使用 Envoy Local Rate Limit Envoy 提供了 Local Rate Limit Filter，但它的计数器默认位于当前 Envoy 进程中。 假设我们有 4 个 Envoy 实例，并为某个租户配置： RPM = 100 如果每个 Envoy 都独立维护 100 RPM，那么整个集群实际上可能放行： 4 × 100 = 400 RPM 这显然不是我们想要的结果。...

Kubernetes 官方在 2025 年 11 月 11 日发布博客，正式宣布 Ingress NGINX 项目进入退役（Retirement）阶段，并将于 2026 年 3 月彻底停止维护。 这一举措标志着 Kubernetes 在集群入口与流量管理方面正式进入 Gateway API 时代。对于正在使用 Ingress NGINX 的团队，这不仅是一次技术升级，更是一项需要尽快规划的风险管理工作。 本文将基于 Kubernetes 官方退役公告、Gateway API 最新生态与社区最佳实践，系统介绍： 为什么 Ingress NGINX 被退休？ Ingress 模型的根本局限与 Gateway API 的优势 新的推荐替代方案：Envoy Gateway（基于 Gateway API） 如何从 Ingress 迁移到 Gateway API（完整迁移路径） 关键注意事项与生产实践建议 Ingress NGINX 为什么从 Kubernetes 正式退役？ 根据官方博客（2025–11–11），Ingress NGINX 的退役原因包括： ● 1. 项目长期缺乏维护者 虽然 Ingress NGINX 使用极广，但维护压力巨大，而核心维护者数量越来越少，社区贡献下滑。项目经过数月讨论，确定无法持续投入。 ● 2. 无法跟上 Kubernetes 网络模型的发展 Ingress 诞生于 Kubernetes 早期，仅支持 HTTP(s) 基础路由；而随着 Service Mesh、多协议服务、网关统一治理等场景爆发，Ingress 模型难以满足现代需求。...