Sobre a descoberta de serviços

Este documento explica como a descoberta de serviços no Google Kubernetes Engine (GKE) simplifica o gerenciamento de aplicativos e como estender a descoberta de serviços além de um único cluster usando escopos do Cloud DNS, serviços de vários clusters (MCS, na sigla em inglês) e o diretório de serviços.

Este documento é destinado a usuários, desenvolvedores, administradores e arquitetos do GKE. Para saber mais sobre papéis comuns e tarefas de exemplo que referenciamos no Google Cloud conteúdo, consulte Funções e tarefas comuns do usuário do GKE.

Antes de ler este documento, confira se você entende os seguintes conceitos:

Visão geral

A descoberta de serviços é um mecanismo que permite que serviços e aplicativos se encontrem e se comuniquem dinamicamente sem codificar endereços IP ou configurações de endpoint. A descoberta de serviços ajuda a garantir que os aplicativos sempre tenham acesso a endereços IP de pods atualizados, mesmo quando os pods são reagendados ou novos pods são adicionados. O GKE oferece várias maneiras de implementar a descoberta de serviços, incluindo kube-dns, implantações personalizadas do kube-dns e o Cloud DNS. É possível otimizar ainda mais o desempenho do DNS com NodeLocal DNSCache.

Benefícios da descoberta de serviços

A descoberta de serviços oferece os seguintes benefícios:

  • Gerenciamento de aplicativos simplificado: a descoberta de serviços elimina a necessidade de codificar endereços IP nas configurações do aplicativo. Os aplicativos se comunicam usando nomes de serviço lógicos, que são resolvidos automaticamente para os endereços IP corretos do pod. Essa abordagem simplifica a configuração, especialmente em ambientes dinâmicos em que os endereços IP do pod podem mudar devido ao escalonamento ou reagendamento.
  • Escalonamento e resiliência simplificados: a descoberta de serviços simplifica o escalonamento ao desacoplar os consumidores de serviços dos endereços IP do pod, que mudam com frequência. À medida que o aplicativo é escalonado ou se os pods falham e são substituídos, o Kubernetes atualiza automaticamente quais pods estão disponíveis para receber tráfego de um determinado serviço. A descoberta de serviços ajuda a garantir que as solicitações para o nome de serviço estável sejam direcionadas apenas a pods íntegros, o que permite que o aplicativo seja escalonado ou se recupere de falhas sem intervenção manual ou reconfiguração do cliente.
  • Alta disponibilidade: o GKE usa o balanceamento de carga com a descoberta de serviços para ajudar a garantir alta disponibilidade e melhorar a capacidade de resposta dos aplicativos, mesmo em cargas pesadas.

Balanceamento de carga com descoberta de serviços

O GKE ajuda a garantir alta disponibilidade para seus aplicativos combinando diferentes níveis de balanceamento de carga com a descoberta de serviços.

  • Serviços internos: para serviços acessíveis apenas no cluster, o plano de dados do GKE (kube-proxy ou Cilium) atua como um balanceador de carga. Ele distribui o tráfego de entrada de maneira uniforme em vários pods íntegros, evitando a sobrecarga e ajudando a garantir alta disponibilidade.
  • Serviços externos: para serviços que precisam ser acessíveis de fora do cluster, o GKE provisiona Google Cloud balanceadores de carga. Esses balanceadores de carga incluem balanceadores de carga externos Google Cloud para acesso público à Internet e balanceadores de carga internos Google Cloud para acesso na rede da nuvem privada virtual. Esses balanceadores de carga distribuem o tráfego entre os nós do cluster. O plano de dados em cada nó encaminha o tráfego para os pods apropriados.

Em cenários internos e externos, a descoberta de serviços atualiza continuamente a lista de pods disponíveis para cada serviço. Essa atualização contínua ajuda a garantir que o plano de dados (para serviços internos) e os Google Cloud balanceadores de carga (para serviços externos) direcionem o tráfego apenas para instâncias íntegras.

Casos de uso da descoberta de serviços

