Acerca da deteção de serviços

Este documento explica como a descoberta de serviços no Google Kubernetes Engine (GKE) simplifica a gestão de aplicações e como estender a descoberta de serviços para além de um único cluster através dos âmbitos do Cloud DNS, dos serviços multicluster (MCS) e do Service Directory.

Este documento destina-se a utilizadores, programadores, administradores e arquitetos do GKE. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE Enterprise. Google Cloud

Antes de ler este documento, certifique-se de que compreende os seguintes conceitos:

Vista geral

A deteção de serviços é um mecanismo que permite que os serviços e as aplicações encontrem e comuniquem entre si dinamicamente sem codificar endereços IP nem configurações de pontos finais. A deteção de serviços ajuda a garantir que as aplicações têm sempre acesso a endereços IP de pods atualizados, mesmo quando os pods são reagendados ou são adicionados novos pods. O GKE oferece várias formas de implementar a deteção de serviços, incluindo kube-dns, implementações kube-dns personalizadas e o Cloud DNS. Pode otimizar ainda mais o desempenho do DNS com o NodeLocal DNSCache.

Vantagens da deteção de serviços

A deteção de serviços oferece as seguintes vantagens:

  • Gestão de aplicações simplificada: a deteção de serviços elimina a necessidade de codificar endereços IP nas configurações da sua aplicação. As aplicações comunicam através de nomes de serviços lógicos, que são automaticamente resolvidos para os endereços IP dos pods corretos. Esta abordagem simplifica a configuração, especialmente em ambientes dinâmicos onde os endereços IP dos pods podem mudar devido ao escalonamento ou reagendamento.
  • Escalabilidade e resiliência simplificadas: a descoberta de serviços simplifica a escalabilidade ao separar os consumidores de serviços dos endereços IP dos pods, que mudam com frequência. À medida que a sua aplicação é dimensionada ou se os pods falharem e forem substituídos, o Kubernetes atualiza automaticamente os pods que estão disponíveis para receber tráfego para um determinado serviço. A deteção de serviços ajuda a garantir que os pedidos para o nome do serviço estável são direcionados apenas para pods em bom estado, o que permite que a sua aplicação seja dimensionada ou recuperada de falhas sem intervenção manual nem reconfiguração do cliente.
  • Elevada disponibilidade: o GKE usa o balanceamento de carga juntamente com a deteção de serviços para ajudar a garantir a elevada disponibilidade e melhorar a capacidade de resposta das suas aplicações, mesmo sob cargas pesadas.

Balanceamento de carga com deteção de serviços

O GKE ajuda a garantir a elevada disponibilidade das suas aplicações combinando diferentes níveis de equilíbrio de carga com a deteção de serviços.

  • Serviços internos: para serviços que só são acessíveis no cluster, o plano de dados do GKE (kube-proxy ou Cilium) funciona como um equilibrador de carga. Distribui o tráfego recebido de forma uniforme por vários pods em bom estado, evitando a sobrecarga e ajudando a garantir uma elevada disponibilidade.
  • Serviços externos: para serviços que precisam de ser acessíveis a partir do exterior do cluster, o GKE aprovisiona Google Cloud equilibradores de carga. Estes 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 sua rede de nuvem privada virtual. Estes balanceadores de carga distribuem o tráfego pelos nós no seu cluster. Em seguida, o plano de dados em cada nó encaminha o tráfego para os pods adequados.

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

Exemplos de utilização da descoberta de serviços

Seguem-se exemplos de utilização comuns da deteção de serviços:

  • Arquitetura de microserviços: numa arquitetura de microserviços, as aplicações consistem frequentemente em muitos serviços mais pequenos e independentes que precisam de interagir. A deteção de serviços permite que estas aplicações se encontrem e troquem informações, mesmo enquanto o cluster é dimensionado.
  • Ative implementações sem tempo de inatividade e melhore a resiliência: a deteção de serviços facilita as atualizações sem tempo de inatividade para aplicações, incluindo implementações controladas e implementações canary. Automatiza a deteção de novas versões de serviços e transfere o tráfego para as mesmas, o que ajuda a reduzir o tempo de inatividade durante a implementação e garante uma transição sem problemas para os utilizadores. A deteção de serviços também melhora a resiliência. Quando um Pod falha no GKE, é implementado um novo, e a descoberta de serviços regista o novo Pod e redireciona o tráfego para este, o que ajuda a minimizar o tempo de inatividade da aplicação.

Como funciona a deteção de serviços

No GKE, as aplicações consistem frequentemente em vários pods que precisam de se encontrar e comunicar entre si. A deteção de serviços oferece esta capacidade através do Sistema de Nomes de Domínio (DNS). Tal como usa o DNS para encontrar Websites na Internet, os pods num cluster do GKE usam o DNS para localizar e estabelecer ligação a serviços através dos respetivos nomes de serviços. Esta abordagem permite que os pods interajam eficazmente, independentemente de onde estão a ser executados no cluster, e permite que as aplicações comuniquem através de nomes de serviços consistentes em vez de endereços IP instáveis.

