Mūsdienu, vispirms mākoņainas lietojumprogrammu izstrāde, vismaz Azure, ir kļuvusi gandrīz atkarīga no Kubernetes. Tādas tehnoloģijas kā Virtual Kubelets, AKS (Azure Kubernetes Service) un Azure Service Fabric Mesh ir galvenās, lai izveidotu mērogojamas izplatītās lietojumprogrammas Azure, izmantojot konteinerus, lai izvietotu un pārvaldītu mikropakalpojumus.
Aplūkojot Azure Kubernetes rīkus, ir skaidrs, ka Microsoft daudz strādā Cloud Native Computing Foundation un ap to, strādājot pie visiem atvērtā pirmkoda ietvara aspektiem. Mums nevajadzētu pārsteigt; Microsoft nolīga vienu no projekta Kubernetes dibinātājiem un pēc tam iegādājās nozīmīgu pārdevēju Deis. Deis komanda ir aiz viena no jaunākajiem Azure ieguldījumiem Kubernetes ekosistēmā - Service Mesh Interface (SMI).
Iepazīstinām ar pakalpojumu tīkliem
Varbūt vislabāk ir vispirms izskaidrot, kas ir pakalpojumu siets un kāpēc tas ir svarīgi jebkurai Kubernetes balstītai lietojumprogrammai.
Mūsdienu IT arhitektūras pamatā ir abstrakcija. Izmantojot mākoņpakalpojumus, mums vairs nav jādomā par pamata aparatūru. Ja izmantojam IaaS, koda mitināšanai definējam virtuālās mašīnas. Izmantojot PaaS, mēs atrodamies vēl tālāk no aparatūras, izmantojot izvēlētos pakalpojumus un API, izvēloties atbilstošu veiktspējas līmeni mūsu lietojumprogrammām un budžetam. Ar konteineriem balstītām arhitektūrām, piemēram, Kubernetes, mēs atrodamies kaut kur starp abiem: izmantojot tādus pakalpojumus kā AKS, mēs varam definēt pamatā esošās virtuālās mašīnas, kuras pēc tam mitina mūsu konteineru pākstis un palielinās, mainoties skaitļošanai un atmiņai (un tagad ar KEDA (uz Kubernetes balstītu notikumu virzītu autoskalēšanu), saņemot notikumus).
Tas ir tikai viens abstrakcijas aspekts. Kubernetes mikropakalpojumi savā sirdī ir bezvalstnieki; viņi izmanto ārējo atmiņu un sēž virsū fiziskajiem vai virtuālajiem tīkliem. Iespējams, ka visgrūtākais ir Kubernetes palaišanas tīkla aspekts: pakalpojumiem paplašinoties un samazinoties, jums ir jāpārveido tīkls, lai tas atbilstu jūsu lietojumprogrammas izmaiņām. Bet kā uzturēt savienojumus pakalpojumos, kad lietojumprogrammas priekšējā un aizmugurējā daļa var tikt mērogota ar atšķirīgu ātrumu?
Tieši šeit parādās servisa tīkli. Tie ir jauns abstrakcijas slānis, kas paceļ jūsu kodu prom no pamata tīkla, izmantojot mūsdienu programmatūras definēta tīkla iespējas. Darbojoties kā tīkla starpniekserveru kopa, kas tiek izvietots kopā ar jūsu kodu, pakalpojumu siets pārvalda pakalpojumu savstarpēju saziņu bez jūsu koda nepieciešamības apzināties pamata tīklu. Pakalpojuma sietu varat uzskatīt par automatizētu vadības plakni lietojumprogrammas tīklā, pārvaldot pamata vadības plakni, kad Kubernetes maina jūsu kodu uz augšu un uz leju.
Programmatūras noteikts tīkls mikropakalpojumiem
Varbūt vislabāk ir domāts par veidu, kā līdzās pakalpojuma atrašanai ieviest viedu, ar latentumu apzinātu, mērogojamu slodzes līdzsvarošanu, pakalpojuma siets būtībā ir izplatīts maršrutētājs ar dinamiskiem maršrutēšanas noteikumiem, kas tiek pārvaldīti kā daļa no Kubernetes izvietošanas. Jūs varat definēt papildu noteikumus; piemēram, ražošanas un testēšanas sistēmu nodalīšana vai jauna laidiena izvietošanas un konteinera versiju maiņas apstrāde. Katrai lietojumprogrammas pākšai ir tīkla sieta eksemplārs, kas darbojas kā blakusvāģis, ar pakalpojuma atrašanu un citiem stāvokļa elementiem, kas darbojas ārpus jūsu pakalpojumiem.
Izmantojot pakalpojumu sietu, jūs ievietojat inteliģenci jaunā tīkla slānī, tāpēc jums tas nav jāievieto mikropakalpojumos. Jāšifrē savienojums? Tas ir darbs jūsu tīkla tīklam. Nepieciešams autorizēt klientus? Vēl viens uzdevums servisa tīklam.
Pārāk daudz acu
Kubernetes izvietošanas apvienošana ar pakalpojumu sietu ir ļoti jēgpilna. Tomēr ir vēl viena liela problēma: kuru jūs izmantojat? Sūtnis? Istio? Linkerd? Apses acs? Ja jūs izvēlējāties vienu, kas var liegt citas biznesa daļas attīstības komandai izvēlēties citu? Tad kas notiek, ja jūsu uzņēmums nolemj standartizēt konkrētā platformā?
Tā ir problēma, kuru Microsoft plāno atrisināt, izmantojot pakalpojumu tīkla saskarni. Tā vietā, lai katram pakalpojumu tīklam būtu savs API kopums, SMI ir veids, kā ieviest kopīgas API, kas darbojas dažādos pakalpojumu tīklos, pārvaldot šo jauno viedo tīklu. Tā vietā, lai bloķētu kodu noteiktā pakalpojumu sietā un tā API, jūs varat ierakstīt kodu, kas adresēts visbiežāk izmantotajiem gadījumiem, izmantojot kopēju API. Ja jums ir nepieciešams nomainīt pakalpojumu sietu - ja maināt pakalpojumu sniedzēju vai atrodat kādu, kas darbojas labāk, kods nav jāmaina, ja vien tīkla siets ievieš SMI. Viss, kas jums jādara, ir mainīt servisa tīkla blakusvāģus un pārvietot kodu.
SMI: kopīgas pakalpojumu tīkla API
Sadarbojoties ar tādiem Kubernetes ekosistēmas uzņēmumiem kā Hashicorp un Buoyant, Microsoft ir definējis galvenās SMI funkcijas, kas atbalsta kopīgus klientu pieprasījumus. Sākotnējā izlaidumā tā ir koncentrējusies uz trim jomām: satiksmes politikai, satiksmes telemetrijai un satiksmes pārvaldībai. Šīs trīs jomas kontrolē lielākā daļa pakalpojumu sietu, un to mērķis ir padarīt šo specifikāciju, kuru ir viegli ieviest, nemainot pamatā esošo lietojumprogrammu.
Padarot SMI par standarta API kopu, nekas neliedz pakalpojumu tīkla piegādātājiem turpināt piedāvāt savus API vai papildu funkcijas ārpus norādītajām. Alternatīvi viņiem nav jāveic nekādas izmaiņas; trešās puses var izveidot tulkošanas slāņus, kas atrodas starp SMI API un patentētu pakalpojumu API. Jums arī nebūs nepieciešama jauna Kubernetes versija, jo SMI API tiek ieviesti kā paplašinājumu API serveri un pielāgotu resursu definīcijas. Varat turpināt un instalēt tos jebkurā klasterī, izmantojot esošos pārvaldības rīkus. Tam vajadzētu atvieglot SMI Azure un citiem mākoņos mitinātiem Kubernetes pakalpojumiem, lai tos integrētu esošajos pārvaldītajos Kubernetes pakalpojumos.
Neatkarīgi no tā, vai vēlaties izmantot Linkerd vai Aspen Mesh, vai VMware NSX Service Mesh, ar SMI varēsiet izvēlēties sev vēlamo, uzlabojot koda pārnesamību un izvairoties no piekļuves noteiktiem mākoņpakalpojumiem. Tad ir iespēja mainīt servisa tīklus, neietekmējot kodu. Ja jauns servisa siets piedāvā labāku veiktspēju, viss, kas jums jādara, ir mainīt būvēšanas cauruļvadu, lai izmantotu jauno sietu, un pēc tam izvietot atjauninātu lietojumprogrammu.
Ir interesanti redzēt, kā Microsoft uzņemas vadību šāda veida projektā, strādājot ar plašu Kubernetes kopienas šķērsgriezumu. Izmantojot pieeju, kas nepārprotami nav vērsta uz pakalpojumu tīkla izveidošanu, Azure var piedāvāt dažādas pakalpojumu sietas kā daļu no AKS konfigurēšanas, ļaujot jums izvēlēties vajadzīgo rīku, nemainot kodu.
