关于Kubernetes失败状态Pod是否释放已申请集群资源的技术咨询

背景 #

我有如下Kubernetes Job模板：

apiVersion: batch/v1
kind: Job
metadata:
  name: "gpujob"
spec:
  completions: 1
  backoffLimit: 0
  ttlSecondsAfterFinished: 600000
  template:
    metadata:
      name: batch
    spec:
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: "test"
      containers:
      - name: myhub
        image: smat-jupyterlab
        env:
        - name: JUPYTERHUB_COOKIE_SECRET
          value: "sdadasdasda"
        resources:
          requests:
            memory: 500Gi
          limits:
            nvidia.com/gpu: 1
        command: ["/bin/bash", "/usr/local/bin/jobscript.sh", smat-job]
        volumeMounts:
        - name: data
          mountPath: /data
      restartPolicy: Never
      nodeSelector:
        dso-node-role: "inference"

如您所见，我为该Job申请了大量内存资源。我的问题是：处于失败状态的Pod是否会立即释放其已申请的集群资源？由于合规规定，我必须在集群中保留Pod一周时间，否则我会设置一个非常低的ttlSecondsAfterFinished值。我在多篇技术文章中看到了相互矛盾的内容，但在Kubernetes官方文档中未找到明确说明。

简言之：失败状态的Pod是否会释放其已申请的集群资源？如果不会，有什么合适的解决方案？

好问题，这个点确实容易让人混淆，我来给你理清楚：

核心结论：失败状态的Pod不会立即释放已申请的资源 #

只要Pod对象还存在于集群中（不管它的状态是Failed、Completed还是Running），它声明的resources.requests对应的资源会一直被节点标记为「已分配」。这意味着节点调度器在分配新Pod时，会把这些资源算在已使用额度里，不会将新工作负载调度到资源不足的节点上——哪怕失败的Pod已经停止运行，完全没有实际占用资源。

原因很直接：Kubernetes的资源预留机制是基于Pod对象的存在性，而非Pod的运行状态。只要Pod没被删除，节点就会为它保留requests中声明的资源额度。

针对合规需求的解决方案 #

既然你需要保留Pod一周时间，同时又不想浪费宝贵的集群资源，这里有几个实用的方案：

1. 调整Job的ttlSecondsAfterFinished为一周 #

直接把Job的ttlSecondsAfterFinished值设置为7天对应的秒数（604800），这样当Pod进入Failed或Completed状态后，会自动在一周后被删除，届时资源会立即释放。这个方案最简单，完全符合你的合规要求，不需要额外工具或脚本。

修改后的Job spec片段：

spec:
  completions: 1
  backoffLimit: 0
  ttlSecondsAfterFinished: 604800  # 7天 = 7*24*3600秒

2. 修改失败Pod的资源请求为0 #

如果你需要立即释放资源，但又要保留Pod对象，可以手动或通过脚本修改失败Pod的resources.requests为0。这样节点会把之前预留的资源标记为可用，但Pod的日志、事件和元数据依然存在，满足合规审计需求。

举个手动修改的命令（替换<pod-name>为你的Pod名称）：

kubectl patch pod <pod-name> -p '{"spec":{"containers":[{"name":"myhub","resources":{"requests":{"memory":"0Gi","cpu":"0"}}}]}}'

你也可以写一个简单的定时脚本（比如用CronJob），自动扫描集群中所有Failed状态的Pod，批量修改它们的资源请求。

3. 调度失败Pod到闲置节点 #

如果你的集群有专门的闲置节点（不运行生产工作负载），可以给失败Pod添加一个节点选择器，把它们调度到这些节点上。这样既保留了Pod对象，又不会占用生产节点的资源。

修改失败Pod的节点选择器命令：

kubectl patch pod <pod-name> -p '{"spec":{"nodeSelector":{"node-role.kubernetes.io/idle": "true"}}}'

前提是你已经给闲置节点打上了对应的标签（node-role.kubernetes.io/idle=true）。

4. 使用自定义控制器管理Pod资源 #

如果你的集群有很多这类场景，可以部署一个自定义Kubernetes控制器，自动监听Pod状态变化：当Pod进入Failed状态时，自动修改其资源请求为0，或者执行其他你需要的操作。这种方案适合规模化的场景，一劳永逸。

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