O comparație cu rețele de servicii Kubernetes

Când discutăm despre arhitectura microserviciilor și containerizarea, un set de instrumente dovedite în producție a captat cea mai mare atenție în ultimii ani: rețeaua de servicii.

Într-adevăr, arhitectura microserviciilor și Kubernetes (deseori stilizate „K8s”) au devenit rapid norma pentru aplicațiile scalabile, făcând problema gestionării comunicațiilor între servicii un subiect fierbinte, iar rețelele de servicii o soluție atractivă. Eu însumi am folosit rețele de serviciu în producție, în special Linkerd, Istio și o formă anterioară de Ambasador. Dar ce fac mai exact rețelele de serviciu? Care este cel mai bun de folosit? De unde știi dacă ar trebui să folosești unul?

Pentru a răspunde la aceste întrebări, vă ajută să înțelegeți de ce au fost dezvoltate rețele de serviciu. Din punct de vedere istoric, infrastructura IT tradițională avea aplicații care rulau ca monoliți. Un serviciu rula pe un server; dacă avea nevoie de mai multă capacitate, soluția era să-l scalați pe verticală prin furnizarea unei mașini mai mari.

Atingând limitele acestei abordări, marile companii de tehnologie au adoptat rapid o arhitectură cu trei niveluri, separând un echilibrator de încărcare de serverele de aplicații și un nivel de bază de date. În timp ce această arhitectură a rămas oarecum scalabilă, au decis să descompună nivelul aplicației în microservicii. Comunicarea dintre aceste servicii a devenit critică pentru monitorizare și securizare pentru ca aplicațiile să se extindă.

Pentru a permite comunicarea între servicii, aceste companii au dezvoltat biblioteci interne: Finagle la Twitter, Hystrix la Netflix și Stubby la Google (care a devenit gRPC în 2016). Aceste biblioteci și-au propus să rezolve problemele ridicate de arhitectura microserviciilor: securitatea între servicii, latența, monitorizarea și echilibrarea încărcării. Dar gestionarea unei biblioteci mari ca dependență – în mai multe limbi – este complexă și necesită timp.

În cele din urmă, acest tip de bibliotecă a fost înlocuit cu un proxy ușor și ușor de utilizat. Astfel de proxy-uri erau independente din exterior de nivelul aplicației – potențial transparente pentru aplicație – și mai ușor de actualizat, întreținut și implementat. Astfel, a luat naștere plasa de serviciu.

Ce este o plasă de serviciu?

O plasă de servicii este un strat de infrastructură software pentru controlul comunicării între servicii; este, în general, format din două componente:

1. Planul de date , care gestionează comunicațiile în apropierea aplicației. De obicei, aceasta este implementată cu aplicația ca un set de proxy de rețea, așa cum sa ilustrat mai devreme.
2. Planul de control, care este „creierul” rețelei de serviciu. Planul de control interacționează cu proxy-urile pentru a împinge configurații, pentru a asigura descoperirea serviciului și pentru a centraliza observabilitatea.

Rețelele de servicii au trei obiective principale în jurul comunicării interservicii:

1. Conectivitate
2. Securitate
3. Observabilitate

Conectivitate

Acest aspect al arhitecturii mesh de servicii permite descoperirea serviciului și rutarea dinamică. De asemenea, acoperă rezistența comunicării , cum ar fi reîncercări, expirări, întreruperea circuitului și limitarea ratei.

O caracteristică de bază a rețelelor de serviciu este echilibrarea sarcinii . Toate serviciile care sunt interconectate de proxy permit implementarea politicilor de echilibrare a încărcăturii între servicii, cum ar fi round robin, aleatorii și cele mai puține solicitări. Aceste politici sunt strategia folosită de rețeaua de servicii pentru a decide ce replică va primi cererea inițială, la fel ca în cazul în care ați avea mici echilibratori de încărcare în fața fiecărui serviciu.

În cele din urmă, rețelele de servicii oferă controlul rutei sub formă de deplasare și oglindire a traficului.

Securitate

În arhitectura tradițională de microservicii, serviciile comunică între ele cu trafic necriptat. Traficul intern necriptat este considerat în prezent o practică proastă în ceea ce privește securitatea, în special pentru infrastructura publică cloud și rețelele de încredere zero.

