Стручок / развертывание Kubernetes при передаче аргументов в контейнер?

С точки зрения конкретных полей:

• command: Кубернетеса соответствует концепции «точки входа» Докера, и все, что здесь указано, запускается как основной процесс контейнера. Вам не нужно указывать command: в спецификации модуля, если ваш Dockerfile уже имеет правильный ENTRYPOINT.
• args: Кубернетеса соответствует концепции «команды» Докера, и все, что здесь указано, передается в качестве аргументов командной строки точке входа.
• Переменные среды в Docker и Kubernetes имеют свою обычную семантику Unix.
• Dockerfile ARG указывает настройку конфигурации времени сборки для изображения. Правила расширения и взаимодействие с переменными среды немного странны. По моему опыту, у этого есть несколько полезных вариантов использования («какую версию JVM я на самом деле хочу построить?»), Но каждый контейнер , построенный из образа, будет иметь то же унаследованное значение ARG; это не очень хороший механизм для конфигурации во время выполнения .
• Для различных вещей, которые могут быть установлены в Dockerfile или во время выполнения (переменные ENV, EXPOSE d-порты, значение по умолчанию CMD, особенно VOLUME), нет особой необходимости «объявлять» их в Dockerfile, чтобы иметь возможность устанавливать их во время выполнения.

Есть пара более или менее эквивалентных способов сделать то, что вы описываете. (Я буду использовать синтаксис docker run для компактности.) Вероятно, наиболее гибкий способ - установить ROLE в качестве переменной окружения; когда вы запускаете сценарий точки входа, вы можете предположить, что $ROLE имеет значение, но его стоит проверить.

#!/bin/sh
# --> I expect $ROLE to be set
# --> Pass some command to run as additional arguments
if [ -z "$ROLE" ]; then
  echo "Please set a ROLE environment variable" >&2
  exit 1
fi
echo "You are running $ROLE version of your app"
exec "$@"

docker run --rm -e ROLE=some_role docker.local:5000/test /bin/true

В этом случае вы можете указать значение по умолчанию ROLE в Dockerfile, если хотите.

FROM centos:7.4.1708
COPY ./role.sh /usr/local/bin
RUN chmod a+x /usr/local/bin/role.sh
ENV ROLE="default_role"
ENTRYPOINT ["role.sh"]

Второй путь заключается в том, чтобы принять роль в качестве параметра командной строки:

#!/bin/sh
# --> pass a role name, then a command, as parameters
ROLE="$1"
if [ -z "$ROLE" ]; then
  echo "Please pass a role as a command-line option" >&2
  exit 1
fi
echo "You are running $ROLE version of your app"
shift        # drops first parameter
export ROLE  # makes it an environment variable
exec "$@"

docker run --rm docker.local:5000/test some_role /bin/true

Я бы, вероятно, предпочел бы путь с переменной окружением, поскольку он немного легче предоставить несколько несвязанных опций и не смешивать «настройки» и «команду» в части «команда» вызова Docker.

Относительно того, почему ваш модуль «падает»: Kubernetes обычно ожидает, что он будет работать долго, поэтому, если вы напишите контейнер, который просто печатает что-то и выходит, Kubernetes перезапустит его, а когда он не будет работать, он будет всегда находиться в состоянии CrashLoopBackOff. Что вы пытаетесь сделать прямо сейчас, не беспокойтесь об этом и посмотрите на kubectl logs капсулы. Подумайте об установке политики перезапуска спецификации модуля pod, если это вас беспокоит.

Чтобы ответить на вашу конкретную ситуацию, ни ваша ARG, ни ваша ENV, кажется, не имеют эффекта, учитывая то, как вы их объявили.

Ваш рабочий процесс будет выглядеть следующим образом:

1. напишите свой Dockerfile (как вы, хорошо)
2. соберите ваш контейнер (у вас нет ' t при условии, что вы использовали команду build, но с учетом объявления вашего ARG, я предполагаю, что вам нужно было передать туда значение)
3. запустить ваш контейнер (либо docker run, либо в модуле kubernetes pod / deploy / etc) [ 1111]

Ваш ENV ROLE="" означает, что во время сборки у вас должна быть пустая переменная $ ROLE, которую вы можете использовать в Dockerfile, и она будет доступна под тем же именем в среде работающего контейнера (предположительно, как пустая строка).

Ваш ARG ROLE означает, что вам нужно передать роль в вашу команду docker build, которая будет доступна во всем Dockerfile во время сборки, предположительно перезаписывая ранее объявленный ENV, но не оказывая влияния на процесс сборки. [1116 ]

Что касается вашего запущенного скрипта, единственная роль, которая имеет значение, это ROLE=$1, например. переменная $ ROLE, которая принимает значение первого аргумента. Это означает, что бессмысленно указывать ПРАВИЛО env в вашем kubernetes yml, потому что при запуске вашего сценария оно будет перезаписывать RULE первым аргументом вашего сценария, даже если его нет (в результате получается пустое значение).

Эта спецификация выглядит корректно, и не забудьте, что вы можете заменить args: ["master"] чем-то вроде args: ["$(ROLE)"] (например: он будет ожидать, что ROLE env var будет установлен на машине, выполняющей ваш kubectl.

apiVersion: v1
kind: Pod
metadata:
  name: master-pod
  labels:
     app: test-master
spec:
  containers:
    - name: test-master-container
      image: docker.local:5000/test
      command: ["role.sh"]
      args: ["master"]