Ao iniciar um cluster Kubernetes para um aplicativo específico, é necessário compreender quais requisitos o próprio aplicativo, os negócios e os desenvolvedores impõem a esse recurso. Com essas informações em mãos, é possível começar a tomar decisões arquitetônicas e, em particular, escolher um controlador de Ingress específico, dos quais já existem muitos disponíveis hoje. Para fornecer uma visão básica das opções disponíveis sem a necessidade de estudar vários artigos/documentação, preparamos esta visão geral, incluindo os principais controladores de Ingress (prontos para produção).
Esperamos que isso ajude os colegas na escolha de soluções arquitetônicas — pelo menos, será um ponto de partida para obter mais informações detalhadas e para experimentos práticos. Inicialmente, estudamos outros materiais semelhantes na internet e, estranhamente, não encontramos uma única visão geral que fosse mais ou menos completa e, principalmente — estruturada. Então, vamos preencher essa lacuna!
Critérios
Para, em princípio, realizar comparações e obter resultados úteis, é preciso entender não apenas o domínio do assunto, mas também ter uma lista concreta de critérios que definem a direção da pesquisa. Sem pretender analisar todos os casos possíveis de uso do Ingress/Kubernetes, procuramos destacar os requisitos mais comuns para os controladores — esteja preparado para que todas as especificidades ainda precisarão ser estudadas separadamente.
Mas começarei com características que se tornaram tão familiares que estão implementadas em todas as soluções e não são discutidas:
- descoberta dinâmica de serviços (service discovery);
- terminação SSL;
- suporte a websockets.
Agora — sobre os pontos de comparação:
Protocolos suportados
Um dos critérios fundamentais para a escolha. Seu software pode não funcionar com HTTP padrão ou pode exigir o uso de múltiplos protocolos simultaneamente. Se esse for seu caso — não padrão, considere esse fator, para não ter que reconfigurar o cluster depois. A lista de protocolos suportados varia entre os controladores.
Software na base
Existem várias opções de aplicativos nos quais o controlador é baseado. Os mais populares são nginx, traefik, haproxy, envoy. De forma geral, isso pode não afetar muito como o tráfego é recebido e transmitido, mas sempre é bom conhecer os potenciais detalhes e características do que está "sob o capô".
Roteamento de tráfego
Com base em que se pode decidir a direção do tráfego para um ou outro serviço? Normalmente, são o host e o caminho, mas podem haver também opções adicionais.
Espaço de nomes no cluster
O espaço de nomes (namespace) é a possibilidade de dividir logicamente os recursos no Kubernetes (por exemplo, em stage, produção, etc.). Existem controladores Ingress que precisam ser instalados separadamente em cada namespace (e então podem direcionar o tráfego apenas para os pods desse espaço). E há aqueles (que são a grande maioria) que funcionam globalmente para todo o cluster — neles, o tráfego é direcionado para qualquer pod do cluster, independentemente do espaço de nomes.
Verificações para upstreams
De que maneira é garantido que o tráfego seja direcionado para instâncias saudáveis do aplicativo, serviços? Existem opções com verificações ativas e passivas, tentativas repetidas (retries), circuit breakers (para mais informações, veja, por exemplo, a ), implementações personalizadas de verificações de estado (custom health checks) etc. É um parâmetro bastante importante se você tem altas exigências de disponibilidade e para remoção oportuna de serviços que falharam da balanceação.
Algoritmos de balanceamento
Aqui existem inúmeras opções: desde os tradicionais até opções exóticas como , além de oportunidades específicas como .
Autenticação
Quais esquemas de autorização o controlador suporta? Basic, digest, oauth, external-auth — acredito que essas opções devem ser familiares. Este é um critério importante se muitas interfaces para desenvolvedores (e/ou simplesmente áreas fechadas) são usadas, acesso ao qual é realizado através do Ingress.
Distribuição de tráfego
O controlador suporta mecanismos frequentemente usados para distribuição de tráfego, como implementações canárias (canary), testes A/B, espelhamento de tráfego (mirroring/shadowing)? Este é um tema realmente delicado para aplicações que exigem um controle cuidadoso e preciso do tráfego para testes produtivos, depuração de erros de produto fora do ambiente de produção (ou com perdas mínimas), análise de tráfego, etc.
Assinatura paga
Há uma versão paga do controlador, com funcionalidades estendidas e/ou suporte técnico?
Interface Gráfica (Web UI)
Existe alguma interface gráfica para gerenciar a configuração do controlador? Principalmente para facilitar o uso e/ou para aqueles que precisam fazer alterações na configuração do Ingress, mas trabalhar com templates 'brutos' é inconveniente. Pode ser útil caso os desenvolvedores queiram realizar experimentos com o tráfego em tempo real.
Validação JWT
A presença de verificação embutida de tokens web JSON para autorização e validação do usuário em aplicativos finais.
Possibilidades de customização da configuração
A extensibilidade dos templates no sentido de ter mecanismos que permitam adicionar diretrizes, flags, etc., próprias aos templates de configuração padrão.
Mecanismos básicos de proteção contra DDoS
Algoritmos simples de rate limit ou variantes mais complexas de filtragem de tráfego com base em endereços, listas brancas, países, etc.
Rastreamento de requisições
Capacidades de monitoramento, rastreamento e depuração de requisições do Ingress para serviços/pods específicos, e idealmente – também entre serviços/pods.
WAF
Suporte .
Controladores Ingress
A lista de controladores foi compilada com base na e . Alguns deles foram excluídos da revisão devido à especificidade ou baixa disseminação (fase inicial de desenvolvimento). Os restantes são discutidos abaixo. Começaremos com uma descrição geral das soluções e continuaremos com uma tabela resumida.
Ingress do Kubernetes
Site:
Licença: Apache 2.0
Este é o controlador oficial para Kubernetes, que é desenvolvido pela comunidade. Como o nome sugere, ele é baseado no nginx e complementado por um conjunto de plugins Lua usados para implementar funcionalidades adicionais. Devido à popularidade do nginx e às modificações mínimas feitas sobre ele ao ser usado como controlador, essa opção pode ser a mais simples e compreensível para configuração para engenheiros médios (com experiência em web).
Ingress da NGINX Inc
Site:
Licença: Apache 2.0
Produto oficial dos desenvolvedores do nginx. Possui uma versão paga, baseada em A ideia principal é um alto nível de estabilidade, compatibilidade contínua, ausência de módulos externos e a velocidade aumentada (em comparação com o controlador oficial), alcançada ao abrir mão do Lua.
A versão gratuita é significativamente reduzida, mesmo em comparação com o controlador oficial (devido à ausência dos mesmos módulos Lua). A versão paga, por sua vez, possui um conjunto amplo de funcionalidades adicionais: métricas em tempo real, validação JWT, verificações de saúde ativas e mais. Uma importante vantagem sobre o NGINX Ingress é o suporte completo ao tráfego TCP/UDP (incluindo na versão comunitária!). Desvantagem — de recursos de distribuição de tráfego, o que, no entanto, "tem máxima prioridade para os desenvolvedores", mas requer tempo para implementação.
Kong Ingress
Site:
Licença: Apache 2.0
Produto desenvolvido pela Kong Inc. em duas versões: comercial e gratuita. Baseado no nginx, cujas capacidades são ampliadas por uma grande quantidade de módulos em Lua.
Originalmente focado no processamento e roteamento de solicitações de API, ou seja, como um API Gateway, no entanto, atualmente se tornou um controlador de Ingress completo. Principais vantagens: uma multitude de módulos adicionais (incluindo de desenvolvedores externos), que são fáceis de instalar e configurar, através dos quais se implementa uma ampla gama de funcionalidades adicionais. No entanto, as funções embutidas já oferecem muitas possibilidades. A configuração é feita utilizando recursos CRD.
Uma característica importante do produto — a operação dentro de um único namespace (em vez de cross-namespaced) é um tema controverso: para alguns pode parecer uma desvantagem (é necessário criar entidades para cada namespace), mas para outros é uma feature (maior nível de isolamento, pois se um controlador falhar, o problema se limita a um único namespace).maiorgithub.com/containous/traefik
Traefik
Site:
Licença: MIT
Um proxy que foi inicialmente criado para trabalhar com o roteamento de solicitações para microsserviços e seu ambiente dinâmico. Daí muitas funcionalidades úteis: atualização de configuração sem reinicializações, suporte a um grande número de métodos de balanceamento, interface web, transmissão de métricas, suporte a vários protocolos, REST API, lançamentos canários e muito mais. Uma característica agradável é também o suporte a certificados Let’s Encrypt pronto para uso. A desvantagem é que, para organizar alta disponibilidade (HA), será necessário instalar e conectar um armazenamento KV próprio ao controlador.
HAProxy
Site:
Licença: Apache 2.0
O HAProxy é bem conhecido como proxy e balanceador de tráfego. No âmbito de um cluster Kubernetes, ele oferece atualização "suave" da configuração (sem perda de tráfego), descoberta de serviços baseada em DNS, configuração dinâmica através da API. A personalização completa do modelo de configurações através da substituição de CM, bem como a possibilidade de uso de funções da biblioteca Sprig, pode ser atraente. No geral, o foco principal da solução é na alta velocidade de operação, otimização e eficiência no consumo de recursos. A principal vantagem do controlador é o suporte a um número recorde de métodos de balanceamento diferentes.
Voyager
Site:
Licença: Apache 2.0
Um controlador baseado no HAproxy, que se posiciona como uma solução universal, suportando amplas funcionalidades em muitos provedores. Oferece a capacidade de balancear o tráfego em L7 e L4, e o balanceamento de tráfego TCP L4 pode ser considerado uma das principais características da solução.
Contour
Site:
Licença: Apache 2.0
Esta solução é baseada não apenas no Envoy: ela foi desenvolvida em conjunto com os criadores deste popular proxy. Uma característica importante é a capacidade de dividir o gerenciamento dos recursos Ingress usando recursos CRD IngressRoute. Para organizações com várias equipes de desenvolvimento utilizando um único cluster, isso ajuda a manter a segurança do tráfego em contornos adjacentes e a protegê-los contra erros ao modificar recursos Ingress.
Também está disponível um conjunto avançado de métodos de balanceamento (incluindo espelhamento de solicitações, tentativas automáticas, limitação de taxa de solicitações e muito mais), monitoramento detalhado do fluxo de tráfego e falhas. Pode ser uma desvantagem significativa para alguns a ausência de suporte a sessões persistentes (apesar do trabalho ).
Istio Ingress
Site:
Licença: Apache 2.0
Uma solução completa de service mesh que funciona não apenas como um controlador de Ingress, gerenciando o tráfego de entrada externo, mas também controla todo o tráfego dentro do cluster. Por trás das cenas, utiliza o Envoy como um proxy sidecar para cada serviço. Essencialmente, é uma grande ferramenta que "pode fazer tudo", com a ideia principal de máxima gerenciabilidade, escalabilidade, segurança e transparência. Com ela, você pode configurar em detalhes a roteação de tráfego, a autorização de acesso entre serviços, balanceamento, monitoramento, lançamentos canários e muito mais. Saiba mais sobre o Istio em uma série de artigos sobre».
Ambassador
Site:
Licença: Apache 2.0
Mais uma solução baseada no Envoy. Possui versões gratuitas e comerciais. É posicionada como "totalmente nativa do Kubernetes", oferecendo as respectivas vantagens (integração estreita com os métodos e entidades do cluster K8s).
Tabela comparativa
Assim, o clímax do artigo é esta enorme tabela:
Ela é clicável para visualização mais detalhada e também está disponível no formato .
Vamos resumir
O objetivo deste artigo é fornecer uma compreensão mais completa (embora não abrangente!) sobre qual escolha fazer em seu caso específico. Como costuma acontecer, cada controlador tem suas vantagens e desvantagens...
O Ingress clássico do Kubernetes se destaca por sua acessibilidade e confiabilidade, contando com uma gama generosa de recursos — geralmente, é mais do que suficiente. No entanto, se há exigências elevadas quanto à estabilidade, nível de recursos e desenvolvimento, vale a pena considerar o Ingress com NGINX Plus e uma assinatura paga. O Kong possui um extenso conjunto de plugins (e, consequentemente, das capacidades que eles oferecem), aliás, na versão paga há até mais funcionalidades. Ele tem amplas possibilidades para atuar como API Gateway, configuração dinâmica baseada em recursos CRD, além dos serviços básicos do Kubernetes.
Para demandas elevadas em balanceamento e métodos de autorização, atente-se ao Traefik e ao HAProxy. Estes são projetos de código aberto, testados ao longo dos anos, extremamente estáveis e em desenvolvimento ativo. O Contour surgiu há poucos anos, mas ainda parece muito imaturo e possui apenas recursos básicos adicionados sobre o Envoy. Se houver demandas para a inclusão de um WAF antes da aplicação, o Ingress do Kubernetes ou o HAProxy podem ser boas opções.
Os produtos mais ricos em funcionalidades são aqueles baseados no Envoy, especialmente o Istio. Ele se apresenta como uma solução abrangente, que "pode tudo", o que, por sua vez, implica em um limiar de complexidade significativamente mais alto em configuração/implementação/administração do que outras soluções.
Nós escolhemos o Ingress do Kubernetes como controlador padrão, e ele continua a ser usado, cobrindo de 80 a 90% das necessidades. Ele é bastante confiável, fácil de configurar e expandir. Em geral, na ausência de requisitos específicos, ele deve atender à maioria dos clusters/aplicações. Produtos igualmente versáteis e relativamente simples que podem ser recomendados são o Traefik e o HAProxy.
P.S.
Confira também em nosso blog:
- «De Volta aos Microserviços com Istio»: , , ;
- «»;
- «».
Fonte: habr.com
