3 篇博文 含有标签「负载均衡」

gRPC 在 Kubernetes 中“能调用成功”并不等于“已经具备生产级负载均衡”。当客户端只解析到一个 ClusterIP，再通过一条长期存在的 HTTP/2 连接发送请求时，多个 Pod 很可能长期冷热不均。

本文以 service-a 这一通用 Java 服务为例，复盘一条典型的生产治理路径：保留现有 ClusterIP Service 兼容原有调用，再增加只供内部 gRPC 发现的 Headless Service，让 Java gRPC 客户端和 Envoy 看见每一个 Pod，并把服务发现、健康检查、摘流、连接排空、超时重试、可观测性和发布验收串成闭环。

如果需要先补齐协议和 Java 基础，可以依次阅读 HTTP/2 协议层、Java 与 Netty 实现 和 gRPC 生产治理；本文专注 Kubernetes 与 Envoy 的端点级落地。

这不是一份只解决“DNS 返回几个 IP”的配置说明。生产落地需要同时回答六个问题：

1. 客户端究竟发现了 VIP，还是每个 Pod？
2. 负载均衡发生在 TCP 连接、HTTP/2 Stream，还是 RPC 级别？
3. 不可用 Pod 会不会继续出现在发现结果里？
4. Pod 下线时，存量长连接和在途 RPC 如何处理？
5. Java 客户端与 Envoy 谁负责重试、健康检查和摘除？
6. 如何证明流量真的分散，而不是只证明 DNS 能解析？

如果只看一份最小配置，Envoy 很像“另一个 Nginx”：监听一个端口，把请求转发给后端。但真正让 Envoy 成为云原生基础设施核心组件的，不是反向代理本身，而是它把路由、服务发现、负载均衡、故障隔离、安全和可观测性做成了一个可动态控制的数据平面。

这也是为什么 Envoy 会出现在 API Gateway、Kubernetes Gateway、Service Mesh、gRPC 基础设施、边缘代理和多集群流量治理中。

本文沿着一条生产链路展开：

1. Envoy 到底解决什么问题，什么时候值得使用；
2. 一个请求如何穿过 Listener、Filter、Route、Cluster 和 Endpoint；
3. 怎样在本地跑起一个具有灰度路由、健康检查和异常摘除能力的代理；
4. 怎样正确设计超时、重试、熔断、限流、鉴权和动态配置；
5. 怎样在 Kubernetes 上用 Envoy Gateway 部署一个跨节点、可扩缩、可优雅升级的高可用入口；
6. 上线前应该监控什么、演练什么，以及故障时如何定位。

本文基于 2026 年 9 月 4 日可用的官方资料与稳定版本：Envoy 1.39.1、Envoy Gateway 1.9.1。示例固定具体版本，避免生产环境无意间拉取变化中的 latest 镜像。

"框架的 Hello World 只需要 5 分钟，但在生产环境中跑稳它需要 5 年的经验。"

在 上一篇 中，我们深入了 grpc-java 的内部实现。 本文聚焦 生产环境治理——当你的 gRPC 服务部署到 Kubernetes 集群后，你需要关心的每一件事。