Kub-på-kub, metakluster, bikakor, resursfördelning

Ris. 1. Kubernetes ekosystem på Alibaba Cloud

Sedan 2015 har Alibaba Cloud Container Service för Kubernetes (ACK) varit en av de snabbast växande molntjänsterna i Alibaba Cloud. Den betjänar många kunder och stöder även Alibabas interna infrastruktur och företagets andra molntjänster.

Precis som med liknande containertjänster från molnleverantörer i världsklass är våra högsta prioriteringar tillförlitlighet och tillgänglighet. Därför har en skalbar och globalt tillgänglig plattform skapats för tiotusentals Kubernetes-kluster.

I den här artikeln kommer vi att dela vår erfarenhet av att hantera ett stort antal Kubernetes-kluster på molninfrastruktur, såväl som arkitekturen för den underliggande plattformen.

Entry

Kubernetes har blivit de facto-standarden för en mängd olika arbetsbelastningar i molnet. Som visas i fig. 1 ovan, fler och fler Alibaba Cloud-applikationer körs nu på Kubernetes-kluster: statistiska och tillståndslösa applikationer, såväl som applikationshanterare. Kubernetes management har alltid varit ett intressant och seriöst diskussionsämne för ingenjörer som bygger och underhåller infrastruktur. När det kommer till molnleverantörer som Alibaba Cloud kommer frågan om skalning i förgrunden. Hur hanterar man Kubernetes-kluster i denna skala? Vi har redan behandlat bästa praxis för att hantera enorma Kubernetes-kluster med 10 000 noder. Naturligtvis är detta ett intressant skalningsproblem. Men det finns en annan skala: kvantitet själva klustren.

Vi har diskuterat detta ämne med många ACK-användare. De flesta av dem väljer att köra dussintals, om inte hundratals, små eller medelstora Kubernetes-kluster. Det finns goda skäl till detta: begränsa potentiell skada, separera kluster för olika team, skapa virtuella kluster för testning. Om ACK siktar på att betjäna en global publik med denna användningsmodell, måste den på ett tillförlitligt och effektivt sätt hantera ett stort antal kluster över mer än 20 regioner.

Ris. 2. Problem med att hantera ett stort antal Kubernetes-kluster

Vilka är de största utmaningarna med att hantera kluster i denna skala? Som visas i figuren finns det fyra frågor att ta itu med:

• Heterogenitet

ACK bör stödja olika typer av kluster, inklusive standard, serverlösa, Edge, Windows och flera andra. Olika kluster kräver olika alternativ, komponenter och värdmodeller. Vissa kunder behöver hjälp med anpassning för sina specifika fall.

• Olika klusterstorlekar

Kluster varierar i storlek, från ett par noder med några få baljor till tiotusentals noder med tusentals baljor. Resursbehoven varierar också mycket. Felaktig resursallokering kan påverka prestandan eller till och med orsaka fel.

• Olika versioner

Kubernetes utvecklas väldigt snabbt. Nya versioner släpps med några månaders mellanrum. Kunder är alltid villiga att prova nya funktioner. Så de vill placera testbelastningen på de nya versionerna av Kubernetes och produktionsbelastningen på de stabila. För att möta detta krav måste ACK kontinuerligt leverera nya versioner av Kubernetes till kunder samtidigt som de bibehåller stabila versioner.

• Säkerhetsefterlevnad

Kluster är fördelade över olika regioner. Som sådana måste de uppfylla olika säkerhetskrav och officiella föreskrifter. Till exempel måste ett kluster i Europa vara GDPR-kompatibelt, medan ett finansiellt moln i Kina måste ha ytterligare lager av skydd. Dessa krav är obligatoriska och det är oacceptabelt att ignorera dem, eftersom detta skapar enorma risker för kunderna av molnplattformen.

ACK-plattformen är designad för att lösa de flesta av ovanstående problem. Den hanterar för närvarande tillförlitligt och stabilt mer än 10 tusen Kubernetes-kluster runt om i världen. Låt oss titta på hur detta uppnåddes, inklusive genom flera viktiga design-/arkitekturprinciper.

Design

Kub-på-kub och honungskaka

Till skillnad från en centraliserad hierarki används cellbaserad arkitektur vanligtvis för att skala en plattform bortom ett enda datacenter eller för att utöka omfattningen av katastrofåterställning.

Varje region i Alibaba-molnet består av flera zoner (AZ) och motsvarar vanligtvis ett specifikt datacenter. I en stor region (t.ex. Huangzhou) finns det ofta tusentals Kubernetes-klientkluster som kör ACK.

ACK hanterar dessa Kubernetes-kluster genom att använda Kubernetes själv, vilket innebär att vi har ett Kubernetes-metakluster igång för att hantera Kubernetes-klientens kluster. Denna arkitektur kallas också "kube-on-kube" (KoK). KoK-arkitekturen förenklar hanteringen av klientkluster eftersom klusterdistribution är enkel och deterministisk. Ännu viktigare är att vi kan återanvända inbyggda Kubernetes-funktioner. Till exempel hantera API-servrar genom distribution, använda etcd-operatorn för att hantera flera etcds. En sådan rekursion ger alltid speciellt nöje.

