Como escolher? Gateway de API vs. Controlador de entrada vs. MALHA DE SERVIÇOS

Em quase todos os webinars sobre controladores Ingress e service meshes que realizamos ao longo de 2021, ouvimos algumas variações das perguntas "Como essa ferramenta é diferente de um gateway de API?" ou "Preciso de um gateway de API e de um controlador Ingress (ou service mesh) no Kubernetes?"

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

• Controladores de entrada e malhas de serviço podem atender a muitos casos de uso de gateway de API.
• Alguns fornecedores posicionam sua ferramenta de gateway de API como uma alternativa ao uso de um controlador Ingress ou service mesh – ou eles reúnem todos os três recursos em uma ferramenta.

Neste blog, abordamos como essas ferramentas diferem e quais usar para 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 do API Gateway para Kubernetes .

Definições

Em essência, gateways de API, controladores de entrada e malhas de serviço são cada um um tipo de proxy, projetado para direcionar tráfego para dentro e ao redor de seus ambientes.

O que é um gateway de API?

Um gateway de API roteia solicitações de API de um cliente para os serviços apropriados. Mas um grande mal-entendido sobre essa definição simples é a ideia de que um gateway de API é uma peça única de tecnologia. Não é. Em vez disso, “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 Ingress ou malha de serviço.

Não há muito acordo no setor sobre quais recursos são "indispensáveis" para que uma ferramenta sirva como um gateway de API. Normalmente vemos clientes exigindo as seguintes habilidades (agrupadas por caso de uso):

Casos de uso de resiliência

• Teste A/B, implantações canário e implantações azul-verde
• 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çalho e corpo de solicitação/resposta
• Roteamento de solicitação na camada 7

Casos de uso de segurança

• Aplicação do esquema de API
• Autenticação e autorização do cliente
• Respostas personalizadas
• Controle de acesso detalhado
• Término TLS

Quase todos esses casos de uso são comumente utilizados no Kubernetes. A transformação de protocolo e a manipulação de cabeçalho e corpo de solicitação/resposta 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 casos de uso de gateway de API em Implantando o NGINX como um gateway de API, Parte 1 em nosso blog.

O que é um controlador de entrada?

Um controlador de entrada (também chamado de Controlador de entrada do Kubernetes – KIC para abreviar) é um proxy especializado de Camada 4 e Camada 7 que recebe tráfego para o Kubernetes, para os serviços e retorna novamente (chamado de tráfego de entrada-saída ou norte-sul). Além do gerenciamento de tráfego, os controladores Ingress também podem ser usados para visibilidade e solução de problemas, segurança e identidade, e todos os casos de uso de gateway de API, exceto os mais avançados.

Saiba mais sobre como você pode usar um controlador Ingress para mais do que apenas gerenciamento básico de tráfego em Um guia para escolher um controlador Ingress, parte 1: Identifique suas necessidades em nosso blog.

O que é uma malha de serviços?

Uma malha de serviço manipula o tráfego que flui entre os serviços do Kubernetes (chamado de tráfego serviço a serviço ou leste-oeste) e é comumente usada para obter criptografia de ponta a ponta (E2EE). A adoção da malha de serviço é pequena, mas está crescendo à medida que mais organizações lançam implantações avançadas ou têm requisitos para E2EE. Uma malha de serviço pode ser usada como um gateway de API distribuído (leve) muito próximo dos aplicativos, possibilitado no nível do plano de dados pelos sidecars da malha de serviço.

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

Use ferramentas nativas do Kubernetes para ambientes Kubernetes

Como ouvimos de Mark Church em sua palestra principal do NGINX Sprint 2.0 sobre Kubernetes e o futuro das redes de aplicativos , “gateways de API, balanceadores de carga e malhas de serviço continuarão a se parecer cada vez mais entre si e a fornecer recursos semelhantes”. Concordamos plenamente com essa afirmação e acrescentamos que o importante é escolher a ferramenta certa para o trabalho com base em onde (e como) você vai usá-la. Afinal, tanto um facão quanto uma faca de manteiga são usados para cortar, mas você provavelmente não vai usar o primeiro na sua torrada matinal.

Então, como você decide qual ferramenta é a certa para você? Vamos simplificar: se você precisa da funcionalidade de gateway de API dentro do Kubernetes, geralmente é melhor escolher uma ferramenta que possa ser configurada usando ferramentas de configuração nativas do Kubernetes, como YAML. Normalmente, é um controlador Ingress ou service mesh. Mas ouvimos você dizendo: “Minha ferramenta de gateway de API tem muito mais recursos do que meu controlador Ingress (ou service mesh) – não estou perdendo alguma coisa?” Não! Mais recursos não significam melhor ferramenta, especialmente no Kubernetes, onde a complexidade da ferramenta pode ser fatal.

