Como escolher? API Gateway vs. Ingress Controller vs. Service Mesh

Jenn GileDiretor de Marketing de Produto, NGINX

Em praticamente todos os webinars sobre controladores Ingress e malhas de serviço que realizamos ao longo de 2021, ouvimos alguma variação das perguntas “Qual é a diferença entre esta ferramenta e um gateway de API?” ou “Preciso de um gateway de API e também de um controlador Ingress (ou uma malha de serviço) no Kubernetes?”

A confusão é totalmente compreensível por dois motivos:

• Controladores de Ingress e malhas de serviço podem atender a muitos casos de uso de gateways de API.
• Alguns fornecedores posicionam sua ferramenta de gateway de API como uma alternativa ao uso de um controlador de Ingress ou de uma malha de serviços — ou reúnem as três funcionalidades em uma única ferramenta.

Neste blog, abordamos as diferenças entre essas ferramentas e qual delas usar em casos de uso de gateway de API específicos do Kubernetes. Para uma análise mais aprofundada, incluindo demonstrações, assista ao webinar Casos de uso de gateway de API para Kubernetes.

Definições

Em essência, gateways de API, controladores de Ingress e malhas de serviço são tipos de proxy projetados para direcionar o tráfego para dentro dos seus ambientes e entre os componentes deles.

O que é um gateway de API?

Um gateway de API encaminha as solicitações de API de um cliente para os serviços apropriados. No entanto, um grande equívoco sobre essa definição simples é a ideia de que um gateway de API seja uma tecnologia específica. Não é. Na verdade, “gateway de API” descreve um conjunto de casos de uso que podem ser implementados por meio de diferentes tipos de proxies — mais comumente, um ADC ou balanceador de carga e proxy reverso e, cada vez mais, um controlador de Ingress ou uma malha de serviços.

Não há muito consenso no setor sobre quais recursos são “indispensáveis” para que uma ferramenta funcione como um gateway de API. Normalmente, vemos clientes exigirem os seguintes recursos (agrupados por caso de uso):

Casos de uso de resiliência

• Testes A/B, implantações canário e implantações blue-green
• Transformação de protocolo (entre JSON e XML, por exemplo)
• Limitação de taxa
• Descoberta de serviços

Casos de uso de gerenciamento de tráfego

• Roteamento e correspondência baseados em método
• Manipulação de cabeçalhos e corpos de requisições/respostas
• Roteamento de solicitações na Camada 7

Casos de uso de segurança

• Aplicação do esquema da API
• Autenticação e autorização de clientes
• Respostas personalizadas
• Controle de acesso granular
• Terminação TLS

Quase todos esses casos de uso são comuns no Kubernetes. A transformação de protocolos e a manipulação de cabeçalhos e corpos de solicitações e respostas são menos comuns, pois geralmente estão vinculadas a APIs legadas que não são adequadas para ambientes de Kubernetes e microsserviços.

Saiba mais sobre os casos de uso de gateway de API em Implantação do NGINX como gateway de API, parte 1 em nosso blog.

O que é um Ingress Controller?

Um controlador de Ingress (também chamado de Kubernetes Ingress Controller — ou KIC, na sigla em inglês) é um proxy especializado de Camada 4 e Camada 7 que direciona o tráfego para o Kubernetes e seus serviços e, depois, de volta para fora (o chamado tráfego de entrada e saída ou norte-sul). Além do gerenciamento de tráfego, os controladores de Ingress também podem ser usados para observabilidade e solução de problemas, segurança e identidade e para praticamente todos os casos de uso de gateway de API, exceto os mais avançados.

Saiba mais sobre como usar um controlador de Ingress para muito mais do que apenas o gerenciamento básico de tráfego em Guia para escolher um controlador de Ingress, Parte 1: identifique seus requisitos em nosso blog.

O que é uma malha de serviços?

Uma malha de serviços gerencia o tráfego entre os serviços do Kubernetes (conhecido como tráfego serviço a serviço ou leste-oeste) e é comumente usada para obter criptografia de ponta a ponta (E2EE). A adoção de malhas de serviços ainda é pequena, mas está crescendo à medida que mais organizações implementam ambientes avançados ou precisam de E2EE. Uma malha de serviços pode ser usada como um gateway de API distribuído (e leve), muito próximo dos aplicativos, o que é viabilizado, no nível do plano de dados, pelos sidecars da malha de serviços.

Saiba mais sobre service mesh – e quando você estará pronto para usar um – em Como escolher um service mesh no nosso blog.

Use ferramentas nativas do Kubernetes em ambientes Kubernetes

