Moderne, cloud-first applikationsudvikling, i det mindste på Azure, er næsten blevet afhængig af Kubernetes. Teknologier som Virtual Kubelets, AKS (Azure Kubernetes Service) og Azure Service Fabric Mesh er nøglen til at opbygge skalerbare distribuerede applikationer på Azure ved hjælp af containere til at implementere og administrere mikroservices.
Når man ser på Azures Kubernetes-værktøjer, er det klart, at Microsoft gør meget arbejde i og omkring Cloud Native Computing Foundation og arbejder på alle aspekter af open source-rammen. Vi bør ikke blive overrasket; Microsoft hyrede en af grundlæggerne af Kubernetes-projektet og købte derefter Deis, en betydelig leverandør. Deis-teamet står bag et af de seneste Azure-bidrag til Kubernetes-økosystemet, Service Mesh Interface (SMI).
Introduktion til servicemasker
Det er måske bedst først at forklare, hvad et servicenet er, og hvorfor det er vigtigt for enhver Kubernetes-baseret applikation.
Moderne it-arkitekturer handler om abstraktion. Med cloud-tjenester behøver vi ikke længere tænke på den underliggende hardware. Hvis vi bruger IaaS, definerer vi virtuelle maskiner til at være vært for vores kode. Med PaaS er vi endnu længere væk fra hardwaren ved at bruge de tjenester og API'er, vi valgte, og vælge et passende ydeevneniveau til vores applikationer og budgetter. Med containerbaserede arkitekturer som Kubernetes er vi et sted et sted imellem de to: ved hjælp af tjenester som AKS kan vi definere de underliggende virtuelle maskiner, som derefter er vært for vores containerpods og skalerer ud med ændringer i beregning og hukommelse (og nu med KEDA (Kubernetes-baseret begivenhedsdrevet autoskalering), efter modtagelse af begivenheder).
Det er kun et aspekt af abstraktion. Kubernetes mikrotjenester er i bund og grund statsløse; de bruger ekstern lagring og sidder oven på enten fysiske eller virtuelle netværk. Det er netværksaspektet ved at køre Kubernetes, der sandsynligvis er det mest vanskelige: Da tjenester skaleres ud og skaleres ned, skal du ændre dit netværk for at matche ændringerne i din applikation. Men hvordan holder du tjenester tilsluttet, når en applikations frontend og backend kan skaleres med forskellige hastigheder?
Det er her servicemasker kommer ind. De er et nyt abstraktionslag, der løfter din kode væk fra det underliggende netværk ved at udnytte mulighederne i et moderne softwaredefineret netværk. Ved at fungere som et sæt netværksproxyer, der er implementeret med din kode, styrer et servicenetværk service-til-service-kommunikation uden at din kode har brug for nogen bevidsthed om det underliggende netværk. Du kan tænke på et servicenetværk som et automatiseret kontrolplan til din applikations netværk og styre det underliggende kontrolplan, når Kubernetes skalerer din kode op og ned.
Et softwaredefineret netværk til mikrotjenester
Måske bedst tænkt på som en måde at implementere smart, latenstidsbevidst, skalerbar belastningsbalancering sammen med serviceopdagelse, er et servicenet grundlæggende en distribueret router med dynamiske routingsregler, der styres som en del af en Kubernetes-implementering. Du kan definere yderligere regler; for eksempel at holde produktions- og testsystemer adskilt eller håndtere en implementering af en ny udgivelse og skiftet mellem containerversioner. Hver pod i en applikation har en service mesh-forekomst, der kører som et sidevogn, med service discovery og andre statefulde elementer, der kører uden for dine tjenester.
Med et servicenet skubber du intelligens ind i et nyt netværkslag, så du behøver ikke lægge det i dine mikrotjenester. Brug for at kryptere en forbindelse? Det er et job til dit servicenet. Brug for at godkende kunder? En anden opgave for servicenettet.
For mange masker
At kombinere en Kubernetes-implementering med et servicenet giver meget mening. Der er dog endnu et stort problem: Hvilket bruger du? Udsending? Istio? Linkerd? Aspen Mesh? Hvis du vælger en, hvad skal der forhindre, at et udviklingsteam i en anden del af din virksomhed vælger en anden? Hvad sker der så, hvis din virksomhed beslutter at standardisere på en bestemt platform?
Det er problemet, som Microsoft er ved at løse med Service Mesh Interface. I stedet for at hvert servicenet har sit eget sæt API'er, er SMI en måde at implementere almindelige API'er, der fungerer på tværs af forskellige servicenetværk, og administrere det nye smarte netværk. I stedet for at låse din kode i et bestemt servicenetværk og dets API'er kan du skrive kode, der adresserer de mest almindelige brugssager via en fælles API. Hvis du har brug for at bytte et servicenet ud - hvis du skifter udbyder, eller hvis du finder en, der fungerer bedre - er der ingen grund til at ændre din kode, så længe servicenettet implementerer SMI. Alt hvad du skal gøre er at ændre dine servicemesh sidevogne og omplacere din kode.
SMI: fælles servicenet-API'er
I samarbejde med Kubernetes-økosystemvirksomheder som Hashicorp og Buoyant har Microsoft defineret de vigtigste funktioner til SMI, der understøtter almindelige anmodninger fra sine kunder. I den oprindelige udgivelse har det fokuseret på tre områder: trafikpolitik, trafiktelemetri og trafikstyring. Disse tre områder styres af de fleste servicemasker, og hensigten er at gøre dette til en specifikation, der er nem at implementere uden at ændre den underliggende applikation.
Ved at gøre SMI til et sæt standard API'er er der intet, der forhindrer servicemesh-leverandører i at fortsætte med at tilbyde deres egne API'er eller yderligere funktioner uden for de angivne. Alternativt behøver de ikke foretage ændringer; tredjeparter kan oprette oversættelseslag, der sidder mellem SMI API'er og proprietære service-API'er. Du har heller ikke brug for en ny version af Kubernetes, da SMI API'erne implementeres som udvidelses-API-servere og tilpassede ressourcedefinitioner. Du kan gå videre og installere dem i enhver klynge ved hjælp af eksisterende styringsværktøjer. Det skulle gøre SMI let for Azure og andre cloud-hostede Kubernetes-tjenester at bygge dem ind i deres eksisterende administrerede Kubernetes-tjenester.
Uanset om du vil bruge Linkerd eller Aspen Mesh eller VMwares NSX Service Mesh, med SMI vil du være i stand til at vælge den, du foretrækker, forbedre kodeportabilitet og undgå lock-in til specifikke cloudtjenester. Så er der muligheden for at skifte servicenet uden at påvirke din kode. Hvis et nyt servicenet giver bedre ydeevne, skal du blot ændre din build-pipeline for at bruge det nye mesh og derefter implementere en opdateret applikation.
Det er interessant at se Microsoft tage føringen på et projekt som dette, der arbejder med et bredt tværsnit af Kubernetes-samfundet. Ved at tage en tilgang, der eksplicit ikke er fokuseret på at opbygge et servicenetværk, kan Azure tilbyde forskellige servicenetværk som en del af konfigurationen af AKS, så du kan vælge det værktøj, du ønsker, uden at skulle ændre nogen kode.
