如何确保gRPC请求始终发送至K8s主控制器Pod

各方案优劣分析 #

• 方案1：查询Service关联Pod IP并广播请求
  这种方式问题不少：广播请求会让副本Pod也收到，平白浪费资源，还得额外做请求过滤；而且Pod IP是动态的，每次都要查，Pod重启后IP变了还得重新获取，维护起来麻烦，可靠性也差。

• 方案2：查询Lease获取持有者身份再拿Pod信息
  优点是贴合K8s主选举的原生逻辑——主副本控制器一般都是用Lease做选举的，能精准定位主Pod。但缺点也明显：你的程序得集成K8s API客户端，还要写Lease查询、关联Pod的逻辑，复杂度高；每次请求前查API还会增加延迟，得做缓存优化才行。

• 方案3：主Pod自加专属标签，Service匹配该标签
  这是最贴合K8s原生设计的方式：完全利用Service的标签选择器能力，外部程序直接请求Service域名就能只打到主Pod，不用额外开发客户端逻辑。唯一要做的是让主Pod在当选后给自己加个标签（比如role=leader），失去主身份时再删掉。当然要确保标签更新的原子性，避免主切换时Service找不到后端或者路由错了。

最佳实践：方案3 #

优先选方案3，理由如下：

1. 省心：不用额外写复杂的客户端逻辑，全靠K8s原生的服务发现机制，维护成本低；
2. 可靠：主Pod通过选举逻辑维护标签，Service会自动更新后端端点，主切换时能无缝过渡；
3. 简单：外部程序只需要请求Service域名就行，完全不用管主Pod是谁、有没有变化。

实现小细节 #

• 主选举逻辑里，当选主成功后，调用K8s API给自己的Pod加个专属标签，比如controller-role=leader；
• 把Service的标签选择器改成匹配app=my-controller（你的控制器基础标签）+controller-role=leader，确保只路由到主Pod；
• 如果主Pod启动或切换时需要初始化时间，可以给Service加publishNotReadyAddresses: true，或者让主Pod等标签更新完再进入Ready状态，避免短暂的服务不可用；
• 要是用Operator SDK这类框架，直接用内置的主选举能力，再结合Pod标签更新的钩子，能省不少事。

备选场景：方案2 #

如果没法修改主Pod的标签逻辑（比如用的是第三方控制器），可以选方案2，但要注意：

• 缓存Lease的持有者信息，别每次请求都查K8s API；
• 监听Lease和Pod的变化事件，实时更新缓存，保证主Pod信息准确；
• 做好降级逻辑，要是拿不到主Pod信息，能 fallback 到广播请求或者其他策略。

内容的提问来源于stack exchange，提问作者lidlesseye