By Jermine

☰

在 Kubernetes 中，服务发现和负载均衡是微服务架构的核心能力。然而，当服务分布在不同的 Namespace 中，或者使用 gRPC 协议时，一些"默认"机制并不能完全满足需求。本文将首先介绍跨 Namespace 访问服务的标准方法，然后深入剖析 gRPC 在 Kubernetes 中遇到的负载不均衡问题，并给出多种解决方案，帮助你在生产环境中构建稳定、高效的服务通信。

一、跨 Namespace 访问服务：用 FQDN 打通隔离

Kubernetes 的 Namespace 提供了一种逻辑隔离机制，但服务之间往往需要跨 Namespace 通信。最直接、最推荐的方式就是使用服务的全限定域名（Fully Qualified Domain Name, FQDN）。

FQDN 格式

Kubernetes 集群内部的 DNS（如 CoreDNS）会为每个 Service 生成一条 DNS 记录，其 FQDN 格式如下：

<service-name>.<namespace>.svc.cluster.local

例如，production 命名空间中有一个名为 database 的服务，那么在任何其他 Namespace（比如 development）中，都可以通过 database.production.svc.cluster.local 来访问它。

注意：在同一个 Namespace 内，可以直接使用短域名（如 database），但跨 Namespace 时必须使用 FQDN，否则 DNS 查询会被限制在当前 Namespace 内，导致解析失败。

进阶方案

  • ExternalName Service：在当前 Namespace 中创建一个 ExternalName 类型的 Service，指向目标服务的 FQDN。这样，本 Namespace 的应用可以通过本地短域名访问，而无需感知目标 Namespace。
  • Ingress 结合 ExternalName：Ingress 默认只能路由到同 Namespace 的后端。可以通过将 Ingress 路由到本 Namespace 的 ExternalName Service，间接实现跨 Namespace 路由。
  • Gateway API + ReferenceGrant：作为 Ingress 的下一代替代，Gateway API 通过 ReferenceGrant 资源允许显式授权跨 Namespace 引用，更加安全灵活。

注意事项

  • NetworkPolicy：即使 DNS 解析成功，目标 Namespace 的 NetworkPolicy 可能阻止来自源 Namespace 的流量，需要提前规划策略。
  • 环境变量不可靠：Kubernetes 会自动为 Pod 注入同 Namespace 服务的环境变量（如 DATABASE_SERVICE_HOST），但这些变量不会跨 Namespace 注入，因此不要依赖它们进行服务发现。
  • Service 类型：集群内部通信使用 ClusterIP 即可，无需暴露到集群外部。

二、gRPC 负载不均衡：原因与解法

当你通过 FQDN 访问一个 gRPC 服务时，可能会发现流量全部打到了某一个 Pod 上，其他 Pod 几乎空闲。这不是 Kubernetes 的"bug"，而是 gRPC 的 HTTP/2 长连接特性与 Kubernetes 默认的连接级负载均衡共同导致的结果。

问题根源

  • gRPC 基于 HTTP/2：它会与服务器建立一个持久化的 TCP 长连接，并在该连接上多路复用大量请求。
  • Kubernetes Service 默认是 L4 负载均衡：当客户端通过 FQDN 解析到 Service 的 ClusterIP 并与它建立连接时，kube-proxy 会将该连接转发到某一个后端 Pod。由于连接是长久的，后续所有复用该连接的请求都只会被路由到同一个 Pod，造成流量倾斜。

解决方案一：客户端负载均衡（推荐）

这是最主流、最轻量的方式。核心思路是让 gRPC 客户端直接拿到所有 Pod 的 IP 列表，并在客户端进行请求级别的负载均衡。

步骤一：使用 Headless Service

将 Service 的 clusterIP 设置为 None，这样 DNS 解析将直接返回所有就绪 Pod 的 IP 地址，而不是一个 ClusterIP。

 1apiVersion: v1
 2kind: Service
 3metadata:
 4  name: my-grpc-service
 5spec:
 6  clusterIP: None  # 关键配置
 7  selector:
 8    app: my-grpc-app
 9  ports:
10    - port: 50051

步骤二：配置 gRPC 客户端使用 round_robin

客户端需要指定使用 dns 解析器（注意是 dns:/// 三个斜杠）和 round_robin 负载均衡策略。以下是几种常用语言的示例：

Go：

1conn, err := grpc.NewClient(
2    "dns:///my-grpc-service.namespace.svc.cluster.local:50051",
3    grpc.WithTransportCredentials(insecure.NewCredentials()),
4    grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin":{}}]}`),
5)

Python：

1channel = grpc.insecure_channel(
2    "dns:///my-grpc-service.namespace.svc.cluster.local:50051",
3    options=[("grpc.lb_policy_name", "round_robin")],
4)

Java：

1managedChannel = ManagedChannelBuilder.forTarget(
2        "dns:///my-grpc-service.namespace.svc.cluster.local:50051")
3    .defaultLoadBalancingPolicy("round_robin")
4    .build();

这样配置后，客户端会周期性刷新 Pod 列表，并将每个 gRPC 请求均匀分发到不同 Pod 上，实现真正的负载均衡。

解决方案二：服务网格（Service Mesh）

使用 Istio、Linkerd 等服务网格，它们通过注入 Sidecar 代理（如 Envoy）在 L7 层对 gRPC 流量进行智能负载均衡，同时还能提供流量管理、可观测性和安全能力。这种方法对应用代码无侵入，但会引入额外的架构复杂度和资源开销。

解决方案三：代理负载均衡

在客户端与服务端之间部署独立的代理（如 Envoy、Nginx），由代理终结客户端的 gRPC 长连接，再与后端 Pod 分别建立连接并分发请求。这种方法对客户端透明，但代理本身可能成为性能瓶颈和单点故障。

三、最佳实践总结

  1. 跨 Namespace 访问：优先使用 FQDN，明确依赖关系；若需简化，可辅以 ExternalName Service。
  2. gRPC 负载均衡：强烈推荐客户端负载均衡方案——将 Service 改为 Headless，并配置 gRPC 客户端使用 dns:/// 解析器和 round_robin 策略。此方案简单高效，无需额外组件，已在众多生产环境中验证。
  3. 网络策略：无论采用何种方式，都需确保 NetworkPolicy 允许跨 Namespace 的流量。
  4. 监控与可观测性：建议为 gRPC 服务添加 metrics（如 QPS、延迟、错误率），便于观察负载均衡效果和发现问题。

结语

Kubernetes 提供了强大的服务发现机制，但在跨 Namespace 和特殊协议（如 gRPC）场景下，我们需要深入理解其工作原理并做出相应调整。FQDN 是跨 Namespace 通信的基石，而 Headless Service + 客户端负载均衡是应对 gRPC 流量倾斜的标准解法。希望本文能帮助你规避常见陷阱，构建更健壮的云原生应用。

如果你在生产环境中遇到了其他相关问题，欢迎留言交流！ 🚀