Pe lângă protejarea confidențialității datelor clienților acolo unde nu există control direct asupra hardware-ului, criptarea traficului intern adaugă un nivel de complexitate suplimentar binevenit în cazul unei breșe de sistem. Prin urmare, toate rețelele de servicii utilizează criptarea TLS reciprocă (mTLS) pentru comunicarea interservicii, adică toate comunicațiile interproxy.

Rețelele de servicii pot chiar să impună matrice complexe ale politicii de autorizare , permițând sau respingând traficul pe baza politicilor care vizează anumite medii și servicii.

Observabilitate

Scopul rețelelor de servicii este de a aduce vizibilitate comunicațiilor interservicii. Prin controlul rețelei, o rețea de servicii impune observabilitatea, oferind valori de nivel șapte , care, la rândul lor, permit alerte automate atunci când traficul atinge un prag personalizabil.

Acceptat de obicei de instrumente terțe sau de plug-in-uri precum Jaeger sau Zipkin, un astfel de control permite, de asemenea, urmărirea prin injectarea antetelor de urmărire HTTP .

Avantajele Service Mesh

Mesh-ul de servicii a fost creat pentru a compensa o parte din sarcina operațională creată de o arhitectură de microservicii. Cei cu experiență în arhitecturi de microservicii știu că necesită o cantitate semnificativă de muncă pentru a funcționa zilnic. Pentru a profita din plin de potențialul microserviciilor, în mod normal, necesită instrumente externe pentru a gestiona jurnalizarea centralizată, gestionarea configurației și mecanismele de scalabilitate, printre altele. Utilizarea unei rețele de servicii standardizează aceste capacități, precum și configurarea și integrarea lor .

Observabilitatea rețelei de servicii, în special, oferă metode extrem de versatile de depanare și optimizare. Datorită vizibilității granulare și complete asupra schimburilor dintre servicii, inginerii, în special SRE, pot depana mai rapid posibilele erori și configurațiile greșite ale sistemului. Cu urmărirea rețelei de servicii, aceștia pot urmări o solicitare de la intrarea acesteia în sistem (la un echilibrator de încărcare sau un proxy extern) până la serviciile private din interiorul stivei. Ei pot folosi înregistrarea pentru a mapa o solicitare și pentru a înregistra latența pe care o întâlnește în fiecare serviciu. Rezultatul final: informații detaliate despre performanța sistemului .

Gestionarea traficului oferă posibilități puternice înainte de a trece la o lansare completă a unei noi versiuni ale unui serviciu:

1. Redirecționați procente mici de solicitări.
2. Și mai bine, oglindiți cererile de producție către o nouă versiune pentru a-și testa comportamentul cu trafic în timp real.
3. Testează A/B orice serviciu sau combinație de servicii.

Rețelele de servicii eficientizează toate scenariile de mai sus, facilitând evitarea și/sau atenuarea oricăror surprize în producție.

Kubernetes Service Mesh Comparație

În multe privințe, rețelele de servicii reprezintă setul suprem de instrumente pentru arhitectura microserviciilor; multe dintre ele rulează pe unul dintre cele mai importante instrumente de orchestrare a containerelor, Kubernetes. Am selectat trei dintre principalele rețele de servicii care rulează astăzi pe Kubernetes: Linkerd (v2), Istio și Consul Connect. Vom discuta și despre alte rețele de servicii: Kuma, Traefik Mesh și AWS App Mesh. Deși în prezent sunt mai puțin proeminente în ceea ce privește utilizarea și comunitatea, sunt suficient de promițătoare pentru a le revizui aici și pentru a ține evidența în general.

O notă rapidă despre proxy-urile Sidecar

Nu toate rețelele de servicii Kubernetes adoptă aceeași abordare arhitecturală, dar una obișnuită este utilizarea modelului sidecar. Aceasta implică atașarea unui proxy (sidecar) la aplicația principală pentru a intercepta și regla traficul de rețea de intrare și de ieșire al aplicației. În practică, acest lucru se face în Kubernetes printr-un container secundar în fiecare pod de aplicație care va urma ciclul de viață al containerului de aplicație.

Există două avantaje principale ale abordării sidecar a rețelelor de service:

• Proxy-urile Sidecar sunt independente de timpul de execuție și chiar de limbajul de programare al aplicației.
  • Acest lucru înseamnă că este ușor să activați toate caracteristicile unei rețele de servicii oriunde va fi folosită, în întreaga stivă.
• Un sidecar are același nivel de permisiuni și acces la resurse ca și aplicația.
  • Sidecar-ul poate ajuta la monitorizarea resurselor utilizate de aplicația principală, fără a fi necesară integrarea monitorizării în baza de cod a aplicației principale.

