Expor uma aplicação vinculada a localhost para outros pods - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Quando uma aplicação se vincula a localhost (127.0.0.1) em vez de 0.0.0.0, outros pods no cluster não conseguem acessá-la, mesmo que um Service do Kubernetes exponha a porta correta. Este tópico explica o motivo e apresenta duas soluções.

Descrição do problema

Uma aplicação no cluster escuta em localhost e outros pods não conseguem acessá-la por meio do Service do Kubernetes.

Padrões comuns de vinculação a localhost:

Linguagem	Código
Go	`net.Listen("tcp", "localhost:8080")`
Node.js	`http.createServer().listen(8080, "localhost")`
Python	`socket.socket().bind(("localhost", 8083))`

Causa

Cada pod no Kubernetes recebe seu próprio endereço IP. Um Service roteia o tráfego para esse IP do pod, e não para localhost dentro do pod. Quando uma aplicação se vincula a localhost, ela aceita conexões apenas na interface de loopback (127.0.0.1), cujo escopo se limita ao namespace de rede do próprio pod. O tráfego que chega pelo IP do pod nunca alcança a aplicação.

Em um cluster gerenciado pelo ASM, o proxy sidecar do Istio adiciona outra camada: ele intercepta o tráfego de entrada por meio de regras iptables e o encaminha para a aplicação. Se a aplicação escutar apenas em localhost, o proxy sidecar não conseguirá entregar o tráfego a ela, pois o encaminhamento tem como destino o IP do pod, e não o endereço de loopback.

Soluções

Duas abordagens estão disponíveis:

Abordagem	Quando usar
Alterar o endereço de vinculação	Você tem controle sobre o código-fonte da aplicação
Configure um resource Sidecar	Não é possível modifique o código da aplicação

Solução 1: Alterar o endereço de vinculação

Atualize o código da aplicação para escutar em 0.0.0.0 em vez de localhost. Isso faz com que a aplicação aceite conexões em todas as interfaces de rede, incluindo o IP do pod.

Linguagem	Antes (localhost)	Depois (todas as interfaces)
Go	`net.Listen("tcp", "localhost:8080")`	`net.Listen("tcp", "0.0.0.0:8080")`
Node.js	`http.createServer().listen(8080, "localhost")`	`http.createServer().listen(8080, "0.0.0.0")`
Python	`socket.socket().bind(("localhost", 8083))`	`socket.socket().bind(("0.0.0.0", 8083))`

Após implantar o código atualizado, verifique se outros pods conseguem acessar a aplicação por meio do Service.

Solução 2: Configure um resource Sidecar

Quando não for viável alterar o código da aplicação, crie um resource Sidecar do Istio que encaminhe o tráfego de entrada para o endereço localhost. O proxy sidecar recebe o tráfego na porta do Service e o redireciona para 127.0.0.1:<container-port> dentro do pod.

Procedimento

Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique em no nome da instância do ASM. No painel de navegação à esquerda, escolha Traffic Management Center > Sidecar Traffic Configuration. Na página exibida, clique em Create from YAML.
Clique em Create from YAML.
Na página Create, selecione um namespace e um modelo, cole a seguinte configuração YAML e clique em Create.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: localhost-access
  namespace: <namespace>
spec:
  ingress:
    - defaultEndpoint: '127.0.0.1:<container-port>'
      port:
        name: tcp
        number: <service-port>
        protocol: TCP
  workloadSelector:
    labels:
      <label-key>: <label-value>

Substitua os seguintes espaços reservados pelos seus valores reais:

Espaço reservado	Descrição	Exemplo
`<namespace>`	Namespace onde a aplicação está implantada	`default`
`<container-port>`	Porta em que a aplicação escuta no localhost	`8080`
`<service-port>`	Porta exposta pelo Service do Kubernetes	`80`
`<label-key>: <label-value>`	Rótulo do pod que identifica a carga de trabalho de destino	`app: my-service`

O campo defaultEndpoint indica ao proxy sidecar para onde encaminhar o tráfego de entrada. Definir esse campo como 127.0.0.1:<container-port> direciona as requisições para o endereço de loopback, correspondendo ao local onde a aplicação já escuta.

Verifique a correção

Após aplicar qualquer uma das soluções, teste a conectividade entre pods:

# From another pod, send a request to the application through its Service
kubectl exec -it <test-pod> -- curl http://<service-name>.<namespace>.svc.cluster.local:<service-port>

Uma resposta bem-sucedida confirma que a aplicação está acessível a partir de outros pods.

Se a requisição falhar, verifique os logs do proxy sidecar em busca de erros de encaminhamento:

kubectl logs <pod-name> -c istio-proxy