Flera Kubernetes-metakluster är utplacerade inom en region, beroende på antalet klienter. Vi kallar dessa metakluster celler. För att skydda mot fel i en hel zon stöder ACK multiaktiva distributioner i en enda region: metaklustret distribuerar Kubernetes klientklusterhuvudkomponenter över flera zoner och kör dem samtidigt, det vill säga i multiaktivt läge. För att säkerställa masterns tillförlitlighet och effektivitet optimerar ACK placeringen av komponenter och säkerställer att API-servern och etcd är nära varandra.

Denna modell låter dig hantera Kubernetes effektivt, flexibelt och tillförlitligt.

Metakluster resursplanering

Som vi redan nämnt beror antalet metakluster i varje region på antalet klienter. Men vid vilken tidpunkt ska man lägga till ett nytt metakluster? Detta är ett typiskt resursplaneringsproblem. Som regel är det vanligt att skapa ett nytt när befintliga metakluster har förbrukat alla sina resurser.

Låt oss ta nätverksresurser, till exempel. I KoK-arkitekturen distribueras Kubernetes-komponenter från klientkluster som pods i ett metakluster. Vi använder Terway (Fig. 3) är ett högpresterande plugin utvecklat av Alibaba Cloud för hantering av containernätverk. Det ger en rik uppsättning säkerhetspolicyer och låter dig ansluta till kunders virtuella privata moln (VPC) genom Alibaba Cloud Elastic Networking Interface (ENI). För att effektivt distribuera nätverksresurser över noder, poddar och tjänster i ett metakluster måste vi noggrant övervaka deras användning inom metaklustret av virtuella privata moln. När nätverksresurserna tar slut skapas en ny cell.

För att bestämma det optimala antalet klientkluster i varje metakluster tar vi även hänsyn till våra kostnader, täthetskrav, resurskvot, tillförlitlighetskrav och statistik. Beslutet att skapa ett nytt metakluster tas baserat på all denna information. Observera att små kluster kan expandera kraftigt i framtiden, så resursåtgången ökar även om antalet kluster förblir oförändrat. Vi lämnar vanligtvis tillräckligt med ledigt utrymme för varje kluster att växa.

Ris. 3. Terway nätverksarkitektur

Skalningsguidekomponenter över klientkluster

Wizardkomponenter har olika resursbehov. De beror på antalet noder och poddar i klustret, antalet icke-standardiserade kontroller/operatörer som interagerar med APIServer.

I ACK skiljer sig varje Kubernetes-klientkluster i storlek och körtidskrav. Det finns ingen universell konfiguration för att placera guidekomponenter. Om vi ​​av misstag ställer in en låg resursgräns för en stor klient, kommer dess kluster inte att klara av belastningen. Om du sätter en konservativt hög gräns för alla kluster kommer resurser att gå till spillo.

För att hitta en subtil avvägning mellan tillförlitlighet och kostnad, använder ACK ett typsystem. Vi definierar nämligen tre typer av kluster: små, medelstora och stora. Varje typ har en separat resursallokeringsprofil. Typen bestäms baserat på belastningen av guidekomponenter, antalet noder och andra faktorer. Klustertypen kan ändras med tiden. ACK övervakar kontinuerligt dessa faktorer och kan skriva upp/ner därefter. När klustertypen har ändrats uppdateras resursallokeringen automatiskt med minimalt användaringripande.

Vi arbetar för att förbättra detta system med finare skalning och mer exakt typuppdatering så att dessa förändringar sker smidigare och blir mer ekonomiskt förnuftiga.

Ris. 4. Intelligent flerstegsväxling

Utveckling av kundkluster i stor skala

De föregående avsnitten täckte vissa aspekter av att hantera ett stort antal Kubernetes-kluster. Det finns dock ett annat problem som måste lösas: utvecklingen av kluster.

Kubernetes är molnvärldens "Linux". Den uppdateras kontinuerligt och blir mer modulär. Vi måste ständigt leverera nya versioner till våra kunder, åtgärda sårbarheter och uppdatera befintliga kluster, samt hantera ett stort antal relaterade komponenter (CSI, CNI, Device Plugin, Scheduler Plugin och många andra).

Låt oss ta Kubernetes komponenthantering som ett exempel. Till att börja med utvecklade vi ett centraliserat system för att registrera och hantera alla dessa anslutna komponenter.

Ris. 5. Flexibla och pluggbara komponenter

Innan du går vidare måste du se till att uppdateringen lyckades. För att göra detta har vi utvecklat ett system för kontroll av komponenters funktionalitet. Kontrollen utförs före och efter uppdateringen.