Dar sidecar-urile sunt o binecuvântare mixtă din cauza modului în care influențează direct o aplicație:

• Inițializarea sidecar poate bloca mecanismul de pornire al unei aplicații.
• Proxy-urile Sidecar adaugă o latență potențială peste aplicația dvs.
• Proxy-urile Sidecar adaugă, de asemenea, o amprentă de resurse care poate costa o sumă semnificativă de bani la scară.

Având în vedere aceste avantaje și dezavantaje, abordarea sidecar este adesea un subiect de dezbatere în comunitatea de servicii. Acestea fiind spuse, patru dintre cele șase rețele de servicii comparate aici folosesc proxy-ul sidecar Envoy, iar Linkerd folosește propria sa implementare sidecar; Traefik Mesh nu folosește sidecar-uri în designul său.

Linkerd Review

Linkerd, care a debutat în 2017, este cea mai veche rețea de servicii de pe piață. Creat de Buoyant (o companie începută de doi foști ingineri Twitter), Linkerd v1 a fost bazat pe Finagle și Netty.

Linkerd v1 a fost descris ca fiind înaintea timpului său, deoarece era o rețea de servicii completă, pregătită pentru producție. În același timp, a fost puțin greu în ceea ce privește utilizarea resurselor. De asemenea, lacunele semnificative în documentație au făcut dificilă configurarea și rularea în producție.

Cu asta, Buoyant a avut șansa de a lucra cu un model de producție complet, de a câștiga experiență din acesta și de a aplica această înțelepciune. Rezultatul a fost Conduit, rescrierea completă Linkerd lansată de companie în 2018 și redenumită Linkerd v2 mai târziu în acel an. Linkerd v2 a adus cu sine mai multe îmbunătățiri convingătoare; întrucât dezvoltarea activă a lui Buoyant a Linkerd v1 a încetat cu mult timp în urmă, mențiunile noastre despre „Linkerd” în restul acestui articol se referă la v2.

Complet open source, Linkerd se bazează pe un proxy de casă scris în Rust pentru planul de date și pe codul sursă scris în Go pentru planul de control.

Conectivitate

Proxy-urile Linkerd au caracteristici de reîncercare și de timeout, dar nu au întrerupere de circuit sau injecție de întârziere la momentul scrierii acestui articol. Suportul de intrare este extins; Linkerd se mândrește cu integrarea cu următoarele controlere de intrare:

• Traefik
• Nginx
• GCE
• Ambasador
• Gloo
• Contur
• Kong

Profilurile de servicii din Linkerd oferă capabilități îmbunătățite de rutare, oferind utilizatorului valori, reglarea reîncercării și setări de timeout, toate pe o rută. În ceea ce privește echilibrarea sarcinii, Linkerd oferă injecție automată de proxy, propriul tablou de bord și suport nativ pentru Grafana.

Securitate

Suportul mTLS din Linkerd este convenabil prin faptul că configurarea sa inițială este automată, la fel ca și rotația zilnică automată a tastelor.

Observabilitate

Din cutie, statisticile și rutele Linkerd sunt observabile printr-un CLI. Pe partea GUI, opțiunile includ tablouri de bord Grafana prefabricate și un tablou de bord nativ Linkerd.

Linkerd se poate conecta la o instanță a lui Prometheus.

Urmărirea poate fi activată printr-un supliment cu OpenTelemetry (fostul OpenCensus) ca colector, iar Jaeger efectuând urmărirea în sine.

Instalare

Instalarea Linkerd se face prin injectarea unui proxy sidecar, care se face prin adăugarea unei adnotări la resursele dvs. în Kubernetes. Există două moduri de a proceda în acest sens:

1. Folosind o diagramă Helm. (Pentru mulți, Helm este managerul de configurare și șabloane de bază pentru resursele Kubernetes.)
2. Instalarea Linkerd CLI, apoi utilizarea acestuia pentru a instala Linkerd într-un cluster.

A doua metodă începe cu descărcarea și rularea unui script de instalare:

 curl -sL https://run.linkerd.io/install | sh

De acolo, instrumentul Linkerd CLI linkerd oferă un set de instrumente util care vă ajută să instalați restul Linkerd și să interacționeze cu clusterul de aplicații și cu planul de control.

