Ao iniciar um cluster Kubernetes para um aplicativo específico, você precisa entender o que o próprio aplicativo, o negócio e os desenvolvedores representam para esse recurso. Com essas informações, você pode começar a tomar uma decisão arquitetural e, em particular, escolher um controlador Ingress específico, que já existe em grande número hoje. Para ter uma ideia básica das opções disponíveis sem ter que passar por muitos artigos/documentações, etc., preparamos esta visão geral, incluindo os principais controladores Ingress (prontos para produção).
Esperamos que ajude os colegas na escolha de uma solução arquitetônica - pelo menos se tornará um ponto de partida para obter informações mais detalhadas e experimentos práticos. Anteriormente, estudamos outros materiais semelhantes na rede e, curiosamente, não encontramos uma revisão mais ou menos completa e, o mais importante, estruturada. Então vamos preencher essa lacuna!
critérios
Em princípio, para fazer uma comparação e obter algum resultado útil, você precisa entender não apenas a área do assunto, mas também ter uma lista específica de critérios que definirão o vetor de pesquisa. Sem a pretensão de analisar todos os casos possíveis de utilização do Ingress/Kubernetes, procuramos destacar os requisitos mais gerais para controllers - esteja preparado que em qualquer caso você terá que estudar todas as suas especificidades e particularidades separadamente.
Mas começarei com as características que se tornaram tão familiares que são implementadas em todas as soluções e não são consideradas:
- descoberta dinâmica de serviços (service discovery);
- terminação SSL;
- trabalhando com websocket.
Agora vamos aos pontos de comparação:
Protocolos suportados
Um dos critérios de seleção fundamentais. Seu software pode não funcionar em HTTP padrão ou pode exigir trabalho em vários protocolos ao mesmo tempo. Se o seu caso não for padrão, certifique-se de levar esse fator em consideração para não precisar reconfigurar o cluster posteriormente. Para todos os controladores, a lista de protocolos suportados varia.
software no núcleo
Existem diversas variações de aplicações nas quais o controlador é baseado. Os populares são nginx, traefik, haproxy, enviado. No caso geral, pode não ter muito efeito sobre 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 é possível tomar uma decisão sobre a direção do tráfego para um determinado serviço? Geralmente são host e caminho, mas existem possibilidades adicionais.
Namespace dentro de um cluster
Namespace (namespace) - a capacidade de dividir recursos logicamente no Kubernetes (por exemplo, no palco, produção etc.). Existem controladores Ingress que devem ser instalados separadamente em cada namespace (e então pode direcionar o tráfego apenas aos pods deste espaço). E há aqueles (e sua clara maioria) que funcionam globalmente para todo o cluster - neles o tráfego é direcionado para qualquer pod do cluster, independente do namespace.
Amostras para upstreams
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 mais detalhes, veja, por exemplo, ), implementações próprias de verificações de integridade (verificações de integridade personalizadas) etc. Um parâmetro muito importante se você tiver altos requisitos de disponibilidade e remoção oportuna de serviços com falha do balanceamento.
Algoritmos de balanceamento
As opções são muitas: do tradicional ao exótico , bem como recursos individuais como .
Autenticação
Quais esquemas de autorização o controlador suporta? Basic, digest, oauth, external-auth - acho que essas opções devem ser familiares. Esse é um critério importante se houver muitos loops de desenvolvedor (e/ou apenas privados) acessados por meio do Ingress.
distribuição de tráfego
O controlador oferece suporte a mecanismos de distribuição de tráfego comumente usados, como lançamentos de canário (canário), teste A / B, espelhamento de tráfego (espelhamento / sombreamento)? Este é um assunto realmente delicado para aplicativos que exigem gerenciamento de tráfego preciso e preciso para testes produtivos, depuração de bugs do produto off-line (ou com perda mínima), análise de tráfego e assim por diante.
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 (Web UI)
Existe alguma GUI para gerenciar a configuração do controlador? Principalmente para "manipulação" e/ou para quem precisa fazer alguma alteração na configuração do Ingress'a, mas trabalhar com templates "brutos" é inconveniente. Pode ser útil se os desenvolvedores quiserem realizar alguns experimentos com tráfego em tempo real.
validação JWT
A presença de validação integrada de tokens da Web JSON para autorização e validação do usuário para o aplicativo final.
Possibilidades de personalização de configuração
Extensibilidade do modelo no sentido de ter mecanismos que permitem adicionar suas próprias diretivas, sinalizadores, etc. aos modelos de configuração padrão.
Mecanismos básicos de proteção DDOS
Algoritmos de limite de taxa simples ou opções de filtragem de tráfego mais complexas com base em endereços, listas brancas, países, etc.
Solicitar rastreamento
A capacidade de monitorar, rastrear e depurar solicitações de Ingresses para serviços/pods específicos e, idealmente, também entre serviços/pods.
WAF
apoio .
controladores
A lista de controladores foi formada com base em и . Excluímos alguns deles da revisão devido à especificidade ou baixa prevalência (estágio inicial de desenvolvimento). O resto é discutido abaixo. Vamos começar com uma descrição geral das soluções e continuar com uma tabela de resumo.
Entrada do Kubernetes
website:
Licença: Apache 2.0
Este é o controlador oficial do Kubernetes e está sendo desenvolvido pela comunidade. Obviamente, pelo nome, ele é baseado no nginx e é complementado por um conjunto diferente de plug-ins Lua usados para implementar recursos adicionais. Devido à popularidade do próprio nginx e modificações mínimas quando usado como um controlador, esta opção pode ser a mais fácil e fácil de configurar para o engenheiro médio (com experiência na web).
Entrada por NGINX Inc.
website:
Licença: Apache 2.0
O produto oficial dos desenvolvedores nginx. Tem uma versão paga baseada em . A ideia principal é um alto nível de estabilidade, compatibilidade constante com versões anteriores, a ausência de quaisquer módulos estranhos e o aumento de velocidade declarado (em comparação com o controlador oficial), alcançado devido à rejeição de Lua.
A versão gratuita é significativamente reduzida, inclusive quando comparada com o controlador oficial (devido à falta dos mesmos módulos Lua). Ao mesmo tempo, o pago 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 para tráfego TCP / UDP (e na versão da comunidade também!). Menos - recurso de distribuição de tráfego, que, no entanto, “tem a maior prioridade para os desenvolvedores”, mas leva tempo para ser implementado.
Entrada Kong
website:
Licença: Apache 2.0
Produto desenvolvido pela Kong Inc. em duas versões: comercial e gratuita. Baseado no nginx, que foi estendido com um grande número de módulos Lua.
Inicialmente, estava focado no processamento e roteamento de solicitações de API, ou seja, como um API Gateway, mas no momento ele se tornou um controlador Ingress completo. Principais vantagens: muitos módulos adicionais (incluindo os de desenvolvedores terceirizados) fáceis de instalar e configurar e com a ajuda dos quais uma ampla gama de recursos adicionais é implementada. No entanto, as funções integradas já oferecem muitas possibilidades. A configuração do trabalho é feita usando recursos CRD.
Uma característica importante do produto - trabalhar dentro do mesmo contorno (em vez de cross-namespaced) é um tópico controverso: para alguns parecerá uma desvantagem (você tem que produzir entidades para cada contorno), e para alguém é um recurso ( bоMaior nível de isolamento, pois se um controlador estiver quebrado, o problema é limitado apenas ao circuito).
Traefik
website:
Licença: MIT
Um proxy que foi originalmente criado para trabalhar com roteamento de solicitações para microsserviços e seu ambiente dinâmico. Portanto, muitos recursos úteis: atualizar a configuração sem reinicializar, suporte para um grande número de métodos de balanceamento, interface da web, encaminhamento de métricas, suporte para vários protocolos, API REST, versões canárias e muito mais. Outro recurso interessante é o suporte para certificados Let's Encrypt prontos para uso. A desvantagem é que, para organizar a alta disponibilidade (HA), o controlador precisará instalar e conectar seu próprio armazenamento KV.
HAPROxy
website:
Licença: Apache 2.0
O HAProxy é conhecido há muito tempo como proxy e balanceador de tráfego. Como parte de um 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 API. Pode ser atraente personalizar completamente o modelo de configuração substituindo o CM, bem como a capacidade de usar as funções da biblioteca Sprig nele. Em geral, a principal ênfase da solução está na alta velocidade, sua otimização e eficiência nos recursos consumidos. A vantagem do controlador é o suporte de um número recorde de diferentes métodos de balanceamento.
Viajante
website:
Licença: Apache 2.0
Baseado no controlador HAproxy, que se posiciona como uma solução universal que suporta uma ampla gama de recursos em um grande número de provedores. Uma oportunidade é oferecida para balancear o tráfego em L7 e L4, e balancear o tráfego TCP L4 como um todo pode ser considerado um dos principais recursos da solução.
Contorno
website:
Licença: Apache 2.0
Esta solução não se baseia apenas no Envoy: foi desenvolvida pela junto com os autores deste procurador popular. Um recurso importante é a capacidade de separar o controle dos recursos do Ingress usando os recursos CRD do IngressRoute. Para organizações com muitas equipes de desenvolvimento usando o mesmo cluster, isso ajuda a maximizar a segurança de trabalhar com tráfego em loops vizinhos e protegê-los de erros ao alterar os recursos do Ingress.
Ele também oferece um conjunto estendido de métodos de balanceamento (há espelhamento de solicitações, repetição automática, limitação da taxa de solicitações e muito mais), monitoramento detalhado do fluxo de tráfego e falhas. Talvez para alguém seja uma desvantagem significativa a falta de suporte para sticky sessions (embora o trabalho ).
Entrada do Istio
website:
Licença: Apache 2.0
Uma solução de malha de serviço abrangente que não é apenas um controlador Ingress que gerencia o tráfego de entrada de fora, mas também controla todo o tráfego dentro do cluster. Sob o capô, o Envoy é usado como um proxy secundário para cada serviço. Em essência, esta é uma grande combinação que “pode fazer qualquer coisa”, e sua ideia principal é a máxima capacidade de gerenciamento, extensibilidade, segurança e transparência. Com ele, você pode ajustar o roteamento de tráfego, autorização de acesso entre serviços, balanceamento, monitoramento, versões canário e muito mais. Leia mais sobre o Istio na série de artigos "".
Embaixadora
website:
Licença: Apache 2.0
Outra solução baseada no Envoy. Possui versões gratuitas e comerciais. Está posicionado como "totalmente nativo do Kubernetes", o que traz as vantagens correspondentes (estreita integração com os métodos e entidades do cluster K8s).
tabela de comparação
Então, o ponto culminante do artigo é esta enorme tabela:
É clicável para uma visão mais próxima e também está disponível no formato .
para resumir
O objetivo deste artigo é fornecer uma compreensão mais completa (porém, de forma alguma exaustiva!) de qual escolha fazer em seu caso particular. Como de costume, cada controlador tem suas próprias vantagens e desvantagens…
O Ingress clássico do Kubernetes é bom por sua disponibilidade e comprovação, recursos ricos o suficiente - no caso geral, deve ser "suficiente para os olhos". No entanto, se houver requisitos aumentados de estabilidade, nível de recursos e desenvolvimento, você deve prestar atenção ao Ingress com NGINX Plus e uma assinatura paga. Kong tem o conjunto mais rico de plug-ins (e, consequentemente, as oportunidades que eles oferecem) e, na versão paga, há ainda mais deles. Possui amplas oportunidades para funcionar como API Gateway, configuração dinâmica baseada em recursos CRD, bem como serviços básicos do Kubernetes.
Com maiores requisitos para 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 Contour já existe há alguns anos, mas ainda parece muito jovem e tem apenas recursos básicos adicionados ao Envoy. Se houver requisitos para a presença / incorporação de WAF na frente do aplicativo, você deve prestar atenção ao mesmo Ingress do Kubernetes ou HAProxy.
E os mais ricos em termos de recursos são os produtos construídos sobre o Envoy, especialmente o Istio. Parece ser uma solução abrangente que "pode fazer qualquer coisa", o que, no entanto, também significa um limite de entrada significativamente maior para configuração / inicialização / administração do que outras soluções.
Escolhemos e ainda usamos o Ingress do Kubernetes como controlador padrão, que cobre de 80 a 90% das necessidades. É bastante confiável, fácil de configurar e expandir. Em geral, na ausência de requisitos específicos, deve atender a maioria dos clusters/aplicações. Dos mesmos produtos universais e relativamente simples, o Traefik e o HAProxy podem ser recomendados.
PS
Leia também em nosso blog:
- "Voltar aos microsserviços com o Istio": , , ;
- «";
- «".
Fonte: habr.com