Регистрация Войти
Рейтинг:1
avatar Server

Избегайте конфликтов переменных среды модуля со ссылками в стиле Docker.

флаг in
Petr Gladkikh

Мы запускаем компоненты в Kubernetes с Docker в качестве среды выполнения контейнера. Проблема с этим заключается в том, что среда pod загрязнена переменными ссылки в стиле Docker, такими как

  • SERVICENAME_PORT_8181_TCP
  • SERVICENAME_PORT_HTTP
  • .....
  • SERVICENAME_PORT

для каждой видимой службы (те, что в одном пространстве имен). В этой ситуации автоматически созданные переменные довольно легко могут конфликтовать с явно объявленной средой. Иногда это приводит к труднодиагностируемым проблемам. Я также не хотел бы полагаться на эти автоматические переменные, поскольку предпочел бы, чтобы контейнеры не зависели от деталей конфигурации службы Kubernetes. В настоящее время я добавляю уникальные префиксы имен к явным переменным, чтобы избежать таких конфликтов.

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

98
0 + 0
Рейтинг:2
avatar Server
флаг in
mdaniel

Есть ли способ настроить кластер, чтобы не добавлять эти автоматические переменные для каждой видимой службы?

Да и нет: не в масштабах всего кластера, насколько я знаю, но enableServiceLinks: ложь поле в спецификация: предназначен для того, чтобы вы могли отключить их

В качестве альтернативы, решит ли эту проблему использование других сред выполнения, таких как containerd?

Нет, эти имена были добавлены в духе совместимости с докером, но они вообще не связаны с докером — они введенный кубелетом

Как вообще я могу использовать среду, не сталкиваясь с такими конфликтами имен? Или имена сервисов считаются частью контракта с контейнерами, и я не должен их свободно менять?

Другой вариант — не запрещать их целиком, а просто замаскировать. конкретный те, которые беспокоят ваше приложение; те, которые заканчиваются на _HTTP особенно проблематичны с Spring Boot, где есть Оказание услуг чья метаданные: {имя: какое-то супер общее имя, например оказание услуг или же сервер

Вы можете сделать это для каждого развертывания:

среда:
- имя: SERVICENAME_PORT_HTTP
  # опускаем значение: просто устанавливаем пустую строку в контейнере
# и остальные

или вы можете объявить ConfigMap, содержащую оскорбительные, и полностью перезаписать их с помощью envОт: (чтобы не приходилось исправлять каждое затронутое развертывание

0 + 0
флаг in
Petr Gladkikh
Спасибо! Мне нравится `enableServiceLinks: false`. Последний вариант, явное маскирование переменных, кажется непрактичным, так как уже должно быть известно, что они мешают, что само по себе может быть неочевидным (это проблема, с которой я начал), и имена изменились бы, если бы кто-то переименовал службы. или создавать новые.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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