linkerd check --pre va executa toate verificările preliminare necesare instalării dvs. Linkerd, oferind jurnalele clare și precise despre motivul pentru care o potențială instalare Linkerd ar putea să nu funcționeze încă. Fără --pre , această comandă poate fi folosită pentru depanarea post-instalare.

Următorul pas este să instalați Linkerd în cluster rulând:

 linkerd install | kubectl apply -f -

Linkerd va instala apoi multe componente diferite cu o amprentă de resurse foarte mică; prin urmare, ei înșiși au o abordare a microserviciilor:

• linkerd-controller , care oferă API-ul public cu care interacționează CLI și tabloul de bord
• linkerd-identity , care oferă autoritatea de certificare pentru implementarea mTLS
• linkerd-proxy-injector , care se ocupă de injectarea proxy-ului prin mutarea configurației unui pod
• linkerd-web , care oferă un tablou de bord care permite monitorizarea implementărilor și podurilor, precum și a componentelor interne Linkerd

Linkerd își bazează cea mai mare parte a configurației pe CustomResourceDefinitions (CRD). Aceasta este considerată cea mai bună practică atunci când se dezvoltă software-ul suplimentar Kubernetes - este ca și cum ați instala în mod durabil un plug-in într-un cluster Kubernetes.

Adăugarea de urmărire distribuită – care poate sau nu este ceea ce urmăresc de fapt utilizatorii Linkerd, din cauza unor mituri comune – necesită un alt pas cu linkerd-collector și linkerd-jaeger. Pentru asta, vom crea mai întâi un fișier de configurare:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Pentru a activa urmărirea, vom rula:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Ca și în cazul oricărei rețele de servicii bazate pe proxy-uri sidecar, va trebui să modificați codul aplicației pentru a activa urmărirea. Cea mai mare parte a acestui lucru este pur și simplu adăugarea unei biblioteci client pentru a propaga antetele de urmărire; apoi trebuie inclus în fiecare serviciu.

Funcția de împărțire a traficului a Linkerd, expusă prin API-ul compatibil cu Service Mesh Interface (SMI), permite deja lansări canare. Dar pentru a le automatiza și gestionarea traficului, veți avea nevoie și de instrumente externe precum Flagger.

Flagger este un instrument de livrare progresivă care va evalua ceea ce Linkerd numește valorile „de aur” : „volumul cererilor, rata de succes și distribuțiile de latență”. (Inițial, Google SRE foloseau termenul de semnale de aur și includeau un al patrulea - saturație - dar Linkerd nu îl acoperă deoarece ar necesita valori care nu sunt direct accesibile, cum ar fi utilizarea CPU și a memoriei.) Flagger le urmărește în timp ce împarte traficul utilizarea unei bucle de feedback; prin urmare, puteți implementa versiuni canare automate și care țin seama de valori.

După aprofundarea procesului de instalare, devine clar că pentru a avea o rețea de servicii Linkerd operațională și pentru a exploata capabilitățile dorite în mod obișnuit, este ușor să ajungeți să rulați cel puțin o duzină de servicii. Acestea fiind spuse, mai multe dintre ele sunt furnizate de Linkerd la instalare decât cu alte rețele de serviciu.

Rezumatul rețelei serviciului Linkerd

Avantaje:

Linkerd beneficiază de experiența creatorilor săi, doi foști ingineri Twitter care au lucrat la instrumentul intern, Finagle, și au învățat ulterior de la Linkerd v1. Fiind una dintre primele rețele de servicii, Linkerd are o comunitate înfloritoare (Slack are peste 5.000 de utilizatori, plus are o listă de corespondență activă și un server Discord) și un set extins de documentație și tutoriale. Linkerd este matur odată cu lansarea versiunii 2.9, așa cum demonstrează adoptarea sa de către mari corporații precum Nordstrom, eBay, Strava, Expedia și Subspace. Asistența plătită la nivel de întreprindere de la Buoyant este disponibilă pentru Linkerd.

Dezavantaje:

Există o curbă de învățare destul de puternică pentru a utiliza rețelele de servicii Linkerd la întregul lor potențial. Linkerd este acceptat numai în containerele Kubernetes (adică, nu există un mod „universal” bazat pe VM). Proxy-ul Linkerd sidecar nu este Envoy. Deși acest lucru îi permite lui Buoyant să-l regleze după cum consideră de cuviință, elimină extensibilitatea inerentă pe care o oferă Envoy. De asemenea, înseamnă că Linkerd nu are suport pentru întreruperea circuitului, injecția întârziată și limitarea ratei. Niciun API anume nu este expus pentru a controla cu ușurință planul de control Linkerd. (Totuși, puteți găsi legarea gRPC API.)

