最近在玩kubeflow/katib和kubeflow/pipeline 找了个例子, 具体流程是：

超参调优（Katib）-- train — serving

但是跑着跑着忽然脱了，cluster中多了数百个Error状态的pod，而且数量还在不断增加，这是要crash的节奏啊！

赶紧抓了一个pod describe看了看，发现这个：

  - apiVersion: batch/v1
    blockOwnerDeletion: true
    controller: true
    kind: Job

感情是个Job，这么有规律的增加不是有人在while true就是cronJob了，查了查资源，果然有几个cronJob再卖力的生产pod。

找到罪魁祸首就好办，看了看cronJob的定义：

      schedule: "*/1 * * * *"
      successfulJobsHistoryLimit: 0
      failedJobsHistoryLimit: 1

一分钟一个，但是已经设置了

successfulJobsHistoryLimit: 0

failedJobsHistoryLimit: 1

这两个属性的意思是说成功的Job pod全部会被删除，失败的pod只会保留一个，估计是为了让你查看错误原因。

但为啥我Error状态的pod都飙到上百了？

查了查google，这个锅果然得k8s背：

https://github.com/kubernetes/kubernetes/issues/53331

简单来说就是上面提到的两个配置支队pod state是Succeeded和Failed的pod起效，对其他状态如：Error并不加理会的，这就是pod大量堆积的原因。

不过是Error状态并不可怕，可怕的是Pending状态，也不理会啊。

这个问题在k8s v1.12仍然存在，当然据说可以通过在job上设置：activeDeadlineSeconds来解决，这个设置会让k8s在若干时间段之后把该pod删除掉，但是这个时间怎么设置，看起来也不是个完美的解决方案。

至于为啥我的pod都Error了，这是另外一个话题了。