Šiuolaikinė, pirmiausia debesų programa, bent jau „Azure“, tapo beveik priklausoma nuo „Kubernetes“. Tokios technologijos, kaip „Virtual Kubelets“, AKS („Azure Kubernetes Service“) ir „Azure Service Fabric Mesh“, yra raktas kuriant išplečiamąsias paskirstomas programas „Azure“, naudojant konteinerius diegiant ir tvarkant mikroservisus.
Žvelgiant į „Azure“ „Kubernetes“ įrankius, akivaizdu, kad „Microsoft“ daug dirba „Cloud Native Computing Foundation“ ir aplink jį, dirbdama su visais atvirojo kodo sistemos aspektais. Neturėtume nustebti; „Microsoft“ pasamdė vieną iš „Kubernetes“ projekto įkūrėjų, o tada įsigijo reikšmingą pardavėją „Deis“. „Deis“ komanda yra viena iš naujausių „Azure“ įnašų į „Kubernetes“ ekosistemą - „Service Mesh Interface“ (SMI).
Pristatome paslaugų tinklus
Galbūt geriausia pirmiausia paaiškinti, kas yra paslaugų tinklas ir kodėl tai svarbu bet kuriai „Kubernetes“ pagrįstai programai.
Šiuolaikinės IT architektūros yra susijusios su abstrakcija. Naudodamiesi debesų paslaugomis, mums nebereikia galvoti apie pagrindinę techninę įrangą. Jei mes naudojame „IaaS“, mes nustatome virtualias mašinas, kad būtų galima laikyti mūsų kodą. Naudodamiesi „PaaS“, mes dar labiau nutolome nuo aparatinės įrangos, naudojame pasirinktas paslaugas ir API ir pasirenkame tinkamą programų ir biudžeto našumo lygį. Naudodami konteinerių architektūras, tokias kaip „Kubernetes“, mes esame taške tarp dviejų: naudodamiesi tokiomis paslaugomis kaip AKS, mes galime apibrėžti pagrindines virtualias mašinas, kurios vėliau talpina mūsų konteinerių dėžutes ir keičiasi skaičiuojant bei keičiant atmintį (ir dabar su KEDA („Kubernetes“ pagrįstas įvykių valdomas automatinis mastelis), gavus įvykius).
Tai tik vienas abstrakcijos aspektas. „Kubernetes“ mikro paslaugos yra širdyje be pilietybės; jie naudoja išorinę saugyklą ir sėdi ant fizinių ar virtualių tinklų. Ko gero, pats kebliausias yra „Kubernetes“ paleidimo tinklo aspektas: kai paslaugos plečiasi ir mažėja, turite modifikuoti savo tinklą, kad jis atitiktų jūsų programos pakeitimus. Bet kaip palaikyti paslaugas, kai programos priekinė ir galinė dalys keičiasi skirtingais tempais?
Štai kur atsiranda paslaugų tinklai. Tai naujas abstrakcijos sluoksnis, kuris pakelia jūsų kodą nuo pagrindinio tinklo, pasinaudodamas šiuolaikinio programinės įrangos apibrėžto tinklo galimybėmis. Veikdama kaip tinklo tarpinių serverių rinkinys, kuris yra įdiegtas kartu su jūsų kodu, paslaugų tinklas valdo ryšį tarp paslaugų ir paslaugų, jūsų kodui nereikia žinoti apie pagrindinį tinklą. Galite galvoti apie tinklo tinklą kaip automatizuotą valdymo plokštumą savo programos tinklui valdyti pagrindinę valdymo plokštumą, kai „Kubernetes“ keičia jūsų kodą aukštyn ir žemyn.
Programinės įrangos apibrėžtas tinklas, skirtas mikropaslaugoms
Ko gero, geriausia pagalvoti apie būdą, kaip kartu su paslaugų atradimu įdiegti protingą, delspinigius suvokiantį, keičiamo dydžio apkrovos balansavimą, paslaugų tinklas iš esmės yra paskirstytasis maršrutizatorius su dinaminėmis maršruto parinkimo taisyklėmis, kurios yra valdomos kaip „Kubernetes“ diegimo dalis. Galite apibrėžti papildomas taisykles; pavyzdžiui, atskirti gamybos ir bandymo sistemas arba tvarkyti naujo leidimo diegimą ir keitimą tarp konteinerio versijų. Kiekvienoje programos dėžutėje yra tinklo tinklo egzempliorius, veikiantis kaip šalutinis automobilis, o paslaugų atradimas ir kiti būsenos elementai veikia ne jūsų paslaugose.
Naudodamiesi tinklo tinklu, jūs įstumiate intelektą į naują tinklo sluoksnį, todėl jums nereikės jo dėti į savo mikro paslaugas. Reikia užšifruoti ryšį? Tai jūsų paslaugų tinklo darbas. Reikia įgalioti klientus? Kita tarnybinio tinklo užduotis.
Per daug akių
„Kubernetes“ diegimą su paslaugų tinklu derinti yra labai prasminga. Tačiau yra dar viena didelė problema: kurią naudojate? Pasiuntinys? Istio? Linkerd? Drebulės tinklelis? Jei pasirinkote vieną, kas gali sustabdyti kitos verslo dalies vystymo komandą rinktis kitą? Tada kas nutiks, jei jūsų įmonė nuspręs standartizuoti pagal konkrečią platformą?
Tai problema, kurią „Microsoft“ ketina išspręsti naudodama „Service Mesh“ sąsają. Vietoj to, kad kiekvienas paslaugų tinklas turėtų savo API rinkinį, SMI yra būdas įdiegti bendras API, kurios veikia skirtingose paslaugų tinkluose, valdydamos tą naują išmanųjį tinklą. Užuot užrakinę kodą konkrečiame paslaugų tinkle ir jo API, galite parašyti kodą, kuris nukreipia dažniausiai naudojamus atvejus per bendrą API. Jei reikia pakeisti paslaugų tinklą - jei pakeisite paslaugų teikėją arba rasite tokį, kuris veikia geriau - nereikia keisti kodo, jei paslaugų tinklas įdiegia SMI. Viskas, ką jums reikia padaryti, tai pakeisti savo tinklo tinklo šonines priekabas ir perdaryti kodą.
SMI: bendrosios tinklo tinklo API
Dirbdama su „Kubernetes“ ekosistemos įmonėmis, tokiomis kaip „Hashicorp“ ir „Buoyant“, „Microsoft“ apibrėžė pagrindines SMI funkcijas, palaikančias įprastus klientų prašymus. Pradiniame leidinyje jis sutelkė dėmesį į tris sritis: eismo politiką, eismo telemetriją ir eismo valdymą. Šias tris sritis valdo dauguma paslaugų tinklų, todėl ketinama padaryti tai specifikaciją, kurią būtų lengva įgyvendinti nekeičiant pagrindinės programos.
Padarius SMI standartinių API rinkiniu, niekas netrukdo paslaugų tinklo tinklų tiekėjams toliau siūlyti savo API ar papildomas funkcijas, nenurodytas nurodytose. Arba jiems nereikia daryti jokių pakeitimų; trečiosios šalys gali sukurti vertimo sluoksnius, esančius tarp SMI API ir patentuotų paslaugų API. Jums taip pat nereikės naujos „Kubernetes“ versijos, nes SMI API yra įdiegtos kaip plėtinių API serveriai ir tinkinti išteklių apibrėžimai. Galite tęsti ir įdiegti juos į bet kurį klasterį naudodami esamus valdymo įrankius. Tai turėtų palengvinti SMI „Azure“ ir kitoms debesyse priglobtoms „Kubernetes“ tarnyboms jas integruoti į esamas valdomas „Kubernetes“ paslaugas.
Nesvarbu, ar norite naudoti „Linkerd“, „Aspen Mesh“, ar „VMware“ „NSX Service Mesh“, su SMI galėsite pasirinkti tą, kurį norite, pagerindami kodo perkeliamumą ir išvengdami užrakinimo prie konkrečių debesų paslaugų. Tada yra galimybė pakeisti paslaugų tinklus nepaveikiant jūsų kodo. Jei naujas paslaugų tinklas siūlo geresnį našumą, viskas, ką jums reikia padaryti, tai pakeisti savo statybos vamzdyną, kad būtų naudojamas naujas tinklelis, ir tada įdiegti atnaujintą programą.
Įdomu matyti, kaip „Microsoft“ imasi vadovauti tokiam projektui, dirbdama su plačiu „Kubernetes“ bendruomenės skerspjūviu. Laikydamasi požiūrio, kuris nėra aiškiai orientuotas į paslaugų tinklo kūrimą, „Azure“ gali pasiūlyti skirtingas paslaugų tinklelius kaip AKS konfigūravimo dalį, leidžiantį pasirinkti norimą įrankį nereikalaujant keisti jokio kodo.