Linkerd a făcut progrese mari de la v1 în ceea ce privește utilizarea și ușurința instalării. Lipsa unui API expus oficial este o omisiune notabilă. Dar datorită documentației bine gândite, funcționalitatea ieșită din cutie din Linkerd este ușor de testat.

Consul Connect Review

Următorul nostru candidat al rețelei de servicii, Consul Connect, este un hibrid unic. Consul de la HashiCorp este mai bine cunoscut pentru stocarea cheie-valoare pentru arhitecturi distribuite, care există de mulți ani. După evoluția Consul într-o suită completă de instrumente de service, HashiCorp a decis să construiască o rețea de servicii pe deasupra: Consul Connect.

Pentru a fi precis cu privire la natura sa hibridă:

Planul de date Consul Connect se bazează pe Envoy, care este scris în C++. Planul de control al Consul Connect este scris în Go. Aceasta este partea care este susținută de Consul KV, un magazin cheie-valoare.

La fel ca majoritatea celorlalte rețele de servicii, Consul Connect funcționează prin injectarea unui proxy sidecar în interiorul aplicației dumneavoastră. În ceea ce privește arhitectura, Consul Connect se bazează pe agenți și servere . Din cutie, Consul Connect este menit să aibă disponibilitate ridicată (HA) folosind trei sau cinci servere ca StatefulSet care specifică anti-afinitatea podului. Anti-afinitatea podului este practica de a se asigura că podurile unui sistem software distribuit nu vor ajunge pe același nod (server), garantând astfel disponibilitatea în cazul în care un singur nod eșuează.

Conectivitate

Nu există multe care să facă Consul Connect să iasă în evidență în acest domeniu; oferă ceea ce face orice rețea de serviciu (ceea ce este destul de puțin), plus caracteristici de nivel șapte pentru rutare bazată pe căi, deplasarea traficului și echilibrarea sarcinii.

Securitate

Ca și în cazul celorlalte rețele de servicii, Consul Connect oferă capabilități mTLS de bază. De asemenea, oferă integrare nativă între Consul și Vault (tot de HashiCorp), care poate fi folosită ca furnizor de CA pentru a gestiona și semna certificate într-un cluster.

Observabilitate

Consul Connect adoptă cea mai comună abordare a observabilității prin încorporarea Envoy ca proxy sidecar pentru a oferi capabilități de nivel șapte. Configurarea interfeței de utilizare a Consul Connect pentru a prelua valorile implică modificarea unui fișier de configurare încorporat și, de asemenea, activarea unui furnizor de valori precum Prometheus. De asemenea, este posibil să configurați unele tablouri de bord Grafana pentru a afișa valori relevante specifice serviciului.

Instalare

Consul Connect este instalat într-un cluster Kubernetes folosind o diagramă Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Va trebui să modificați valorile values.yaml dacă doriți să activați interfața de utilizare sau să faceți ca modulul Consul Connect să-și injecteze proxy-ul sidecar:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Pentru a consulta membrii și a verifica diferitele noduri, Consul recomandă exec într-unul dintre containere, apoi folosirea instrumentului CLI consul .

Pentru a servi interfața de utilizare web gata de utilizare pe care Consul o oferă, rulați kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Rezumatul rețelei serviciului Consul Connect

Avantaje:

• Consul este susținut de HashiCorp; ca produs freemium, există și o versiune de întreprindere cu funcții suplimentare care oferă suport la nivel de întreprindere. În ceea ce privește experiența echipei de dezvoltare, Consul este unul dintre cele mai vechi instrumente de pe piață.
• Consul are o comunitate solidă de întreprinderi și se știe că rulează pe infrastructură cu 50.000 de noduri. De asemenea, există din 2014, ceea ce îl face un produs matur în raport cu piața.
• Consul Connect rulează bine în interiorul unui VM, datorită suportului nativ.
• Cu Consul Connect, este posibil să se realizeze integrări de aplicații la fel de profunde precum implementările pre-service-mesh la companiile de tehnologie de top. Acest lucru se datorează expunerii unui API complet documentat, la nivel de bibliotecă.

Dezavantaje:

