如何将Kubernetes Lease用作服务选择器，仅向主Pod转发流量？

针对你遇到的Deployment会覆盖Pod标签的问题，以下是几种可行的实现思路：

方案1：自定义控制器同步Lease到Service/Endpoints #

• 核心逻辑：编写轻量控制器监听Lease资源的spec.holderIdentity字段变化，动态更新Service选择器或直接维护Endpoints对象，确保流量仅指向当前主Pod。
• 具体步骤：
  1. 使用client-go开发控制器，监听目标Lease对象的更新事件。
  2. 当主Pod变更时，通过Pod名称查询对应Pod的IP和端口信息。
  3. 方式A：更新Service的spec.selector，添加pod-name: <holderIdentity>（确保Service初始无冲突选择器），Kubernetes会自动将流量转发至该Pod。
  4. 方式B：直接修改Endpoints对象，清空原有端点后仅保留主Pod的IP和端口；同时将Service的spec.selector设为空，手动绑定该Endpoints。
• 优势：完全规避Deployment的标签覆盖问题，流量切换自动化，适合生产环境。

方案2：利用Pod注解+自定义端点控制器 #

• 核心逻辑：在主节点选举sidecar中为主Pod添加注解（而非标签），通过自定义控制器识别注解并维护Endpoints。
• 具体步骤：
  1. 在leader选举sidecar中，当Pod成为主节点时添加注解（如app/leader: "true"），注意不要在Deployment的Pod模板中定义该注解。
  2. 编写控制器监听Pod的注解变化：发现带有app/leader: "true"的Pod时，将其IP和端口写入目标Endpoints；移除注解时则从Endpoints中删除对应条目。
  3. 让Service关联该Endpoints，实现流量仅指向主Pod。
• 优势：注解不会被Deployment的reconcile逻辑覆盖，sidecar逻辑改动极小。

方案3：使用StatefulSet替代Deployment #

• 核心逻辑：StatefulSet的Pod名称固定（如my-app-0、my-app-1），可结合Lease实现主节点的动态切换与流量转发。
• 具体步骤：
  1. 将原Deployment改为StatefulSet，确保Pod名称稳定。
  2. 主节点选举逻辑触发时，更新Service的选择器为statefulset.kubernetes.io/pod-name: <leader-pod-name>。
  3. 控制器监听Lease变化，自动同步Service选择器到当前主Pod的固定名称。
• 优势：Pod名称稳定，便于追踪和管理，适合有状态服务的主备场景。

方案4：轻量脚本定时同步Lease到Endpoints #

• 核心逻辑：用简单脚本（bash+kubectl）定期查询Lease信息并更新Endpoints，无需编写复杂控制器。
• 具体步骤：
  1. 编写同步脚本：

     # 获取当前主Pod名称
     LEADER_POD=$(kubectl get lease <lease-name> -o jsonpath='{.spec.holderIdentity}')
     # 获取主Pod的IP
     POD_IP=$(kubectl get pod $LEADER_POD -o jsonpath='{.status.podIP}')
     # 更新Endpoints（假设服务端口为8080）
     kubectl apply -f - <<EOF
     apiVersion: v1
     kind: Endpoints
     metadata:
       name: <service-name>
     subsets:
     - addresses:
       - ip: $POD_IP
       ports:
       - port: 8080
         name: http
     EOF
     

  2. 将脚本封装为CronJob，设置执行间隔小于Lease过期时间（如10秒），确保Endpoints始终指向当前主Pod。
• 优势：实现简单，无需Go开发成本，适合测试或轻量场景。

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