Confira a seguir casos de uso comuns para a descoberta de serviços:

  • Arquitetura de microsserviços: em uma arquitetura de microsserviços, os aplicativos geralmente consistem em muitos serviços menores e independentes que precisam interagir. A descoberta de serviços permite que esses aplicativos se encontrem e troquem informações, mesmo enquanto o cluster é escalonado.
  • Ativar implantações sem tempo de inatividade e melhorar a resiliência: a descoberta de serviços facilita atualizações sem tempo de inatividade para aplicativos, incluindo lançamentos controlados e implantações canário. Ela automatiza a descoberta de novas versões de serviço e muda o tráfego para elas, o que ajuda a reduzir o tempo de inatividade durante a implantação e garante uma transição tranquila para os usuários. A descoberta de serviços também melhora a resiliência. Quando um pod falha no GKE, um novo é implantado, e a descoberta de serviços registra o novo pod e redireciona o tráfego para ele, o que ajuda a minimizar o tempo de inatividade do aplicativo.

Como a descoberta de serviços funciona

No GKE, os aplicativos geralmente consistem em vários pods que precisam se encontrar e se comunicar. A descoberta de serviços fornece essa capacidade usando o sistema de nome de domínio (DNS, na sigla em inglês). Assim como você usa o DNS para encontrar sites na Internet, os pods em um cluster do GKE usam o DNS para localizar e se conectar a serviços usando os nomes deles. Essa abordagem permite que os pods interajam de maneira eficaz, independentemente de onde estejam em execução no cluster, e permite que os aplicativos se comuniquem usando nomes de serviço consistentes em vez de endereços IP instáveis.

Como os pods realizam a resolução de DNS

Os pods em um cluster do GKE resolvem nomes DNS para serviços e outros pods usando uma combinação de registros DNS gerados automaticamente e a configuração de DNS local.

Nomes DNS de serviço

Quando você cria um serviço do Kubernetes, o GKE atribui automaticamente um nome DNS a ele. Esse nome segue um formato previsível, que qualquer pod no cluster pode usar para acessar o serviço:

<service-name>.<namespace>.svc.cluster.local

O domínio de cluster padrão é cluster.local, mas é possível personalizar o domínio ao criar o cluster. Por exemplo, um serviço chamado my-web-app em o namespace padrão teria o nome DNS my-web-app.default.svc.cluster.local.

O papel de /etc/resolv.conf

Para resolver esses nomes DNS, os pods dependem do arquivo /etc/resolv.conf. Esse arquivo de configuração informa ao pod qual servidor de nomes enviar as consultas DNS. O endereço IP do servidor de nomes listado nesse arquivo depende dos recursos de DNS específicos ativados no cluster do GKE. A tabela a seguir descreve qual IP do servidor de nomes um pod usa, com base na sua configuração:

Cloud DNS para GKE NodeLocal DNSCache Valor do servidor de nomes `/etc/resolv.conf`
Ativado Ativado `169.254.20.10`
Ativado Desativado `169.254.169.254`
Desativado Ativado Endereço IP do serviço `kube-dns`
Desativado Desativado Endereço IP do serviço `kube-dns`

Essa configuração ajuda a garantir que as consultas DNS do pod sejam direcionadas ao componente correto:

  • NodeLocal DNSCache: fornece pesquisas locais rápidas no nó.
  • Endereço IP do servidor de metadados (169.254.169.254): é usado quando o Cloud DNS para GKE está ativado sem o NodeLocal DNSCache. As consultas DNS são direcionadas a esse endereço IP, que o Cloud DNS usa para interceptar e processar solicitações DNS.
  • Endereço IP do serviço kube-dns: é usado para resolução padrão no cluster quando o Cloud DNS para GKE está desativado.

Arquitetura de DNS no GKE

