Kubernetes: можно ли монтировать тома в контейнер, работающий как CronJob?

Я пытаюсь создать Kubernetes CronJob для запуска приложения каждую минуту.

Обязательным условием является то, что мне нужно поместить код моего приложения в контейнер, который работает в CronJob. Я полагаю, что лучший способ сделать это — использовать постоянный том, pvclaim, а затем определить том и смонтировать его в контейнер. Я сделал это успешно с контейнерами, работающими в поде, но это кажется невозможным в CronJob? Вот моя попытка конфигурации:

apiVersion: batch/v2alpha1
kind: CronJob
metadata:
  name: update_db
spec:
  volumes:
  - name: application-code
    persistentVolumeClaim:
      claimName: application-code-pv-claim
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: update-fingerprints
            image: python:3.6.2-slim
            command: ["/bin/bash"]
            args: ["-c", "python /client/test.py"]
          restartPolicy: OnFailure

Соответствующая ошибка:

ошибка: ошибка проверки "cron-applications.yaml": ошибка проверки данных: найдены недопустимые тома полей для v2alpha1.CronJobSpec; если вы решите игнорировать эти ошибки, отключите проверку с --validate=false

Я не могу найти никаких ресурсов, которые показывают, что это возможно. Итак, если это невозможно, как решить проблему добавления кода приложения в работающий CronJob?


person theoneandonly2    schedule 05.10.2017    source источник


Ответы (2)


CronJob использует PodTemplate как все остальное основано на модулях и может использовать тома. Вы разместили спецификацию Volume непосредственно в CronJobSpec вместо PodSpec, используйте его следующим образом:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: update-db
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: update-fingerprints
            image: python:3.6.2-slim
            command: ["/bin/bash"]
            args: ["-c", "python /client/test.py"]
            volumeMounts:
            - name: application-code
              mountPath: /where/ever
          restartPolicy: OnFailure
          volumes:
          - name: application-code
            persistentVolumeClaim:
              claimName: application-code-pv-claim
person Simon Tesar    schedule 05.10.2017
comment
Я не могу его отредактировать, но yaml недействителен: - под containers:: image: и следующий ключ должен быть на том же уровне, что и name:, кроме mountPath) - под volumes:: persistentVolumeClaim и claimName должны быть на том же уровне, что и name: - person Nicolas Pepinster; 25.01.2019
comment
Думаю, ты прав, @NicolasPepinster, спасибо за это. - person Simon Tesar; 29.01.2019
comment
Здравствуйте, если claimName находится на том же уровне отступа, что и persistenceVolumeClaim, возникает следующая ошибка: недопустимый тип для io.k8s.api.core.v1.PersistentVolumeClaimVolumeSource: получена строка, ожидаемая карта. Поэтому я думаю, что claimName должен быть отступ вправо. - person l.cotonea; 15.02.2021
comment
@l.cotonea, очевидно :-) Забавно, как это заняло два года. - person Simon Tesar; 16.02.2021
comment
Я обновил пример до Kubernetes 1.20 и исправил все ошибки с двумя/четырьмя пробелами. - person Simon Tesar; 16.02.2021

Другой вопрос: как решить проблему добавления кода приложения в работающий CronJob?

Вы создаете свой собственный образ, содержащий код. Вот как это обычно делается.

FROM python:3.6.2-slim
ADD test.py /client/test.py

CMD ['python','-c','/client/test.py']

Сборка и отправка в реестр докеров.

docker build -t myorg/updatefingerprints
docker push myorg/updatefingerprints

Используйте это изображение в дескрипторе.

apiVersion: batch/v2alpha1
kind: CronJob
metadata:
  name: update_db
spec:
  volumes:
  - name: application-code
    persistentVolumeClaim:
      claimName: application-code-pv-claim
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: update-fingerprints
            image: myorg/update-fingerprints
            imagePullPolicy: Always
          restartPolicy: OnFailure

Это требует совсем другого подхода к управлению конфигурацией и контролю версий.

person Gudlaugur Egilsson    schedule 30.03.2021