Como ouvimos de Mark Church em sua palestra principal no NGINX Sprint 2.0 sobre Kubernetes e o futuro das redes de aplicações, “gateways de API, balanceadores de carga e malhas de serviço continuarão cada vez mais parecidos entre si e oferecerão recursos semelhantes”. Concordamos plenamente com essa afirmação e acrescentamos que tudo se resume a escolher a ferramenta certa para o trabalho, com base em onde (e como) ela será usada. Afinal, tanto um facão quanto uma faca de manteiga servem para cortar, mas você provavelmente não usaria o primeiro na torrada do café da manhã.

Então, como decidir qual ferramenta é a mais adequada para você? Vamos simplificar: se você precisa de funcionalidades de gateway de API no Kubernetes, geralmente é melhor escolher uma ferramenta que possa ser configurada usando recursos de configuração nativos do Kubernetes, como YAML. Normalmente, isso significa um controlador Ingress ou uma malha de serviços. Mas já podemos ouvir você dizendo: “Minha ferramenta de gateway de API tem muito mais recursos do que meu controlador Ingress (ou minha malha de serviços) — não estou perdendo alguma coisa?” Não! Ter mais recursos não significa que a ferramenta seja melhor, especialmente no Kubernetes, onde a complexidade das ferramentas pode ser fatal.

Observação: Nativo do Kubernetes (não confundir com Knative) refere-se a ferramentas projetadas e desenvolvidas para o Kubernetes. Normalmente, elas funcionam com a CLI do Kubernetes, podem ser instaladas usando o Helm e se integram aos recursos do Kubernetes.

A maioria dos usuários do Kubernetes prefere ferramentas que possam ser configuradas de forma nativa para Kubernetes, pois isso evita mudanças na experiência de desenvolvimento ou de GitOps. Uma ferramenta compatível com YAML oferece três grandes benefícios:

• YAML é uma linguagem familiar para as equipes que trabalham com Kubernetes. Por isso, a curva de aprendizado é pequena ou até inexistente quando se usa uma ferramenta existente do Kubernetes para oferecer funcionalidades de gateway de API. Assim, suas equipes podem aproveitar as habilidades que já possuem, sem precisar aprender a configurar uma nova ferramenta que talvez usem apenas ocasionalmente.
• Você pode automatizar uma ferramenta compatível com YAML da mesma forma que suas outras ferramentas do Kubernetes. Qualquer ferramenta que se integre perfeitamente aos seus fluxos de trabalho será bem recebida pela sua equipe, aumentando a probabilidade de que ela seja utilizada.
• Você pode reduzir o conjunto de ferramentas de gerenciamento de tráfego do Kubernetes usando seu controlador Ingress, sua malha de serviços ou ambos. Afinal, cada salto adicional faz diferença, e não há motivo para adicionar latência desnecessária ou pontos únicos de falha. E, claro, reduzir o número de tecnologias implantadas no Kubernetes também é bom para o seu orçamento e para a segurança geral.

Casos de uso de gateway de API Norte-Sul: use um controlador de Ingress

Os controladores de Ingress têm o potencial de viabilizar muitos casos de uso de gateways de API. Além daqueles descritos em Definições, constatamos que as organizações valorizam principalmente um controlador de Ingress capaz de implementar:

• Transferência da autenticação e da autorização
• Roteamento baseado em autorização
• Roteamento e correspondência na camada 7 (HTTP, HTTP/S, cabeçalhos, cookies, métodos)
• Compatibilidade de protocolos (HTTP, HTTP/2, WebSocket, gRPC)
• Limitação de taxa

Cenário de exemplo: roteamento em nível de método

Você deseja implementar a correspondência e o roteamento no nível do método, usando o controlador Ingress para rejeitar o método POST nas solicitações de API.

Alguns invasores procuram vulnerabilidades em APIs enviando tipos de solicitação que não estão em conformidade com a definição da API — por exemplo, enviando solicitações POST para uma API definida para aceitar apenas solicitações GET. Os firewalls de aplicações Web (WAF) não conseguem detectar esses tipos de ataque — eles examinam apenas as strings e os corpos das solicitações em busca de ataques —, portanto, a prática recomendada é usar um gateway de API na camada de Ingress para bloquear solicitações mal-intencionadas.

Como exemplo, suponha que a nova API /coffee/{coffee-store}/brand tenha acabado de ser adicionada ao seu cluster. A primeira etapa é expor a API usando o NGINX Ingress Controller — basta adicionar a API ao campo upstreams.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80

