Atunci când lansăm un cluster Kubernetes pentru o aplicație specifică, trebuie să înțelegem ce cerințe are aplicația, afacerea și dezvoltatorii. Cu aceste informații, putem începe luarea unei decizii arhitecturale și, în special, alegerea unui anumit Ingress Controller, dintre care există deja o mulțime. Pentru a avea o imagine de ansamblu de bază asupra opțiunilor disponibile, fără a fi necesar să studiem o mulțime de articole/documentație etc., am pregătit această revizuire, incluzând principalele (ready for production) Ingress Controllers.
Sperăm că va ajuta colegii în alegerea soluției arhitecturale — cel puțin, va fi un punct de plecare pentru a obține informații mai detaliate și experimente practice. În prealabil, am studiat alte materiale similare disponibile pe internet și, spre surprinderea noastră, nu am găsit niciun fel de revizuire completă, și mai ales — structurată. Așadar, hai să completăm această lacună!
Criterii
Pentru a putea face o comparație și a obține un rezultat util, trebuie să înțelegem nu doar domeniul tematic, ci și să avem o listă specifică de criterii care să ghideze direcția cercetării. Fără a pretinde că analizăm toate cazurile posibile de utilizare a Ingress/Kubernetes, ne-am străduit să evidențiem cele mai comune cerințe pentru controlere — fiți pregătiți că specificul și detaliile vor trebui studiate separat.
Dar voi începe cu caracteristicile care au devenit atât de familiari, încât sunt implementate în toate soluțiile și nu sunt discutate:
- descoperirea dinamică a serviciilor (service discovery);
- terminarea SSL;
- lucru cu websocket-uri.
Acum, să discutăm despre punctele de comparație:
Protocolele suportate
Unul dintre criteriile fundamentale pentru alegerea. Software-ul dvs. poate funcționa nu conform standardului HTTP sau poate necesita să funcționeze pe mai multe protocoale simultan. Dacă cazul dvs. este neobișnuit, asigurați-vă că luați în considerare acest factor, pentru a nu fi nevoit să reconfigurați clusterul ulterior. Lista protocoalelor suportate de toate controlerele variază.
Software-ul de bază
Există mai multe variante de aplicații pe care se bazează controlerul. Cele mai populare sunt nginx, traefik, haproxy, envoy. În general, acesta poate să nu influențeze foarte mult modul în care este acceptat și transmis traficul, însă întotdeauna este util să cunoaștem nuanțele și caracteristicile potențiale ale ceea ce se află „sub capotă”.
Rutarea traficului
Pe baza a ce putem lua decizii cu privire la direcționarea traficului către un anumit serviciu? De obicei, este vorba despre host și path, dar pot exista și opțiuni suplimentare.
Spațiul de nume în cadrul cluster-ului
Spațiul de nume (namespace) este o oportunitate de a împărți logic resursele în Kubernetes (de exemplu, în stagiu, producție etc.). Există controlere Ingress care trebuie instalate separat în fiecare namespace (și atunci pot direcționa traficul doar câtre pod-urile acestui spațiu). Există și controlere care funcționează la nivel global în întregul cluster — în acest caz, traficul este direcționat către orice pod din cluster, indiferent de spațiul de nume.
Probe pentru upstream-uri
Cum se asigură direcționarea traficului către instanțele sănătoase ale aplicației și serviciilor? Există opțiuni cu verificări active și passive, încercări repetate (retries), circuit breakers (pentru mai multe detalii, consultați de exemplu, în ), implementări proprii ale verificărilor de stări (custom health checks) etc. Acesta este un parametru foarte important, dacă aveți cerințe ridicate pentru disponibilitate și pentru eliminarea oportună a serviciilor defecte din balansare.
Algoritmii de balansare
Aici există o mulțime de opțiuni: de la cele tradiționale la cele exotice, cum ar fi , precum și anumite opțiuni precum .
Autentificare
Ce scheme de autorizare sunt suportate de controler? Basic, digest, oauth, external-auth — cred că aceste opțiuni ar trebui să fie familiare. Acesta este un criteriu important, dacă sunt folosite multe medii pentru dezvoltatori (și/sau pur și simplu medii închise), accesibile prin intermediul Ingress.
Distribuția traficului
Suportă controlerul astfel de mecanisme frecvent utilizate pentru distribuirea traficului, cum ar fi implementările canar (canary), testarea A/B, oglindirea traficului (mirroring/shadowing)? Aceasta este o temă cu adevărat delicată pentru aplicațiile care necesită o gestionare precisă și delicată a traficului pentru testare productivă, depanarea erorilor de produs în condiții de siguranță (sau cu pierderi minime), analiza traficului etc.
Abonament plătit
Există o variantă plătită a controller-ului, cu funcționalități extinse și/sau suport tehnic?
Interfață grafică (Web UI)
Există vreo interfață grafică pentru gestionarea configurației controller-ului? În principal pentru „conveniență” și/sau pentru cei care trebuie să facă modificări în configurația Ingress-ului, dar a lucra cu șabloane „brute” este incomod. Poate fi utilă în cazul în care dezvoltatorii doresc să experimenteze cu traficul în timpul rulării.
Validarea JWT
Disponibilitatea unei verificări încorporate a token-urilor web JSON pentru autorizarea și validarea utilizatorului aplicației finale.
Capabilități de personalizare a configurației
Extensibilitate a șabloanelor în sensul că există mecanisme care permit adăugarea propriilor directive și flaguri în șabloanele standard de configurație.
Mecanisme de bază de protecție împotriva DDOS
Algoritmi simpli de limitare a ratei sau variante mai complexe de filtrare a traficului pe baza adreselor, listelor albe, țărilor etc.
Urmărirea cererilor
Capabilități de monitorizare, urmărire și depanare a cererilor de la Ingress-uri către servicii/pod-uri specifice, iar ideal — și între servicii/pod-uri.
WAF
Asistență .
Controlele Ingress
Lista controlelor a fost formulată pe baza și . Unele dintre ele au fost excluse din revizuire din cauza specificității sau a rarității (stadiul incipient de dezvoltare). Cele rămase sunt analizate mai jos. Vom începe cu o descriere generală a soluțiilor și vom continua cu un tabel rezumat.
Ingress de la Kubernetes
Site:
Licență: Apache 2.0
Acesta este controller-ul oficial pentru Kubernetes, dezvoltat de comunitate. Așa cum sugerează numele, este bazat pe nginx și îmbogățit cu un set divers de plugin-uri Lua, utilizate pentru a implementa funcționalități suplimentare. Datorită popularității nginx-ului și modificărilor minime efectuate asupra acestuia, utilizarea ca firewall poate fi cea mai simplă și clară pentru un inginer mediu (cu experiență în web).
Ingress de la NGINX Inc
Site:
Licență: Apache 2.0
Produs oficial al dezvoltatorilor nginx. Are o versiune plătită, bazată pe . Ideea principală este un nivel ridicat de stabilitate, compatibilitate constantă, absența unor module externe și viteza crescută declarată (comparativ cu controllerul oficial), obținută prin renunțarea la Lua.
Versiunea gratuită este semnificativ limitată, inclusiv în comparație cu controllerul oficial (din cauza absenței acelorași module Lua). Cea plătită, pe de altă parte, are o gamă destul de largă de funcționalități suplimentare: metrici în timp real, validare JWT, verificări active de sănătate și altele. Un avantaj important față de NGINX Ingress este suportul complet pentru traficul TCP/UDP (inclusiv în versiunea community!). Minusul este funcțiilor de distribuție a traficului, ceea ce, totuși, „are prioritate maximă pentru dezvoltatori”, dar necesită timp pentru implementare.
Kong Ingress
Site:
Licență: Apache 2.0
Produs dezvoltat de compania Kong Inc. în două variante: comercială și gratuită. Se bazează pe nginx, a cărui capacitate este extinsă cu un număr mare de module Lua.
Inițial a fost orientat spre procesarea și rutarea cererilor API, adică ca API Gateway, dar în prezent s-a transformat într-un controller Ingress complet. Principalele avantaje: numeroase module suplimentare (inclusiv de la dezvoltatori terți), care sunt ușor de instalat și configurat și cu ajutorul cărora se realizează o gamă largă de funcționalități adiționale. Totuși, funcțiile încorporate oferă deja multe opțiuni. Configurarea funcționării se face prin resurse CRD.
O caracteristică importantă a produsului este că funcționează în cadrul unui singur contur (în loc de cross-namespaced), ceea ce este o temă controversată: pentru unii poate părea o neajuns (de la a crea entități pentru fiecare contur), iar pentru alții — o funcționalitate (unmarenivel mai mare de izolare, deoarece, dacă un controller este compromis, problema este limitată la un singur contur).
Traefik
Site:
Licență: MIT
Proxy-ul care a fost creat inițial pentru a lucra cu rutarea cererilor pentru microservicii și medii lor dinamice. De aici și multe funcții utile: actualizarea configurației fără reporniri, suport pentru un număr mare de metode de balansare, interfață web, redirecționarea metricilor, suport pentru diverse protocoale, REST API, lansări canar și multe altele. O caracteristică plăcută este, de asemenea, suportul pentru certificatele Let’s Encrypt din cutie. Un dezavantaj este că, pentru a organiza o disponibilitate ridicată (HA), controllerul va necesita instalarea și conectarea unui propriul KV-stocare.
HAProxy
Site:
Licență: Apache 2.0
HAProxy este cunoscut de mult timp ca un proxy și un balansor de trafic. În cadrul cluster-ului Kubernetes, acesta oferă o „actualizare blândă” a configurației (fără pierderi de trafic), descoperire a serviciului bazată pe DNS și configurație dinamică prin API. Oferirea posibilității de personalizare completă a șablonului de configurații prin înlocuirea CM-ului, precum și oportunitățile de utilizare a funcțiilor bibliotecii Sprig pot deveni atrăgătoare. În general, accentul principal al soluției se pune pe viteza mare de funcționare, optimizarea acesteia și eficiența în utilizarea resurselor. Avantajul controllerului este suportul pentru un număr record de metode diferite de balansare.
Voyager
Site:
Licență: Apache 2.0
Controller-ul bazat pe HAProxy, care se poziționează ca o soluție universală, ce oferă o gamă largă de funcții pe o mulțime de furnizori. Oferă posibilitatea de a balansa traficul pe L7 și L4, iar balansarea traficului TCP L4 poate fi considerată o caracteristică cheie a soluției.
Contour
Site:
Licență: Apache 2.0
Acestă soluție se bazează nu doar pe Envoy: este dezvoltată în colaborare cu autorii acestui popular proxy. O caracteristică importantă este posibilitatea de a separa gestionarea resurselor Ingress prin resursele CRD IngressRoute. Pentru organizațiile cu multe echipe de dezvoltare care utilizează un singur cluster, acest lucru ajută la maximizarea securității în gestionarea traficului în contururile adiacente și protejează împotriva erorilor în modificarea resurselor Ingress.
De asemenea, este oferit un set extins de metode de balansare (inclusiv mirroring-ul cererilor, repețiri automate, limitarea ratei cererilor și multe altele), monitorizare detaliată a fluxului de trafic și a defecțiunilor. Este posibil ca pentru unii să fie un dezavantaj semnificativ lipsa suportului pentru sticky sessions (deși lucrările ).
Istio Ingress
Site:
Licență: Apache 2.0
O soluție complexă de service mesh, care nu este doar un controler Ingress, gestionând traficul care vine din exterior, ci și controlează tot traficul din cadrul cluster-ului. „Sub capotă”, ca proxy sidecar pentru fiecare serviciu, este utilizat Envoy. Practic, este un mare combinat care „poate face totul”, iar ideea principală este maximizarea gestionabilității, scalabilității, securității și transparenței. Cu ajutorul său, poți configura detaliat rutarea traficului, autorizarea accesului între servicii, balansarea, monitorizarea, lansările canar și multe altele. Citește mai multe despre Istio în seria de articole “».
Ambassador
Site:
Licență: Apache 2.0
O altă soluție bazată pe Envoy. Are versiuni gratuite și comerciale. Este poziționată ca fiind „complet nativă pentru Kubernetes”, ceea ce aduce avantajele corespunzătoare (integrare strânsă cu metodele și entitățile cluster-ului K8s).
Tabel comparativ
Așadar, culminarea articolului - acest tabel uriaș:
Este clicabil pentru a permite o vizualizare mai detaliată și este, de asemenea, disponibil în formatul .
Să tragem concluzii
Scopul articolului este de a oferi o înțelegere mai completă (deși nu exhaustivă!) a alegerii pe care trebuie să o faci în cazul tău specific. Așa cum se întâmplă de obicei, fiecare controler are propriile sale avantaje și dezavantaje...
Ingressul clasic de la Kubernetes este bun datorită disponibilității și stabilității sale, având suficiente funcționalități – în general, ar trebui să fie „suficient pentru majoritatea”. Totuși, dacă există cerințe mai mari pentru stabilitate, nivelul funcțiilor și dezvoltare, ar trebui să luați în considerare Ingress cu NGINX Plus și un abonament plătit. Kong are un set bogat de pluginuri (și, implicit, funcționalitățile furnizate de acestea), iar în versiunea plătită sunt chiar mai multe. Are capacități extinse ca API Gateway, configurare dinamică pe baza resurselor CRD, precum și servicii de bază Kubernetes.
Pentru cerințe mai mari privind echilibrarea și metodele de autorizare, ar trebui să luați în considerare Traefik și HAProxy. Acestea sunt proiecte Open Source, verificate de-a lungul anilor, foarte stabile și în continuă dezvoltare. Contour a apărut acum câțiva ani, dar arată încă prea tânăr și are doar funcționalități de bază, adăugate pe deasupra Envoy. Dacă există cerințe pentru un WAF integrat înainte de aplicatie, ar trebui să luați în considerare același Ingress de la Kubernetes sau HAProxy.
Produsele cele mai bogate în funcții sunt cele construite pe baza Envoy, în special Istio. Acesta se prezintă ca o soluție complexă, care „poate face tot”, ceea ce, însă, implică și un prag de intrare semnificativ mai ridicat pentru configurare/lansare/administare, comparativ cu alte soluții.
Ca standard, am ales și încă folosim Ingress de la Kubernetes, care acoperă 80-90% din nevoi. Este destul de fiabil, ușor de configurat și extins. În general, în absența cerințelor specifice, ar trebui să fie potrivit pentru majoritatea clusterelor/aplicațiilor. Alte produse universale și relativ simple care pot fi recomandate sunt Traefik și HAProxy.
P.S.
Citiți și în blogul nostru:
- „Înapoi la microservicii împreună cu Istio”: , , ;
- «»;
- «».
Sursa: habr.com