O GKE oferece uma arquitetura flexível para descoberta de serviços, principalmente usando o DNS. Os componentes a seguir funcionam juntos para resolver consultas DNS no cluster:

  • kube-dns: o provedor de DNS padrão no cluster para clusters do GKE Standard. Ele é executado como uma implantação gerenciada de pods no namespace kube-system e monitora a API Kubernetes para novos serviços para criar os registros DNS necessários.
  • Cloud DNS: Google Cloudserviço de DNS totalmente gerenciado do Google Cloud. Ele oferece uma alternativa altamente escalonável e confiável ao kube-dns e é o provedor de DNS padrão para clusters do GKE Autopilot.
  • NodeLocal DNSCache: um complemento do GKE que melhora o desempenho da pesquisa de DNS. Ele executa um cache DNS em cada nó do cluster, trabalhando com kube-dns ou Cloud DNS para atender consultas DNS localmente, o que reduz a latência e a carga no provedor de DNS central do cluster. Para clusters do GKE Autopilot, o NodeLocal DNSCache está ativado por padrão e não pode ser modificado.
  • Implantação kube-dns personalizada: uma implantação que permite implantar e gerenciar sua própria instância do kube-dns, que oferece mais controle sobre kube-dns configuração e recursos.

Escolha seu provedor de DNS

A tabela a seguir resume os provedores de DNS disponíveis no GKE, incluindo os recursos e quando escolher cada um deles:

Provedor Recursos Quando usar
`kube-dns` Resolução de DNS no cluster para serviços e pods. Todos os clusters com necessidades de rede padrão. A nova versão do `kube-dns` é adequada para clusters pequenos e grandes.
Cloud DNS Recursos avançados de DNS (zonas particulares, direção de tráfego, balanceamento de carga global) e integração com outros Google Cloud serviços. Exposição de serviços externamente, ambientes de vários clusters ou para clusters com altas taxas de consulta DNS (QPS).
Implantação personalizada do `kube-dns` Controle adicional sobre a configuração, alocação de recursos e o potencial de usar provedores de DNS alternativos. Clusters de grande escala ou necessidades específicas de DNS que exigem escalonamento mais agressivo ou controle refinado sobre a alocação de recursos.

Descoberta de serviço fora de um único cluster

É possível estender a descoberta de serviços além de um único cluster do GKE usando os seguintes métodos:

Escopo do Cloud DNS

Os clusters que usam o Cloud DNS para DNS do cluster podem operar em um dos três escopos disponíveis:

  • Escopo do cluster: esse é o comportamento padrão do Cloud DNS. Nesse modo, o Cloud DNS funciona de maneira equivalente ao kube-dns, fornecendo resolução de DNS exclusivamente para recursos que estão no cluster. Os registros DNS podem ser resolvidos apenas de dentro do cluster e aderem ao esquema de serviço padrão do Kubernetes: <svc>.<ns>.svc.cluster.local.
  • Escopo aditivo da VPC: esse recurso opcional estende o escopo do cluster, tornando os serviços headless resolvíveis a partir de outros recursos na mesma rede VPC, como VMs do Compute Engine ou clientes locais que se conectam usando o Cloud VPN ou o Cloud Interconnect.
  • Escopo da VPC: com essa configuração, os registros DNS dos serviços de cluster podem ser resolvidos em toda a rede VPC. Essa abordagem significa que qualquer cliente que esteja na mesma VPC ou conectado a ela (pelo Cloud VPN ou Cloud Interconnect) pode resolver diretamente os nomes de serviço.

Para saber mais sobre o DNS do escopo da VPC, consulte Como usar o Cloud DNS para GKE.

Serviços de vários clusters

Os serviços de vários clusters (MCS, na sigla em inglês) permitem a descoberta de serviços e o gerenciamento de tráfego em vários clusters do GKE. O MCS permite criar aplicativos que abrangem clusters, mantendo uma experiência de serviço unificada.

O MCS aproveita a descoberta de serviços baseada em DNS para conectar serviços em clusters. Quando você cria uma instância do MCS, ela gera registros DNS no formato de <svc>.<ns>.svc.clusterset.local. Esses registros são resolvidos para os endereços IP dos endpoints do serviço em cada cluster participante.

