Todos os produtos
Search

Este produto

    Alibaba Cloud Service Mesh:Use a DNS proxy for multi-cluster service discovery

    Central de documentação

    Alibaba Cloud Service Mesh:Use a DNS proxy for multi-cluster service discovery

    Última atualização: Jun 28, 2026

    Em uma malha de serviços multicluster, o servidor DNS de cada cluster resolve apenas os serviços implantados localmente. Quando um serviço em um cluster envia uma solicitação para um serviço existente somente em outro cluster, a resolução DNS falha. O DNS proxy soluciona esse problema: o sidecar proxy intercepta as consultas DNS e resolve os nomes dos serviços em todos os clusters gerenciados pelo mesmo plano de controle do Alibaba Cloud Service Mesh (ASM).

    Este documento aborda as seguintes etapas:

    1. Implante dois serviços em clusters distintos: sleep em um e HTTPBin no outro.

    2. Confirme que a resolução DNS entre clusters falha sem o DNS proxy.

    3. Ative o DNS proxy e verifique se a descoberta de serviços entre clusters funciona corretamente.

    Como funciona o DNS proxy

    Sem o DNS proxy, o servidor DNS de cada cluster conhece apenas os serviços implantados nesse mesmo cluster. Se o serviço sleep no cluster m1c2 enviar uma solicitação para httpbin:8000, a consulta falhará porque não existe nenhum objeto Service chamado httpbin em m1c2.

    Com o DNS proxy ativado, o sidecar proxy intercepta as consultas DNS de saída antes que cheguem ao servidor DNS do cluster. O plano de controle do ASM mantém uma visão unificada de todos os serviços nos clusters gerenciados. Assim, o sidecar resolve httpbin para o endpoint correto no cluster m1c1, mesmo sem um objeto Service local.

    Architecture diagram showing cross-cluster service discovery with DNS proxy

    Pré-requisitos

    Antes de começar, certifique-se de ter:

    Etapa 1: Implantar os serviços sleep e HTTPBin

    Implante cada serviço em um cluster separado para exigir a descoberta entre clusters.

    1a. Implantar o sleep no m1c2

    Aplique o seguinte YAML ao cluster m1c2. Para instruções de implantação, consulte Implantar uma aplicação em uma instância do ASM.

    sleep service YAML

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curl:8.1.2
        command: ["/bin/sleep", "infinity"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true

    1b. Implantar o HTTPBin no m1c1

    Aplique o seguinte YAML ao cluster m1c1. Para instruções de implantação, consulte Implantar uma aplicação em uma instância do ASM.

    HTTPBin service YAML

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

    Etapa 2: Confirmar a falha na descoberta entre clusters

    Antes de ativar o DNS proxy, verifique se o serviço sleep no m1c2 não consegue resolver httpbin.

    Conecte-se ao cluster m1c2 com kubectl e execute:

    kubectl exec -it deploy/sleep -c sleep -- curl httpbin:8000

    Saída esperada:

    curl: (6) Could not resolve host: httpbin

    O servidor DNS no m1c2 não possui registro para httpbin porque o objeto Service do HTTPBin existe apenas no m1c1.

    Etapa 3: Ativar o DNS proxy e verificar a descoberta entre clusters

    3a. Ativar o DNS proxy

    Ative o recurso DNS proxy para a instância do ASM. Consulte a seção "Enable DNS Proxy" em Configurar sidecar proxies.

    3b. Reimplantar a carga de trabalho sleep

    Reimplante a carga de trabalho sleep no cluster m1c2 para aplicar a configuração atualizada do sidecar. Consulte a seção "(Optional) Redeploy workloads" em Configurar sidecar proxies.

    3c. Testar a descoberta entre clusters

    Conecte-se ao cluster m1c2 com kubectl e execute o mesmo comando:

    kubectl exec -it deploy/sleep -c sleep -- curl httpbin:8000

    Saída esperada:

    <!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <title>httpbin.org</title>
...

    A resposta é a página HTML do HTTPBin servida pelo cluster m1c1. O sidecar proxy no m1c2 interceptou a consulta DNS, resolveu httpbin por meio do plano de controle do ASM e roteou a solicitação para o serviço HTTPBin no m1c1.

    Tópicos relacionados