Kontrollplan för distribuerad Kubernetes PaaS

(Ankur Singla) (15 nov , 2019)

Författare : Ankur Singla , Harshad Nakil

Denna blogg är först i en serie bloggar som täcker olika aspekter av vad som krävs för att vi ska bygga och driva vår SaaS -tjänst:

  1. Kontrollplan för distribuerat Kubernetes PaaS
  2. (Globalt servicenät för distribuerade applikationer)
  3. (Plattformssäkerhet för distribuerad infrastruktur, appar och data)
  4. (Applikations- och nätverkssäkerhet för distribuerade kluster)
  5. Observabilitet över en globalt distribuerad plattform
  6. Verksamhet och SRE för en globalt distribuerad plattform
  7. Golangs servicestruktur för distribuerad mikroservice s

Som vi beskrev i vår tidigare blogg bygger våra kunder komplexa och olika uppsättningar affärslösningar – som smarta tillverkning, video kriminalteknik för allmän säkerhet, algoritmisk handel, telco 5G-nätverk – och därmed måste vi leverera en alltid på, ansluten och pålitlig upplevelse för dessa applikationer och deras slutanvändare.

Eftersom dessa applikationer kunde köras i flera kluster över molnleverantörer eller kundernas kantplatser, var vårt plattformsteam tvunget att bygga ett distribuerat kontrollplan och en PaaS-tjänst för att distribuera, säkra och driva flera Kubernetes-kluster med flera bostäder. Detta distribuerade kontrollplan har gett många fördelar för drift, skalning och prestanda som vi kommer att täcka i vår presentation ( videolänk ) – t.ex. hur man hanterar tusentals kant-K8-kluster med GitOps – och även som ett separat blogginlägg under de kommande veckorna.

TL; DR (Sammanfattning)

  1. Vi kunde inte hitta en enkel att använda lösning på marknaden som kan lösa problemet med att distribuera, säkra och driva flera applikationskluster som distribueras över molnleverantörer, privata moln eller flera kantplatser.
  2. Vi kunde inte hitta en robust Kubernetes distribution eller PaaS (t.ex. OpenShift, Cloud Foundry, etc) som tillhandahöll en omfattande uppsättning säkerhets- och operativa tjänster som behövs för distribuerade kluster – till exempel PKI-baserad identitet, RBAC och användaråtkomsthantering, hemligheter och nyckelhantering över molnleverantörer , nätverk med flera kluster, observations- och granskningsloggar, eller applikations- och nätverkssäkerhet.
  3. Anthos (Google), Azure Arc (Microsoft) och Rancher är flera klusterhanteringsstationer och förpackning av flera olika tjänster ; vår analys var att dessa inte skulle ha löst de krav på drift, skalning, säkerhet och flerfastigheter som vi hade för applikations- och infrastrukturtjänster i flera kluster.
  4. Vi var tvungna att bygga ett eget distribuerat styrplan för vår hanterade PaaS som är byggd ovanpå Kubernetes. Vi började med vanilj Kubernetes och gjorde sedan betydande förändringar för att leverera plattformstjänster som behövs av våra DevOps- och SRE-team. Dessutom var vi tvungna att bygga ett kontrollplan för att hantera ett stort antal distribuerade kluster och leverera flera hyresgäster över heterogen infrastruktur (i kant, vårt nätverk och flera molnleverantörer).

Kubernetes för Apphantering: Varför & Hur

Vi valde Kubernetes (K8s) för att vara kärnan i vår plattform för hantering av distribuerade applikationer eftersom det ger en rik uppsättning funktioner utan att vara alltför receptbelagda – vilket ger oss flexibilitet när det gäller att förnya oss om saker som vi anser är viktiga för våra kunder. Vi använde detta som en grund för att börja bygga vår tjänst och med den ökande populariteten för K8 är det också lättare att hitta utvecklare och operatörer som är bekanta med den.

Med detta sagt är det inte särskilt enkelt att distribuera och hantera ett stort antal Kubernetes-kluster i en hybridmiljö (flera moln, nätverks-POP och kantplatser) eftersom det inte finns några out-of-the -box-lösningar för Kubernetes som kan:

  1. Harmonisera heterogena infrastrukturresurser med automatiserad kluster, skalning och zero-touch-provisionering; detta var särskilt smärtsamt vid kanten och i vårt nätverk PoPs
  2. Ge högpresterande och tillförlitlig anslutning över olika platser – särskilt när du korsar molnleverantörer och kommer från kantplatser
  3. Lös säkerheten problem med data-in-transit, data-at-rest, hemligheter, nycklar och nätverk … allt stöds av en enhetlig PKI-identitet som fungerar över kant, nätverk och moln
  4. Ge verklig flerbostadsrätt – hyresgästisolering och säkerhetsgarantier – med förmågan att köra produktions- och utvecklingsarbetsbelastningar för interna och kundbehov på samma kluster
  5. Ge observerbarhet och drift över distribuerade kluster som kopplas till centraliserad policy och avsikt utan behov av att bygga komplex loggar och statistikinsamling

Efter flera proof-of-concept med flera molnleverantörer och open source-plattformar som GKE, AKS, EKS och RKE samt OpenShift och Cloud Foundry – insåg vi att ingen av dem kunde möta alla fi ovanstående krav. Som ett resultat bestämde vi oss för att bygga vår egen PaaS – från och med ”vanilj” Kubernetes och gjorde flera tillägg – för identitet, nätverk, säkerhet, multi-tenancy, loggning, mätvärden etc. Medan vi använder Kubernetes för att möta våra interna behov, vi var tvungna att fatta några hårda beslut som att inte exponera dessa Kubernetes-kluster direkt för våra interna användare och / eller kunder för att köra sina arbetsbelastningar (mer om det senare, eftersom flerhyresavtal var ett huvudmål för oss).

Förutom flera nya funktioner som vi behövde lägga till, fanns det också ett behov av att köra våra arbetsbelastningar / tjänster tillsammans med kundarbetsbelastningar på många platser över kanten, vårt nätverk och offentliga / privata moln. Detta innebar att vi var tvungna att bygga ytterligare funktioner för att hantera flera kluster i flera miljöer … alla anslutna med vårt globala nätverk och våra distribuerade applikationsgateways för att ge nollförtroende och applikationsnivåanslutning över dessa kluster.

Svår del: Multi-Tenancy och Multi-Cluster för Kubernetes

Att bygga och driva applikationer som körs i ett enda Kubernetes-kluster är en icke-trivial uppgift, även om man konsumerar ett molnleverantörshanterat kluster. Det är därför det är vanligt att DevOps- och SRE-team minimerar sina omkostnader och inte hanterar komplexiteten i många kluster. Det är ganska vanligt att se lag bygga ett stort Kubernetes-kluster och placera alla typer av resurser inom samma kluster. Även om detta verkar bra eftersom de kan förenkla operationerna och köra klustret för maximal beräkningseffektivitet och kostnad, är det inte den bästa idén av flera skäl. För det första är behoven för produktionsarbetsbelastningar mycket annorlunda från dev-test och från iscensättning – instabil utvecklingsarbetsbelastning kan potentiellt orsaka problem för mer stabila produktionsarbetsbelastningar.

Förutom behoven hos olika arbetsbelastningar, K8s säkerhet och isolationsbegränsningar är en annan drivrutin för flerkluster. Ett typiskt tillvägagångssätt för att lösa K8s säkerhet och resursisolering är att öka upp oberoende kluster för varje klient med hjälp av en modell med flera klienter. Även om detta kan vara möjligt att göra i molnet är det inte möjligt att köra flera kluster vid kanten. Edge-webbplatser har beräknings- och lagringsresursbegränsningar och begränsad nätverksbandbredd för att skicka loggar och mätvärden för varje ytterligare kluster till det centrala molnet.