• Consul Connect are o curbă de învățare mai abruptă decât celelalte rețele de servicii și va avea nevoie de mai multe reglaje pentru a rula tablouri de bord și valori vizuale.
• Documentația HashiCorp nu este simplă, lăsând utilizatorilor să sape și să experimenteze pentru a o configura corect.
• Documentația de gestionare a traficului este greu de găsit și constă în principal în link-uri către documentația Envoy, care nu oferă detalii despre gestionarea traficului Consul Connect în special.
• Interfața SMI a Consul Connect este încă experimentală.

Consul Connect poate fi o alegere foarte bună pentru cei care caută un produs de calitate enterprise. HashiCorp este cunoscut pentru calitatea produselor sale, iar Consul Connect nu face excepție. Pot vedea două avantaje puternice aici în comparație cu alte rețele de servicii: suport puternic din partea companiei cu versiunea enterprise și un instrument pregătit pentru tot felul de arhitecturi (nu doar Kubernetes).

Istio Review

În mai 2017, Google, IBM și Lyft au anunțat Istio. Când Istio a intrat în cursa instrumentelor cu plase de service, a câștigat o expunere foarte bună în spațiul tehnologic. Autorii săi au adăugat funcții bazate pe feedback-ul utilizatorilor până la versiunea 1.9.

Istio a promis noi funcții importante față de concurenții săi la acea vreme: echilibrarea automată a sarcinii, injectarea defecțiunilor și multe altele. Acest lucru i-a câștigat o atenție copioasă din partea comunității, dar, așa cum vom detalia mai jos, utilizarea Istio este departe de a fi banală: Istio a fost recunoscut ca fiind deosebit de complex de pus în producție.

Din punct de vedere istoric, proiectul Istio a revenit frecvent în ceea ce privește modificările codului sursă. Odată ce a adoptat o arhitectură de microservicii pentru planul de control, Istio a trecut acum (începând cu versiunea 1.5) la o arhitectură monolitică. Motivul lui Istio pentru revenirea la centralizare a fost că microserviciile erau greu de monitorizat de către operatori, baza de cod era prea redundantă și proiectul atinsese maturitatea organizațională – nu mai era nevoie să aibă multe echipe mici care lucrează în siloz.

Cu toate acestea, pe parcurs, Istio a câștigat notorietate pentru că are unul dintre cele mai mari volume de probleme GitHub deschise. La momentul scrierii acestui articol, numărul se ridică la aproximativ 800 de numere deschise și aproximativ 12.000 închise. În timp ce numărul de probleme poate fi înșelător, în acest caz, ele reprezintă o îmbunătățire semnificativă în ceea ce privește funcțiile rupte anterior și utilizarea scăpată a resurselor.

Conectivitate

Istio este destul de puternic în gestionarea traficului în comparație cu Consul Connect și Linkerd. Acest lucru se datorează unei oferte extinse de subfuncții: rutarea cererilor, injectarea defecțiunilor, schimbarea traficului, expirarea timpului de solicitare, întreruperea circuitului și controlul traficului de intrare și ieșire în rețeaua de serviciu. Noțiunea de servicii virtuale și reguli de destinație o face foarte completă în ceea ce privește managementul traficului.

Cu toate acestea, toate aceste posibilități vin cu o curbă de învățare, plus gestionarea acelor resurse noi pe clusterul tău Kubernetes.

Securitate

Istio se mândrește cu un set cuprinzător de instrumente legate de securitate, cu două axe principale: autentificare și autorizare. Istio poate aplica diferite niveluri de politici pe diferite domenii: specifice sarcinii de lucru, la nivel de spațiu de nume sau la nivel de plasă. Toate aceste resurse de securitate sunt gestionate prin Istio CRD, cum ar fi AuthorizationPolicy sau PeerAuthentication .

Dincolo de suportul standard mTLS, Istio poate fi configurat și să accepte sau să respingă traficul necriptat.

Observabilitate

Aici, Istio este destul de avansat, cu mai multe tipuri de telemetrie care oferă perspective solide asupra rețelei de servicii. Valorile se bazează pe cele patru semnale de aur (latență, trafic, erori și, într-o oarecare măsură, saturație).

În special, Istio oferă valori pentru planul de control însuși. De asemenea, oferă urme distribuite și jurnale de acces, oferindu-se compatibilitate explicită cu Jaeger, Lightstep și Zipkin pentru a permite urmărirea.

Nu există un tablou de bord nativ, dar există suport oficial pentru consola de management Kiali.

Instalare

