Модули задания убиты из-за распространения кеша объектов

Question

Мы пытаемся заставить некоторый код анализа вращаться на кластере kubernetes. Мы хотим запустить 10 пакетов из 1 задания со следующим файлом yaml:

apiVersion: batch/v1
kind: Job
metadata:
 name: job-platooning-s1b
spec:
 parallelism: 10
 template:
   metadata:
     name: job-platooning-s1b
   spec:
     containers:
     - name: platooning-dp-1b
       image: registry.gitlab.com/company_name/repo_name/platooning:latest
       command: ["python3" , "/app/scenario_1b_cluster.py"]
     restartPolicy: 'OnFailure'
     imagePullSecrets:
     - name: regcred-nextsys

Наши 10 модулей могут выжить в течение нескольких минут, прежде чем их убьют. Я получаю ошибку: MountVolume.SetUp failed for volume "default-token-7td4s" : couldn't propagate object cache: timed out waiting for the condition.

Я думаю, что модули потребляют слишком много памяти. Мы попытались указать использование памяти, добавив следующие параметры в containers в файле yaml:

resources:
    limits:
        memory: "15Gi"
    requests:
        memory: "500Mi"

Но это не помогает, так как модули по-прежнему закрыты. Запуск задания с 1 модулем - это нормально, так как его не убивают. В конце концов, мы хотим иметь масштабируемое решение, в котором несколько сценариев с несколькими модулями могут быть запущены в одночасье.

Есть ли у вас какие-либо идеи о том, почему блоки убиваются в этом сценарии?

Стручки работают правильно, когда они запускаются одна за другой (без параллелизма). Когда мы пытаемся запустить многие из них вместе, они работают некоторое время, а затем их убивают (выселяют?), Иногда вызывая эту ошибку:

MountVolume.SetUp не удалось выполнить для тома «default-token-7td4s»: не удалось распространить кэш объекта: истекло время ожидания условия

Странно то, что секрет, который использует это задание, - это не default-token-7td4s, а regcred-nextsys, как видно израбочий файл YAML. Это ожидаемое поведение? И если да, то почему это на самом деле терпит неудачу? Я подозреваю состояние гонки или просто разные модули, пытающиеся подключить один и тот же ресурс, но я не уверен, что это имеет смысл. Другая причина, по которой я подозреваю, это проблема с памятью.

Мы запускаем kubernetes как управляемый сервис от DigitalOcean.

Answer 1

Я работаю вместе с Павлом и столкнулся с этой проблемой. Теперь я понимаю, что модули работают правильно, когда работают один за другим (без параллелизма). Когда мы пытаемся запустить многие из них вместе, они работают некоторое время, а затем убиваются (выселяются?), Иногда вызывая эту ошибку:

MountVolume.SetUp не удалось выполнить для тома «default-token-7td4s»: не удалось распространить кэш объекта: истекло время ожидания условия

Странно то, что секрет, который использует это задание, - это не default-token-7td4s, а regcred-nextsys, как видно израбочий файл YAML. Это ожидаемое поведение? И если да, то почему это на самом деле терпит неудачу? Я подозреваю состояние гонки или просто разные модули, пытающиеся подключить один и тот же ресурс, но я не уверен, что это имеет смысл. Другая причина, по которой я подозреваю, это проблема с памятью.

Мы запускаем kubernetes как управляемый сервис от DigitalOcean.

Answer 2

Вы используете ресурс kubernetes типа JOB, а не POD. Это очень разные вещи. И выполняемое вами задание даже не запущено, поскольку оно не может смонтировать токен по умолчанию, который является еще одним ресурсом kubernetes, который вы должны были указать в качестве секрета.

Скорее всего, когда вы создаете задание, оно навсегда остается в состоянии ContainerCreating. Запустите kubectl get pods, чтобы увидеть это. И запустите kubectl get secrets, чтобы найти токен по умолчанию.

Answer 3

Извините, я не заметил, что вы не используете миникуб. Я исправил свой ответ.

Проверьте, какую версию Kubernetes вы используете. Ваши журналы показывают, что вы работаете 1.12.3.

Это было решено в 1.12.7 в # 74755 .

Здесь вы можете найти более подробную информацию: кешповедение secret / configmap .

Надеюсь, это поможет.