Quando um cliente em um cluster acessa um MCS, as solicitações são encaminhadas para o endpoint disponível mais próximo em qualquer um dos clusters participantes. Essa distribuição de tráfego é gerenciada pelo kube-proxy (ou Cilium no GKE Dataplane V2) em cada nó, o que ajuda a garantir a comunicação eficiente e o balanceamento de carga entre clusters.

Diretório de serviços para o GKE

O Diretório de serviços para o GKE fornece um registro unificado para descoberta de serviços em implantações do Kubernetes e de terceiros. O Diretório de serviços pode registrar serviços do GKE e de terceiros em um único registro.

O Diretório de serviços é útil principalmente se você quiser:

  • que um único registro de aplicativos do Kubernetes e de terceiros descubram uns aos outros;
  • uma ferramenta de descoberta de serviço gerenciado;
  • a capacidade de armazenar metadados sobre o serviço que outros clientes podem acessar;
  • a capacidade de definir permissões de acesso por nível de serviço. Os serviços do Diretório de serviços podem ser resolvidos usando DNS, HTTP e gRPC. O Diretório de serviços é integrado ao Cloud DNS e pode preencher registros do Cloud DNS que correspondam a serviços no Diretório de serviços.

Para mais informações, consulte Configurar o diretório de serviços para o GKE.

Otimizar o desempenho do DNS e as práticas recomendadas

Para ajudar a garantir a descoberta de serviços confiável e eficiente, especialmente em clusters de grande escala ou de alto tráfego, considere as práticas recomendadas e estratégias de otimização a seguir.

Otimizar o desempenho com o NodeLocal DNSCache

Para clusters que têm uma alta densidade de pods ou aplicativos que geram um grande volume de consultas DNS, é possível melhorar as velocidades de busca DNS ativando o NodeLocal DNSCache. O NodeLocal DNSCache é um complemento do GKE que executa um cache DNS em cada nó do cluster. Quando um pod faz uma solicitação DNS, a solicitação vai para o cache que está no mesmo nó. Essa abordagem reduz a latência e o tráfego de rede.

Para mais informações sobre como ativar e configurar esse recurso, consulte Como configurar o NodeLocal DNSCache.

Escalonar o provedor de DNS

Se você usar o kube-dns e tiver tempos limite intermitentes, principalmente durante períodos de alto tráfego, talvez seja necessário escalonar o número de réplicas do kube-dns. O kube-dns-autoscaler ajusta o número de réplicas com base no número de nós e núcleos no cluster, e os parâmetros podem ser ajustados para implantar mais réplicas mais cedo.

Para instruções detalhadas, consulte Configurar uma implantação personalizadakube-dns.

Práticas recomendadas gerais

  • Selecione o provedor de DNS apropriado: escolha o provedor de DNS com base nas necessidades do cluster. O Cloud DNS é recomendado para cargas de trabalho de QPS alta, ambientes de vários clusters e quando você precisa de integração com sua rede VPC mais ampla. A nova versão do kube-dns é adequada para uma ampla variedade de clusters, de pequenos a grandes, que têm necessidades padrão de descoberta de serviços no cluster.
  • Evite VMs spot ou VMs preemptivas para kube-dns: ajude a garantir a estabilidade do serviço DNS do cluster não executando componentes críticos do sistema, como kube-dns em VMs spot ou VMs preemptivas. O encerramento inesperado de nós pode levar a problemas de resolução de DNS.
  • Use nomes de serviço claros e descritivos: adote convenções de nomenclatura consistentes e significativas para seus serviços para facilitar a leitura e a manutenção das configurações do aplicativo.
  • Organize com namespaces: use namespaces do Kubernetes para agrupar serviços relacionados. Essa abordagem ajuda a evitar conflitos de nomenclatura e melhora a organização de recursos do cluster.
  • Monitore e valide o DNS: monitore regularmente as métricas e os registros de DNS para identificar possíveis problemas antes que eles afetem seus aplicativos. Teste periodicamente a resolução de DNS nos pods para garantir que a descoberta de serviços esteja funcionando conforme o esperado.

A seguir