Observação:  Kubernetes nativo (não o mesmo que Knative ) refere-se a ferramentas que foram projetadas e construídas para o Kubernetes. Normalmente, eles funcionam com a CLI do Kubernetes, podem ser instalados usando o Helm e se integram aos recursos do Kubernetes.

A maioria dos usuários do Kubernetes prefere ferramentas que podem ser configuradas de forma nativa do Kubernetes porque isso evita alterações na experiência de desenvolvimento ou do GitOps. Uma ferramenta amigável ao YAML oferece três benefícios principais:

• YAML é uma linguagem familiar para equipes do Kubernetes, então a curva de aprendizado é pequena, ou até mesmo inexistente, se você estiver usando uma ferramenta Kubernetes existente para funcionalidade de gateway de API. Isso ajuda suas equipes a trabalhar dentro de seu conjunto de habilidades existentes, sem a necessidade de aprender a configurar uma nova ferramenta que elas podem usar apenas ocasionalmente.
• Você pode automatizar uma ferramenta compatível com YAML da mesma forma que suas outras ferramentas do Kubernetes. Qualquer coisa que se encaixe perfeitamente em seus fluxos de trabalho será popular entre sua equipe, aumentando a probabilidade de que eles o utilizem.
• Você pode reduzir sua pilha de ferramentas de gerenciamento de tráfego do Kubernetes usando seu controlador Ingress, service mesh ou ambos. Afinal, cada salto extra importa e não há razão 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 seu orçamento e segurança geral.

Casos de uso do North-South API Gateway: Use um controlador Ingress

Os controladores de entrada têm o potencial de habilitar muitos casos de uso de gateway de API. Além dos descritos em Definições , descobrimos que as organizações valorizam mais um controlador Ingress que pode implementar:

• Descarga de autenticação e autorização
• Roteamento baseado em autorização
• Roteamento e correspondência de nível de camada 7 (HTTP, HTTP/S, cabeçalhos, cookies, métodos)
• Compatibilidade de protocolo (HTTP, HTTP/2, WebSocket, gRPC)
• Limitação de taxa

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

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

Alguns invasores procuram vulnerabilidades em APIs enviando tipos de solicitação que não estão em conformidade com uma definição de API – por exemplo, enviando solicitações POST para uma API definida para aceitar apenas solicitações GET . Firewalls de aplicativos da Web (WAF) não conseguem detectar esses tipos de ataques. Eles examinam apenas sequências de solicitações e corpos em busca de ataques. Portanto, a melhor prática é usar um gateway de API na camada de entrada para bloquear solicitações ruins.

Por exemplo, suponha que a nova API /coffee/{coffee-store}/brand tenha acabado de ser adicionada ao seu cluster. O primeiro passo é expor a API usando o NGINX Ingress Controller – simplesmente adicionando a API ao campo upstreams .

apiVersão: k8s.nginx.org/v1kind: VirtualServer
metadados:
nome: cafe
especificação:
host: cafe.example.com
tls:
secreto: cafe-secret
upstreams:
-nome: tea
serviço: tea-svc
porta: 80
-nome: café
serviço: café-svc 
porta: 80

Para habilitar a correspondência em nível de método, adicione um caminho /coffee/{coffee-store}/brand ao campo de rotas e adicione duas condições que usam a variável $request_method para distinguir entre solicitações GET e POST . Qualquer tráfego que utilize o método HTTP GET é passado 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 assim, você protegeu a nova API do tráfego POST indesejado.

rotas: - caminho: /coffee/{coffee-store}/brand
correspondências:
- condições:
- variável: $request_method
valor: POST
ação:
retorno:
código: 403
tipo: texto/simples
corpo: "Você foi rejeitado!"
- condições:
- variável: $request_method
valor: OBTER
ação:
senha: café
- caminho: /chá
ação:
senha:chá

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

Casos de uso do East-West API Gateway: Use uma malha de serviço

Uma malha de serviço não é necessária – nem mesmo útil inicialmente – para a maioria dos casos de uso de gateway de API porque a maior parte do que você deseja realizar pode, e deve, acontecer na camada de entrada. Mas à medida que sua arquitetura aumenta em complexidade, é mais provável que você obtenha valor ao usar uma malha de serviços. Os casos de uso que consideramos mais benéficos estão relacionados ao E2EE e à divisão de tráfego , como testes A/B, implantações canárias 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 HTTP/S.

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