Para habilitar a correspondência por método, adicione o caminho /coffee/{coffee-store}/brand ao campo routes e duas condições que usam a variável $request_method para diferenciar as solicitações GET das POST. Todo o tráfego que usa o método HTTP GET é encaminhado automaticamente para o serviço de café. O tráfego que usa o método POST é direcionado para uma página de erro com a mensagem "Você foi rejeitado!". E pronto: você protegeu a nova API contra tráfego POST indesejado.

routes: - path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "Você foi rejeitado!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea

Para obter mais detalhes sobre como usar o roteamento e a correspondência no nível do método com páginas de erro, consulte a documentação do NGINX Ingress Controller. Para ver um exemplo relacionado à segurança de como usar um controlador Ingress para oferecer funcionalidades de gateway de API, leia Implementação da autenticação OpenID Connect para Kubernetes com Okta e NGINX Ingress Controller em nosso blog.

Casos de uso de gateway de API leste-oeste: use uma malha de serviços

Uma malha de serviços não é necessária — nem mesmo útil inicialmente — para a maioria dos casos de uso de gateways de API, pois grande parte do que você pode querer realizar pode, e deve, ocorrer na camada de Ingress. No entanto, à medida que a complexidade da sua arquitetura aumenta, é mais provável que você obtenha benefícios ao usar uma malha de serviços. Os casos de uso que consideramos mais vantajosos estão relacionados à criptografia de ponta a ponta (E2EE) e à divisão de tráfego — como testes A/B, implantações canário e implantações azul-verde.

Cenário de exemplo: implantação canário

Você deseja configurar uma implantação canário entre serviços com roteamento condicional baseado em critérios de HTTP/S.

A vantagem é que você pode implementar gradualmente alterações na API, como novas funções ou versões, sem afetar a maior parte do tráfego de produção.

Atualmente, o NGINX Ingress Controller roteia o tráfego entre dois serviços gerenciados pelo NGINX Service Mesh: Coffee.frontdoor.svc e Tea.frontdoor.svc. Esses serviços recebem tráfego do NGINX Ingress Controller e o encaminham para as funções apropriadas do aplicativo, incluindo Tea.cream1.svc. Você decide refatorar o Tea.cream1.svc e chama a nova versão de Tea.cream2.svc. Como deseja que seus testadores beta forneçam feedback sobre a nova funcionalidade, você configura uma divisão de tráfego canário com base no cookie de sessão exclusivo desses testadores, garantindo que os usuários regulares acessem apenas o Tea.cream1.svc.

Usando o NGINX Service Mesh, você começa criando uma divisão de tráfego entre todos os serviços disponibilizados por Tea.frontdoor.svc, incluindo Tea.cream1.svc e Tea.cream2.svc. Para habilitar o roteamento condicional, você cria um recurso HTTPRouteGroup (chamado tea-hrg) e o associa à divisão de tráfego. Como resultado, somente as solicitações dos usuários beta (solicitações com o cookie de sessão definido como version=beta) são roteadas de Tea.frontdoor.svc para Tea.cream2.svc. Seus usuários regulares continuam acessando apenas os serviços da versão 1 disponibilizados por Tea.frontdoor.svc.

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"

Este exemplo inicia sua implantação canário com uma divisão de 0‑100, o que significa que todos os seus testadores beta usam o Tea.cream2.svc, mas você pode, é claro, começar com qualquer proporção que esteja alinhada à sua estratégia de testes beta. Após a conclusão dos testes beta, você pode usar uma implantação canário simples (sem o roteamento por cookie) para testar a resiliência do Tea.cream2.svc.

Consulte nossa documentação para obter mais detalhes sobre a divisão de tráfego com o NGINX Service Mesh. A configuração de divisão de tráfego acima é autorreferencial, pois o serviço raiz também está listado como um serviço de backend. No momento, essa configuração não é compatível com a especificação Service Mesh Interface (smi-spec); no entanto, a especificação está atualmente em fase alfa e sujeita a alterações.

Quando (e como) usar uma ferramenta de gateway de API para aplicações Kubernetes

Embora a maioria dos casos de uso de gateway de API para Kubernetes possa (e deva) ser atendida por um controlador Ingress ou uma malha de serviços, há algumas situações específicas em que uma ferramenta de gateway de API, como o NGINX Plus, é adequada.

Requisitos de negócios

Embora várias equipes ou projetos possam compartilhar um conjunto de controladores Ingress, ou os controladores Ingress possam ser especializados para cada ambiente, há motivos para optar pela implantação de um gateway de API dedicado no Kubernetes em vez de utilizar o controlador Ingress existente. O uso conjunto de um controlador Ingress e de um gateway de API no Kubernetes pode proporcionar às organizações a flexibilidade necessária para atender aos requisitos de negócios. Alguns cenários incluem:

