Moderne, sky-første applikasjonsutvikling, i det minste på Azure, har blitt nesten avhengig av Kubernetes. Teknologier som Virtual Kubelets, AKS (Azure Kubernetes Service) og Azure Service Fabric Mesh er nøkkelen til å bygge skalerbare distribuerte applikasjoner på Azure, ved hjelp av containere for å distribuere og administrere mikrotjenester.
Ser vi på Azure's Kubernetes-verktøy, er det tydelig at Microsoft gjør mye arbeid i og rundt Cloud Native Computing Foundation, og jobber med alle aspekter av open source-rammeverket. Vi skal ikke bli overrasket; Microsoft hyret en av grunnleggerne av Kubernetes-prosjektet og kjøpte Deis, en betydelig leverandør. Deis-teamet står bak et av de siste Azure-bidragene til Kubernetes-økosystemet, Service Mesh Interface (SMI).
Vi presenterer servicemasker
Det er kanskje best å først forklare hva et servicenett er og hvorfor det er viktig for alle Kubernetes-baserte applikasjoner.
Moderne IT-arkitekturer handler om abstraksjon. Med skytjenester trenger vi ikke lenger å tenke på den underliggende maskinvaren. Hvis vi bruker IaaS, definerer vi virtuelle maskiner for å være vert for koden vår. Med PaaS er vi enda lenger unna maskinvaren, ved å bruke tjenestene og API-ene vi valgte, og velge et passende ytelsesnivå for våre applikasjoner og budsjetter. Med containerbaserte arkitekturer som Kubernetes, er vi på et punkt et sted mellom de to: ved hjelp av tjenester som AKS kan vi definere de underliggende virtuelle maskiner, som deretter er vert for containerpodene våre og skalerer ut med endringer i beregning og minne (og nå med KEDA (Kubernetes-basert hendelsesdrevet autoskalering), etter mottak av hendelser).
Det er bare ett aspekt av abstraksjonen. Kubernetes mikrotjenester er, i hjertet, statsløse; de bruker ekstern lagring og sitter på toppen av enten fysiske eller virtuelle nettverk. Det er nettverksaspektet ved å kjøre Kubernetes som sannsynligvis er det vanskeligste: Når tjenester skaleres ut og skaleres ned, må du endre nettverket for å matche endringene i applikasjonen din. Men hvordan holder du tjenester tilkoblet når en applikasjons frontend og back-end kan skaleres med forskjellige hastigheter?
Det er her servicemasker kommer inn. De er et nytt abstraksjonslag, et som løfter koden din bort fra det underliggende nettverket ved å utnytte mulighetene til et moderne programvaredefinert nettverk. Ved å fungere som et sett med nettverksproxyer som er distribuert med koden din, administrerer et servicenett tjeneste-til-tjeneste-kommunikasjon uten at koden din trenger noe bevissthet om det underliggende nettverket. Du kan tenke på et servicenett som et automatisert kontrollplan for applikasjonens nettverk, og administrere det underliggende kontrollplanet mens Kubernetes skalerer koden din opp og ned.
Et programvaredefinert nettverk for mikrotjenester
Kanskje best tenkt som en måte å implementere smart, ventetid-bevisst, skalerbar belastningsbalansering sammen med tjenesteoppdagelse, er et servicenett i utgangspunktet en distribuert ruter med dynamiske rutingsregler som administreres som en del av en Kubernetes-distribusjon. Du kan definere flere regler; for eksempel å holde produksjons- og testsystemer atskilt, eller håndtere en distribusjon av en ny utgivelse og skiftet mellom containerversjoner. Hver pod i et program har en service mesh-forekomst som kjører som en sidevogn, med serviceoppdagelse og andre stateful-elementer som kjører utenfor tjenestene dine.
Med et servicenett skyver du intelligens inn i et nytt nettverkslag, slik at du ikke trenger å legge det inn i mikrotjenestene dine. Trenger du å kryptere en forbindelse? Det er en jobb for servicenettet ditt. Trenger du å autorisere klienter? En annen oppgave for servicenettet.
For mange masker
Å kombinere en Kubernetes-distribusjon med et servicenett gir mye mening. Imidlertid er det ett stort problem til: hvilken bruker du? Utsending? Istio? Linkerd? Aspen Mesh? Hvis du valgte en, hva skal da hindre et utviklingsteam i en annen del av virksomheten din i å velge en annen? Hva skjer så hvis firmaet ditt bestemmer seg for å standardisere på en bestemt plattform?
Det er problemet Microsoft legger opp til å løse med Service Mesh Interface. I stedet for at hvert servicenett har sitt eget sett med API-er, er SMI en måte å implementere vanlige API-er som fungerer på tvers av forskjellige servicenettverk, og administrere det nye smarte nettverket. I stedet for å låse koden din i et bestemt servicenettverk og dens APIer, kan du skrive kode som adresserer de vanligste brukssakene via en felles API. Hvis du trenger å bytte ut et servicenett - hvis du bytter leverandør eller finner en som fungerer bedre - er det ikke nødvendig å endre koden din, så lenge servicenettet implementerer SMI. Alt du trenger å gjøre er å endre sidevognene dine i servicenettverket og distribuere koden på nytt.
SMI: felles servicenett-APIer
I samarbeid med Kubernetes-økosystembedrifter som Hashicorp og Buoyant har Microsoft definert de viktigste funksjonene for SMI som støtter vanlige forespørsler fra sine kunder. I den første utgivelsen har den fokusert på tre områder: trafikkpolitikk, trafikktelemetri og trafikkstyring. Disse tre områdene styres av de fleste servicemasker, og intensjonen er å gjøre dette til en spesifikasjon som er enkel å implementere uten å endre den underliggende applikasjonen.
Ved å gjøre SMI til et sett med standard APIer, er det ingenting som hindrer leverandører av servicenettverk i å fortsette å tilby sine egne APIer eller tilleggsfunksjoner utenfor de spesifiserte. Alternativt trenger de ikke gjøre noen endringer; tredjeparter kan bygge oversettelseslag som sitter mellom SMI APIer og proprietære service APIer. Du trenger heller ikke en ny versjon av Kubernetes, siden SMI API-er er implementert som API-servere for utvidelser og egendefinerte ressursdefinisjoner. Du kan fortsette og installere dem i hvilken som helst klynge ved hjelp av eksisterende administrasjonsverktøy. Det burde gjøre SMI enkelt for Azure og andre sky-hostede Kubernetes-tjenester å bygge dem inn i deres eksisterende administrerte Kubernetes-tjenester.
Enten du vil bruke Linkerd eller Aspen Mesh eller VMwares NSX Service Mesh, med SMI vil du kunne velge den du foretrekker, forbedre kodeportabilitet og unngå innlåsing til spesifikke skytjenester. Deretter er det muligheten til å bytte servicenett uten å påvirke koden din. Hvis et nytt servicenett gir bedre ytelse, er alt du trenger å endre bygningsrørledningen for å bruke det nye nettet og deretter distribuere et oppdatert program.
Det er interessant å se Microsoft ta ledelsen på et prosjekt som dette, og jobbe med et bredt tverrsnitt av Kubernetes-samfunnet. Ved å ta en tilnærming som eksplisitt ikke er fokusert på å bygge et servicenett, kan Azure tilby forskjellige servicenett som en del av å konfigurere AKS, slik at du kan velge verktøyet du vil ha uten å måtte endre noen kode.