Atualmente, seu 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 roteiam para as funções de aplicativo apropriadas, incluindo Tea.cream1.svc . Você decide refatorar Tea.cream1.svc , chamando a nova versão de Tea.cream2.svc . Você quer que seus testadores beta forneçam feedback sobre a nova funcionalidade, então você configura uma divisão de tráfego canário com base no cookie de sessão exclusivo dos testadores beta, garantindo que seus usuários regulares experimentem apenas Tea.cream1.svc .

Usando o NGINX Service Mesh, você começa criando uma divisão de tráfego entre todos os serviços frontados por Tea.frontdoor.svc , incluindo Tea.cream1.svc e Tea.cream2.svc . Para habilitar o roteamento condicional, crie um recurso HTTPRouteGroup (chamado tea-hrg ) e associe-o à divisão de tráfego. O resultado é que apenas solicitações de seus 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 a experimentar apenas os serviços da versão 1 por trás do Tea.frontdoor.svc .

apiVersão: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadados:
nome: tea-svc
especificação:
serviço: tea.1
backends:
-serviço: tea.1
peso: 0
- serviço: chá.2
peso: 100
correspondências:
- tipo: HTTPRouteGroup
nome: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
tipo: HTTPRouteGroup
metadados:
nome: tea-hrg
namespace: default
especificação:
correspondências:
-nome: beta-session-cookie
cabeçalhos:
- cookie: "version=beta"

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

Confira nossa documentação para mais detalhes sobre divisões 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 é listado como um serviço de backend. Esta configuração não é atualmente suportada pela especificação da Service Mesh Interface ( smi-spec ); no entanto, a especificação está atualmente em alfa e sujeita a alterações.

Quando (e como) usar uma ferramenta de gateway de API para aplicativos Kubernetes

Embora a maioria dos casos de uso de gateway de API para Kubernetes possam (e devam) ser abordados por um controlador Ingress ou service mesh, há algumas situações especializadas 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 por ambiente, há motivos pelos quais você pode optar por implantar um gateway de API dedicado dentro do Kubernetes em vez de aproveitar o controlador Ingress existente. Usar um controlador Ingress e um gateway de API dentro do Kubernetes pode fornecer flexibilidade para que as organizações atendam 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 eles estiverem confortáveis com a configuração do NGINX, isso aliviará o atrito e diminuirá a curva de aprendizado se eles implantarem o NGINX Plus como um gateway de API no Kubernetes.
• Sua equipe de operações de plataforma prefere dedicar o controlador Ingress apenas ao gerenciamento de tráfego de aplicativos.
• Você tem um caso de uso de gateway de API que se aplica apenas a um dos serviços no seu cluster. Em vez de usar um controlador Ingress para aplicar uma política a todo o seu tráfego norte-sul, você pode implantar um gateway de API para aplicar a política somente onde for necessário.

Migrando 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 normalmente é roteado por meio de um balanceador de carga externo (para balanceamento de carga entre clusters), depois para um balanceador de carga configurado para servir como um gateway de API e, finalmente, para o controlador Ingress dentro do seu cluster Kubernetes.

Suporte a APIs SOAP no Kubernetes

Embora a maioria das APIs modernas sejam criadas usando REST – em parte porque os serviços e APIs RESTful ou gRPC são capazes de aproveitar ao máximo a plataforma Kubernetes – você ainda pode ter algumas APIs SOAP que não foram rearquitetadas. Embora as APIs SOAP não sejam recomendadas para o Kubernetes porque não são otimizadas para microsserviços, você pode acabar precisando 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, caso em que você precisa de uma maneira de traduzir entre os protocolos SOAP e REST. Embora você possa executar essa funcionalidade com um controlador Ingress, não recomendamos isso porque ele consome muitos recursos. Em vez disso, recomendamos implantar uma ferramenta de gateway de API como um proxy por pod ou por serviço para traduzir entre SOAP e REST.

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

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

Observação:  Diferentemente das ferramentas nativas do Kubernetes, as ferramentas amigáveis ao Kubernetes (também chamadas às vezes de Kubernetes‑accomodativas ) 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, permitindo que funcionem no Kubernetes sem adicionar latência significativa ou exigir soluções alternativas extensas.

Introdução ao NGINX

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

Ferramentas nativas do Kubernetes:

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

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

Para um gateway de API amigável ao Kubernetes dentro ou fora dos seus ambientes Kubernetes:

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

Para saber mais sobre como usar o NGINX Plus como um gateway de API, solicite seu teste gratuito de 30 dias e consulte Implantando o NGINX como um gateway de API .