Como os pods realizam a resolução de DNS

Os pods num cluster do GKE resolvem nomes DNS para serviços e outros pods através de uma combinação de registos DNS gerados automaticamente e da respetiva configuração DNS local.

Nomes DNS do serviço

Quando cria um serviço Kubernetes, o GKE atribui-lhe automaticamente um nome DNS. Este nome segue um formato previsível que qualquer Pod no cluster pode usar para aceder ao serviço:

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

O domínio do cluster predefinido é cluster.local, mas pode personalizar o domínio quando cria o cluster. Por exemplo, um serviço denominado my-web-app no espaço de nomes predefinido teria o nome DNS my-web-app.default.svc.cluster.local.

O papel do /etc/resolv.conf

Para resolver estes nomes DNS, os pods dependem do respetivo ficheiro /etc/resolv.conf. Este ficheiro de configuração indica ao Pod para que servidor de nomes enviar as respetivas consultas DNS. O endereço IP do servidor de nomes indicado neste ficheiro depende das funcionalidades de DNS específicas ativadas no cluster do GKE. A tabela seguinte descreve o IP do servidor de nomes que 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`

Esta configuração ajuda a garantir que as consultas DNS do pod são direcionadas para o 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 para este endereço IP, que o Cloud DNS usa para intercetar e processar pedidos DNS.
  • kube-dns Endereço IP do serviço: é usado para a 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 a deteção de serviços, principalmente através da utilização de DNS. Os seguintes componentes funcionam em conjunto para resolver consultas de DNS no cluster:

  • kube-dns: o fornecedor DNS predefinido no cluster para clusters GKE Standard. É executado como uma implementação gerida de pods no espaço de nomes kube-system e monitoriza a API Kubernetes para novos serviços de modo a criar os registos de DNS necessários.
  • Cloud DNS: Google Cloud; serviço DNS totalmente gerido. Oferece uma alternativa altamente escalável e fiável ao kube-dns e é o fornecedor de DNS predefinido para clusters do GKE Autopilot.
  • NodeLocal DNSCache: um suplemento do GKE que melhora o desempenho da pesquisa de DNS. Executa uma cache DNS em cada nó no cluster, funcionando com o kube-dns ou o Cloud DNS para fornecer consultas DNS localmente, o que reduz a latência e a carga no fornecedor DNS central do cluster. Para clusters do GKE Autopilot, NodeLocal DNSCache está ativado por predefinição e não pode ser substituído.
  • Implementação kube-dns personalizada: uma implementação que lhe permite implementar e gerir a sua própria instância do kube-dns, o que lhe dá mais controlo sobre a configuração e os recursos do kube-dns.

Escolha o seu fornecedor de DNS

A tabela seguinte resume os fornecedores de DNS disponíveis no GKE, incluindo as respetivas funcionalidades e quando escolher cada um:

Fornecedor Funcionalidades 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 de pequena e grande escala.
Cloud DNS Funcionalidades avançadas de DNS (zonas privadas, encaminhamento de tráfego, balanceamento de carga global) e integração com outros Google Cloud serviços. Expor serviços externamente, ambientes com vários clusters ou clusters com taxas de consulta DNS elevadas (QPS).
Implementação personalizada do `kube-dns` Controlo adicional sobre a configuração, a atribuição de recursos e a possibilidade de usar fornecedores DNS alternativos. Clusters de grande escala ou necessidades específicas de DNS que requerem um escalamento mais agressivo ou um controlo detalhado sobre a atribuição de recursos.

Deteção de serviços fora de um único cluster

Pode expandir a deteção de serviços para além de um único cluster do GKE através dos seguintes métodos:

Âmbito do Cloud DNS

Os clusters que usam o Cloud DNS para o DNS do cluster podem funcionar num de três âmbitos disponíveis:

  • Âmbito do cluster: este é o comportamento predefinido do Cloud DNS. Neste modo, o Cloud DNS funciona de forma equivalente ao kube-dns, fornecendo resolução de DNS exclusivamente para recursos que estão no cluster. Os registos DNS só são resolvidos a partir do cluster e cumprem o esquema de serviço Kubernetes padrão: <svc>.<ns>.svc.cluster.local.
  • Âmbito da VPC aditivo: esta funcionalidade opcional expande o âmbito do cluster tornando os serviços sem cabeça resolvíveis a partir de outros recursos na mesma rede da VPC, como VMs do Compute Engine ou clientes no local que se ligam através do Cloud VPN ou do Cloud Interconnect.
  • Âmbito da VPC: com esta configuração, os registos DNS para os serviços de cluster são resolvidos em toda a rede VPC. Esta abordagem significa que qualquer cliente que esteja na mesma VPC ou que esteja ligado a ela (através do Cloud VPN ou do Cloud Interconnect) pode resolver diretamente os nomes dos serviços.

Para mais informações sobre o DNS ao nível do VPC, consulte o artigo Usar o Cloud DNS para o GKE.

Serviços em vários clusters

Os serviços em vários clusters (MCS) permitem a descoberta de serviços e a gestão de tráfego em vários clusters do GKE. O MCS permite-lhe criar aplicações que abrangem clusters, mantendo uma experiência de serviço unificada.

O MCS tira partido da descoberta de serviços baseada em DNS para ligar serviços em vários clusters. Quando cria uma instância do MCS, esta gera registos de DNS no formato de <svc>.<ns>.svc.clusterset.local. Estes registos são resolvidos para os endereços IP dos pontos finais do serviço em cada cluster participante.

Quando um cliente num cluster acede a um MCS, os pedidos são encaminhados para o ponto final disponível mais próximo em qualquer um dos clusters participantes. Esta distribuição de tráfego é gerida pelo kube-proxy (ou Cilium no GKE GKE Dataplane V2) em cada nó, o que ajuda a garantir uma comunicação eficiente e o equilíbrio de carga entre clusters.

Service Directory para o GKE

O Service Directory para GKE oferece um registo unificado para a deteção de serviços nas suas implementações do Kubernetes e não do Kubernetes. O Service Directory pode registar serviços GKE e não GKE num único registo.

O diretório de serviços é particularmente útil se quiser qualquer uma das seguintes opções:

  • Um único registo para que as aplicações Kubernetes e não Kubernetes se descubram umas às outras.
  • Uma ferramenta de deteção de serviços gerida.
  • A capacidade de armazenar metadados sobre o seu serviço aos quais outros clientes podem aceder.
  • A capacidade de definir autorizações de acesso ao nível do serviço. Os serviços do Service Directory podem ser resolvidos através de DNS, HTTP e gRPC. O Service Directory está integrado com o Cloud DNS e pode preencher registos do Cloud DNS que correspondam a serviços no Service Directory.

Para mais informações, consulte o artigo Configurar o Service Directory para o GKE.

Otimize o desempenho e as práticas recomendadas de DNS

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

Otimize o desempenho com a NodeLocal DNSCache

Para clusters com uma elevada densidade de pods ou aplicações que geram um volume elevado de consultas DNS, pode melhorar as velocidades de procura de DNS ativando o NodeLocal DNSCache. O NodeLocal DNSCache é um suplemento do GKE que executa uma cache de DNS em cada nó no seu cluster. Quando um pod faz um pedido de DNS, o pedido é enviado para a cache que está no mesmo nó. Esta abordagem reduz a latência e o tráfego de rede.

Para mais informações sobre como ativar e configurar esta funcionalidade, consulte o artigo Configurar NodeLocal DNSCache.

Expanda o seu fornecedor DNS

Se usar o kube-dns e tiver tempos limite intermitentes, particularmente durante períodos de tráfego elevado, pode ter de dimensionar 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 respetivos parâmetros podem ser ajustados para implementar mais réplicas mais cedo.

Para ver instruções detalhadas, consulte o artigo Aumentar a escala do kube-dns.

Práticas recomendadas gerais

  • Selecione o fornecedor DNS adequado: escolha o fornecedor DNS com base nas necessidades do seu cluster. O Cloud DNS é recomendado para cargas de trabalho de QPS elevado, ambientes de vários clusters e quando precisa de integração com a sua rede VPC mais ampla. A nova versão do kube-dns é adequada para uma vasta gama de clusters, de pequenos a grandes, que têm necessidades de deteção de serviços padrão no cluster.
  • Evite VMs do Spot ou VMs preemptivas para kube-dns: ajude a garantir a estabilidade do serviço DNS do seu cluster não executando componentes críticos do sistema, como kube-dns, em VMs do Spot ou VMs preemptivas. As terminações inesperadas de nós podem originar problemas de resolução de DNS.
  • Use nomes de serviços claros e descritivos: adote convenções de nomenclatura consistentes e significativas para os seus serviços, de modo a tornar as configurações das aplicações mais fáceis de ler e manter.
  • Organize com espaços de nomes: use espaços de nomes do Kubernetes para agrupar serviços relacionados. Esta abordagem ajuda a evitar conflitos de nomenclatura e melhora a organização dos recursos do cluster.
  • Monitorize e valide o DNS: monitorize regularmente as métricas e os registos de DNS para identificar potenciais problemas antes de afetarem as suas aplicações. Teste periodicamente a resolução de DNS a partir dos seus pods para garantir que a deteção de serviços está a funcionar conforme esperado.

O que se segue?