k8s CronJobs導致的一次崩潰

最近在玩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了，這是另外一個話題了。