APISIX Ingress Controller integra-se com Service Discovery

A Descoberta de Serviço é Necessária em Aplicações Nativas na Nuvem?

Contexto

A arquitetura de microsserviços é uma das arquiteturas de aplicação mais populares atualmente. Com o aumento do tamanho das aplicações, a gestão da aplicação torna-se mais difícil. A arquitetura de microsserviços tenta resolver esse problema dividindo a aplicação em vários componentes de serviço menores, que cooperam entre si para completar a lógica e as funções de negócio específicas.

Esses componentes devem se comunicar dinamicamente para funcionarem bem juntos. Geralmente, é necessário introduzir ferramentas de descoberta de serviços. Escrevemos um artigo anteriormente introduzindo a descoberta de serviços em microsserviços: O que é Descoberta de Serviço em Microsserviços - API7.ai.

Ao introduzir a descoberta de serviços, os componentes podem ser obtidos dinamicamente. Eles só precisam se preocupar com os nomes dos outros componentes, sem se preocupar com outras informações, como localização de implantação ou IP de implantação.

Descoberta de Serviço no Kubernetes

No ambiente Kubernetes, os pods são a menor unidade implantável.

E no Kubernetes, os componentes têm mais dificuldade para se comunicar entre si porque o IP do Pod não é persistente e muda frequentemente.

Portanto, é ainda mais importante se adaptar a esse ambiente dinâmico ao implantar aplicações no Kubernetes.

O Kubernetes considera essa necessidade e fornece seu próprio mecanismo de descoberta de serviços baseado em DNS.

O Kubernetes fornece um conceito chamado Service, semelhante a um proxy reverso. O cliente só precisa usar o Service e não precisa conhecer os pods encapsulados por trás.

Cada Service receberá um ClusterIP persistente. Assim, quando o IP do pod mudar, outros componentes ainda podem colaborar através do ClusterIP fixo do Service.

Ao mesmo tempo, o serviço no Kubernetes atualizará automaticamente um registro A/AAAA no DNS do cluster.

O registro se parece com:

my-svc.my-namespace.svc.cluster-domain.example

O cliente pode resolver entre namespaces ou no mesmo namespace, facilitando muito a descoberta de serviços entre os componentes.

No entanto, para a arquitetura tradicional de microsserviços que não está no Kubernetes, geralmente usamos ferramentas de descoberta de serviços para alcançar a colaboração entre os serviços. Para se adaptar totalmente ao mecanismo de descoberta de serviços baseado em DNS no ambiente Kubernetes, é necessário um certo custo de transformação/migração.

Portanto, você deve manter o mecanismo original de descoberta de serviços se quiser custos de transformação mais baixos.

Sob essa premissa, qual é a melhor maneira de expor serviços recém-migrados para o Kubernetes?

Como o APISIX Ingress Funciona com a Descoberta de Serviços?

O APISIX Ingress é uma implementação do controlador Ingress no Kubernetes. Ele usa o Apache APISIX como o plano de dados e suporta a configuração de regras de proxy através do Ingress, CRD personalizado e Gateway API. Ao mesmo tempo, também fornece integração com ferramentas de descoberta de serviços, o que facilita o proxy dos serviços registrados e os expõe ao cliente.

Explicaremos isso em detalhes nesta seção.

Suporte do APISIX para Descoberta de Serviços

O APISIX é um gateway de API nativo na nuvem de alto desempenho e totalmente dinâmico que fornece mais de 80 plugins prontos para uso, cobrindo a maioria dos cenários de uso.

Uma das excelentes capacidades é a integração com ferramentas de descoberta de serviços.

O APISIX pode ser integrado com as seguintes ferramentas de descoberta de serviços:

• Consul
• DNS
• Eureka
• Nacos

Basta adicionar a seguinte configuração ao arquivo de configuração do APISIX (usando DNS como exemplo):

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # use o endereço real do seu servidor DNS

Dessa forma, ao configurar o upstream, o APISIX pode resolver dinamicamente as informações reais do endereço upstream através da descoberta de serviços e fazer o proxy da solicitação.

Como o APISIX Ingress Faz Isso?

O APISIX Ingress usa o APISIX como o componente de proxy do plano de dados. Ao integrar pela primeira vez a descoberta de serviços, consideramos duas opções.

• Integração no plano de controle: configurar a descoberta de serviços no controlador Ingress, analisar e analisar a configuração e enviar os resultados para o APISIX para fazer o proxy.
• Integração no plano de dados: configurar a descoberta de serviços no plano de dados do APISIX, e o plano de dados realiza a análise e o proxy da configuração.

Essas duas soluções têm suas próprias vantagens, mas considerando a atualização em tempo real da configuração e a maturidade da solução, escolhemos a solução de integração no plano de dados.

Ao usar essa solução, os usuários podem integrá-la com um custo menor, e essa solução é bastante madura, tendo passado por muitas verificações de produção.

Como usar o APISIX Ingress?

Primeiro, certifique-se de que a configuração correta de descoberta de serviços foi incluída na configuração do APISIX. O exemplo a seguir usa DNS:

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

Crie um recurso ApisixUpstream e modifique sua configuração relacionada a discovery de acordo com o cenário de uso. Por exemplo, type: dns e serviceName a ser proxyado são definidos aqui:

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

Finalmente, crie um recurso ApisixRoute cujo upstreams se refere ao recurso ApisixUpstream criado anteriormente:

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

Depois que os recursos acima forem criados corretamente, você poderá acessar httpbin.default.svc.cluster.local registrado no DNS através de local.httpbin.org.

Benefícios e Perspectivas

Através dessa integração, é muito conveniente expor serviços aos clientes através do APISIX Ingress para aplicações que já estão usando ferramentas de descoberta de serviços. Esse recurso do APISIX Ingress é distintivo, pois a maioria dos controladores Ingress não fornece essa solução de integração.

Obrigado por ler. Ainda estamos no caminho para construir o APISIX Ingress para fornecer as melhores experiências ao usuário!

Para mais informações sobre gateway de API, visite nossos blogs ou entre em contato conosco.