K8s缩容时如何优先删除空闲Pod而非忙碌Pod？

核心问题拆解 #

K8s默认缩容逻辑会优先删除NOT READY状态的Pod，无论controller.kubernetes.io/pod-deletion-cost注解值多少——这是因为NOT READY的Pod已脱离服务流量池，删除它们对业务可用性影响最小，优先级高于删除成本。你的方案冲突点就在于用readinessProbe把忙碌Pod标记为NOT READY，反而让它们成为缩容的首选目标。

方案一：队列消费+本地任务锁（推荐） #

放弃用readinessProbe控制任务路由，改用任务队列消费逻辑+本地锁实现单Pod单任务，同时保留删除成本注解确保缩容优先级：

• 任务拉取逻辑：Pod启动后，仅在本地无正在处理的任务时，从队列（如RabbitMQ、Kafka或Redis队列）拉取一个任务；处理期间通过本地内存标记或文件锁标记为BUSY，处理完成后清除标记再拉取下一个。
• 删除成本配置：任务处理中，将Pod的controller.kubernetes.io/pod-deletion-cost设为100；空闲时重置为1。
• 优势：Pod始终处于READY状态，K8s缩容时会严格按照删除成本优先级，优先删除成本更低的空闲Pod；同时本地锁保证了单Pod一次仅处理一个任务，无需依赖readinessProbe的流量拦截。

方案二：自定义缩容逻辑（复杂度较高） #

如果必须保留readinessProbe的流量拦截方式，需要绕过K8s默认缩容逻辑，实现自定义的Pod删除策略：

• 编写一个监控程序（或K8s Operator），监听Deployment的副本数变更事件；
• 当检测到缩容需求时，遍历所有Pod：
  1. 筛选出status为IDLE（空闲）且处于READY状态的Pod；
  2. 优先删除这类Pod；
  3. 若没有空闲Pod，再考虑删除忙碌的NOT READY Pod；
• 部署该程序并赋予K8s API的Pod删除权限。
• 注意：该方案需要额外开发维护成本，仅适合无法修改任务消费逻辑的场景。

关键配置示例 #

以方案一为例，给出Pod内任务处理的伪代码（Python）：

import time
from kubernetes import client, config

# 加载K8s配置（Pod内使用ServiceAccount）
config.load_incluster_config()
v1 = client.CoreV1Api()

def update_deletion_cost(pod_name, namespace, cost):
    patch = {"metadata": {"annotations": {"controller.kubernetes.io/pod-deletion-cost": str(cost)}}}
    v1.patch_namespaced_pod(pod_name, namespace, patch)

def process_task(task):
    # 标记为忙碌，更新删除成本为100
    update_deletion_cost("my-pod-xxx", "default", 100)
    print(f"Processing task: {task}")
    time.sleep(60)  # 模拟任务处理
    # 任务完成，标记为空闲，更新删除成本为1
    update_deletion_cost("my-pod-xxx", "default", 1)

def main():
    while True:
        # 检查本地是否有正在处理的任务（此处用内存变量模拟）
        if not globals().get("is_busy", False):
            globals()["is_busy"] = True
            task = pull_task_from_queue()  # 从队列拉取任务
            if task:
                process_task(task)
            globals()["is_busy"] = False
        time.sleep(5)

if __name__ == "__main__":
    main()

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