Kubernetes单副本Pod驱逐未遵循滚动更新策略的解决方案咨询

背景 #

• Deployment/Service/Pod 仅1个Replica（依赖昂贵共享资源，修改扩容成本极高）
• 滚动更新策略配置：maxSurge=1，maxUnavailable=0（短期双倍资源占用可接受）
• Pod因可预见原因（如集群Autoscaler缩容）被驱逐时，服务出现非预期Downtime

执行kubectl rollout restart ...时，滚动更新策略能完美生效，但Pod被集群Autoscaler驱逐时，该策略完全不生效。核心疑问：Kubernetes中是否存在可模拟滚动更新策略行为的功能？

目前找到的近似方案：

• 通过PodDisruptionBudget（PDB）确保至少1个Pod在线
• 每隔X分钟执行kubectl rollout restart

但这两个方案都无法彻底解决问题，期望实现以下流程：

期望时间线 #

• 集群Autoscaler通过Eviction API通知Pod需被驱逐
• 创建新Pod（进入短期双倍资源占用状态）
• 新Pod就绪
• 终止旧Pod（结束双倍资源占用），全程无服务Downtime

实际时间线（当前问题） #

• 触发Eviction API
• 直接终止旧Pod（Downtime开始）
• 创建新Pod
• 新Pod就绪（Downtime结束）

可行解决方案 #

1. PodDisruptionBudget + PreStop钩子组合

配置minAvailable=1的PDB，确保旧Pod在新Pod就绪前不会被强制终止；同时给Pod添加PreStop钩子，在收到终止信号时触发Deployment滚动更新：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-deployment
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: your-app
    spec:
      containers:
      - name: your-container
        image: your-image
        lifecycle:
          preStop:
            exec:
              command: ["kubectl", "rollout", "restart", "deployment/your-deployment"]
      serviceAccountName: rollout-restart-sa # 需要配置有Deployment编辑权限的ServiceAccount
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: your-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: your-app

注意：需给Pod绑定的ServiceAccount配置足够权限，且PreStop钩子的超时时间要大于Pod启动就绪的时间，避免旧Pod被提前终止。

2. 自定义控制器监听Eviction事件

开发一个轻量自定义控制器，监听集群中的Eviction资源请求：

• 当检测到目标Pod的驱逐请求时，先调用Kubernetes API触发对应Deployment的滚动更新
• 控制器等待新Pod进入Ready状态后，再放行原驱逐请求
  这种方式能精准匹配期望的时间线，完全控制驱逐流程。

3. 优化集群Autoscaler配置

调整集群Autoscaler的参数，比如设置--scale-down-delay-after-add=5m（新Pod创建后延迟缩容），同时给目标Pod配置合适的PriorityClass，确保集群优先在其他节点调度新Pod（如果有可用资源）后再驱逐旧Pod。但这种方式依赖集群剩余资源，可靠性不如前两种方案。

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