Ao iniciar um cluster Kubernetes para um aplicativo específico, você deve entender quais requisitos o próprio aplicativo, os negócios e os desenvolvedores apresentam para esse recurso. Se você tiver essas informações, poderá começar a tomar uma decisão arquitetural e, em particular, selecionar um controlador Ingress específico, do qual já existe um grande número hoje. Para ter uma idéia básica das opções disponíveis sem precisar estudar muitos artigos / documentação, etc., preparamos essa revisão incluindo os principais controladores Ingress (prontos para produção).
Esperamos que ajude os colegas a escolher uma solução arquitetônica - pelo menos, seja o ponto de partida para informações mais detalhadas e experimentos práticos. Anteriormente, estudamos outros materiais semelhantes na rede e, curiosamente, não encontramos uma única revisão mais ou menos completa e, mais importante - estruturada. Então, preencha essa lacuna!
Critérios
Para fazer uma comparação de princípio e obter qualquer resultado útil, você precisa entender não apenas a área de assunto, mas também ter uma lista específica de critérios que determinarão o vetor de pesquisa. Sem pretender analisar todos os casos possíveis de uso do Ingress / Kubernetes, tentamos destacar os requisitos mais gerais para controladores - esteja preparado para que você tenha que estudar todas as suas especificidades e detalhes em qualquer caso separadamente.
Mas vou começar com as características que se tornaram tão familiares que são implementadas em todas as decisões e não são consideradas:
- descoberta dinâmica de serviços (descoberta de serviço);
- Terminação SSL;
- trabalhar com websockets.
Agora, sobre os pontos de comparação:
Protocolos suportados
Um dos critérios fundamentais para a seleção. Seu software pode não funcionar no HTTP padrão ou pode exigir trabalho em vários protocolos ao mesmo tempo. Se o seu caso não for padrão, leve esse fator em consideração para que você não precise reconfigurar o cluster posteriormente. Para todos os controladores, a lista de protocolos suportados varia.
Baseado em software
Existem várias opções de aplicativo nas quais o controlador se baseia. Os mais populares são nginx, traefik, haproxy, enviado. No caso geral, pode não afetar a maneira como o tráfego é recebido e transmitido, mas é sempre útil conhecer as possíveis nuances e características do que está “sob o capô”.
Roteamento de tráfego
Com base no que podemos decidir sobre a direção do tráfego para um serviço específico? Geralmente, esse é o host e o caminho, mas há recursos adicionais.
Namespace do cluster
Namespace (namespace) - a capacidade de dividir logicamente os recursos no Kubernetes (por exemplo, no palco, produção etc.). Existem controladores do Ingress que devem ser definidos separadamente em cada espaço para nome (e, em seguida, ele pode direcionar
apenas o tráfego para os pods desse espaço). E existem aqueles (e a maioria esmagadora) que funcionam globalmente em todo o cluster - neles o tráfego é direcionado para qualquer pod do cluster, independentemente do espaço para nome.
Amostras para montante
Como o tráfego é direcionado para instâncias íntegras do aplicativo, serviços? Existem opções com verificações ativas e passivas,
novas tentativas, disjuntores
(para obter mais detalhes, veja-os, por exemplo, no artigo sobre Istio ) , implementações personalizadas de verificação de integridade, etc. Um parâmetro muito importante se você tiver altos requisitos de acessibilidade e retirada oportuna de serviços com falha da balança.
Algoritmos de balanceamento
Há muitas opções: do
round-robin tradicional aos exóticos, como
rdp-cookies , além de alguns recursos, como
sessões persistentes .
Autenticação
Quais esquemas de autorização o controlador suporta? Básico, resumo, oauth, autenticação externa - acho que essas opções devem ser familiares. Esse é um critério importante se você usar muitos circuitos para desenvolvedores (e / ou apenas fechados) acessados pelo Ingress.
Distribuição de tráfego
O controlador suporta mecanismos tão comumente usados para distribuição de tráfego como lançamentos de canários, testes A / B, tráfego de espelhamento (espelhamento / sombreamento)? Esse é um assunto muito delicado para aplicativos que exigem gerenciamento de tráfego exato e preciso para testes produtivos, depuração de erros do produto que não estão em combate (ou com perdas mínimas), análise de tráfego etc.
Assinatura paga
Existe uma opção paga para o controlador, com funcionalidade avançada e / ou suporte técnico?
Interface gráfica do usuário (UI da Web)
Existe alguma interface gráfica para controlar a configuração do controlador? Principalmente para “prático” e / ou para aqueles que precisam fazer algumas alterações na configuração do Ingress, mas trabalhar com modelos “brutos” é inconveniente. Pode ser útil se os desenvolvedores quiserem realizar experimentos com tráfego em tempo real.
Validação JWT
A presença de verificação JSON integrada de tokens da web para autorização e validação do usuário do aplicativo final.
Recursos para personalização da configuração
Extensibilidade de modelos no sentido de ter mecanismos para adicionar suas próprias diretivas, sinalizadores etc. aos modelos de configuração padrão
Mecanismos básicos de proteção DDOS
Algoritmos simples de limite de taxa ou opções mais sofisticadas para filtrar o tráfego com base em endereços, listas brancas, países etc.
Solicitar rastreamento
Possibilidades de observar, rastrear e depurar solicitações do Ingresss para serviços / pods específicos e, idealmente, entre serviços / pods também.
WAF
Suporte para
firewall de aplicativos .
Controladores de ingresso
A lista de controladores foi baseada na
documentação oficial do Kubernetes e
nesta tabela . Excluímos alguns deles da revisão devido à sua especificidade ou baixa prevalência (estágio inicial de desenvolvimento). Os restantes são discutidos abaixo. Começamos com uma descrição geral das soluções e continuamos com a tabela dinâmica.
Ingress by Kubernetes
Website: github.com/kubernetes/ingress-nginxLicença: Apache 2.0Este é o controlador oficial do Kubernetes, que está sendo desenvolvido pela comunidade. Obviamente, a partir do nome, ele é baseado no nginx e é complementado por um conjunto diferente de plugins Lua usados para implementar recursos adicionais. Devido à popularidade do próprio nginx e a modificações mínimas quando usado como controlador, essa opção pode ser o engenheiro médio de configuração mais simples e compreensível (com experiência na Web).
Ingress por NGINX Inc
Site: github.com/nginxinc/kubernetes-ingressLicença: Apache 2.0O produto oficial dos desenvolvedores nginx. Possui uma versão paga baseada no
NGINX Plus . A idéia principal é um alto nível de estabilidade, compatibilidade reversa constante, ausência de módulos externos e aumento da velocidade declarada (em comparação com o controlador oficial) alcançada devido à rejeição de Lua.
A versão gratuita foi significativamente reduzida, inclusive quando comparada com o controlador oficial (devido à falta dos mesmos módulos Lua). O sistema pago ao mesmo tempo possui uma funcionalidade adicional bastante ampla: métricas em tempo real, validação de JWT, verificações de integridade ativas e muito mais. Uma vantagem importante sobre o NGINX Ingress é o suporte total ao tráfego TCP / UDP (e também na versão da comunidade!). A desvantagem é a
falta de recursos para distribuição de tráfego, que, no entanto, "tem a maior prioridade para os desenvolvedores", mas leva tempo para ser implementado.
Kong Ingress
Site: github.com/Kong/kubernetes-ingress-controllerLicença: Apache 2.0Produto desenvolvido por Kong Inc. em duas versões: comercial e gratuita. É baseado no nginx, cujos recursos são expandidos por um grande número de módulos em Lua.
Inicialmente, ele estava focado no processamento e roteamento de solicitações de API, ou seja, como o API Gateway, mas no momento ele se tornou um controlador de ingresso completo. Principais vantagens: muitos módulos adicionais (incluindo desenvolvedores de terceiros) que são fáceis de instalar e configurar e com os quais uma ampla variedade de recursos adicionais é implementada. No entanto, os recursos internos já oferecem muitos recursos. A configuração do trabalho é feita usando recursos CRD.
Uma característica importante do produto - trabalhar dentro do mesmo circuito (em vez de espaço entre nomes) é um tópico controverso: para alguns, parece uma desvantagem (você precisa produzir entidades para cada circuito) e para alguém é um recurso (
um nível mais alto de isolamento, porque se um controlador estiver quebrado, o problema será limitado apenas a um circuito).
Traefik
Website: github.com/containous/traefikLicença: MITUm proxy criado originalmente para trabalhar com o roteamento de solicitações de microsserviços e seu ambiente dinâmico. Portanto, muitos recursos úteis: atualização completa da configuração sem reinicializações, suporte a um grande número de métodos de balanceamento, interface da web, métricas de encaminhamento, suporte a vários protocolos, APIs REST, releases canários e muito mais. Um recurso interessante também é o suporte para certificados Let's Encrypt fora da caixa. A desvantagem é que, para a organização de alta disponibilidade (HA), o controlador precisará instalar e conectar seu próprio armazenamento KV.
HAProxy
Website: github.com/jcmoraisjr/haproxy-ingressLicença: Apache 2.0O HAProxy é conhecido há muito tempo como um balanceador de proxy e tráfego. Como parte do cluster Kubernetes, oferece uma atualização de configuração "suave" (sem perda de tráfego), descoberta de serviço baseada em DNS, configuração dinâmica usando a API. A personalização completa do modelo de configuração por meio da substituição do CM'a, bem como a possibilidade de usar as funções da biblioteca Sprig, podem se tornar atraentes. Em geral, o foco principal da solução é a alta velocidade, seu otimismo e eficiência nos recursos consumidos. A vantagem do controlador é suportar um número recorde de diferentes métodos de balanceamento.
Voyager
Site: github.com/appscode/voyagerLicença: Apache 2.0Controlador baseado em HAproxy, posicionado como uma solução universal que suporta amplos recursos em um grande número de fornecedores. A oportunidade é proposta para equilibrar o tráfego em L7 e L4, e equilibrar o tráfego TCP L4 como um todo pode ser chamado de um dos principais recursos da solução.
Contorno
Website: github.com/heptio/contourLicença: Apache 2.0O enviado não apenas lançou as bases dessa solução: ela foi desenvolvida em
conjunto com os autores desse proxy popular. Um recurso importante é a capacidade de dividir o gerenciamento de recursos do Ingress usando os recursos CRD do IngressRoute. Para organizações com muitas equipes de desenvolvimento usando um único cluster, isso ajuda a maximizar a segurança do tráfego nos circuitos vizinhos e a protegê-los contra erros ao alterar os recursos do Ingress.
Ele também oferece um conjunto expandido de métodos de balanceamento (há espelhamento de solicitações, novas tentativas automáticas, restrição na taxa de solicitações e muito mais), monitoramento detalhado do fluxo de tráfego e falhas. Talvez para alguns seja uma desvantagem significativa da falta de suporte para sessões complicadas (embora o trabalho
já esteja
em andamento ).
Isstio ingress
Website: istio.io/docs/tasks/traffic-management/ingressLicença: Apache 2.0Uma solução abrangente de malha de serviço, que não é apenas um controlador do Ingress que controla o tráfego recebido de fora, mas também controla todo o tráfego no cluster. Sob o capô, o Envoy é usado como um proxy de side-car para cada serviço. Em essência, essa é uma grande combinação que “pode fazer qualquer coisa”, e sua idéia principal é máxima gerenciabilidade, extensibilidade, segurança e transparência. Com ele, você pode ajustar o roteamento de tráfego, a autorização de acesso entre serviços, balanceamento, monitoramento, liberações de canários e muito mais. Leia mais sobre o Istio na série de artigos
Voltar aos microsserviços com Istio .
Embaixador
Website: github.com/datawire/ambassadorLicença: Apache 2.0Outra solução baseada no enviado. Tem uma versão gratuita e comercial. Está posicionado como "completamente nativo do Kubernetes", o que traz vantagens correspondentes (forte integração com métodos e entidades do cluster K8s).
Tabela de comparação
Portanto, o clímax do artigo é esta enorme tabela:
É clicável para uma visualização mais detalhada e também está disponível no formato do
Planilhas Google .
Resumir
O objetivo do artigo é fornecer uma compreensão mais completa (no entanto, absolutamente não exaustiva!) De que escolha fazer no seu caso particular. Como sempre, cada controlador tem suas próprias vantagens e desvantagens ...
O clássico Kubernetes Ingress é bom por sua acessibilidade e comprovação, bastante rico em recursos - em geral, deve ser "o suficiente para os olhos". No entanto, se houver um aumento nos requisitos de estabilidade, nível de recursos e desenvolvimento, vale a pena prestar atenção ao Ingress com o NGINX Plus e uma assinatura paga. Kong possui um rico conjunto de plug-ins (e, consequentemente, os recursos fornecidos por eles), e na versão paga há ainda mais deles. Possui amplas oportunidades para trabalhar como um API Gateway, configurar dinamicamente com base em recursos CRD, bem como serviços básicos do Kubernetes.
Com os requisitos aumentados para os métodos de balanceamento e autorização, dê uma olhada no Traefik e no HAProxy. Estes são projetos de código aberto, comprovados ao longo dos anos, muito estáveis e em desenvolvimento ativo. O contorno existe há alguns anos, mas ainda parece jovem demais e possui apenas os recursos básicos adicionados ao Envoy. Se houver requisitos para a presença / incorporação do WAF antes da aplicação, você deve prestar atenção ao mesmo Ingress da Kubernetes ou HAProxy.
E os recursos mais ricos são os produtos criados com base no Envoy, especialmente no Istio. Parece ser uma solução complexa que “pode fazer qualquer coisa”, o que, no entanto, também significa um limite de entrada significativamente mais alto para configuração / inicialização / administração do que outras soluções.
Escolhemos e ainda usamos o Kubernetes Ingress, que cobre 80-90% das necessidades, como controlador padrão. É bastante confiável, fácil de configurar, expandir. No caso geral, na ausência de requisitos específicos, deve atender à maioria dos clusters / aplicativos. Dos mesmos produtos versáteis e relativamente simples, Traefik e HAProxy podem ser recomendados.
PS
Leia também em nosso blog: