Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Resolução de nomes DNS
Este documento se aplica ao Cloud Service Mesh com o Envoy e às APIs de balanceamento de carga
mais antigas, que incluem regras de encaminhamento.
Este documento explica a relação entre o endereço IP virtual de uma regra de encaminhamento e como ela está associada a um serviço. O documento também
descreve como planejar e configurar o DNS para uma comunicação serviço a serviço em
uma malha de serviço do Cloud Service Mesh.
Considere este exemplo, em que há três serviços, service-a,
service-b e service-c, que se comunicam. Os desenvolvedores costumam
usar nomes de domínio totalmente qualificados no código para comunicação de serviço a
serviço. Se o nome do domínio for example.com, os três serviços poderão ser
representados como:
service-a.example.com
service-b.example.com
service-c.example.com
Ao configurar os recursos do Cloud Service Mesh para criar uma malha de serviço,
você configura uma regra de encaminhamento para cada um dos serviços. Uma regra de encaminhamento representa o par IP:Port do serviço de destino. Para que o tráfego de saída seja interceptado por um proxy sidecar do Envoy, o endereço IP de destino precisa corresponder
ao endereço IP associado à regra de encaminhamento. Portanto, você precisa provisionar um endereço IP para cada serviço. Exemplo:
service-a.example.com tem o endereço IP 10.0.0.100
service-b.example.com tem o endereço IP 10.0.0.101
service-c.example.com tem o endereço IP 10.0.0.102
A configuração correspondente do Cloud Service Mesh tem três regras de encaminhamento,
FR1, FR2 e FR3, cada uma usando a porta 80:
FR1 tem o endereço IP 10.0.0.100:80, que está associado a service-a.example.com.
FR2 tem o endereço IP 10.0.0.101:80, que está associado a service-b.example.com.
FR3 tem o endereço IP 10.0.0.102:80, que está associado a service-c.example.com.
Quando service-a invoca service-b usando o nome de domínio totalmente qualificado (FQDN, na sigla em inglês)
service-b.example.com, três coisas acontecem:
service-a primeiro executa uma busca DNS para service-b.example.com para resolver o endereço IP de service-b.
O domínio é resolvido para 10.0.0.101 para que corresponda ao endereço IP configurado da regra de encaminhamento de service-b.
O proxy do Envoy agora pode interceptar o tráfego e roteá-lo para o serviço de
back-end que tem back-ends de service-b, sejam eles NEGs ou MIGs.
É possível configurar uma zona particular gerenciada do Cloud DNS para hospedar os registros
de recursos dos serviços.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# DNS name resolution\n===================\n\nThis document applies to Cloud Service Mesh with Envoy and the older load-balancing\nAPIs, which include forwarding rules.\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis document explains the relationship between a forwarding rule's virtual IP\naddress and how the forward rule is associated with a service. The document also\noutlines how to plan and configure DNS for a service-to-service communication in\na Cloud Service Mesh service mesh.\n\nConsider this example, in which there are three services, `service-a`,\n`service-b`, and `service-c`, that communicate with each other. Developers often\nuse fully- qualified-domain names in their code for service-to-service\ncommunication. If your domain name is example.com, the three services might be\nrepresented as:\n\n- `service-a.example.com`\n- `service-b.example.com`\n- `service-c.example.com`\n\nWhen you configure Cloud Service Mesh resources to create a service mesh,\nyou configure a forwarding rule for each of the services. A forwarding rule\nrepresents the `IP:Port` pair of the destination service. For egress traffic to\nbe intercepted by an Envoy sidecar proxy, the destination IP address must match\nwith the IP address associated with the forwarding rule. Therefore, you need to\nprovision an IP address for each service. For example:\n\n- `service-a.example.com` has the IP address `10.0.0.100`\n- `service-b.example.com` has the IP address `10.0.0.101`\n- `service-c.example.com` has the IP address `10.0.0.102`\n\nThe corresponding Cloud Service Mesh configuration has three forwarding rules,\nFR1, FR2, and FR3, each using port `80`:\n\n- FR1 has IP address `10.0.0.100:80`, which is associated with `service-a.example.com`.\n- FR2 has IP address `10.0.0.101:80`, which is associated with `service-b.example.com`.\n- FR3 has IP address `10.0.0.102:80`, which is associated with `service-c.example.com`.\n\nWhen `service-a` invokes `service-b` using the fully qualified domain name (FQDN)\n`service-b.example.com`, three things happen:\n\n1. `service-a` first performs a DNS lookup for `service-b.example.com` to resolve `service-b`'s IP address.\n2. The domain is resolved to `10.0.0.101` so that it matches the configured IP address of `service-b`'s forwarding rule.\n3. The Envoy proxy is now able to intercept traffic and route it to the backend service that has `service-b`'s backends, whether those are NEGs or MIGs.\n\nYou can configure a Cloud DNS managed private zone to host the resource\nrecords for your services."]]
