Sodoben razvoj aplikacij, prvi v oblaku, je vsaj na Azureju postal skoraj odvisen od Kubernetesa. Tehnologije, kot so navidezni kubeleti, AKS (Azure Kubernetes Service) in Azure Service Fabric Mesh, so ključne za gradnjo razširljivih porazdeljenih aplikacij v Azureju z uporabo vsebnikov za razmestitev in upravljanje mikro storitev.
Če pogledamo Azureova orodja Kubernetes, je jasno, da Microsoft veliko dela v in okoli Cloud Native Computing Foundation in dela na vseh vidikih odprtokodnega okvira. Ne bi smeli biti presenečeni; Microsoft je najel enega od ustanoviteljev projekta Kubernetes in nato prevzel Deis, pomembnega prodajalca. Skupina Deis stoji za enim najnovejših prispevkov Azure za ekosistem Kubernetes, vmesnikom storitvenih mrež (SMI).
Predstavljamo servisne mreže
Morda je najbolje, da najprej razložite, kaj je servisna mreža in zakaj je to pomembno za katero koli aplikacijo, ki temelji na Kubernetesu.
Sodobne IT arhitekture se ukvarjajo z abstrakcijo. Pri storitvah v oblaku ni več treba razmišljati o osnovni strojni opremi. Če uporabljamo IaaS, določimo navidezne stroje za gostovanje naše kode. S PaaS smo še bolj oddaljeni od strojne opreme, uporabljamo storitve in API-je, ki smo jih izbrali, in izberemo ustrezno raven zmogljivosti za naše aplikacije in proračune. Z arhitekturami, ki temeljijo na vsebnikih, kot je Kubernetes, smo nekje vmes med obema: z uporabo storitev, kot je AKS, lahko definiramo osnovne virtualne stroje, ki nato gostijo naše vsebnike in se spreminjajo s spremembami v računih in pomnilniku zdaj s KEDA (samodejno skaliranje na osnovi dogodkov, ki temelji na Kubernetesu), ob prejemu dogodkov).
To je samo en vidik abstrakcije. Mikroservice Kubernetes so po duši brez državljanstva; uporabljajo zunanji pomnilnik in sedijo na fizičnem ali navideznem omrežju. Verjetno je najbolj zapleten mrežni vidik delovanja Kubernetesa: ko se storitve razširjajo in zmanjšujejo, morate spremeniti svoje omrežje, da se prilagodi spremembam v vaši aplikaciji. Kako pa ohranjate povezavo med storitvami, če se prednji in zadnji del aplikacije spreminjata z različnimi hitrostmi?
Tu pridejo servisne mreže. So nova plast abstrakcije, ki vašo kodo oddalji od osnovnega omrežja z izkoriščanjem zmogljivosti sodobnega programsko opredeljenega omrežja. Z delovanjem kot nabora omrežnih strežnikov, ki so nameščeni z vašo kodo, servisna mreža upravlja komunikacijo med storitvami, ne da bi vaša koda potrebovala zavedanje o osnovnem omrežju. Storitveno mrežo lahko predstavljate kot avtomatizirano krmilno ravnino za mreženje vaše aplikacije, ki upravlja osnovno ravnino nadzora, ko Kubernetes lestvico spreminja navzgor in navzdol.
Programsko definirano omrežje za mikro storitve
Morda je najbolje mišljeno kot način za izvajanje pametnega, zakasnitvenega, prilagodljivega uravnoteženja obremenitve ob odkrivanju storitev, servisna mreža je v bistvu porazdeljeni usmerjevalnik s pravili dinamičnega usmerjanja, ki se upravljajo kot del uvajanja Kubernetesa. Določite lahko dodatna pravila; na primer ločevanje proizvodnih in preskusnih sistemov ali ravnanje z uvedbo nove izdaje in prehodom med različicami vsebnika. Vsak pod v aplikaciji ima primerek storitvene mreže, ki se izvaja kot stranska prikolica, z odkrivanjem storitev in drugimi elementi s stanjem, ki se izvajajo zunaj vaših storitev.
S storilno mrežo potisnete inteligenco v novo omrežno plast, zato vam je ni treba vnašati v svoje mikro storitve. Ali želite šifrirati povezavo? To je naloga za vašo servisno mrežo. Morate pooblastiti stranke? Druga naloga servisne mreže.
Preveč očes
Kombinacija uvajanja Kubernetesa s servisno mrežo je zelo smiselna. Vendar pa obstaja še en velik problem: katerega uporabite? Odposlanec? Istio? Linkerd? Aspen Mesh? Če ste izbrali enega, kaj lahko razvojno skupino v drugem delu vašega podjetja ustavi pred izbiro drugega? Kaj se potem zgodi, če se vaše podjetje odloči za standardizacijo na določeni platformi?
To je težava, ki si jo Microsoft želi rešiti z vmesnikom Service Mesh. Namesto da ima vsaka servisna mreža svoj nabor API-jev, je SMI način za izvajanje skupnih API-jev, ki delujejo v različnih servisnih mrežah, in upravlja to novo pametno omrežje. Namesto da zaklenete kodo v določeno servisno mrežo in njene API-je, lahko preko običajnega API-ja napišete kodo, ki naslavlja najpogostejše primere uporabe. Če morate zamenjati servisno mrežo - če zamenjate ponudnika ali najdete tistega, ki deluje bolje - vaše kode ni treba spremeniti, če storitvena mreža izvaja SMI. Vse, kar morate storiti, je, da spremenite stranske vozičke mreže storitev in prerazporedite kodo.
SMI: običajni API-ji za mrežne storitve
Microsoft je v sodelovanju s podjetji Kubernetes-ekosistema, kot sta Hashicorp in Buoyant, opredelil ključne značilnosti SMI, ki podpirajo pogoste zahteve kupcev. V prvi izdaji se je osredotočil na tri področja: prometno politiko, prometno telemetrijo in upravljanje prometa. Ta tri področja nadzoruje večina mrežnih očes, namen pa je, da to postane specifikacija, ki jo je enostavno uporabiti, ne da bi spremenili osnovno aplikacijo.
Če SMI nastavimo kot nabor standardnih API-jev, prodajalci storitvenih mrež ne preprečujejo, da bi še naprej ponujali lastne API-je ali dodatne funkcije, ki niso navedene. Drugače jim ni treba spreminjati; tretje osebe lahko gradijo sloje prevajanja, ki se nahajajo med API-ji SMI in API-ji lastniške storitve. Tudi nove različice Kubernetesa ne boste potrebovali, saj so API-ji SMI implementirani kot razširitveni strežniki API in definicije virov po meri. Lahko jih namestite v katero koli gručo z uporabo obstoječih orodij za upravljanje. To bi moralo olajšati SMI za Azure in druge storitve Kubernetes, ki jih gosti v oblaku, da jih vgradijo v svoje obstoječe upravljane storitve Kubernetes.
Ne glede na to, ali želite uporabiti Linkerd ali Aspen Mesh ali NSM Service Mesh podjetja VMware, boste s sistemom SMI lahko izbrali tistega, ki vam je ljubši, izboljšati prenosljivost kode in se izogniti zaklepanju določenih oblačnih storitev. Potem obstaja možnost zamenjave servisnih mrež, ne da bi to vplivalo na vašo kodo. Če nova servisna mreža ponuja boljšo zmogljivost, morate samo spremeniti gradbeni cevovod, da bo uporabil novo mrežno mrežo, in nato razviti posodobljeno aplikacijo.
Zanimivo je videti, da je Microsoft prevzel vodilno vlogo pri tovrstnem projektu in sodeloval s širokim prerezom skupnosti Kubernetes. S pristopom, ki izrecno ni osredotočen na ustvarjanje servisne mreže, lahko Azure kot del konfiguriranja AKS ponudi različne servisne mreže, tako da lahko izberete želeno orodje, ne da bi morali spremeniti kodo.
