Ao lanzar un clúster de Kubernetes para unha aplicación específica, cómpre comprender o que a propia aplicación, a empresa e os desenvolvedores representan a este recurso. Con esta información, podes comezar a tomar unha decisión arquitectónica e, en particular, a elixir un controlador de Ingress específico, do que xa hai un gran número na actualidade. Para ter unha idea básica das opcións dispoñibles sen ter que pasar por moitos artigos/documentación, etc., preparamos esta visión xeral, incluíndo os principais controladores de entrada (preparados para a produción).
Agardamos que axude aos compañeiros a escoller unha solución arquitectónica, polo menos se converterá nun punto de partida para obter información máis detallada e experimentos prácticos. Anteriormente, estudamos outros materiais similares na rede e, curiosamente, non atopamos nin unha recensión máis ou menos completa e, sobre todo, estruturada. Entón, imos cubrir ese oco!
criterios
En principio, para facer unha comparación e obter algún resultado útil, cómpre comprender non só a área temática, senón tamén ter unha lista específica de criterios que establecerán o vector de investigación. Sen pretender analizar todos os posibles casos de uso de Ingress/Kubernetes, intentamos destacar os requisitos máis xerais dos controladores: prepárate para que, en todo caso, terás que estudar todos os teus detalles e detalles por separado.
Pero comezarei coas características que se fixeron tan familiares que se implementan en todas as solucións e non se consideran:
- descubrimento dinámico de servizos (descubrimento de servizos);
- Terminación SSL;
- traballando con websockets.
Agora para os puntos de comparación:
Protocolos admitidos
Un dos criterios fundamentais de selección. É posible que o teu software non funcione en HTTP estándar ou que requira traballar en varios protocolos á vez. Se o teu caso non é estándar, asegúrate de ter en conta este factor para non ter que reconfigurar o clúster máis tarde. Para todos os controladores, a lista de protocolos admitidos varía.
software no núcleo
Hai varias variacións de aplicacións nas que se basea o controlador. Os populares son nginx, traefik, haproxy, envoy. No caso xeral, pode que non teña moito efecto sobre como se recibe e se transmite o tráfico, pero sempre é útil coñecer os posibles matices e características do que está "baixo o capó".
Enrutamento do tráfico
En base ao que é posible tomar unha decisión sobre a dirección do tráfico a un servizo en particular? Normalmente son host e ruta, pero hai posibilidades adicionais.
Espazo de nomes dentro dun clúster
Espazo de nomes (espazo de nomes): a capacidade de dividir loxicamente os recursos en Kubernetes (por exemplo, no escenario, na produción, etc.). Hai controladores Ingress que deben instalarse por separado en cada espazo de nomes (e entón pode dirixir o tráfico só ás vainas deste espazo). E hai aqueles (e a súa clara maioría) que funcionan globalmente para todo o clúster: neles o tráfico diríxese a calquera pod do clúster, independentemente do espazo de nomes.
Mostras para augas arriba
Como se dirixe o tráfico a instancias saudables da aplicación e dos servizos? Hai opcións con comprobacións activas e pasivas, reintentos e interruptores (Para máis detalles, consulte, por exemplo, ), implementacións propias de controis de saúde (controles de saúde personalizados), etc. Un parámetro moi importante se tes altos requisitos de dispoñibilidade e eliminación oportuna dos servizos fallidos do equilibrio.
Algoritmos de equilibrio
Hai moitas opcións: dende tradicional ao exótico , así como funcións individuais como .
Autenticación
Que esquemas de autorización admite o controlador? Basic, digest, oauth, external-auth - Creo que estas opcións deberían ser familiares. Este é un criterio importante se hai moitos bucles de desenvolvedores (e/ou só privados) aos que se accede a través de Ingress.
Distribución do tráfico
O controlador admite mecanismos de distribución de tráfico de uso habitual, como os lanzamentos de canary (canary), probas A/B, espello de tráfico (replicación/sombra)? Este é un tema realmente doloroso para aplicacións que requiren unha xestión precisa e precisa do tráfico para probas produtivas, depuración de erros de produtos fóra de liña (ou cunha perda mínima), análise de tráfico, etc.
Subscrición de pago
Existe unha opción de pago para o controlador, con funcións avanzadas e/ou soporte técnico?
Interfaz gráfica de usuario (IU web)
Hai algunha GUI para xestionar a configuración do controlador? Principalmente por "manebilidade" e/ou para aqueles que precisan facer algúns cambios na configuración de Ingress'a, pero traballar con modelos "en bruto" é un inconveniente. Pode ser útil se os desenvolvedores queren realizar algúns experimentos co tráfico sobre a marcha.
Validación JWT
A presenza de validación integrada de tokens web JSON para a autorización e validación do usuario ata a aplicación final.
Posibilidades de personalización da configuración
Extensibilidade de modelos no sentido de contar con mecanismos que lle permitan engadir as súas propias directivas, bandeiras, etc. aos modelos de configuración estándar.
Mecanismos básicos de protección DDOS
Algoritmos sinxelos de límite de tarifa ou opcións de filtrado de tráfico máis complexas baseadas en enderezos, listas brancas, países, etc.
Solicitar rastrexo
A capacidade de supervisar, rastrexar e depurar solicitudes de Ingresses a servizos/pods específicos e, idealmente, tamén entre servizos/pods.
WAF
Apoiar .
Controladores
A lista de controladores formouse en base a и . Excluímos algúns deles da revisión debido á especificidade ou á baixa prevalencia (fase inicial de desenvolvemento). O resto coméntase a continuación. Comecemos cunha descrición xeral das solucións e continúe cunha táboa resumo.
Entrada desde Kubernetes
Páxina web:
Licenza: Apache 2.0
Este é o controlador oficial de Kubernetes e está a ser desenvolvido pola comunidade. Obviamente, polo nome, está baseado en nginx e compleméntase cun conxunto diferente de complementos Lua utilizados para implementar funcións adicionais. Debido á popularidade do propio nginx e ás mínimas modificacións que se lle fan cando se usa como controlador, esta opción pode ser a máis sinxela e fácil de configurar para o enxeñeiro medio (con experiencia na web).
Entrada de NGINX Inc.
Páxina web:
Licenza: Apache 2.0
O produto oficial dos desenvolvedores nginx. Ten unha versión de pago baseada en . A idea principal é un alto nivel de estabilidade, unha compatibilidade cara atrás constante, a ausencia de módulos estraños e o aumento da velocidade declarado (en comparación co controlador oficial), conseguido debido ao rexeitamento de Lua.
A versión gratuíta redúcese significativamente, incluso cando se compara co controlador oficial (debido á falta dos mesmos módulos Lua). Ao mesmo tempo, o pago ten unha funcionalidade adicional bastante ampla: métricas en tempo real, validación JWT, comprobacións de saúde activas e moito máis. Unha vantaxe importante sobre NGINX Ingress é o soporte total para o tráfico TCP/UDP (e tamén na versión da comunidade!). Menos - característica de distribución de tráfico, que, con todo, "ten a máxima prioridade para os desenvolvedores", pero leva tempo implementada.
Kong Ingress
Páxina web:
Licenza: Apache 2.0
Produto desenvolvido por Kong Inc. en dúas versións: comercial e gratuíta. Baseado en nginx, que se estendeu cunha gran cantidade de módulos Lua.
Inicialmente, centrouse no procesamento e enrutamento de solicitudes de API, é dicir. como pasarela API, pero polo momento converteuse nun controlador de entrada de pleno dereito. Vantaxes principais: moitos módulos adicionais (incluídos os de desenvolvedores de terceiros) que son fáciles de instalar e configurar e coa axuda dos cales se implementan unha ampla gama de funcións adicionais. Non obstante, as funcións integradas xa ofrecen moitas posibilidades. A configuración do traballo realízase mediante recursos CRD.
Unha característica importante do produto: traballar dentro do mesmo contorno (en lugar de espaciados entre nomes) é un tema controvertido: para algúns parecerá unha desvantaxe (ten que producir entidades para cada contorno) e para alguén é unha característica ( bоMaior nivel de illamento, como se un controlador está roto, entón o problema limítase só ao circuíto).
Traefik
Páxina web:
Licenza: MIT
Un proxy que se creou orixinalmente para funcionar co enrutamento de solicitudes para microservizos e o seu entorno dinámico. De aí, moitas funcións útiles: actualizar a configuración sen reiniciar en absoluto, soporte para un gran número de métodos de equilibrio, interface web, reenvío de métricas, soporte para varios protocolos, API REST, versións canarias e moito máis. Outra característica agradable é o soporte para os certificados Let's Encrypt listos para usar. A desvantaxe é que para organizar a alta dispoñibilidade (HA), o controlador terá que instalar e conectar o seu propio almacenamento KV.
HAProxy
Páxina web:
Licenza: Apache 2.0
HAProxy coñécese durante moito tempo como un proxy e equilibrador de tráfico. Como parte dun clúster de Kubernetes, ofrece unha actualización de configuración "suave" (sen perda de tráfico), descubrimento de servizos baseado en DNS, configuración dinámica mediante API. Pode ser atractivo personalizar completamente o modelo de configuración substituíndo o CM, así como a posibilidade de usar as funcións da biblioteca Sprig nel. En xeral, a principal énfase da solución está na alta velocidade, a súa optimización e eficiencia nos recursos consumidos. A vantaxe do controlador é o soporte dun número récord de métodos de equilibrio diferentes.
Viaxeiro
Páxina web:
Licenza: Apache 2.0
Baseado no controlador HAproxy, que se posiciona como unha solución universal que admite unha ampla gama de funcións nun gran número de provedores. Ofrécese unha oportunidade para equilibrar o tráfico en L7 e L4, e equilibrar o tráfico TCP L4 no seu conxunto pódese chamar unha das características fundamentais da solución.
Contorno
Páxina web:
Licenza: Apache 2.0
Esta solución non só está baseada en Envoy: foi desenvolvida por conxuntamente cos autores deste popular proxy. Unha característica importante é a capacidade de separar o control dos recursos de Ingress mediante os recursos CRD de IngressRoute. Para as organizacións con moitos equipos de desenvolvemento que usan o mesmo clúster, isto axuda a maximizar a seguridade de traballar co tráfico en bucles veciños e protexelos de erros ao cambiar os recursos de Ingress.
Tamén ofrece un conxunto amplo de métodos de equilibrio (hai espello de solicitudes, repetición automática, limitación da taxa de solicitudes e moito máis), seguimento detallado do fluxo de tráfico e fallos. Quizais para alguén sexa un inconveniente importante a falta de apoio ás sesións pegajosas (aínda que o traballo ).
Istio Ingress
Páxina web:
Licenza: Apache 2.0
Unha solución integral de malla de servizos que non só é un controlador de entrada que xestiona o tráfico entrante desde o exterior, senón que tamén controla todo o tráfico dentro do clúster. Baixo o capó, Envoy úsase como proxy sidecar para cada servizo. En esencia, esta é unha gran combinación que "pode facer calquera cousa", e a súa idea principal é a máxima manexabilidade, extensibilidade, seguridade e transparencia. Con el, podes afinar o enrutamento do tráfico, a autorización de acceso entre servizos, o equilibrio, o seguimento, as versións canarias e moito máis. Ler máis sobre Istio na serie de artigos "».
Embaixador
Páxina web:
Licenza: Apache 2.0
Outra solución baseada en Envoy. Ten versións gratuítas e comerciais. Está posicionado como "totalmente nativo de Kubernetes", o que aporta as vantaxes correspondentes (estreita integración cos métodos e entidades do clúster K8s).
táboa de comparación
Entón, a culminación do artigo é esta enorme táboa:
Pódese facer clic para ver máis de preto e tamén está dispoñible no formato .
para resumir
O propósito deste artigo é proporcionar unha comprensión máis completa (sen embargo, de ningún xeito exhaustiva!) de que opción facer no seu caso particular. Como é habitual, cada controlador ten as súas propias vantaxes e desvantaxes...
O clásico Ingress de Kubernetes é bo pola súa dispoñibilidade e proba, unhas características suficientemente ricas: no caso xeral, debería ser "bastante para os ollos". Non obstante, se hai máis requisitos de estabilidade, nivel de funcións e desenvolvemento, debes prestar atención a Ingress con NGINX Plus e unha subscrición de pago. Kong ten o conxunto máis rico de complementos (e, en consecuencia, as oportunidades que ofrecen), e na versión de pago hai aínda máis. Ten amplas oportunidades para traballar como pasarela API, configuración dinámica baseada en recursos CRD, así como servizos básicos de Kubernetes.
Con máis requisitos para os métodos de equilibrio e autorización, bótalle un ollo a Traefik e HAProxy. Trátase de proxectos de código aberto, comprobados ao longo dos anos, moi estables e en desenvolvemento activo. Contour xa leva un par de anos, pero aínda parece demasiado novo e só ten funcións básicas engadidas enriba de Envoy. Se hai requisitos para a presenza/inserción de WAF diante da aplicación, debes prestar atención ao mesmo Ingress de Kubernetes ou HAProxy.
E o máis rico en funcións son os produtos construídos sobre Envoy, especialmente Istio. Parece ser unha solución integral que "pode facer calquera cousa", o que, con todo, tamén significa un limiar de entrada significativamente máis elevado para a configuración/lanzamento/administración que outras solucións.
Escollemos e seguimos usando Ingress de Kubernetes como controlador estándar, que cobre o 80-90% das necesidades. É bastante fiable, fácil de configurar e ampliar. En xeral, en ausencia de requisitos específicos, debería adaptarse á maioría dos clusters/aplicacións. Dos mesmos produtos universais e relativamente sinxelos, pódense recomendar Traefik e HAProxy.
PS
Lea tamén no noso blog:
- "Volver aos microservizos con Istio": , , ;
- «»;
- «».
Fonte: www.habr.com