为何Kubernetes Pod完成与Job完成状态间存在显著延迟？

我近期开始使用Kubernetes Job，尝试理解其工作流，用了官方文档里的首个示例：

kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

执行kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml部署后，用kubectl wait --for=condition=complete job/pi等待Job完成。查看状态发现：Pod在10:54:21启动，10:54:25完成；但Job的Completed At时间是10:54:31，Pod完成后间隔6秒Job才标记完成，延迟时长甚至超过Pod运行时间的1.5倍。

我已经排除了以下可能：

• Pod实际运行时长比kubectl describe显示的更长：用busybox镜像执行sleep 5测试，Pod确实5秒完成，但Job需要8-10秒才标记完成。
• Job在官方Completed At时间前实际已完成：kubectl wait会等待完整时长，Pod完成后仍需等3-5秒才返回。
• 问题源于特定集群：在docker-desktop、k3s（VPS）、GCP集群测试都存在这个延迟。

想知道：Job在Pod完成后到底在等什么？为什么不能立即标记完成？

这个延迟是Kubernetes Job控制器的周期性同步机制导致的，核心原因如下：

1. Job控制器的轮询间隔
   Job控制器不会实时监听Pod的状态变化，而是通过周期性的list-watch机制同步集群资源状态。默认情况下，控制器的同步周期是5-10秒（具体取决于Kubernetes版本，多数版本默认在10秒以内）。当Pod完成后，控制器需要等到下一次同步周期才会检测到Pod的终态，进而更新Job的状态为Completed。

2. Pod终态的上报与确认
   Pod完成后，kubelet需要先将Pod的终态上报给API Server，这个过程存在微小延迟。之后Job控制器在同步周期内拉取Pod状态，确认所有关联Pod都已达到预期终态（比如restartPolicy: Never下Pod成功终止），才会更新Job的Completed At时间。

3. 资源状态的一致性校验
   Job控制器还会做额外的一致性校验：比如确认没有其他需要启动的Pod（根据parallelism和completions配置）、Pod的退出码符合预期等。这些校验逻辑会占用少量时间，但主要延迟还是来自轮询间隔。

简单来说，Job不是实时响应Pod状态变化的，而是“定期查岗”，所以Pod完成后需要等控制器的下一次同步周期，才会被标记为完成。

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