Deteção de serviços

Este documento contém uma vista geral da deteção de serviços baseada em DNS do Kubernetes e como pode ser usada com o Kf.

Quando usar a deteção de serviços do Kubernetes com o Kf

A deteção de serviços do Kubernetes pode ser usada por aplicações que precisam de localizar serviços de apoio de forma consistente, independentemente de onde a aplicação está implementada. Por exemplo, uma equipa pode querer usar um URI comum na respetiva configuração que aponta sempre para o gateway SMTP local para desassociar o código do ambiente em que foi executado.

A descoberta de serviços ajuda as equipas de aplicações das seguintes formas:

  • Reduzir a quantidade de configuração por ambiente.
  • Desassociar aplicações cliente e servidor.
  • Permitir que as aplicações sejam portáteis para novos ambientes.

Pode usar a deteção de serviços do Kubernetes quando:

  • As aplicações usam as configurações de DNS do respetivo contentor para resolver anfitriões.
  • As aplicações são implementadas com os respetivos serviços de apoio no mesmo cluster ou espaço de nomes do Kubernetes.
  • Os serviços de apoio têm um serviço Kubernetes associado. Kf cria estes para cada app.
  • As NetworkPolicies do Kubernetes permitem o tráfego entre uma aplicação e o serviço do Kubernetes com o qual precisa de comunicar. O Kf cria estas políticas em cada espaço do Kf.

Não deve usar a deteção de serviços do Kubernetes se:

  • As aplicações têm de fazer failover entre vários clusters.
  • Substitui o resolvedor de DNS usado pela sua aplicação.
  • As aplicações precisam de tipos específicos de balanceamento de carga.

Como funciona a deteção de serviços do Kubernetes

A deteção de serviços do Kubernetes funciona através da modificação da configuração de DNS dos contentores em execução num nó do Kubernetes. Quando uma aplicação procura um nome de domínio não qualificado, o resolvedor de DNS local tenta primeiro resolver o nome no cluster local.

Os domínios sem várias partes são resolvidos em relação aos nomes dos serviços Kubernetes no espaço de nomes do contentor. Cada app do Kf cria um serviço do Kubernetes com o mesmo nome. Se duas apps Kf ping e pong foram implementadas no mesmo espaço Kf, ping podia usar o URL http://pong para enviar tráfego para o outro serviço.

Os domínios com um único ponto são resolvidos em relação aos serviços do Kubernetes no espaço de nomes do Kubernetes com o mesmo nome que a etiqueta após o ponto. Por exemplo, se existir uma base de dados PostgreSQL com um serviço no espaço de nomes customersdatabase, uma aplicação noutro espaço de nomes pode resolvê-lo através de postgres://customers.database.

Como usar a descoberta de serviços com o Kf

A deteção de serviços baseada em DNS do Kubernetes pode ser usada em qualquer app do Kf. Cada app do Kf cria um serviço do Kubernetes com o mesmo nome, e cada espaço do Kf cria um espaço de nomes do Kubernetes com o mesmo nome.

  • Referir-se a uma app Kf no espaço atual através de protocol://app-name.
  • Referir-se a uma app Kf num espaço diferente através de protocol://app-name.space-name.
  • Referir-se a uma app Kf no espaço atual a ouvir numa porta personalizada através de protocol://app-name:port.
  • Referir-se a uma app Kf num espaço diferente a ouvir uma porta personalizada através de protocol://app-name.space-name:port.

Práticas recomendadas

As aplicações que vão ser o destino da deteção de serviços baseada em DNS devem ter verificações de estado frequentes para garantir que são adicionadas e removidas rapidamente do conjunto de anfitriões que aceitam ligações.

As aplicações que usam a deteção de serviços baseada em DNS não devem colocar em cache os endereços IP dos serviços resolvidos, porque não é garantido que sejam estáveis.

Se existirem serviços específicos do ambiente fora do cluster, estes podem ser resolvidos através do DNS do Kubernetes se configurar serviços do Kubernetes ExternalName. Estes serviços do Kubernetes oferecem as mesmas capacidades de resolução, mas devolvem um registo CNAME para redirecionar pedidos para uma autoridade externa.

Comparação com o Eureka

O Eureka é um equilibrador de carga do lado do cliente de código aberto criado pela Netflix. É usado comumente como parte do Spring Cloud Services service broker. O Eureka foi criado para ser um mecanismo de descoberta de serviços e equilibrador de carga regional para serviços executados num ambiente que causava interrupções frequentes nas cargas de trabalho, o que resultava em endereços IP instáveis.

O Eureka foi concebido como um modelo cliente/servidor. Os clientes registam-se no servidor indicando os nomes com os quais querem ser associados e enviam periodicamente sinais de pulsação ao servidor. O servidor permite que todos os clientes com ligação resolvam nomes.

Em geral, deve usar o DNS do Kubernetes em vez do Eureka no Kubernetes pelos seguintes motivos:

  • O DNS funciona com todas as linguagens de programação e aplicações sem necessidade de bibliotecas.
  • A verificação de estado existente da sua aplicação vai ser reutilizada, o que reduz as combinações de erros.
  • O Kubernetes gere o servidor DNS, o que lhe permite depender de menos dependências.
  • O DNS do Kubernetes respeita a mesma política e restrições de RBAC que o resto do Kubernetes.

Existem algumas situações em que a implementação de um servidor Eureka é vantajosa:

  • Precisa de deteção de serviços em aplicações baseadas em VMs e no Kubernetes.
  • Precisa de balanceamento de carga baseado no cliente.
  • Precisa de verificações de funcionamento independentes.

O que se segue?