Как сделать переменную среды разной для двух модулей одного и того же развертывания в kubernetes?

Question

На основе этого можно создавать переменные среды, которые одинаковы для всех определяемых вами модулей развертывания.

Есть ли способ указать развертыванию Kubernetes создатьpods, которые имеют разные переменные окружения?

Вариант использования:

Допустим, у меня есть контейнер мониторинга, и я хочу создать 4 его копии.Этот контейнер имеет службу, которая отправляет почтовые сообщения, если переменные среды определяют это.Например, если env var IS_MASTER имеет значение true, то служба переходит к отправке этих электронных писем.

apiVersion: v1
kind: Deployment
metadata:
  ...
spec:
  ...
  replicas: 4
  ...
  template:
    ...
    spec:
      containers:
      -env: 
        -name: IS_MASTER
         value: <------------- True only in one of the replicas

(В моем случае я использую helm, но то же самое можно сделать и без helm)

Answer 1

Еще одно решение - использовать одну и ту же таблицу управления рулем для обоих случаев и запустить одно развертывание руля для каждого случая.Вы можете перезаписывать переменные env с помощью helm (используя --set .Values.foo.deployment.isFirst= "0" или "1")

Обратите внимание, что Helm / K8s не позволит вам POST одинаковую конфигурацию дважды .

Таким образом, вам придется условно применить некоторые конкретные конфигурации Kubernetes (Secrets, ConfigMaps, Secrets и т. Д.) Только для первого развертывания.

{{- if eq .Values.foo.deployment.isFirst "1" }}
...
...
{{- end }}

Answer 2

Все реплики Pod в развертывании будут иметь одинаковые переменные среды и не иметь уникального значения для идентификации конкретного Pod.Создание нескольких развертываний - лучшее решение.

Не знаю, почему OP предназначен только для одного развертывания.Одним из решений является использование StatefulSets .Имена узлов будут выглядеть как web-0, web1, web-2 и так далее.В проверке кода для имени хоста, если это web-0, отправьте электронные письма или сделайте что-нибудь еще.

Это грязное решение, но я не могу придумать лучшего решения, чем создание нескольких развертываний.

Answer 3

То, что вы ищете, насколько я знаю, больше похоже на антишаблон, чем на невозможное.

Из того, что я понимаю, вы, похоже, ищете развертывание масштабируемой платформы мониторинга / HA, котораяне будет отправлять X раз по оповещениям, так что вы можете либо создать контейнер с коляской, который будет общаться с его братьями и сестрами, и «выбрать» мастер-почтовик (StatefulSet сделает это проще в этом случае), либо просто отделить почтовик отмониторинг и заставить их общаться друг с другом через службу.Это позволило бы вам балансировать нагрузку как на мониторинг, так и на рассылку по отдельности.

monitoring-1 \                 / mailer-1
monitoring-2 --- > mailer.svc -- mailer-2
monitoring-3 /                 \ mailer-3

Любой почтовый запрос будет обрабатываться одним и только одним почтовым агентом из пула, но это при условии, что ваши модули мониторинга не все запущенывместе в оповещениях ... Если это не так, то независимо от ваших «главных» выборов для почтовой программы, вам придется сначала решить эту проблему.

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

Хотя, если вашреплики просто для того, чтобы как-то расширить вычислительную мощность, и ваш мастер должен быть статичным, затем просто использовать StatefulSet и добавить один вкладыш во время выполнения, выполнив if hostname == $statefulset-name-0 then MASTER, но я чувствую, что это не лучшая идея.

Answer 4

По определению, каждый модуль в развертывании идентичен другим его репликам.Это невозможно в определении yaml.

Дополнительным решением будет переопределение модуля command, его обработка и вычисление значения переменной, установка переменной (export IS_MASTER=${resolved_value}) и запускточка входа по умолчанию для контейнера.

Это означает, что вам придется выяснить логику для реализации этого (то есть откуда модуль знает, что это должно быть IS_MASTER = true?).Это деталь реализации, которую можно выполнить с БД или другим общим общим ресурсом, используемым в качестве флага или семафора.