Kontrolplan til distribueret Kubernetes PaaS

(Ankur Singla) (15. nov. , 2019)

Forfattere : Ankur Singla , Harshad Nakil

Denne blog er først i en række blogs, der dækker forskellige aspekter af, hvad det krævede for os at opbygge og drive vores SaaS -tjeneste:

  1. Kontrolplan til distribueret Kubernetes PaaS
  2. (Global servicenet til distribuerede applikationer)
  3. (Platformsikkerhed for distribueret infrastruktur, apps og data)
  4. (Applikations- og netværkssikkerhed af distribuerede klynger)
  5. Observabilitet på tværs af en globalt distribueret platform
  6. Operationer og SRE af en globalt distribueret platform
  7. Golang-serviceramme til distribueret mikroservice s

Som vi beskrev i vores tidligere blog , bygger vores kunder komplekse og forskellige sæt forretningsløsninger – som smart fremstilling, videoforskning til offentlig sikkerhed, algoritmisk handel, telco 5G-netværk – og derfor er vi nødt til at levere en altid tilsluttet, pålidelig og pålidelig oplevelse for disse applikationer og deres slutbrugere.

Da disse applikationer kunne køre i flere klynger på tværs af skyudbydere eller kunders kantplaceringer, var vores platformteam nødt til at opbygge et distribueret kontrolplan og en PaaS-tjeneste til at implementere, sikre og drive flere Kubernetes-klynger med flere lejre. Dette distribuerede kontrolplan har leveret mange fordele ved drift, skalering og ydeevne, som vi vil dække i vores præsentation ( videolink ) – f.eks hvordan man styrer tusindvis af kant-K8-klynger med GitOps – og også som et separat blogindlæg i de kommende uger.

TL; DR (Resumé)

  1. Vi kunne ikke finde en brugervenlig løsning på markedet, der kan løse problemet med implementering, sikring og drift af flere applikationsklynger, der distribueres på tværs af skyudbydere, private skyer eller flere kantplaceringer.
  2. Vi kunne ikke finde en robust Kubernetes distribution eller PaaS (f.eks. OpenShift, Cloud Foundry osv.), Der leverede et omfattende sæt sikkerheds- og operationelle tjenester, der er nødvendige for distribuerede klynger – for eksempel PKI-baseret identitet, RBAC og brugeradgangsstyring, hemmeligheder og nøglehåndtering på tværs af skyudbydere , multi-cluster-servicenetværk, observations- og auditlogfiler eller applikations- og netværkssikkerhed.
  3. Anthos (Google), Azure Arc (Microsoft) og Rancher er multiklyngestyringsstationer og emballering af flere forskellige tjenester ; vores analyse var, at disse ikke ville have løst de operationelle, skalerings-, sikkerheds- og multi-lejekrav, som vi havde til applikations- og infrastrukturtjenester på tværs af flere klynger.
  4. Vi måtte bygge vores eget distribuerede kontrolplan til vores administrerede PaaS, der er bygget oven på Kubernetes. Vi startede med vanilje Kubernetes og lavede derefter betydelige ændringer for at levere platformtjenester, der var nødvendige af vores DevOps- og SRE-teams. Derudover måtte vi bygge et kontrolplan til at styre et stort antal distribuerede klynger og levere multi-tenancy på tværs af heterogen infrastruktur (i kant, vores netværk og flere cloud-udbydere).

Kubernetes til App Management: Hvorfor & Hvordan

Vi valgte Kubernetes (K8s) til at være kernen i vores platform til styring af distribuerede applikationer, da det giver et rigt sæt funktioner uden at være alt for ordinerende – hvilket giver os fleksibilitet til at innovere om ting, som vi mener betyder noget for vores kunder. Vi brugte dette som et fundament, hvorpå vi kunne starte vores service, og med den voksende popularitet af K8er er det også lettere at finde udviklere og operatører, der er fortrolige med det.

