用 Kubernetes 给 gRPC 扩容：让每个 Pod 都忙起来

先来段代码，看看问题在哪

// 服务端 - 一个简单的 gRPC 服务器packagemainimport("net""google.golang.org/grpc"pb"your/proto/package")typeserverstruct{pb.UnimplementedYourServiceServer}func(s*server)YourMethod(ctx context.Context,req*pb.Request)(*pb.Response,error){// 处理请求...return&pb.Response{},nil}funcmain(){lis,_:=net.Listen("tcp",":9090")s:=grpc.NewServer()pb.RegisterYourServiceServer(s,&server{})s.Serve(lis)// 开始服务}

// 客户端 - 看起来没问题对吧？conn,err:=grpc.NewClient("server:9090",grpc.WithTransportCredentials(insecure.NewCredentials()),)deferconn.Close()

问题来了：这段代码在开发环境跑得好好的，一上 Kubernetes 扩容就翻车 🚗💥

问题的根源：长连接是个"痴情种"

REST API 之所以扩容简单，是因为它像个"渣男"——每次请求都是新的 TCP 连接，来去自由，Kubernetes 的负载均衡器可以随意分配。

但 gRPC 不一样，它是个"痴情种"。客户端一旦建立连接，就会长期持有这个 TCP 连接。问题来了：Kubernetes 的默认负载均衡器是按连接数分配，而不是按请求数分配。

尴尬场景：Pod 在摸鱼 🐟

想象一下：你有10个服务器 Pod，但只有3个客户端。结果就是——7个 Pod 在idle摸鱼，资源白白浪费。

更糟的是自动扩容：假设你设置了内存使用率90%触发扩容，一个客户端把某个 Pod 用到90%，系统新增一个 Pod… 但这个客户端根本不会用新 Pod！因为它已经"爱上"了原来的连接。

解决方案：三步走 💡

第一步：Headless Service（无头服务）

关键技巧：不用Kubernetes 内置的负载均衡器。

apiVersion:v1kind:Servicemetadata:name:serverspec:clusterIP:None# 关键！设为 None 变成 headlessports:-name:grpcport:9090targetPort:9090selector:app.kubernetes.io/name:server

Headless Service 没有固定 IP，而是通过DNS 暴露所有 Pod 的 IP，让客户端自己决定怎么负载均衡。

第二步：客户端负载均衡

conn,err:=grpc.NewClient(target,grpc.WithTransportCredentials(insecure.NewCredentials()),grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`),)

设置round_robin策略，让请求轮询分发到各个 Pod。

第三步：DNS 解析器（关键！）

等等，还没完！客户端启动时获取一次 IP 列表后，默认不会再更新。新扩容的 Pod 它根本不知道。

funcinit(){resolver.Register(resolver.Get("dns"))}funcmain(){conn,err:=grpc.NewClient(fmt.Sprintf("dns:///%s",target),// 注意 dns:/// 前缀grpc.WithTransportCredentials(insecure.NewCredentials()),grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`),)}

注册 DNS resolver，让客户端定期刷新可用 Pod 列表。

总结

这样一来，你的 gRPC 服务就能像 REST API 一样优雅扩容了。每个 Pod 都能忙起来，资源不再浪费，老板看了都开心！🎉