Instalarea este la fel de simplă precum urmați pașii oficiali. Istio este, de asemenea, integrat nativ în GKE ca o funcție beta, dar acolo GKE folosește Istio 1.4.X, versiunea mai veche de microservicii, spre deosebire de cea mai recentă versiune monolit.

O instalare nativă începe cu descărcarea celei mai recente versiuni:

 curl -L https://istio.io/downloadIstio | sh -

După ce ați copiat în folderul cd istio-* nou creat, îl puteți adăuga la calea dvs., astfel încât să puteți utiliza instrumentul utilitar istioctl :

 export PATH=$PWD/bin:$PATH

De acolo, puteți instala Istio în clusterul dvs. Kubernetes prin istioctl :

 istioctl install

Aceasta va instala Istio cu un profil default . Profilurile istioctl vă permit să creați diferite configurații de instalare și să comutați între ele dacă este necesar. Dar chiar și într-un scenariu cu un singur profil, puteți personaliza profund instalarea Istio modificând unele CRD-uri.

Resursele Istio vor fi mai greu de gestionat, deoarece va trebui să gestionați mai multe tipuri de CRD-uri — VirtualService , DestinationRule și Gateway cel puțin — pentru a vă asigura că gestionarea traficului este la loc.

• O resursă VirtualService este o configurație care declară un serviciu și diferitele reguli de rutare care sunt aplicate cererilor.
• O resursă DestinationRule este utilizată pentru a grupa și a aplica politicile de trafic specifice țintei.
• O resursă Gateway este creată pentru a gestiona traficul de rețea de serviciu de intrare și de ieșire (adică, proxy-uri Envoy suplimentare, dar care rulează la margine, mai degrabă decât ca sidecar-uri).

Detaliile semantice depășesc domeniul de aplicare al acestei revizuiri, dar să ne uităm la un exemplu rapid care arată că fiecare dintre acestea lucrează împreună. Să presupunem că avem un site de comerț electronic cu un serviciu numit products . Serviciul nostru VirtualService ar putea arăta astfel:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

DestinationRule corespunzătoare ar putea fi atunci:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

În sfârșit, Gateway noastră de acces:

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Cu aceste trei fișiere la locul lor, o instalare Istio ar fi gata să gestioneze traficul de bază.

Istio Service Mesh Rezumat

Avantaje:

• Dintre diferitele rețele de servicii, Istio este cea cu cea mai mare comunitate online la momentul scrierii acestui articol. Cu rezultate de peste 10 ori peste Stack Overflow ca oricare dintre principalii săi concurenți, este cea mai discutată rețea de servicii de pe web; colaboratorii săi GitHub sunt, de asemenea, cu un ordin de mărime dincolo de cei ai Linkerd.
• Istio acceptă atât modurile Kubernetes, cât și VM; acesta din urmă este în versiune beta începând cu versiunea 1.9.

Dezavantaje:

• Istio nu este liber, în două sensuri:
  • Cerințele sale sunt mari în ceea ce privește timpul necesar pentru a citi documentația, a o configura, a o face să funcționeze corect și a o întreține. În funcție de dimensiunea infrastructurii și de numărul de servicii, Istio va dura de la câteva săptămâni la câteva luni de lucru cu normă întreagă pentru a fi pe deplin funcțional și integrat în producție.
  • De asemenea, adaugă o cantitate semnificativă de supraîncărcare a resurselor: va fi nevoie de 350 de milicore (mCPU) pentru containerul Envoy la 1.000 de solicitări pe secundă (RPS). Chiar și planul de control în sine poate consuma resurse. (Anterior, utilizarea resurselor era greu de prezis, dar după ceva efort, istiod s-a stabilizat folosind 1 vCPU și 1,5 GB de memorie.)
• Nu are tablou de bord nativ de administrare, spre deosebire de Linkerd.
• Istio necesită utilizarea propriului gateway de intrare.
• Planul de control Istio este acceptat numai în containerele Kubernetes (adică, nu există un mod VM, spre deosebire de planul de date al Istio).

Istio este un exemplu grozav al giganților tehnologiei care se unesc pentru a crea un proiect open-source pentru a aborda o provocare cu care se confruntă cu toții. A fost nevoie de ceva timp pentru ca proiectul Istio în ansamblu să se structureze singur (reamintind schimbarea arhitecturală de la microservicii la monolit) și să rezolve numeroasele sale probleme inițiale. Astăzi, Istio face absolut tot ce ne-am aștepta de la o rețea de serviciu și poate fi extins foarte mult. Dar toate aceste posibilități vin cu cerințe abrupte în ceea ce privește cunoștințele, orele de lucru și resursele de calcul pentru a sprijini utilizarea acestora într-un mediu de producție.

