Când lansați un cluster Kubernetes pentru o anumită aplicație, trebuie să înțelegeți ce prezintă aplicația în sine, afacerea și dezvoltatorii pentru această resursă. Cu aceste informații, puteți începe să luați o decizie arhitecturală și, în special, să alegeți un anumit controler Ingress, dintre care există deja un număr mare astăzi. Pentru a ne face o idee de bază despre opțiunile disponibile fără a fi nevoie să parcurgem o mulțime de articole/documentații etc., am pregătit această prezentare generală, inclusiv principalele controlere Ingress (gata de producție).
Sperăm că îi va ajuta pe colegi în alegerea unei soluții arhitecturale – cel puțin va deveni un punct de plecare pentru obținerea de informații mai detaliate și experimente practice. Anterior, am studiat și alte materiale similare pe net și, în mod ciudat, nu am găsit o singură recenzie mai mult sau mai puțin completă și, cel mai important, - structurată. Deci, să umplem acest gol!
criterii
În principiu, pentru a face o comparație și a obține orice rezultat util, trebuie să înțelegeți nu doar domeniul de studiu, ci și să aveți o listă specifică de criterii care vor stabili vectorul de cercetare. Fără să pretindem că analizăm toate cazurile posibile de utilizare a Ingress / Kubernetes, am încercat să evidențiem cerințele cele mai generale pentru controlere - fiți pregătiți că, în orice caz, va trebui să vă studiați toate specificul și detaliile separat.
Dar voi începe cu caracteristicile care au devenit atât de familiare încât sunt implementate în toate soluțiile și nu sunt luate în considerare:
- descoperirea dinamică a serviciilor (descoperirea serviciilor);
- terminare SSL;
- lucrul cu websocket-uri.
Acum pentru punctele de comparație:
Protocoale acceptate
Unul dintre criteriile fundamentale de selecție. Este posibil ca software-ul dvs. să nu funcționeze pe HTTP standard sau poate necesita lucru pe mai multe protocoale simultan. Dacă cazul dvs. nu este standard, asigurați-vă că luați în considerare acest factor, astfel încât să nu fiți nevoit să reconfigurați clusterul mai târziu. Pentru toate controlerele, lista de protocoale acceptate variază.
software-ul la bază
Există mai multe variante de aplicații pe care se bazează controlerul. Cele populare sunt nginx, traefik, haproxy, envoy. În cazul general, este posibil să nu aibă prea mult efect asupra modului în care traficul este primit și transmis, dar este întotdeauna util să cunoașteți potențialele nuanțe și caracteristici a ceea ce este „sub capotă”.
Dirijarea traficului
Pe baza a ceea ce este posibil să luați o decizie cu privire la direcția de circulație către un anumit serviciu? De obicei, acestea sunt gazdă și cale, dar există posibilități suplimentare.
Spațiu de nume într-un cluster
Namespace (namespace) - capacitatea de a împărți în mod logic resursele în Kubernetes (de exemplu, pe scenă, producție etc.). Există controlere Ingress care trebuie instalate separat în fiecare spațiu de nume (și apoi pot direcționa traficul numai la păstăile acestui spaţiu). Și există acelea (și majoritatea lor clară) care funcționează la nivel global pentru întregul cluster - în ele traficul este direcționat către orice pod al clusterului, indiferent de spațiul de nume.
Mostre pentru amonte
Cum este direcționat traficul către instanțe sănătoase ale aplicației, serviciilor? Există opțiuni cu verificări active și pasive, reîncercări, întrerupătoare (Pentru mai multe detalii, vezi, de exemplu, ), implementări proprii ale controalelor de sănătate (controale personalizate de sănătate), etc. Un parametru foarte important dacă aveți cerințe ridicate pentru disponibilitate și eliminarea în timp util a serviciilor eșuate din echilibrare.
Algoritmi de echilibrare
Există multe opțiuni: de la tradițional la exotic , precum și caracteristici individuale precum .
autentificare
Ce scheme de autorizare suportă controlorul? Basic, digest, oauth, external-auth - Cred că aceste opțiuni ar trebui să fie familiare. Acesta este un criteriu important dacă există multe bucle de dezvoltator (și/sau doar private) care sunt accesate prin Ingress.
Distribuția traficului
Controlerul acceptă mecanisme de distribuție a traficului utilizate în mod obișnuit, cum ar fi lansările Canary (Canary), testarea A/B, oglindirea traficului (oglindire/umbrire)? Acesta este un subiect cu adevărat dureros pentru aplicațiile care necesită o gestionare precisă și precisă a traficului pentru testare productivă, depanarea erorilor de produs off-line (sau cu pierderi minime), analiza traficului și așa mai departe.
Abonament plătit
Există o opțiune plătită pentru controler, cu funcționalitate avansată și/sau suport tehnic?
Interfață grafică cu utilizatorul (interfață de utilizare web)
Există vreo GUI pentru a gestiona configurația controlerului? În principal pentru „mâneciune” și/sau pentru cei care trebuie să facă unele modificări în configurația Ingress’a, dar lucrul cu șabloane „brute” este incomod. Poate fi util dacă dezvoltatorii doresc să efectueze câteva experimente cu traficul din mers.
validare JWT
Prezența validării încorporate a token-urilor web JSON pentru autorizarea și validarea utilizatorului la aplicația finală.
Posibilitati de personalizare a configuratiei
Extensibilitatea șabloanelor în sensul de a avea mecanisme care vă permit să adăugați propriile directive, steaguri etc. la șabloanele de configurare standard.
Mecanisme de bază de protecție DDOS
Algoritmi simpli de limitare a ratei sau opțiuni mai complexe de filtrare a traficului bazate pe adrese, liste albe, țări etc.
Solicitați urmărirea
Capacitatea de a monitoriza, urmări și depana solicitările de la Ingress-uri către anumite servicii / poduri și, în mod ideal, și între servicii / poduri.
WAF
Sprijini .
Controlorii
Lista controlorilor a fost formată pe baza и . Pe unele dintre ele le-am exclus din revizuire din cauza specificității sau a prevalenței scăzute (stadiul incipient de dezvoltare). Restul sunt discutate mai jos. Să începem cu o descriere generală a soluțiilor și să continuăm cu un tabel rezumativ.
Intrare din Kubernetes
Site-ul:
Licență: Apache 2.0
Acesta este controlerul oficial pentru Kubernetes și este dezvoltat de comunitate. Evident, din nume, se bazează pe nginx și este completat de un set diferit de plugin-uri Lua folosite pentru a implementa funcții suplimentare. Datorită popularității nginx în sine și modificărilor minime aduse acestuia atunci când este utilizat ca controler, această opțiune poate fi cea mai ușor și mai ușor de configurat pentru un inginer obișnuit (cu experiență web).
Intrarea de către NGINX Inc.
Site-ul:
Licență: Apache 2.0
Produsul oficial al dezvoltatorilor nginx. Are o versiune plătită bazată pe . Ideea principală este un nivel ridicat de stabilitate, compatibilitate inversă constantă, absența oricăror module străine și viteza crescută declarată (comparativ cu controlerul oficial), obținută din cauza respingerii lui Lua.
Versiunea gratuită este redusă semnificativ, inclusiv chiar și în comparație cu controlerul oficial (din cauza lipsei acelorași module Lua). În același timp, cel plătit are o funcționalitate suplimentară destul de largă: metrici în timp real, validare JWT, controale active de sănătate și multe altele. Un avantaj important față de NGINX Ingress este suportul complet pentru traficul TCP / UDP (și în versiunea comunității!). minus - Funcția de distribuție a traficului, care, totuși, „are cea mai mare prioritate pentru dezvoltatori”, dar necesită timp pentru a fi implementată.
Kong Ingress
Site-ul:
Licență: Apache 2.0
Produs dezvoltat de Kong Inc. în două versiuni: comercială și gratuită. Bazat pe nginx, care a fost extins cu un număr mare de module Lua.
Inițial, s-a concentrat pe procesarea și rutarea cererilor API, de exemplu. ca API Gateway, dar în acest moment a devenit un controler Ingress cu drepturi depline. Principalele avantaje: multe module suplimentare (inclusiv cele de la dezvoltatori terți) care sunt ușor de instalat și configurat și cu ajutorul cărora este implementată o gamă largă de caracteristici suplimentare. Cu toate acestea, funcțiile încorporate oferă deja multe posibilități. Configurarea jobului se face folosind resurse CRD.
O caracteristică importantă a produsului - lucrul în același contur (în loc de spații de nume încrucișate) este un subiect controversat: pentru unii va părea un dezavantaj (trebuie să produci entități pentru fiecare contur), iar pentru cineva este o caracteristică ( bоNivel mai mare de izolare, ca dacă un controler este defect, atunci problema este limitată doar la circuit).
Traefik
Site-ul:
Licență: MIT
Un proxy care a fost creat inițial pentru a funcționa cu rutarea cererilor pentru microservicii și mediul lor dinamic. Prin urmare, multe caracteristici utile: actualizarea configurației fără a reporni deloc, suport pentru un număr mare de metode de echilibrare, interfață web, redirecționare a valorilor, suport pentru diverse protocoale, API REST, versiuni canary și multe altele. O altă caracteristică plăcută este suportul pentru certificatele Let's Encrypt din cutie. Dezavantajul este că, pentru a organiza disponibilitatea ridicată (HA), controlerul va trebui să instaleze și să conecteze propriul depozit KV.
HAProxy
Site-ul:
Licență: Apache 2.0
HAProxy a fost cunoscut de mult ca proxy și echilibrator de trafic. Ca parte a unui cluster Kubernetes, oferă o actualizare de configurare „soft” (fără pierderi de trafic), descoperire de servicii bazată pe DNS, configurare dinamică folosind API. Poate fi atractiv să personalizați complet șablonul de configurare prin înlocuirea CM-ului, precum și capacitatea de a utiliza funcțiile bibliotecii Sprig în acesta. În general, principalul accent al soluției este pe viteza mare, optimizarea acesteia și eficiența în resursele consumate. Avantajul controlerului este suportul unui număr record de metode diferite de echilibrare.
Călător
Site-ul:
Licență: Apache 2.0
Bazat pe controlerul HAproxy, care este poziționat ca o soluție universală care acceptă o gamă largă de caracteristici pentru un număr mare de furnizori. Se oferă o oportunitate pentru echilibrarea traficului pe L7 și L4, iar echilibrarea traficului TCP L4 în ansamblu poate fi numită una dintre caracteristicile cheie ale soluției.
Contur
Site-ul:
Licență: Apache 2.0
Această soluție nu se bazează doar pe Envoy: a fost dezvoltată de în comun cu autorii acestui proxy popular. O caracteristică importantă este capacitatea de a separa controlul resurselor Ingress utilizând resursele CRD IngressRoute. Pentru organizațiile cu multe echipe de dezvoltare care utilizează același cluster, acest lucru ajută la maximizarea securității lucrului cu traficul în bucle învecinate și la protejarea lor de erori la modificarea resurselor Ingress.
Oferă, de asemenea, un set extins de metode de echilibrare (există oglindire a cererilor, repetare automată, limitarea ratei cererilor și multe altele), monitorizare detaliată a fluxului de trafic și a eșecurilor. Poate că pentru cineva va fi un dezavantaj semnificativ lipsa de sprijin pentru sesiunile lipicioase (deși munca ).
Istio Ingress
Site-ul:
Licență: Apache 2.0
O soluție cuprinzătoare de rețea de servicii care nu este doar un controler Ingress care gestionează traficul de intrare din exterior, ci și controlează tot traficul din cluster. Sub capotă, Envoy este folosit ca proxy sidecar pentru fiecare serviciu. În esență, aceasta este o combină mare care „poate face orice”, iar ideea sa principală este gestionabilitate maximă, extensibilitate, securitate și transparență. Cu acesta, puteți ajusta rutarea traficului, autorizarea accesului între servicii, echilibrare, monitorizare, lansări canare și multe altele. Citiți mai multe despre Istio în seria de articole "".
Ambasador
Site-ul:
Licență: Apache 2.0
O altă soluție bazată pe Envoy. Are versiuni gratuite și comerciale. Este poziționat ca „complet nativ pentru Kubernetes”, ceea ce aduce avantajele corespunzătoare (integrare strânsă cu metodele și entitățile clusterului K8s).
Tabelul de comparație
Deci, punctul culminant al articolului este acest tabel imens:
Se poate face clic pentru o vizualizare mai atentă și este disponibil și în format .
Pentru a rezuma
Scopul acestui articol este de a oferi o înțelegere mai completă (totuși, deloc exhaustivă!) a alegerii de făcut în cazul dvs. particular. Ca de obicei, fiecare controler are propriile sale avantaje și dezavantaje...
Clasicul Ingress de la Kubernetes este bun pentru disponibilitatea și probabilitatea sa, caracteristici suficient de bogate - în cazul general, ar trebui să fie „suficient pentru ochi”. Cu toate acestea, dacă există cerințe crescute pentru stabilitate, nivelul de caracteristici și dezvoltare, ar trebui să acordați atenție Ingress cu NGINX Plus și un abonament plătit. Kong are cel mai bogat set de plug-in-uri (și, în consecință, oportunitățile pe care le oferă), iar în versiunea cu plată există și mai multe. Are oportunități ample de a funcționa ca gateway API, configurație dinamică bazată pe resurse CRD, precum și servicii Kubernetes de bază.
Cu cerințe crescute pentru metodele de echilibrare și autorizare, aruncați o privire la Traefik și HAProxy. Acestea sunt proiecte Open Source, dovedite de-a lungul anilor, foarte stabile și în curs de dezvoltare. Contour este disponibil de câțiva ani, dar încă pare prea tânăr și are doar caracteristici de bază adăugate pe partea de sus a lui Envoy. Dacă există cerințe pentru prezența / încorporarea WAF în fața aplicației, ar trebui să acordați atenție aceluiași Ingress din Kubernetes sau HAProxy.
Iar cele mai bogate în ceea ce privește caracteristicile sunt produsele construite pe partea superioară a lui Envoy, în special Istio. Pare a fi o soluție cuprinzătoare care „poate face orice”, ceea ce înseamnă însă și un prag de intrare semnificativ mai mare pentru configurare/lansare/administrare decât alte soluții.
Am ales și folosim în continuare Ingress de la Kubernetes ca controler standard, care acoperă 80-90% din nevoi. Este destul de fiabil, ușor de configurat și extins. În general, în absența unor cerințe specifice, ar trebui să se potrivească majorității cluster-urilor / aplicațiilor. Dintre aceleași produse universale și relativ simple, pot fi recomandate Traefik și HAProxy.
PS
Citește și pe blogul nostru:
- „Înapoi la microservicii cu Istio”: , , ;
- «»;
- «".
Sursa: www.habr.com