Definir variáveis de ambiente de proxy num Pod do Kubernetes

Coloque as variáveis de proxy HTTP suportadas na especificação do contentor Kubernetes e mantenha as rotas diretas do cluster separadas da configuração de obtenção de imagens.

Um comando no nó do Kubernetes pode usar um proxy de shell enquanto um Pod nesse nó não tem qualquer ambiente de proxy. O ambiente do contentor é definido pela sua imagem e pela configuração do Pod.

Para uma aplicação que suporta estas variáveis, adicione uma lista env à entrada de contentor existente:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

Num Deployment, isto fica sob o contentor relevante em spec.template.spec.containers. Atualize a carga de trabalho através do seu lançamento normal para que os novos Pods o recebam. Forneça também nomes em minúsculas quando o cliente real os exigir.

A lista de exceção é uma ilustração inicial, não um inventário de todas as rotas do cluster. Utilize o sufixo DNS real do cluster e os destinos internos. As aplicações que usam IP de serviço podem precisar dos intervalos de serviço reais numa sintaxe suportada pelo seu cliente.

Os contentores de inicialização têm as suas próprias especificações de contentor. Adicione aí a configuração pretendida quando realizam uma transferência externa. Para transferências HTTP públicas, um endpoint da lista de proxies HTTP é um candidato para estes valores de ambiente do contentor.

A obtenção de imagens ocorre antes de a aplicação ser executada e é realizada pelo runtime de contentores do nó. O ambiente do Pod não pode configurar essa ligação anterior ao registo.

Por fim, as variáveis de proxy HTTP afetam apenas os clientes que as utilizam. Não redirecionam tráfego arbitrário de bases de dados, UDP ou outros sockets a partir do Pod.

Artigos relacionados