☰

Evite conflitos de variáveis ​​de ambiente de pod com links estilo Docker

tag-icon • tag-icon kubernetes environment-variables
Evite conflitos de variáveis ​​de ambiente de pod com links estilo Docker

Executamos componentes no Kubernetes com Docker como tempo de execução do contêiner. Um problema é que o ambiente do pod está poluído com variáveis ​​de link no estilo Docker, como

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

para cada serviço visível (aqueles no mesmo namespace). Nesta situação é bastante fácil que variáveis ​​criadas automaticamente tenham conflitos com o ambiente explicitamente declarado. Isso às vezes leva a problemas difíceis de diagnosticar. Eu também não gostaria de depender dessas variáveis ​​automáticas, pois preferiria que os contêineres não dependessem dos detalhes da configuração do serviço Kubernetes. Atualmente estou adicionando prefixos de nomes exclusivos a variáveis ​​explícitas para evitar tais conflitos.

Existe uma maneira de configurar o cluster para não adicionar essas variáveis ​​automáticas para cada serviço visível? Como alternativa, o uso de outros tempos de execução resolveria containerdesse problema? Estou surpreso que não existam soluções facilmente pesquisáveis ​​no Google para isso, já que a configuração por meio de variáveis ​​de ambiente é considerada uma boa prática. Como, em geral, uso o ambiente sem entrar em tais conflitos de nomenclatura? Ou os nomes dos serviços são considerados parte do contrato com os contêineres e não devo alterá-los livremente?

Responder1

Existe uma maneira de configurar o cluster para não adicionar essas variáveis ​​automáticas para cada serviço visível?

Sim e não: não em todo o cluster, AFAIK, mas noenableServiceLinks: falsecampo emspec:foi projetado para permitir que você os desligue

Como alternativa, o uso de outros tempos de execução como o containerd resolveria esse problema?

Não, esses nomes foram adicionados no espírito de compatibilidade com o docker, mas não estão relacionados ao docker - eles sãoinjetado por kubelet

Como, em geral, uso o ambiente sem entrar em tais conflitos de nomenclatura? Ou os nomes dos serviços são considerados parte do contrato com os contêineres e não devo alterá-los livremente?

Outra opção é, em vez de proibi-los em massa, você também pode simplesmente mascarar oespecíficoaqueles que incomodam seu aplicativo; aqueles que terminam em _HTTPsão especialmente problemáticos com o Spring Boot, onde existe um Servicenome metadata: { name:super genérico como serviceouserver

Você pode fazer isso por implantação:

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

ou você pode declarar um ConfigMap contendo os ofensivos e substituí-los por atacado envFrom:(para não precisar corrigir cada implantação afetada

informação relacionada