Controlevlak voor gedistribueerde Kubernetes PaaS

(Ankur Singla) (15 november) , 2019)

Auteurs : Ankur Singla , Harshad Nakil

Deze blog is de eerste in een reeks blogs die verschillende aspecten behandelen van wat er nodig was om onze SaaS -service:

  1. Controlevlak voor gedistribueerde Kubernetes PaaS
  2. (Global service mesh voor gedistribueerde applicaties)
  3. (Platformbeveiliging van gedistribueerde infrastructuur, apps en gegevens)
  4. (Applicatie- en netwerkbeveiliging van gedistribueerde clusters)
  5. Waarneembaarheid op een wereldwijd gedistribueerd platform
  6. Operaties en SRE van een wereldwijd gedistribueerd platform
  7. Golang-serviceframework voor gedistribueerde microservice s

Zoals we beschreven in onze eerdere blog , bouwen onze klanten complexe en diverse sets zakelijke oplossingen, zoals slimme fabricage, video-forensisch onderzoek voor openbare veiligheid, algoritmische handel, telco 5G-netwerken – en daarom moeten we een altijd actieve, verbonden en betrouwbare ervaring bieden voor deze applicaties en hun eindgebruikers.

Aangezien deze applicaties zou kunnen draaien in meerdere clusters over cloudproviders of edge-locaties van klanten, moest ons platformteam een ​​gedistribueerd controlevlak en een PaaS-service bouwen om meerdere multi-tenant Kubernetes-clusters te implementeren, beveiligen en exploiteren. Dit gedistribueerde besturingsvlak heeft veel operationele, schaal- en prestatievoordelen opgeleverd die we zullen bespreken in onze presentatie ( videolink ) – bijv hoe duizenden edge K8s-clusters te beheren met GitOps – en ook als een aparte blogpost in de komende weken.

TL; DR (Samenvatting)

  1. We konden niet vinden een eenvoudig te gebruiken oplossing op de markt die het probleem zou kunnen oplossen van het implementeren, beveiligen en beheren van meerdere applicatieclusters die zijn verspreid over cloudproviders, privéclouds of meerdere edge-locaties.
  2. We konden geen robuuste Kubernetes-distributie of PaaS (bijv.OpenShift, Cloud Foundry, enz.) Die een uitgebreide set beveiligings- en operationele services bood die nodig zijn voor gedistribueerde clusters – bijvoorbeeld op PKI gebaseerde identiteit, RBAC en gebruikerstoegangsbeheer, geheimen en sleutelbeheer tussen cloudproviders , multi-cluster service mesh, observeerbaarheid en audit logs, of applicatie- en netwerkbeveiliging.
  3. Anthos (Google), Azure Arc (Microsoft) en Rancher zijn multi-cluster beheerstations en pakketten van meerdere verschillende services ; onze analyse was dat deze niet de operationele, schaal-, beveiligings- en multitenancyvereisten zouden hebben opgelost die we hadden voor applicatie- en infrastructuurservices in meerdere clusters.
  4. We moesten ons eigen gedistribueerde besturingsvlak bouwen voor onze beheerde PaaS die bovenop Kubernetes is gebouwd. We zijn begonnen met vanilla Kubernetes en hebben vervolgens belangrijke wijzigingen aangebracht om platformdiensten te leveren die nodig zijn voor onze DevOps- en SRE-teams. Bovendien moesten we een controlevlak bouwen om grote aantallen gedistribueerde clusters te beheren en multi-tenancy te leveren via heterogene infrastructuur (in edge, ons netwerk en meerdere cloudproviders).

Kubernetes voor app-beheer: waarom & Hoe

We hebben Kubernetes (K8s) gekozen als de kern van ons platform voor het beheer van gedistribueerde applicaties, omdat het een rijke set aan functionaliteit biedt zonder overdreven prescriptief te zijn – waardoor we flexibiliteit krijgen bij het innoveren van dingen die volgens ons belangrijk zijn voor onze klanten. We hebben dit als basis gebruikt om onze service op te bouwen en met de groeiende populariteit van K8s is het ook gemakkelijker om ontwikkelaars en operators te vinden die ermee vertrouwd zijn.