• Sua equipe de gateway de API não está familiarizada com o Kubernetes e não usa YAML. Por exemplo, se a equipe estiver habituada à configuração do NGINX, implantar o NGINX Plus como um gateway de API no Kubernetes reduzirá os atritos e facilitará o aprendizado.
• Sua equipe de Operações de Plataforma prefere dedicar o controlador de Ingress exclusivamente ao gerenciamento do tráfego de aplicações.
• Você tem um caso de uso de gateway de API que se aplica apenas a um dos serviços do seu cluster. Em vez de usar um controlador de Ingress para aplicar uma política a todo o tráfego norte-sul, você pode implantar um gateway de API para aplicar a política somente onde ela for necessária.

Migração de APIs para ambientes Kubernetes

Ao migrar APIs existentes para ambientes Kubernetes, você pode publicar essas APIs em uma ferramenta de gateway de API implantada fora do Kubernetes. Nesse cenário, o tráfego da API geralmente é roteado por um balanceador de carga externo (para o balanceamento de carga entre clusters), depois para um balanceador de carga configurado para atuar como gateway de API e, por fim, para o controlador Ingress no seu cluster Kubernetes.

Compatibilidade com APIs SOAP no Kubernetes

Embora a maioria das APIs modernas seja criada usando REST — em parte porque os serviços e as APIs RESTful ou gRPC conseguem aproveitar ao máximo a plataforma Kubernetes —, talvez você ainda tenha algumas APIs SOAP que não foram rearquitetadas. Embora as APIs SOAP não sejam recomendadas para o Kubernetes por não serem otimizadas para microsserviços, talvez seja necessário implantar uma API SOAP no Kubernetes até que ela possa ser rearquitetada. É provável que a API precise se comunicar com clientes de API baseados em REST. Nesse caso, você precisará de uma forma de fazer a conversão entre os protocolos SOAP e REST. Embora seja possível implementar essa funcionalidade com um controlador Ingress, não recomendamos essa abordagem, pois ela consome muitos recursos. Em vez disso, recomendamos implantar uma ferramenta de gateway de API como proxy por pod ou por serviço para fazer a conversão entre SOAP e REST.

Gerenciamento do tráfego de APIs dentro e fora do Kubernetes

Um número relativamente pequeno de nossos clientes tem interesse em gerenciar APIs que abrangem ambientes dentro e fora do Kubernetes. Se uma estratégia de gerenciamento de APIs tiver prioridade maior do que a escolha de ferramentas nativas do Kubernetes, um gateway de API compatível com o Kubernetes (que possa ser integrado a uma solução de gerenciamento de APIs) implantado no Kubernetes pode ser a escolha certa.

Observação: Ao contrário das ferramentas nativas do Kubernetes, as ferramentas compatíveis com Kubernetes (também chamadas, às vezes, de ferramentas adaptadas ao Kubernetes) não foram projetadas para o Kubernetes e não podem ser gerenciadas usando configurações do Kubernetes. No entanto, elas são ágeis e leves, o que lhes permite operar no Kubernetes sem adicionar latência significativa nem exigir soluções alternativas complexas.

Primeiros passos com o NGINX

O NGINX oferece opções para os três tipos de cenários de implantação.

Ferramentas nativas do Kubernetes:

• NGINX Ingress Controller – Controlador de Ingress para Kubernetes baseado no NGINX Plus, que oferece controle e modelagem avançados de tráfego, monitoramento e visibilidade, além de autenticação e logon único (SSO).
• NGINX Service Mesh – Malha de serviços leve, pronta para uso e fácil de usar para desenvolvedores, com o NGINX Plus como sidecar empresarial.

Comece solicitando sua avaliação gratuita de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e DoS e baixe o NGINX Service Mesh, que é sempre gratuito.

Para um gateway de API compatível com Kubernetes, dentro ou fora dos seus ambientes Kubernetes:

• NGINX Plus – O balanceador de carga, proxy reverso, servidor web e gateway de API completo, com recursos de nível empresarial, como alta disponibilidade, verificações ativas de integridade, descoberta de sistemas DNS, persistência de sessão e uma API RESTful. Integra-se ao NGINX Controller [agora F5 NGINX Management Suite] para oferecer uma solução completa para o ciclo de vida das APIs.

Para saber mais sobre como usar o NGINX Plus como gateway de API, solicite sua avaliação gratuita de 30 dias e consulte Implantação do NGINX como gateway de API.

Sobre o autor

Jenn GileDiretor de Marketing de Produto, NGINX

Mais publicações de Jenn Gile