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) e 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 referenciados no conteúdo do Google Cloud , consulte Tarefas e papéis de usuário comuns do GKE Enterprise.

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 pod atualizados, mesmo quando os pods são reprogramados 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 de 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 simplificado de aplicativos: 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 dos pods, 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 para 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 seu 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 garantir a alta disponibilidade e melhorar a capacidade de resposta dos aplicativos, mesmo sob cargas pesadas.

Balanceamento de carga com descoberta de serviços

O GKE ajuda a garantir a alta disponibilidade dos seus aplicativos combinando diferentes níveis de balanceamento de carga com 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 entre 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 balanceadores de carga Google Cloud . Esses balanceadores de carga incluem balanceadores de carga Google Cloud externos para acesso público à Internet e balanceadores de carga Google Cloud internos para acesso na rede de nuvem privada virtual. Esses balanceadores distribuem o tráfego entre os nós do cluster. O plano de dados em cada nó roteia ainda mais o tráfego para os pods apropriados.

Nos 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 balanceadores de carga Google Cloud (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 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.
  • Ative implantações sem tempo de inatividade e melhore 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. Ele 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 aumenta 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 oferece essa capacidade usando o Sistema de Nomes de Domínio (DNS). 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, independente de onde estejam sendo executados 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 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 padrão do cluster é cluster.local, mas é possível personalizar o domínio ao criar o cluster. Por exemplo, um serviço chamado my-web-app no namespace padrão teria o nome DNS my-web-app.default.svc.cluster.local.

A função de /etc/resolv.conf

Para resolver esses nomes de 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 específicos de DNS ativados no cluster do GKE. A tabela a seguir descreve qual IP de 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: oferece pesquisas locais rápidas no nó.
  • 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 DNS. Os seguintes componentes trabalham juntos para resolver consultas de DNS no cluster:

  • kube-dns: o provedor de DNS padrão no cluster para clusters padrão do GKE. Ele é executado como uma implantação gerenciada de pods no namespace kube-system e monitora a API Kubernetes para novos serviços e cria os registros DNS necessários.
  • Cloud DNS:serviç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 às consultas DNS localmente, o que reduz a latência e a carga no provedor DNS central do cluster. Para clusters do GKE Autopilot, NodeLocal DNSCache é ativado por padrão e não pode ser substituído.
  • Implantação personalizada do kube-dns: uma implantação que permite implantar e gerenciar sua própria instância do kube-dns, o que oferece mais controle sobre a configuração e os recursos do kube-dns.

Escolha seu provedor de DNS

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

Provedor Recursos Quando escolher
`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 de grande escala.
Cloud DNS Recursos avançados de DNS (zonas particulares, direcionamento de tráfego, balanceamento de carga global) e integração com outros serviços do Google Cloud . Expor serviços externamente, ambientes de vários clusters ou clusters com altas taxas de consultas de DNS (QPS).
Implantação personalizada do `kube-dns` Mais controle sobre a configuração, a alocação de recursos e a possibilidade de usar provedores de DNS alternativos. Clusters em grande escala ou necessidades específicas de DNS que exigem um 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 dentro do cluster. Os registros DNS só podem ser resolvidos de dentro do cluster e obedecem ao esquema padrão de serviç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 de VPC: com essa configuração, os registros DNS dos serviços de cluster podem ser resolvidos em toda a rede da VPC. Isso significa que qualquer cliente na mesma VPC ou conectado a ela (pelo Cloud VPN ou Cloud Interconnect) pode resolver diretamente os nomes de serviço.

Para mais informações 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) permitem a descoberta de serviços e o gerenciamento de tráfego em vários clusters do GKE. Com o MCS, é possível criar aplicativos que abrangem clusters e manter uma experiência de serviço unificada.

O MCS usa 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 <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 roteadas 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 uma 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 oferece 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ços gerenciados;
  • A capacidade de armazenar metadados sobre seu 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 Como configurar o Service Directory para GKE.

Otimizar a performance e as práticas recomendadas de DNS

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

Otimizar a performance com o NodeLocal DNSCache

Para clusters com 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, ela vai para o cache 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 seu provedor de DNS

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

Para instruções detalhadas, consulte Como aumentar a escala do kube-dns.

Práticas recomendadas gerais

  • Selecione o provedor de DNS adequado: escolha o provedor de DNS com base nas necessidades do cluster. O Cloud DNS é recomendado para cargas de trabalho de alto QPS, 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 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 preemptivas. O encerramento inesperado de nós pode causar 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, facilitando a leitura e a manutenção das configurações de aplicativos.
  • 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 dos 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 seus pods para garantir que a descoberta de serviços esteja funcionando como esperado.

A seguir