Dat gezegd hebbende, het implementeren en beheren van een groot aantal Kubernetes-clusters van productiekwaliteit in een hybride omgeving (meerdere clouds, netwerk-POPs en edge-locaties) is niet erg eenvoudig, omdat er geen out-of-the -box-oplossingen voor Kubernetes die:

  1. heterogene infrastructuurbronnen kunnen harmoniseren met geautomatiseerde clustering, schaalvergroting en zero-touch provisioning; dit was vooral pijnlijk aan de edge en in onze netwerk-PoPs
  2. Bied krachtige en betrouwbare connectiviteit op verschillende locaties – vooral wanneer we cloudproviders oversteken en afkomstig zijn van edge-locaties
  3. Los de beveiliging op probleem van data-in-transit, data-at-rest, geheimen, sleutels en netwerk … allemaal ondersteund door een uniforme PKI-identiteit die werkt over edge, netwerk en cloud
  4. Zorg voor echte multi-tenancy – tenant isolatie en veiligheidsgaranties – met de mogelijkheid om productie- en ontwikkelingswerklasten voor interne en klantbehoeften op dezelfde clusters uit te voeren
  5. Waarneembaarheid en operaties bieden over gedistribueerde clusters die aansluiten bij gecentraliseerd beleid en intentie, zonder de noodzaak om complex te bouwen logboeken en metrische gegevens verzamelen

Na verschillende proofs-of-concept met meerdere cloudproviders en open-sourceplatforms zoals GKE, AKS, EKS en RKE, evenals OpenShift en Cloud Foundry – realiseerden we ons dat geen van hen alle fi kon ontmoeten ve vereisten hierboven. Als gevolg hiervan hebben we besloten om onze eigen PaaS te bouwen – te beginnen met “vanilla” Kubernetes en verschillende toevoegingen gedaan – voor identiteit, netwerken, beveiliging, multi-tenancy, logboekregistratie, metrische gegevens, enz. Hoewel we Kubernetes gebruiken om aan onze interne behoeften te voldoen, we moesten een aantal moeilijke beslissingen nemen, zoals deze Kubernetes-clusters niet rechtstreeks aan onze interne gebruikers en / of klanten blootstellen om hun workloads uit te voeren (daarover later meer, aangezien multi-tenancy een hoofddoel voor ons was).

Naast meerdere nieuwe functies die we moesten toevoegen, was het ook nodig om onze workloads / services naast de workloads van klanten uit te voeren op veel locaties in de edge, ons netwerk en publieke / private clouds. Dit betekende dat we extra mogelijkheden moesten bouwen om meerdere clusters in meerdere omgevingen te beheren… allemaal verbonden via ons wereldwijde netwerk en onze gedistribueerde applicatie-gateways om zero-trust en connectiviteit op applicatieniveau te bieden tussen deze clusters.

The Moeilijk onderdeel: Multi-Tenancy en Multi-Cluster voor Kubernetes

Het bouwen en gebruiken van applicaties die in een enkel Kubernetes-cluster worden uitgevoerd, is een niet-triviale taak, zelfs als u een door een cloudprovider beheerd cluster gebruikt. Daarom is het gebruikelijk dat DevOps- en SRE-teams hun overhead minimaliseren en niet omgaan met de complexiteit van veel clusters. Het komt vrij vaak voor dat teams één groot Kubernetes-cluster bouwen en alle soorten resources in hetzelfde cluster plaatsen. Hoewel dit geweldig lijkt omdat ze bewerkingen kunnen vereenvoudigen en het cluster kunnen uitvoeren voor maximale rekenefficiëntie en kosten, is dit om verschillende redenen niet het beste idee. Ten eerste zijn de behoeften aan productieworkloads heel anders dan dev-test en staging – onstabiele ontwikkelingsworkloads kunnen mogelijk problemen veroorzaken voor stabielere productieworkloads.

Naast de behoeften van gevarieerde workloads, K8s-beveiliging en isolatiebeperkingen is een andere driver voor multi-cluster. Een typische benadering voor het oplossen van K8s-beveiliging en resource-isolatie is het opzetten van onafhankelijke clusters voor elke tenant met behulp van een multi-tenant-model. Hoewel dit misschien haalbaar is om in de cloud te doen, is het niet mogelijk om aan de rand meerdere clusters te draaien. Edge-sites hebben beperkingen voor reken- en opslagbronnen en beperkte netwerkbandbreedte om logboeken en statistieken voor elk extra cluster naar de centrale cloud te verzenden.

