Работа Kubernetes против пода в контейнере - PullRequest
Новая
       10

Работа Kubernetes против пода в контейнере

0 голосов
/ 06 мая 2020

Я пытаюсь выяснить, есть ли способ заставить модуль, который застрял в состоянии containerCreating (по уважительным причинам, например, не может смонтировать недоступный NFS и т. Д. c.), Перейти в отказавший состояние после указанного c количества времени.

У меня есть Kubernetes jobs, который я запускаю через конвейер Jenkins. Я использую состояние задания (type: completed|failed), чтобы определить результат, а затем собираю результаты заданий (kubectl get pods + kubectl logs). Он работает хорошо, пока модули go находятся в известном неисправном состоянии, таком как ContainerCannotRun или Backofflimit, и, следовательно, состояние job переходит в failed.

Проблема возникает, когда pod переходит в состояние containerCreating и остается таким. Тогда состояние задания останется active и никогда не изменится. Есть ли способ в манифесте job поместить что-то, чтобы заставить модуль, находящийся в состоянии containerCreating, перейти в состояние сбоя через определенное время?

Пример: статус модуля 

    - image: myimage
      imageID: ""
      lastState: {}
      name: primary
      ready: false
      restartCount: 0
      state:
        waiting:
          reason: ContainerCreating
    hostIP: x.y.z.y
    phase: Pending
    qosClass: BestEffort
    startTime: "2020-05-06T17:09:58Z"

статус задания 

    active: 1
    startTime: "2020-05-06T17:09:58Z"

Спасибо за любой вклад.

1 Ответ

1 голос
/ 07 мая 2020

Как описано здесь используйте activeDeadlineSeconds или backoffLimit

activeDeadlineSeconds применяется к продолжительности задания, независимо от того, сколько подов создано. Как только задание достигает activeDeadlineSeconds, все его запущенные поды завершаются, и статус задания становится типом: Ошибка с причиной: DeadlineExceeded.

После достижения backoffLimit задание будет помечено как неудавшееся и все запущенные поды будут прекращены.

Обратите внимание, что activeDeadlineSeconds задания имеет приоритет над backoffLimit. Таким образом, задание, которое повторяет попытку одного или нескольких отказавших модулей, не будет развертывать дополнительные модули по достижении лимита времени, указанного в activeDeadlineSeconds, даже если backoffLimit еще не достигнуто. 

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-timeout
spec:
  backoffLimit: 5
  activeDeadlineSeconds: 100
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
...