Når det er sagt, er det ikke særlig let at implementere og styre et stort antal Kubernetes-klynger i produktion på tværs af et hybridmiljø (flere skyer, netværks-POPer og kantplaceringer), da der ikke er noget uden for det -box-løsninger til Kubernetes, der kan:

  1. Harmonisere heterogene infrastrukturressourcer med automatisk klyngedannelse, skalering og zero-touch-klargøring; dette var særligt smertefuldt i kanten og i vores netværk PoPer
  2. Giv højtydende og pålidelig forbindelse på tværs af forskellige placeringer – især når du krydser cloud-udbydere og kommer fra kantsteder
  3. Løs sikkerheden problem med data-in-transit, data-at-rest, hemmeligheder, nøgler og netværk … alt bakket op af en ensartet PKI-identitet, der fungerer på tværs af kant, netværk og cloud
  4. Giv ægte multi-tenancy – lejerisolering og sikkerhedsgarantier – med evnen til at køre produktions- og udviklingsarbejdsbelastninger til interne og kundebehov på de samme klynger
  5. Sørg for observerbarhed og drift på tværs af distribuerede klynger, der binder til centraliseret politik og hensigt uden behov for bygningskompleks logs og metrics collection

Efter flere proofs of-concept med flere cloud-udbydere og open source-platforme som GKE, AKS, EKS og RKE samt OpenShift og Cloud Foundry – indså vi at ingen af ​​dem kunne møde alle fi ovenstående krav. Som et resultat besluttede vi at bygge vores egen PaaS – startende med “vanille” Kubernetes og foretog flere tilføjelser – til identitet, netværk, sikkerhed, multi-tenancy, logning, metrics osv. Mens vi bruger Kubernetes til at imødekomme vores interne behov, Vi var nødt til at tage nogle hårde beslutninger som ikke at udsætte disse Kubernetes-klynger direkte for vores interne brugere og / eller kunder for at køre deres arbejdsbelastninger (mere om det senere, da multi-tenancy var et nøglemål for os).

Ud over flere nye funktioner, som vi skulle tilføje, var der også behov for at køre vores arbejdsbelastninger / tjenester sammen med kundearbejdsbelastninger mange steder over kanten, vores netværk og offentlige / private skyer. Dette betød, at vi var nødt til at opbygge yderligere kapaciteter til at styre flere klynger i flere miljøer … alle tilsluttet ved hjælp af vores globale netværk og vores distribuerede applikationsgateways for at give nul tillid og applikationsniveauforbindelse på tværs af disse klynger.

Hård del: Multi-Tenancy og Multi-Cluster for Kubernetes

Bygning og drift af applikationer, der kører i en enkelt Kubernetes-klynge, er en ikke-triviel opgave, selvom der forbruges en cloud-udbyderstyret klynge. Dette er grunden til, at det er almindeligt for DevOps- og SRE-hold at minimere deres omkostninger og ikke håndtere kompleksiteten i mange klynger. Det er ret almindeligt at se hold bygge en stor Kubernetes-klynge og placere alle typer ressourcer i den samme klynge. Selvom dette synes godt, fordi de kan forenkle operationer og køre klyngen for maksimal beregningseffektivitet og omkostning, er dette ikke den bedste idé af flere grunde. For det første er behovet for produktionsarbejdsbelastninger meget forskellige fra dev-test og fra iscenesættelse – ustabil udviklingsarbejdsbelastning kan potentielt medføre problemer med mere stabile produktionsarbejdsbelastninger.

Ud over behovene for forskellige arbejdsbelastninger, K8s sikkerhed og isolationsbegrænsninger er en anden driver til multi-cluster. En typisk tilgang til løsning af K8s sikkerhed og ressourceisolering er at spin-up uafhængige klynger til hver lejer ved hjælp af en model med flere lejere. Selvom dette kan være muligt at gøre i skyen, er det ikke muligt ved kanten at køre flere klynger. Edge-websteder har beregnings- og lagerressourcebegrænsninger og begrænset netværksbåndbredde til at sende logfiler og metrics for hver ekstra klynge til den centrale sky.