För att hantera problemet med flera Kubernetes-kluster utvärderade vi Rancher för centraliserad hantering av våra Kubernetes-kluster (när vi startade existerade inte Anthos och Azure Arc) och KubeFed. De två tillvägagångssätt som var tillgängliga vid den tiden var (och fortfarande samma situation idag):

  1. Multi-cluster management (t.ex. Rancher) från en central konsol skulle ha gett oss möjligheten att distribuera flera kluster på valfri plats och utföra livscykelhanteringsåtgärder som uppgraderingar, återställning osv. Några av dessa system gav också möjligheten att ta itu med ett enskilt kluster med automatisering för konfiguration och distribution av applikationer
  2. En annan metod är att distribuera en Kubernetes cluster federation (KubeFed) kontrollplan och det kan göra att flera fysiska kluster ser ut som ett kluster. Det här projektet började precis när vi tittade och till och med idag är det bara i alfafasen.

Efter det senaste tillkännagivandet av GCP Anthos och Azure Arc utvärderade vi vårt ursprungliga beslut att bygga ett distribuerat kontrollplan och slutsatsen var att även dessa två nya erbjudanden inte kunde ha löst två kritiska problem med distribuerade kluster.Dessa två viktiga funktioner som vi behövde för vår plattform var:

  1. Hantera flera kluster som en flotta för att lösa problemet med att utföra operationer i alla eller en logisk grupp av kluster – operationer som konfiguration, distribution, mätvärden etc. Detta är viktigt eftersom vi vill minska kostnaderna för våra SRE-team, förbättra felsökningsförmågan för våra DevOps och förbättra skalbarheten i vårt system
  2. Förmåga att hugga upp en enskild fysisk Kubernetes-kluster för multi-tenancy utan att behöva snurra upp fysiska kluster – detta är särskilt viktigt i resursbegränsade miljöer där vi inte vill lägga till nya fysiska kluster bara för multi-tenancy

För att lösa dessa två problem var vi tvungna att komma med en ny teknik – distribuerat styrplan – för att lösa den operativa omkostnaden för ”Multipla” kluster och tillhandahålla en motsvarighet till ”multipla kluster” för multi-tenancy i resursbegränsning d-miljöer.

Distribuerad kontrollplan: Hur vi uppnådde Kubernetes med flera kluster

Vårt plattformsteam bestämde sig för att bygga ett distribuerat kontrollplan för Kubernetes som exponerar Kubernetes API för vårt teams användning, dock , dessa API: er kommer från “virtuella” kluster som bara finns i vårt kontrollplan – en virtuell K8s (vK8s) API-server för ett virtuellt K8s-kluster (som visas i Figur 1 ). Detta kontrollplan kartlägger användarens avsikt till flera fysiska Kubernetes-kluster som körs i vår kant, våra POP-nätverk och offentliga molnplatser. Dessa fysiska kluster är endast tillgängliga för vårt distribuerade kontrollplan och inte för någon enskild klient / användare.

Figur 1: Distribuerad kontrollplan

Detta kontrollplan ger varje klient en eller flera ”virtuella” applikationskluster där de kan distribuera sina applikationer ) och baserat på konfiguration kommer kontrollplanet att replikera och hantera det över flera fysiska Kubernetes-kluster. Förutom konfigurations- och distributionsoperationer följer övervakningsoperationer också detta ”virtuella” kluster utan att behöva bygga verktyg för att samla in och dissekera data från flera fysiska kluster.

Låt oss ta ett exempel på ett UI-program som heter produktsida, där användarens avsikt är att köra den fördelad på tre platser – pa2-par, ny8-nyc och ams9-ams med 2 repliker i var och en av dem. När användaren skapar ett vK8s-objekt och bifogar det till ett virtuellt kluster, som omedelbart tillhandahåller en vK8s API-server som kan användas med standard kubectl.

Som nästa steg laddar användaren ner kubeconfig för den här virtuella kluster och skapar standard yaml för att beskriva en K8s-distribution för produktsidan.

Efter skapandet av distributionsspecifikation kan användaren fortsätta med att skapa en distribution på detta virtuella kluster:

Nu om användaren kontrollerar hans distribution ser att 6 repliker har startats med 2 på varje plats (pa2-par, ny8-nyc och ams9-ams).

Följande utdata visar två pods som körs på varje plats med mappning till en viss fysisk nod

Detta enkla exempel visar hur trivialt det är att få multiklusterreplikering av vilken app som helst på minut utan installation och hantering. Förutom att kartlägga avsikten levererar det distribuerade kontrollplanet också observerbarhet för det virtuella klustret och inte på enskild klusterbasis.

Distribuerad kontroll och centraliserad hantering för flerbostadshantering

du kan se i Figur 2 , vårt centraliserade hanteringsplan körs över två offentliga molnleverantörer (en region vardera) – en i AWS och en i Azure (för redundans). Detta hanteringsplan gör det möjligt för vår SRE att skapa hyresgäster med hårt flerbostadsrätt – t.ex. ett utvecklingsteam som arbetar med vår VoltMesh-tjänst kan vara en hyresgäst och ett kundlösningarsteam som arbetar med kundens POC kan vara en egen hyresgäst med en egen uppsättning användare.

Figur 2: Multi-Tenancy och Multi-Cluster

Var och en av dessa hyresgäster kan skapa många namnrymden och tilldela en grupp användare att samarbeta i dessa namnområden. Dessa namnområden är inte Kubernetes namnområden – de är en isoleringsgräns i vår plattform med RBAC-regler och IAM-policyer för användare.

När en användare inom ett namnområde vill skapa ett applikationskluster skapar de ett vK8s-objekt och som i sin tur skapar en vK8s API-server i vårt hanteringsplan.Med hjälp av detta vK8s-objekt kan användaren skapa distributioner, stateful uppsättningar, PVC, etc, och kontrollplanet säkerställer att dessa operationer sker på ett eller flera fysiska kluster, baserat på webbplatser som är associerade med vK8s-objektet.

Eftersom varje hyresgäst och användare använder standard K8-operationer utan några ändringar, gör det att systemet kan vara kompatibelt med ett antal verktyg som är populära hos operatörer – t.ex. Spinnaker, Helm, Jenkins, etc.

Vinster realiserade från en distribuerad kontrollplan

Den stora fördelen med ett distribuerat kontrollplan är att det har löst den operativa omkostnaden för vår SRE och DevOps lag. De kan nu utföra operationer (konfiguration, distribution, övervakning, policy, etc) över ett virtuellt kluster och kontrollplanet kartlägger det automatiskt över flera fysiska kluster. Förutom driftsförenkling för flera kluster har kontrollplanet också löst säkerhets- och isoleringsproblemet för flerfastigheter.

Detta distribuerade kontrollplan har också förbättrat produktiviteten hos utvecklare som vill lägga till nya funktioner till vår plattform – de behöver inte bygga ny automatisering varje gång de lägger till nya funktioner som påverkar konfiguration eller operationer i flera kluster. De använder den avsiktsbaserade konfigurationsmodellen och kontrollplanet vet vad som behöver göras. Dessutom kan de fortsätta att interagera med detta distribuerade och multipla klusterobjekt – virtuella kubernetes – med hjälp av kubectl och inte ännu en CLI.

Efter att ha kört detta i vår dev-test-, staging- och produktionsmiljö för mer än ett år nu insåg vi att detta globalt distribuerade kontrollplan (som körs i våra POP-nätverk) också ger betydande fördelar för skala, prestanda och tillförlitlighet – något som vi inte helt hade föreställt oss under våra tidiga dagar. Vi kommer att täcka detta resultat i vår kommande KubeCon-presentation och som ett separat blogginlägg under de kommande veckorna.

Fortsätt …

Denna serie bloggar kommer att täcka olika aspekter av vad den tog oss att bygga och driva vår globalt distribuerade SaaS-tjänst med många applikationskluster i det offentliga molnet, vårt privata nätverk PoPs och edge-webbplatser. Nästa är (Global Service Mesh for Distributed Apps) …