当遍历pod crashloop backoff实现时，我注意到了一些问题：

1. 回退错误未被成功抑制：

• 这段代码无法正常工作，因为总是存在一个非错误结果(ConfigPodSandbox)和一个nil错误：

kubernetes/pkg/kubelet/kubelet.go
第1964行到第1971行 in 5cf4fbe
| | // 如果唯一的失败是处于回退状态的pods,则不返回错误 |
| | for_, r:=rangeresult.SyncResults { |
| | ifr.Error!=kubecontainer.ErrCrashLoopBackOff&&r.Error!=images.ErrImagePullBackOff { |
| | // 这里不要记录事件，因为我们将所有同步pod失败的日志记录保留在容器运行时本地，以便我们获得更好的错误信息。 |
| | returnfalse, err |
| | } |
| | } |

1. 传播的回退错误意味着pod worker始终立即重新排队pod:
   kubernetes/pkg/kubelet/pod_workers.go
   第1495行到第1497行 in 5cf4fbe
   | | default: |
   | | // 在同步过程中发生错误；回退并重试。 |
   | | p.workQueue.Enqueue(podUID, wait.Jitter(p.backOffPeriod, workerBackOffPeriodJitterFactor)) |

• 如果回退错误被抑制，那么默认的1分钟同步频率将被使用，这将导致非常长的初始回退时间。

这些问题的结果是：

1. 日志垃圾邮件：E0301 01:06:01.286649 1869 pod_workers.go:1294] "Error syncing pod, skipping" err="failed to \"StartContainer\" for \"alpine\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=alpine pod=restarting-pod_default(ca0d5836-1435-497e-9a41-547fbcc10484)\"" pod="default/restarting-pod" podUID=ca0d5836-1435-497e-9a41-547fbcc10484会频繁地被记录
2. Kubelet执行不必要的工作来重新检查处于回退状态的pods和容器
3. (次要)错误重试周期为10秒，这将增加到回退时间的总和为10秒
   我认为理想的修复方法是将回退重试时间从SyncPod 1向上传播到pod worker 2,这样pod就可以使用精确(抖动)的正确重试时间重新排队。一个选项是使用自定义错误类型来封装回退时间，我已经在这里开始工作了：tallclair@5d89eb2
   当然，这些代码路径上的测试覆盖率非常低。