For at håndtere problemet med flere Kubernetes-klynger evaluerede vi Rancher til centraliseret styring af vores Kubernetes-klynger (da vi startede eksisterede Anthos og Azure Arc ikke) og KubeFed. De to tilgængelige tilgange på det tidspunkt var (og stadig den samme situation i dag):

  1. Styring af flere klynger (f.eks. Rancher) fra en central konsol ville have givet os muligheden for at implementere flere klynger hvor som helst og udføre livscyklusadministrationsoperationer som opgraderinger, tilbageførsel osv. Nogle af disse systemer gav også mulighed for at adressere en individuel klynge med automatisering til konfiguration og implementering af applikationer
  2. En anden tilgang er at implementere en Kubernetes clube federation (KubeFed) kontrolplan, og det kan få flere fysiske klynger til at ligne en klynge. Dette projekt var lige ved at komme i gang på det tidspunkt, vi kiggede, og selv i dag er det kun i alfafasen.

Efter den nylige meddelelse om GCP Anthos og Azure Arc, evaluerede vi vores oprindelige beslutning om at bygge et distribueret kontrolplan og konklusionen var, at selv disse to nye tilbud ikke kunne have løst to kritiske problemer med distribuerede klynger.Disse to nøglefunktioner, som vi havde brug for til vores platform, var:

  1. Håndtering af flere klynger som en flåde for at løse problemet med at udføre operationer på tværs af alle eller en logisk gruppe af klynger – operationer som konfiguration, implementering, metrics osv. Dette er kritisk, da vi ønsker at reducere operationelle omkostninger for vores SRE-teams, forbedre debug-evne til vores DevOps og forbedre skalerbarheden i vores system
  2. Evne til at skære en individuel fysisk Kubernetes-klynge til multi-tenancy uden at skulle spinde fysiske klynger op – dette er især kritisk i ressourcebegrænsede miljøer, hvor vi ikke ønsker at tilføje nye fysiske klynger kun til multi-tenancy

For at løse disse to problemer var vi nødt til at finde en ny teknik – distribueret kontrolplan – for at løse den operationelle omkostning ved “Flere” klynger og giver et ækvivalent med “flere klynger” til multi-tenancy i ressourcebegrænsning d miljøer.

Distribueret kontrolplan: Hvordan vi opnåede Multi-Cluster Kubernetes

Vores platformteam besluttede at bygge et distribueret kontrolplan til Kubernetes, der eksponerer Kubernetes APIer til vores teams brug, dog , disse APIer kommer fra “virtuelle” klynger, der kun findes i vores kontrolplan – en virtuel K8s (vK8s) API-server til en virtuel K8s-klynge (som vist i Figur 1 ). Dette kontrolplan kortlægger brugerens hensigt til flere fysiske Kubernetes-klynger, der kører i vores kant, vores netværks-POPer og offentlige skyplaceringer. Disse fysiske klynger er kun tilgængelige for vores distribuerede kontrolplan og ikke for nogen individuel lejer / bruger.

Figur 1: Distribueret kontrolplan

Dette kontrolplan giver hver lejer en eller flere “virtuelle” applikationsklynger, hvor de kan implementere deres applikation (er) ) og baseret på konfiguration vil kontrolplanet replikere og styre det på tværs af flere fysiske Kubernetes-klynger. Ud over konfigurations- og implementeringsoperationer følger overvågningsoperationer også denne “virtuelle” klynge uden behov for at opbygge værktøj til at indsamle og dissekere data fra flere fysiske klynger.

Lad os tage en prøve UI-applikation kaldet productpage, hvor brugerens hensigt er at køre det fordelt på 3 placeringer – pa2-par, ny8-nyc og ams9-ams med 2 replikaer i hver af dem. Da brugeren opretter et vK8s-objekt og vedhæfter det til en virtuel klynge, som straks opretter en vK8s API-server, der kan bruges med standard kubectl.

Som næste trin downloader brugeren kubeconfig til denne virtuelle klynge og opretter standard yaml for at beskrive en K8s-implementering til produktside.

Efter oprettelsen af ​​implementeringsspecifikationer , kan brugeren fortsætte med at oprette en implementering på denne virtuelle klynge:

