Предоставляет ли Kubernetes размещенную ячейку Job?

Question

Интересно, как реализовать единый дополнительный контейнер в Pod в развертывании, который не предоставляет службу, а скорее рабочую нагрузку на работу/пакет?

Справочная информация по моим вопросам заключается в том, что я хочу развернуть масштабируемую службу, в которой каждый экземпляр нуждается в конфигурации после ее запуска. Эта конфигурация выполняется через HTTP POST в свой локальный экземпляр службы. Для этого я использовал дополнительный контейнер, чтобы воспользоваться функцией colocation. Поэтому вспомогательный контейнер всегда знает, какой экземпляр необходимо настроить.

Проблема в том, что restartPolicy необходимо определить на уровне Pod. Я ищу что-то вроде политики перезапуска always для службы и другой политики перезапуска onFailure для задания конфигурации.

Я знаю, что k8s предоставляет ресурс Job для таких нагрузок. Но есть ли возможность помещать эти задания в Pods?

Кроме того, я наткнулся на так называемые контейнеры init, которые могут быть определены с помощью аннотаций. Но они страдают от недостатка, что k8s гарантирует, что фактический Pod будет запущен только после запуска контейнера init. Поэтому по моему сценарию это кажется неприемлемым.

Answer 1

Насколько я понимаю, для его настройки требуется ваша служба.

Ваше решение работоспособно, и вы можете установить restartPolicy: always, вам просто нужен способ сообщить своему одному контейнеру конфигурации, что он уже запущен. Вы можете создать и присоединить тома emptyDir к контейнеру конфигурации, создать на нем файл, чтобы успешно отметить вашу конфигурацию и проверить этот файл из вашего процесса. После инициализации вы вводите сон в цикле. Недостатком является то, что некоторые ресурсы будут использоваться этим контейнером.

Или вы можете просто добавить дополнительный процесс в один и тот же контейнер и выполнить конфигурацию (возможно, с указанным выше файлом в качестве защитника, чтобы избежать настройки дважды). Так написать простой скрипт, как это и запустить его вместо основного процесса:

#!/bin/sh 

(
    [ -f /mnt/guard-vol/stamp ] && exit 0 
    /opt/my-config-process parameters && touch /mnt/guard-vol/stamp 
) & 

exec /opt/my-main-process "$@" 

В качестве альтернативы вы можете реализовать отдельный стручок, который запрашивает kubernetes API для стручков вашей службы с этикетками configured=false. Настройте его и удалите ярлык с помощью API. Вы также должны изменить свою услугу, чтобы выбрать configured=true pods.