Service mesh

Et service mesh er et infrastrukturlag, der håndterer kommunikation mellem tjenester i en distribueret applikation. Det kan samle trafikstyring, forbindelsessikkerhed og observationer af kald, så hver tjeneste ikke selv skal implementere alle disse mekanismer.

Mesh'et skelner typisk mellem et data plane, som behandler trafikken, og et control plane, som administrerer og distribuerer konfiguration. Den konkrete placering af proxyer og understøttede funktioner afhænger af løsningen og dens driftsmodel.

Hvorfor er begrebet vigtigt?

Når mange tjenester kalder hinanden, bliver ensartede forbindelsesregler og fejlsøgning sværere. Et mesh kan give fælles håndtering af eksempelvis routing, trafikmålinger og krypterede forbindelser. Observability betyder her, at signaler fra trafikken hjælper teamet med at forstå systemets tilstand.

Til gengæld får platformen flere komponenter, konfigurationer og afhængigheder. Ændrede trafikregler kan påvirke mange tjenester, og ekstra behandling kræver ressourcer. Behovet bør derfor vurderes mod systemets konkrete problemer og teamets evne til at drive løsningen.

Typisk misforståelse

Et mesh gør ikke automatisk alle interne kald sikre. Mutual Transport Layer Security (mTLS) beskytter og autentificerer forbindelsens parter, men erstatter ikke en beslutning om, hvem der må udføre en operation. Tjenestens egne brugerrettigheder og forretningsregler er fortsat nødvendige.

Alle mesh kræver heller ikke en sidecar-proxy ved hver applikation. Istio tilbyder både sidecar- og ambient-modeller. Deres arkitektur og funktioner skal vurderes særskilt; produktnavnet alene fortæller ikke, hvordan en bestemt forbindelse bliver behandlet.

Eksempel

Et fiktivt platformteam har en ordretjeneste, som kalder en lagertjeneste. Teamet indfører mesh'et i en afgrænset pilot og efterviser, at de forventede kald faktisk går gennem de valgte trafikkomponenter med mTLS.

Derefter afprøver teamet en adgangspolitik, som tillader den godkendte tjenesteidentitet og afviser en uvedkommende testidentitet. Applikationsejeren kontrollerer samtidig den normale ordreopgave. En vellykket krypteret forbindelse alene ville ikke eftervise adgangspolitikken. Ændringerne udvides først efter kontrol af fejlrate, svartid og en afprøvet tilbageførselsvej.

Best practice

• Beskriv problemet og trafikforløbet, før et mesh vælges som løsning.

• Afklar understøttede protokoller, driftsmodel og hvilke workloads der faktisk omfattes.

• Adskil forbindelsesautentifikation, adgangspolitik og applikationens forretningsrettigheder.

• Versionsstyr regler, og afprøv både forventet tilladt og forventet afvist trafik i en pilot.

• Overvåg fejl, latenstid, ressourceforbrug og certifikaters livscyklus; udpeg en ansvarlig for opgraderinger og fejlretning.