☰

Избегайте конфликтов переменных среды pod с помощью ссылок в стиле Docker

tag-icon • tag-icon kubernetes environment-variables
Избегайте конфликтов переменных среды pod с помощью ссылок в стиле Docker

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

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

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

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

решение1

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

И да, и нет: насколько мне известно, не на уровне кластера, ноenableServiceLinks: falseполе вspec:разработаны так, чтобы вы могли их выключить

Или же можно ли решить эту проблему с помощью других сред выполнения, например containerd?

Нет, эти имена были добавлены в целях совместимости с Docker, но они вообще не связаны с Docker — онивведено kubelet

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

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

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

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

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

Связанный контент