Kas yra Linkerd ir kodėl jis svarbus
Kubernetes pasaulyje mikroservisų architektūra tapo standartu, bet kartu atsirado ir naujų iššūkių. Kaip valdyti šimtus ar net tūkstančius tarpusavyje komunikuojančių servisų? Kaip užtikrinti saugumą, stebėseną ir patikimumą tokioje sudėtingoje aplinkoje? Čia į pagalbą ateina service mesh sprendimai, o Linkerd yra vienas populiariausių ir, svarbiausia, paprasčiausių tokių įrankių.
Linkerd buvo vienas pirmųjų service mesh sprendimų, kuris atsirado dar 2016 metais. Nuo to laiko jis evoliucionavo į brandų, CNCF (Cloud Native Computing Foundation) graduated projektą, kuris pasižymi savo paprastumu ir efektyvumu. Skirtingai nei kiti sprendimai, Linkerd nuo pat pradžių buvo kuriamas būtent Kubernetes aplinkai, todėl jis puikiai integruojasi su šia platforma.
Pagrindinis Linkerd tikslas – padaryti mikroservisų komunikaciją saugesnę, patikimesnę ir lengviau stebimą, nepriverčiant kūrėjų keisti aplikacijų kodo. Tai pasiekiama įdiegiant lengvus proxy konteinerius (sidecar) šalia kiekvieno aplikacijos pod’o. Šie proxy’ai perima visą tinklo srautą ir prideda papildomų funkcijų, apie kurias aplikacija net nežino.
Linkerd architektūra: kaip tai veikia praktiškai
Linkerd architektūra susideda iš dviejų pagrindinių dalių: control plane ir data plane. Control plane – tai valdymo lygmuo, kuris veikia kaip atskiri pod’ai jūsų klasteryje. Jis atsakingas už konfigūracijos valdymą, metrikos rinkimą ir sertifikatų valdymą. Data plane – tai minėti sidecar proxy konteineriai, kurie veikia šalia kiekvieno jūsų aplikacijos konteinerio.
Kas daro Linkerd ypatingą, tai jo data plane įgyvendinimas. Skirtingai nei daugelis konkurentų, kurie naudoja Envoy proxy, Linkerd naudoja specialiai sukurtą micro-proxy pavadinimu Linkerd2-proxy, parašytą Rust programavimo kalba. Šis sprendimas leidžia pasiekti itin mažą resursų suvartojimą ir greitą veikimą.
Kai įdiegiate Linkerd į savo Kubernetes klasterį, control plane komponentai užima maždaug 200-300 MB atminties. Kiekvienas sidecar proxy paprastai sunaudoja tik 10-20 MB atminties ir minimalų CPU kiekį. Palyginkite tai su kai kuriais kitais sprendimais, kurie gali reikalauti 50-100 MB atminties vienam proxy – skirtumas tampa akivaizdus, kai turite šimtus pod’ų.
Įdiegimas ir pirmieji žingsniai
Vienas iš dalykų, kurie padaro Linkerd tokį patrauklų, yra jo įdiegimo paprastumas. Visas procesas gali užtrukti vos kelias minutes. Pirmiausia reikia įsidiegti Linkerd CLI įrankį. Linux ar macOS sistemose tai galima padaryti viena komanda:
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
Po to pridėkite Linkerd į savo PATH ir patikrinkite, ar jūsų klasteris tinka Linkerd įdiegimui:
linkerd check --pre
Ši komanda patikrina visus būtinus reikalavimus ir praneša, jei kažkas negerai. Tai puikus pavyzdys, kaip Linkerd rūpinasi vartotojo patirtimi – jums nereikia spėlioti, kas negerai, sistema pati viską patikrina ir paaiškina.
Jei viskas gerai, galite įdiegti Linkerd control plane:
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
Palaukite, kol visi komponentai pasileis, ir patikrinkite įdiegimą:
linkerd check
Dabar jūsų klasteryje veikia Linkerd control plane. Bet jūsų aplikacijos dar nenaudoja service mesh funkcionalumo. Tam reikia „injektuoti” sidecar proxy į jūsų pod’us. Tai galima padaryti keliais būdais: automatiškai (naudojant anotacijas namespace lygyje) arba rankiniu būdu.
Automatinis TLS ir zero-trust saugumas
Viena iš galingiausių Linkerd funkcijų yra automatinis mutual TLS (mTLS) visai komunikacijai tarp servisų. Kai tik įjungiate Linkerd savo aplikacijoms, visa komunikacija tarp pod’ų automatiškai tampa šifruota ir autentifikuota. Jums nereikia konfigūruoti sertifikatų, valdyti raktų ar rašyti papildomo kodo.
Linkerd automatiškai sukuria ir rotuoja TLS sertifikatus kiekvienam servui. Tai vyksta fone, naudojant savo vidinę certificate authority (CA). Sertifikatai yra trumpalaikiai – pagal nutylėjimą galioja 24 valandas – kas sumažina saugumo riziką, jei sertifikatas būtų kompromituotas.
Praktiškai tai reiškia, kad jūsų mikroservisų architektūra automatiškai atitinka zero-trust saugumo principus. Kiekvienas servisas turi patvirtinti savo tapatybę prieš komunikuodamas su kitais servisais. Tai ypač svarbu reguliuojamose pramonės šakose ar kai dirbate su jautriais duomenimis.
Be to, Linkerd palaiko policy funkcionalumą, kuris leidžia apibrėžti, kurie servisai gali komunikuoti tarpusavyje. Galite sukurti detalizuotas taisykles, kurios leidžia ar draudžia komunikaciją pagal service identity, namespace ar kitus kriterijus. Tai prideda papildomą saugumo lygmenį virš Kubernetes network policies.
Observability: matykite, kas vyksta jūsų tinkle
Linkerd iš karto suteikia išsamią informaciją apie visą tinklo srautą jūsų klasteryje. Kiekvienas proxy renka metrikos duomenis apie užklausas: kiek jų buvo, kiek sėkmingų, kokie atsakymo laikai, kiek klaidų. Visa tai matoma realiu laiku, be jokios papildomos konfigūracijos.
Linkerd ateina su integruotu dashboard, kurį galite paleisti komanda:
linkerd viz dashboard
Šis dashboard rodo vizualią jūsų servisų topologiją, success rates, latency metrikas ir kitus svarbius rodiklius. Tai neįtikėtinai naudinga debuginant problemas ar tiesiog norint suprasti, kaip jūsų sistema veikia.
Bet tikroji galia atsiskleidžia, kai integruojate Linkerd su Prometheus ir Grafana. Linkerd automatiškai eksportuoja visas metrikos į Prometheus formatą. Galite sukurti detalizuotus dashboard’us Grafana, nustatyti alertus ir analizuoti istorinius duomenis. Linkerd bendruomenė jau yra sukūrusi daugybę paruoštų Grafana dashboard’ų, kuriuos galite tiesiog importuoti ir naudoti.
Dar viena galinga funkcija yra tap – galimybė realiu laiku stebėti HTTP užklausas tarp servisų. Pavyzdžiui:
linkerd viz tap deploy/web-frontend
Ši komanda parodys visas užklausas, kurias gauna ar siunčia web-frontend deployment. Tai neįkainojama priemonė debuginant problemas produkcijoje, kai negalite tiesiog prisijungti prie konteinerio ir paleisti tcpdump.
Traffic management ir patikimumo funkcijos
Linkerd suteikia keletą svarbių funkcijų, kurios padeda padidinti jūsų aplikacijų patikimumą. Viena iš jų – automatiniai retry mechanizmai. Kai užklausa nepavyksta dėl laikino tinklo sutrikimo, Linkerd gali automatiškai pakartoti užklausą, nepriversdamas aplikacijos kodo tai daryti.
Timeouts – dar viena svarbi funkcija. Galite apibrėžti maksimalų laiką, kurį užklausa gali trukti, ir Linkerd automatiškai nutrauks per ilgai trunkančias užklausas. Tai padeda išvengti situacijų, kai vienas lėtas servisas „užkabina” visą sistemą.
Load balancing Linkerd yra pažangesnis nei standartinis Kubernetes service load balancing. Linkerd naudoja eksponentinį weighted moving average (EWMA) algoritmą, kuris atsižvelgia ne tik į tai, kiek užklausų gauna kiekvienas pod’as, bet ir kaip greitai jie atsako. Tai reiškia, kad lėtesni pod’ai automatiškai gauna mažiau užklausų, o greitesni – daugiau.
Traffic splitting funkcionalumas leidžia palaipsniui perkelti srautą nuo vienos servisų versijos prie kitos. Tai idealu canary deployments ar A/B testavimui. Pavyzdžiui, galite nukreipti 10% srauto į naują versiją, stebėti metrikos, ir jei viskas gerai, palaipsniui didinti procentą.
Linkerd vs kiti service mesh sprendimai
Negalima kalbėti apie Linkerd neminint jo konkurentų, ypač Istio. Istio yra galingiausias ir labiausiai funkcionalus service mesh sprendimas, bet su tuo ateina ir sudėtingumas. Istio turi šimtus konfigūracijos parametrų, sudėtingą architektūrą ir reikalauja nemažai resursų.
Linkerd filosofija yra priešinga – paprastumas ir efektyvumas. Jei jums reikia 80% service mesh funkcionalumo su 20% sudėtingumo, Linkerd yra puikus pasirinkimas. Jis turi mažiau funkcijų nei Istio, bet tos funkcijos, kurias jis turi, veikia puikiai ir yra lengvai naudojamos.
Kitas populiarus pasirinkimas – Consul Connect. Jis yra geras pasirinkimas, jei jau naudojate HashiCorp ekosistemą, bet Linkerd yra labiau orientuotas į Kubernetes ir paprastesnis įdiegti.
Praktiškai, Linkerd yra puikus pasirinkimas daugumai organizacijų, kurios nori pradėti naudoti service mesh. Jis suteikia pakankamai funkcionalumo daugumui use case’ų, yra lengvai įdiegiamas ir prižiūrimas, ir nesuvartoja daug resursų. Jei vėliau suprasite, kad jums reikia labai specifinių funkcijų, kurias turi tik Istio, migracija yra įmanoma, nors ir nėra trivialu.
Realūs scenarijai ir patarimai iš praktikos
Pradedant naudoti Linkerd, rekomenduoju pradėti nuo ne-production aplinkos. Įdiekite Linkerd savo development ar staging klasteryje ir pabandykite su keliais servisais. Stebėkite, kaip keičiasi resursų suvartojimas, kaip veikia metrikos, kaip atrodo dashboard.
Viena dažna klaida – bandyti iš karto „injektuoti” Linkerd į visus namespace’us. Geriau pradėti palaipsniui. Pasirinkite vieną ar du ne kritiniai servisai, įjunkite Linkerd jiems, ir stebėkite savaitę ar dvi. Kai įsitikinsite, kad viskas veikia gerai, galite plėsti toliau.
Dėl mTLS – nors tai nuostabi funkcija, kartais ji gali sukelti problemų su legacy sistemomis, kurios nesuprato TLS. Linkerd leidžia išjungti mTLS tam tikriems servisams, jei reikia, bet geriau planuoti migraciją taip, kad visos sistemos palaikytų šifruotą komunikaciją.
Monitoring yra kritinis. Įsitikinkite, kad turite Prometheus ir Grafana setup’ą, kuris renka Linkerd metrikos. Nustatykite alertus svarbiems rodikliams – success rate kritimas, latency padidėjimas, proxy restart’ai. Linkerd suteikia daug duomenų, bet jie naudingi tik jei juos aktyviai stebite.
Performance tuning paprastai nereikalingas, bet jei turite labai didelį srautą (tūkstančiai užklausų per sekundę vienam pod’ui), gali tekti pakoreguoti proxy resursų limitus. Linkerd dokumentacija turi gerų rekomendacijų šiuo klausimu.
Ateitis su Linkerd: kas laukia toliau
Linkerd bendruomenė ir maintaineriai nuolat tobulina produktą. Neseniai pridėtos funkcijos, tokios kaip policy framework ir HTTPRoute support, rodo, kad projektas aktyviai vystomas ir seka Kubernetes ekosistemos tendencijas.
Service mesh technologija nėra nauja, bet ji tampa vis brandesnė ir labiau priimta. Linkerd, kaip CNCF graduated projektas, yra saugus pasirinkimas ilgalaikei perspektyvai. Projektas turi stiprią bendruomenę, komercinį palaikymą (nuo Buoyant kompanijos) ir aktyvią plėtrą.
Jei dar nenaudojate service mesh, bet jūsų Kubernetes aplinka auga ir tampa sudėtingesnė, Linkerd yra puikus būdas pradėti. Jis nepervers jūsų architektūros aukštyn kojomis, nesuvartoja per daug resursų ir suteikia realią vertę nuo pirmos dienos – saugumą, observability ir patikimumą.
Pradėkite mažai, mokykitės palaipsniui, ir greitai pamatysite, kaip Linkerd tampa neatsiejama jūsų Kubernetes infrastruktūros dalimi. Service mesh nebėra tik didelių kompanijų privilegija – su Linkerd tai prieinamas ir praktiškas sprendimas bet kokio dydžio organizacijoms.