Revizuire rapidă Kuma

Creat de Kong și apoi cu sursă deschisă, Kuma a ajuns la 1.0 la sfârșitul anului 2020. Într-o oarecare măsură, a fost creat ca răspuns la faptul că primele rețele de serviciu erau destul de grele și dificil de operat.

Lista sa de caracteristici sugerează că este foarte modular; ideea din spatele Kuma este să-l orienteze spre integrarea cu aplicațiile care rulează deja pe Kubernetes sau altă infrastructură.

• În domeniul managementului traficului , Kuma oferă caracteristici comune ale rețelei de servicii, cum ar fi injecția de defecțiuni și întreruperea circuitului.
• Dincolo de criptarea mTLS interservicii, schimburile dintre planul de date și planul de control sunt securizate în Kuma printr-un simbol proxy pentru planul de date .
• Observabilitatea este definită în Kuma prin diferite politici de trafic privind valorile, urmărirea și înregistrarea în jurnal.
• Descoperirea serviciului este disponibilă prin Kuma datorită propriului rezolutor DNS care rulează pe portul 5653 al planului de control.
• Kuma pune un accent puternic pe funcționalitatea multimesh : puteți combina cu ușurință mai multe clustere Kubernetes sau medii VM într-un cluster Kuma comun cu tipul său de implementare multizonă.
• Kuma se integrează cu ușurință cu Kong Gateway pentru utilizatorii Kong existenți.

Versiunea universală (non-Kubernetes) a Kuma necesită PostgreSQL ca dependență, iar CTO-ul lui Kong a fost în special împotriva suportării SMI. Dar Kuma a fost dezvoltat cu ideea de implementări multicloud și multicluster încă de la început, iar tabloul de bord reflectă acest lucru.

În timp ce Kuma este încă tânăr în spațiul de rețea de serviciu, cu puține cazuri de utilizare în producție până acum, este un concurent interesant și promițător.

Revizuire rapidă Traefik Mesh

Numit inițial Maesh, Traefik Mesh (de la Traefik Labs) este un alt nou-venit în cursa de scule de service mesh. Misiunea proiectului este de a democratiza rețeaua de servicii, făcându-l ușor de utilizat și configurat; experiența dezvoltatorilor cu bine gândit Traefik Proxy i-a pus într-o poziție privilegiată pentru a realiza acest lucru.

• Funcțiile de gestionare a traficului din Traefik Mesh includ întreruperea circuitului și limitarea ratei.
• În ceea ce privește observabilitatea , Traefik Mesh dispune de suport nativ pentru OpenTracing și de metrice out-of-the-box (instalarea standard include automat Prometheus și Grafana), ceea ce economisește timp de configurare.
• Pentru securitate — în afară de mTLS — specificațiile sunt compatibile cu SMI, iar Traefik Mesh permite reglarea fină a permisiunilor de trafic prin controlul accesului.

Traefik Mesh are nevoie de CoreDNS pentru a fi instalat pe cluster. (În timp ce Azure a folosit CoreDNS în mod implicit începând cu 1.12, GKE este implicit la kube-dns în momentul scrierii acestui articol, ceea ce înseamnă că este implicat un pas suplimentar semnificativ în acest caz.) De asemenea, îi lipsesc capabilitățile multicluster.

Acestea fiind spuse, Traefik Mesh este unic în comparația noastră de rețea de serviciu, deoarece nu utilizează injecția sidecar. În schimb, este implementat ca DaemonSet pe toate nodurile pentru a acționa ca un proxy între servicii, făcându-l neinvaziv. În general, Traefik Mesh este simplu de instalat și utilizat.

Revizuire rapidă AWS App Mesh

În lumea furnizorilor de cloud, AWS este primul care a implementat un serviciu mesh nativ conectabil cu Kubernetes (sau EKS în special), dar și celelalte servicii ale sale. AWS App Mesh a fost lansat în noiembrie 2018 și de atunci AWS repetă pe el. Principalul avantaj al AWS App Mesh este ecosistemul AWS preexistent și poziția pe piață; marea comunitate din spatele AWS în general va continua să stimuleze utilizarea și gradul de utilizare.

• Traffic management in AWS App Mesh includes circuit breaking on top of common features.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infrastructură

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Implementare

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.