Nu hvis brugeren kontrollerer hans implementering ser han 6 replikaer er startet med 2 på hvert sted (pa2-par, ny8-nyc og ams9-ams).

Følgende output viser 2 bælg, der kører på hvert sted med tilknytning til en bestemt fysisk node

Dette enkle eksempel viser, hvor trivielt det er at få multiklyngereplikering af enhver app i minut es uden nogen installations- og administrationsbyrde. Ud over at kortlægge hensigten leverer det distribuerede kontrolplan også observerbarhed for den virtuelle klynge og ikke på individuel klyngebasis.

Distribueret kontrol og centraliseret styring til multi-tenancy

Som du kan se i Figur 2 , vores centrale styringsplan kører over to offentlige cloud-udbydere (en region hver) – en i AWS og en i Azure (til redundans). Dette ledelsesplan giver vores SRE mulighed for at oprette lejere med hård multi-lejemål – f.eks. et udviklingsteam, der arbejder på vores VoltMesh-service, kan være en lejer, og et team til kundeløsninger, der arbejder med kundens POCer, kan være sin egen lejer med sit eget sæt brugere.

Figur 2: Multi-Tenancy og Multi-Cluster

Hver af disse lejere kan skabe mange navneområder og tildele en gruppe brugere at samarbejde om disse navneområder. Disse navneområder er ikke Kubernetes navneområder – de er en isolationsgrænse i vores platform med RBAC-regler og IAM-politikker for brugere.

Når en bruger i et navneområde vil oprette en applikationsklynge, opretter de et vK8s-objekt og der skaber igen en vK8s API-server i vores ledelsesplan.Ved hjælp af dette vK8s-objekt kan brugeren oprette implementeringer, stateful sæt, PVCer osv., Og kontrolplanet vil sikre, at disse operationer sker på en eller flere fysiske klynger, baseret på websteder, der er knyttet til vK8s-objektet.

Da hver lejer og bruger bruger standard K8-operationer uden ændringer, giver det systemet mulighed for at være kompatibelt med et antal værktøjer, der er populære hos operatører – f.eks. Spinnaker, Helm, Jenkins osv.

Gevinster realiseret fra et distribueret kontrolplan

Den store fordel ved et distribueret kontrolplan er, at det har løst den operationelle omkostning for vores SRE og DevOps hold. De kan nu udføre operationer (konfiguration, implementering, overvågning, politik osv.) På tværs af en virtuel klynge, og kontrolplanet kortlægger den automatisk på tværs af flere fysiske klynger. Ud over operationel forenkling af flere klynger har kontrolplanet også løst sikkerheds- og isolationsproblemet for multi-tenancy.

Dette distribuerede kontrolplan har også forbedret produktiviteten hos udviklere, der ønsker at tilføje nye funktioner til vores platform – de behøver ikke opbygge ny automatisering, hver gang de tilføjer nye funktioner, der påvirker konfiguration eller operationer på tværs af flere klynger. De bruger den hensigtsbaserede konfigurationsmodel, og kontrolplanet ved, hvad der skal gøres. Derudover kan de fortsætte med at interagere med dette distribuerede og multiple klyngeobjekt – virtuelle kubernetes – ved hjælp af kubectl og ikke endnu en CLI.

Efter at have kørt dette i vores dev-test, iscenesættelse og produktionsmiljøer for mere end et år nu indså vi, at dette globalt distribuerede kontrolplan (kører i vores POP-netværk) også giver betydelige fordele i skala, ydeevne og pålidelighed – noget som vi ikke helt havde forestillet os i vores tidlige dage. Vi vil dække dette fund i vores kommende KubeCon-præsentation og som et separat blogindlæg i de kommende uger.

Fortsættes …

Denne serie blogs vil dække forskellige aspekter af, hvad det tog for os at opbygge og drive vores globalt distribuerede SaaS-tjeneste med mange applikationsklynger i den offentlige sky, vores private netværk PoPer og kantwebsteder. Dernæst er (Global Service Mesh for Distribuerede Apps)…