Om het probleem van meerdere Kubernetes-clusters aan te pakken, hebben we Rancher geëvalueerd voor gecentraliseerd beheer van onze Kubernetes-clusters (toen we begonnen, bestonden Anthos en Azure Arc niet) en KubeFed. De twee benaderingen die op dat moment beschikbaar waren, waren (en nog steeds dezelfde situatie vandaag):

  1. Beheer van meerdere clusters (bijv. Rancher) vanaf een centrale console zou ons de mogelijkheid hebben gegeven om meerdere clusters te implementeren op elke locatie en voer levenscyclusbeheer uit, zoals upgrades, rollback, enz. Sommige van deze systemen gaven ook de mogelijkheid om een ​​individueel cluster aan te pakken met automatisering voor configuratie en implementatie van applicaties.
  2. Een andere benadering is om een ​​Kubernetes cluster federation (KubeFed) control plane en het kan meerdere fysieke clusters eruit laten zien als één cluster. Dit project was net begonnen op het moment dat we keken en zelfs vandaag bevindt het zich nog maar in de alfafase.

Na de recente aankondiging van GCP Anthos en Azure Arc hebben we onze oorspronkelijke beslissing om bouw een gedistribueerd controlevlak en de conclusie was dat zelfs deze twee nieuwe aanbiedingen niet twee kritieke problemen met gedistribueerde clusters hadden kunnen oplossen.Deze twee belangrijke mogelijkheden die we nodig hadden voor ons platform waren:

  1. Meerdere clusters beheren als een vloot om het probleem van het uitvoeren van bewerkingen in alle of een logische groep clusters op te lossen – bewerkingen zoals configuratie, implementatie, metrische gegevens, enz. Dit is van cruciaal belang omdat we de operationele overhead voor onze SRE-teams willen verminderen, de debugbaarheid voor onze DevOps willen verbeteren en de schaalbaarheid van ons systeem willen verbeteren.
  2. Mogelijkheid om een ​​individuele fysieke Kubernetes-cluster voor multi-tenancy zonder fysieke clusters te hoeven draaien – dit is vooral van cruciaal belang in omgevingen met beperkte middelen waar we geen nieuwe fysieke clusters willen toevoegen alleen voor multi-tenancy.

Om deze twee problemen op te lossen, moesten we een nieuwe techniek bedenken – gedistribueerd besturingsvlak – om de operationele overhead van “Meerdere” clusters en bieden een equivalent van “meerdere clusters” voor multi-tenancy bij beperkte middelen d-omgevingen.

Gedistribueerd besturingsvlak: hoe we Kubernetes met meerdere clusters bereikten

Ons platformteam besloot echter een gedistribueerd besturingsvlak voor Kubernetes te bouwen dat Kubernetes-APIs beschikbaar stelt voor gebruik door ons team. , deze APIs zijn afkomstig van virtuele clusters die alleen bestaan ​​in ons besturingsvlak – een virtuele K8s (vK8s) API-server voor een virtueel K8s-cluster (zoals weergegeven in Figuur 1 ). Dit besturingsvlak wijst de intentie van de gebruiker toe aan meerdere fysieke Kubernetes-clusters die in onze edge, onze netwerk-POPs en openbare cloudlocaties worden uitgevoerd. Deze fysieke clusters zijn alleen toegankelijk voor ons gedistribueerde besturingsvlak, en niet voor individuele tenant / gebruiker.

Figuur 1: Distributed Control Plane

Dit control plane voorziet elke tenant van een of meer “virtuele” applicatieclusters waar ze hun applicatie (s ) en op basis van de configuratie repliceert en beheert het besturingsvlak het over meerdere fysieke Kubernetes-clusters. Naast configuratie- en implementatiebewerkingen volgen monitoringbewerkingen ook dit virtuele cluster zonder de noodzaak om tooling te bouwen om gegevens uit meerdere fysieke clusters te verzamelen en te ontleden.

Laten we een voorbeeld van een UI-applicatie nemen, productpage genaamd, waar de bedoeling van de gebruiker is om het verspreid over 3 locaties uit te voeren – pa2-par, ny8-nyc en ams9-ams met 2 replicas in elk van hen. Terwijl de gebruiker een vK8s-object maakt en dit koppelt aan een virtueel cluster, dat onmiddellijk een vK8s API-server levert die kan worden gebruikt met standaard kubectl.

Als volgende stap downloadt de gebruiker de kubeconfig voor deze virtuele cluster en maakt standaard yaml om een ​​K8s-implementatie voor productpagina te beschrijven.

Na het maken van implementatiespecificaties kan de gebruiker doorgaan met het maken van een implementatie op dit virtuele cluster:

Als de gebruiker nu controleert zijn implementatie ziet hij dat 6 replicas zijn gestart met 2 op elke locatie (pa2-par, ny8-nyc en ams9-ams).

De volgende uitvoer toont 2 pods die op elke locatie worden uitgevoerd met toewijzing aan een bepaald fysiek knooppunt

Dit eenvoudige voorbeeld laat zien hoe triviaal het is om in een paar minuten een multi-cluster replicatie van een app te krijgen zonder enige installatie- en beheerlast. Naast het in kaart brengen van de intentie, levert het gedistribueerde controlevlak ook observeerbaarheid voor het virtuele cluster en niet op individuele clusterbasis.

Gedistribueerde controle en gecentraliseerd beheer voor multi-tenancy

Zoals u kunt zien in Figuur 2 , dat ons gecentraliseerde beheerplatform wordt uitgevoerd door twee openbare cloudproviders (elk een regio) – een in AWS en één in Azure (voor redundantie). Met dit beheersvlak kan onze SRE huurders creëren met harde multi-tenancy – bijv. een ontwikkelingsteam dat aan onze VoltMesh-service werkt, kan een huurder zijn en een team voor klantoplossingen dat aan klant-POCs werkt, kan zijn eigen huurder zijn met zijn eigen gebruikers.

Figuur 2: Multi-Tenancy en Multi-Cluster

Elk van deze tenants kan veel naamruimten en wijs een groep gebruikers toe om samen aan deze naamruimten te werken. Deze naamruimten zijn geen Kubernetes-naamruimten – ze vormen een isolatiegrens in ons platform met RBAC-regels en IAM-beleid voor gebruikers.

Wanneer een gebruiker binnen een naamruimte een applicatiecluster wil maken, maken ze een vK8s-object en dat creëert op zijn beurt een vK8s API-server in ons beheerniveau.Met behulp van dit vK8s-object kan de gebruiker implementaties, stateful sets, PVCs, enz. Maken en het controlevlak zorgt ervoor dat deze bewerkingen plaatsvinden op een of meerdere fysieke clusters, op basis van sites die zijn gekoppeld aan het vK8s-object.

Aangezien elke huurder en gebruiker standaard K8s-bewerkingen gebruikt zonder enige aanpassingen, kan het systeem compatibel zijn met een aantal tools die populair zijn bij operators – bijv. Spinnaker, Helm, Jenkins, etc.

Winsten gerealiseerd met een Distributed Control Plane

Het grote voordeel van een gedistribueerd control plane is dat het de operationele overhead voor onze SRE en DevOps heeft opgelost teams. Ze kunnen nu bewerkingen uitvoeren (configuratie, implementatie, bewaking, beleid, enz.) In een virtueel cluster en het besturingsvlak zal dit automatisch toewijzen aan meerdere fysieke clusters. Naast operationele vereenvoudiging voor meerdere clusters, heeft het control plane ook het beveiligings- en isolatieprobleem voor multi-tenancy opgelost.

Dit gedistribueerde controlevlak heeft ook de productiviteit verbeterd van ontwikkelaars die nieuwe functies willen toevoegen aan ons platform – ze hoeven niet elke keer nieuwe automatisering te bouwen als ze nieuwe functies toevoegen die van invloed zijn op de configuratie of bewerkingen in meerdere clusters. Ze gebruiken het intent-based configuratiemodel en de control plane weet wat er moet gebeuren. Bovendien kunnen ze blijven communiceren met dit gedistribueerde en meervoudige clusterobject – virtuele kubernetes – met behulp van kubectl en niet nog een andere CLI.

Nadat ze dit hebben uitgevoerd in onze dev-test-, staging- en productieomgevingen voor meer meer dan een jaar realiseerden we ons dat dit wereldwijd gedistribueerde besturingsvlak (draaiend in onze netwerk-POPs) ook aanzienlijke schaal-, prestatie- en betrouwbaarheidsvoordelen biedt – iets dat we ons in onze begindagen niet helemaal hadden voorgesteld. We zullen deze bevinding behandelen in onze aanstaande KubeCon-presentatie en als een aparte blogpost in de komende weken.

Wordt vervolgd …

Deze serie blogs behandelt verschillende aspecten van wat het voor ons nodig om onze wereldwijd gedistribueerde SaaS-service te bouwen en te exploiteren met veel applicatieclusters in de openbare cloud, onze particuliere netwerk-PoPs en edge-sites. De volgende is (Global Service Mesh for Distributed Apps) …