Moderni, pilvi ensin -sovelluskehitys, ainakin Azuresta, on tullut melkein riippuvaiseksi Kubernetesista. Teknologiat, kuten Virtual Kubelets, AKS (Azure Kubernetes Service) ja Azure Service Fabric Mesh, ovat avain skaalautuvien hajautettujen sovellusten rakentamiseen Azureen käyttämällä säiliöitä mikropalvelujen käyttöönottoon ja hallintaan.
Azuren Kubernetes-työkaluja tarkasteltaessa on selvää, että Microsoft tekee paljon työtä Cloud Native Computing Foundation -säätiössä ja sen ympäristössä työskentelemällä avoimen lähdekoodin kehyksen kaikilla osa-alueilla. Meidän ei pitäisi olla yllättyneitä; Microsoft palkkasi yhden Kubernetes-projektin perustajista ja osti sitten Deisen, merkittävän toimittajan. Deis-tiimi on yksi viimeisimmistä Azure-julkaisuista Kubernetes-ekosysteemissä, Service Mesh Interface (SMI).
Esittelyssä palveluverkot
On ehkä parasta selittää ensin, mikä palveluverkko on ja miksi se on tärkeää mille tahansa Kubernetes-pohjaiselle sovellukselle.
Nykyaikaiset IT-arkkitehtuurit ovat kaikki abstraktiota. Pilvipalveluiden kanssa meidän ei enää tarvitse ajatella taustalla olevaa laitteistoa. Jos käytämme IaaS: ää, määritämme virtuaalikoneet koodin isännöimiseksi. PaaS: n avulla olemme vielä kauempana laitteistosta, valitsemiemme palveluiden ja sovellusliittymien avulla ja valitsemme sopivan suorituskyvyn sovelluksillemme ja budjeteillemme. Konttipohjaisilla arkkitehtuureilla, kuten Kubernetes, olemme pisteessä jossakin näiden kahden välissä: käyttämällä AKS: n kaltaisia palveluja voimme määritellä taustalla olevat virtuaalikoneet, jotka sitten isännöivät konttipokkejamme ja laajentuvat muutoksilla laskennassa ja muistissa (ja nyt KEDA: lla (Kubernetes-pohjainen tapahtumapohjainen automaattinen skaalaus) tapahtumien vastaanottamisen yhteydessä).
Se on vain yksi abstraktio-osa. Kubernetes-mikropalvelut ovat sydämessään valtiottomia; he käyttävät ulkoista tallennustilaa ja istuvat joko fyysisten tai virtuaalisten verkkojen päällä. Se on luultavasti kaikkein hankalin Kubernetesin suorittamisen verkko-osa: Kun palvelut laajenevat ja pienenevät, sinun on muokattava verkkoasi vastaamaan sovelluksesi muutoksia. Mutta miten pidät palvelut yhdistettyinä, kun sovelluksen käyttöliittymä ja takapää voivat skaalata eri nopeuksilla?
Siellä palveluverkot tulevat sisään. Ne ovat uusi abstraktiokerros, joka nostaa koodisi pois alla olevasta verkosta hyödyntämällä nykyaikaisen ohjelmistomääritetyn verkon ominaisuuksia. Toimimalla koodin kanssa käyttöönotettujen verkkovälityspalvelimien joukona palveluverkko hallitsee palveluiden välistä viestintää ilman, että koodisi tarvitsee tietoisuutta taustalla olevasta verkosta. Voit ajatella palveluverkkoa automaattisena ohjaustasona sovelluksesi verkostoitumiseen ja hallita taustalla olevaa ohjaustasoa, kun Kubernetes skaalaa koodiasi ylös ja alas.
Ohjelmiston määrittämä verkko mikropalveluille
Ehkä paras ajatus tapa toteuttaa älykäs, viivästystietoinen, skaalautuva kuormituksen tasapainottaminen palvelun löytämisen rinnalla, palveluverkko on pohjimmiltaan hajautettu reititin, jossa on dynaamisia reitityssääntöjä, joita hallitaan osana Kubernetes-käyttöönottoa. Voit määrittää muita sääntöjä; Esimerkiksi tuotanto- ja testausjärjestelmien pitäminen erillään tai uuden julkaisun käyttöönoton ja konttiversioiden vaihdon käsittely. Jokaisessa sovelluksen podissa on palveluverkko-ilmentymä, joka toimii sivuvaununa, palveluiden etsinnän ja muiden tilanmukaisten elementtien kanssa palvelujen ulkopuolella.
Palveluverkolla työnnät älykkyyttä uuteen verkkokerrokseen, joten sinun ei tarvitse laittaa sitä mikropalveluihisi. Tarvitseeko yhteys salata? Se on työ palveluverkollesi. Tarvitseeko valtuuttaa asiakkaita? Toinen tehtävä palveluverkolle.
Liian monta silmää
Kubernetes-käyttöönoton yhdistäminen palveluverkkoon on paljon järkevää. On kuitenkin vielä yksi iso ongelma: mitä käytät? Lähettiläs? Istio? Linkerd? Haapa Mesh? Jos valitset yhden, mikä estää yrityksesi toisen osan kehitystiimin valitsemasta toista? Mitä sitten tapahtuu, jos yrityksesi päättää standardisoida tietylle alustalle?
Tämä on ongelma, jonka Microsoft aikoo ratkaista Service Mesh -rajapinnalla. Sen sijaan, että jokaisella palveluverkolla olisi oma joukko sovellusliittymiä, SMI on tapa toteuttaa yleisiä sovellusliittymiä, jotka toimivat eri palveluverkkoissa ja hallita uutta älyverkkoa. Sen sijaan, että lukitsisit koodin tiettyyn palveluverkkoon ja sen sovellusliittymiin, voit kirjoittaa koodin, joka käsittelee yleisimmät käyttötapaukset yhteisen sovellusliittymän kautta. Jos sinun on vaihdettava palveluverkko - jos vaihdat palveluntarjoajaa tai löydät toimivan paremmin - koodiasi ei tarvitse muuttaa, kunhan palveluverkko toteuttaa SMI: n. Sinun tarvitsee vain vaihtaa palveluverkon sivuvaunut ja sijoittaa koodisi uudelleen.
SMI: yhteiset palveluverkon sovellusliittymät
Yhteistyössä Kubernetes-ekosysteemiyritysten, kuten Hashicorpin ja Buoyantin kanssa, Microsoft on määritellyt SMI: n tärkeimmät ominaisuudet, jotka tukevat asiakkaiden yleisiä pyyntöjä. Alkuperäisessä julkaisussa se on keskittynyt kolmeen alueeseen: liikennepolitiikkaan, liikenteen telemetriaan ja liikenteen hallintaan. Näitä kolmea aluetta hallitsee useimmat palveluverkot, ja tarkoituksena on tehdä tästä eritelmä, joka on helppo toteuttaa muuttamatta taustalla olevaa sovellusta.
Tekemällä SMI: stä vakiosovellusliittymien joukko, mikään ei estä palveluverkon toimittajia jatkamasta omien sovellusliittymien tai lisäominaisuuksien tarjoamista määriteltyjen ulkopuolella. Vaihtoehtoisesti heidän ei tarvitse tehdä muutoksia; kolmannet osapuolet voivat rakentaa käännöskerroksia, jotka sijaitsevat SMI-sovellusliittymien ja omistettujen palvelujen sovellusliittymien välillä. Et tarvitse myöskään uutta Kubernetes-versiota, koska SMI-sovellusliittymät toteutetaan laajennus-API-palvelimina ja mukautetuina resurssimääritelminä. Voit mennä eteenpäin ja asentaa ne mihin tahansa klusteriin olemassa olevien hallintatyökalujen avulla. Sen pitäisi tehdä SMI: stä Azurelle ja muille pilvi-isännöimille Kubernetes-palveluille helppo rakentaa ne nykyisiin hallittuihin Kubernetes-palveluihin.
Halusitpa käyttää Linkerdiä, Aspen Meshiä tai VMwaren NSX Service Meshiä, SMI: n avulla voit valita haluamasi, parantaa koodin siirrettävyyttä ja välttää lukittumista tiettyihin pilvipalveluihin. Sitten on mahdollisuus vaihtaa palveluverkkoja vaikuttamatta koodiin. Jos uusi palveluverkko tarjoaa paremman suorituskyvyn, sinun tarvitsee vain vaihtaa rakenneputkisi käyttämään uutta verkkoa ja ottaa sitten käyttöön päivitetty sovellus.
On mielenkiintoista nähdä, kuinka Microsoft ottaa johtoaseman tällaisessa projektissa, joka työskentelee laajalla Kubernetes-yhteisön poikkileikkauksella. Asemalla lähestymistapa, joka ei ole nimenomaisesti keskittynyt palveluverkon rakentamiseen, Azure voi tarjota erilaisia palveluverkkoja osana AKS: n määritystä, jolloin voit valita haluamasi työkalun tarvitsematta muuttaa mitään koodia.
