HttpWebRequest с https в C#

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

• 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, если это вас беспокоит.