Ris. 6. Preliminär kontroll av klusterkomponenter

För att snabbt och tillförlitligt uppdatera dessa komponenter fungerar ett kontinuerligt distributionssystem med stöd för partiell avancemang (gråskala), pauser och andra funktioner. Standard Kubernetes-kontroller är inte väl lämpade för detta användningsfall. För att hantera klusterkomponenter har vi därför utvecklat en uppsättning specialiserade styrenheter, inklusive en plugin och en extra kontrollmodul (sidecar management).

Till exempel är BroadcastJob-styrenheten utformad för att uppdatera komponenter på varje arbetsmaskin eller kontrollera noder på varje maskin. Broadcast-jobbet kör en pod på varje nod i klustret, som en DaemonSet. Men DaemonSet håller alltid podden igång under lång tid, medan BroadcastJob kollapsar den. Broadcast-styrenheten startar också pods på nyligen sammanfogade noder och initierar noderna med de nödvändiga komponenterna. I juni 2019 öppnade vi källkoden för automationsmotorn OpenKruise, som vi själva använder inom företaget.

Ris. 7. OpenKurise organiserar utförandet av Broadcast-uppgiften på alla noder

För att hjälpa kunder att välja rätt klusterkonfigurationer tillhandahåller vi också en uppsättning fördefinierade profiler, inklusive serverlösa, Edge-, Windows- och Bare Metal-profiler. När landskapet vidgas och våra kunders behov växer, kommer vi att lägga till fler profiler för att förenkla den tråkiga installationsprocessen.

Ris. 8. Avancerade och flexibla klusterprofiler för olika scenarier

Global observerbarhet över datacenter

Som visas i nedanstående fig. 9, Alibaba Cloud Container molntjänst har distribuerats i tjugo regioner runt om i världen. Med tanke på denna skala är ett av huvudmålen med ACK att enkelt övervaka tillståndet för körande kluster så att om ett klientkluster stöter på ett problem, kan vi snabbt reagera på situationen. Du behöver med andra ord komma på en lösning som gör att du effektivt och säkert kan samla in statistik i realtid från klientkluster i alla regioner – och visuellt presentera resultaten.

Ris. 9. Global distribution av Alibaba Cloud Container-tjänst i tjugo regioner

Liksom många Kubernetes övervakningssystem använder vi Prometheus som vårt huvudverktyg. För varje metakluster samlar Prometheus-agenter in följande mätvärden:

• OS-mått som värdresurser (CPU, minne, disk, etc.) och nätverksbandbredd.
• Mätvärden för hanteringssystemet för metakluster och klientkluster, såsom kube-apiserver, kube-controller-manager och kube-scheduler.
• Mätvärden från kubernetes-state-metrics och cadvisor.
• etcd-mått som diskskrivtid, databasstorlek, genomströmning av anslutningar mellan noder, etc.

Global statistik samlas in med hjälp av en typisk flerskiktsaggregationsmodell. Övervakningsdata från varje metakluster aggregeras först i varje region och skickas sedan till en central server som visar helhetsbilden. Allt fungerar genom federationsmekanismen. En Prometheus-server i varje datacenter samlar in mätvärden från det datacentret, och den centrala Prometheus-servern ansvarar för att aggregera övervakningsdata. AlertManager ansluter till centrala Prometheus och skickar vid behov varningar via DingTalk, e-post, SMS etc. Visualisering - med Grafana.

I figur 10 kan övervakningssystemet delas in i tre nivåer:

• Gränsnivå

Lagret längst från mitten. Prometheus Edge Server körs i varje metakluster och samlar in mätvärden från meta- och klientkluster inom samma nätverksdomän.

• Kaskadnivå

Funktionen hos Prometheus kaskadlagret är att samla in övervakningsdata från flera regioner. Dessa servrar fungerar på nivå med större geografiska enheter som Kina, Asien, Europa och Amerika. När kluster växer kan regionen delas upp och sedan kommer en Prometheus-server på kaskadnivå att dyka upp i varje ny stor region. Med denna strategi kan du smidigt skala efter behov.

• Central nivå

Den centrala Prometheus-servern ansluter till alla kaskadservrar och utför den slutliga dataaggregationen. För tillförlitligheten togs två centrala Prometheus-instanser upp i olika zoner, kopplade till samma kaskadservrar.

Ris. 10. Global övervakningsarkitektur på flera nivåer baserad på Prometheus federationsmekanism

Sammanfattning

Kubernetes-baserade molnlösningar fortsätter att förändra vår bransch. Alibaba Cloud-containertjänst tillhandahåller säker, pålitlig och högpresterande värd - det är en av de bästa Kubernetes molnvärden. Alibaba Cloud-teamet tror starkt på principerna för öppen källkod och öppen källkod. Vi kommer definitivt att fortsätta att dela med oss ​​av vår kunskap inom området drift och hantering av molnteknologier.

Källa: will.com