Terning-på-terning, metaclusters, honeycombs, ressourcefordeling

Ris. 1. Kubernetes økosystem på Alibaba Cloud

Siden 2015 har Alibaba Cloud Container Service for Kubernetes (ACK) været en af ​​de hurtigst voksende cloud-tjenester i Alibaba Cloud. Det betjener adskillige kunder og understøtter også Alibabas interne infrastruktur og virksomhedens andre cloud-tjenester.

Som med lignende containertjenester fra cloud-udbydere i verdensklasse, er vores topprioriteter pålidelighed og tilgængelighed. Derfor er der skabt en skalerbar og globalt tilgængelig platform for titusindvis af Kubernetes-klynger.

I denne artikel vil vi dele vores erfaring med at administrere et stort antal Kubernetes-klynger på cloud-infrastruktur, samt arkitekturen af ​​den underliggende platform.

Indrejse

Kubernetes er blevet de facto-standarden for en række forskellige arbejdsbelastninger i skyen. Som vist i fig. 1 ovenfor, kører flere og flere Alibaba Cloud-applikationer nu på Kubernetes-klynger: stateful og stateless-applikationer, såvel som applikationsadministratorer. Kubernetes-ledelse har altid været et interessant og seriøst diskussionsemne for ingeniører, der bygger og vedligeholder infrastruktur. Når det kommer til cloud-udbydere som Alibaba Cloud, kommer spørgsmålet om skalering på banen. Hvordan administrerer man Kubernetes-klynger i denne skala? Vi har allerede dækket bedste praksis for administration af enorme Kubernetes-klynger med 10 noder. Selvfølgelig er dette et interessant skaleringsproblem. Men der er en anden skala: mængde selve klyngerne.

Vi har diskuteret dette emne med mange ACK-brugere. De fleste af dem vælger at køre snesevis, hvis ikke hundredvis, af små eller mellemstore Kubernetes-klynger. Der er gode grunde til dette: begrænsning af potentielle skader, adskillelse af klynger for forskellige teams, oprettelse af virtuelle klynger til test. Hvis ACK sigter mod at betjene et globalt publikum med denne brugsmodel, skal det pålideligt og effektivt administrere et stort antal klynger på tværs af mere end 20 regioner.

Ris. 2. Problemer med at administrere et stort antal Kubernetes-klynger

Hvad er hovedudfordringerne ved at styre klynger i denne skala? Som vist i figuren er der fire problemer at tage sig af:

• Heterogenitet

ACK bør understøtte forskellige typer klynger, inklusive standard, serverløse, Edge, Windows og flere andre. Forskellige klynger kræver forskellige muligheder, komponenter og hostingmodeller. Nogle kunder har brug for hjælp til tilpasning til deres specifikke sager.

• Forskellige klyngestørrelser

Klynger varierer i størrelse: fra et par noder med flere bælg til titusindvis af noder med tusindvis af bælg. Kravene til ressourcer varierer også meget. Forkert ressourceallokering kan påvirke ydeevnen eller endda forårsage fejl.

• Forskellige versioner

Kubernetes udvikler sig meget hurtigt. Nye versioner udgives hvert par måneder. Kunder er altid villige til at prøve nye funktioner. Så de vil placere testbelastningen på de nye versioner af Kubernetes og produktionsbelastningen på de stabile. For at imødekomme dette krav skal ACK løbende levere nye versioner af Kubernetes til kunder og samtidig bevare stabile versioner.

• Sikkerhedsoverholdelse

Klynger er fordelt på tværs af forskellige regioner. Som sådan skal de overholde forskellige sikkerhedskrav og officielle forskrifter. For eksempel skal en klynge i Europa være GDPR-kompatibel, mens en finansiel sky i Kina skal have yderligere beskyttelseslag. Disse krav er obligatoriske, og det er uacceptabelt at ignorere dem, da dette skaber enorme risici for cloud-platformens kunder.

ACK-platformen er designet til at løse de fleste af ovenstående problemer. Det administrerer i øjeblikket pålideligt og stabilt mere end 10 tusinde Kubernetes-klynger rundt om i verden. Lad os se på, hvordan dette blev opnået, herunder gennem flere centrale design-/arkitekturprincipper.

design

Terning-på-terning og honeycomb

I modsætning til et centraliseret hierarki bruges cellebaseret arkitektur typisk til at skalere en platform ud over et enkelt datacenter eller til at udvide omfanget af katastrofegendannelse.

Hver region i Alibaba Cloud består af flere zoner (AZ) og svarer normalt til et specifikt datacenter. I en stor region (f.eks. Huangzhou) er der ofte tusindvis af Kubernetes-klientklynger, der kører ACK.

ACK administrerer disse Kubernetes-klynger ved hjælp af Kubernetes selv, hvilket betyder, at vi har en Kubernetes-metacluster, der kører til at administrere Kubernetes-klientens klynger. Denne arkitektur kaldes også "kube-on-kube" (KoK). KoK-arkitekturen forenkler administrationen af ​​klientklynger, fordi klyngeimplementering er enkel og deterministisk. Endnu vigtigere, vi kan genbruge indbyggede Kubernetes-funktioner. For eksempel styring af API-servere gennem implementering, brug af etcd-operatøren til at administrere flere etcd'er. En sådan rekursion bringer altid særlig glæde.

Adskillige Kubernetes-metaklynger er implementeret inden for én region, afhængigt af antallet af klienter. Vi kalder disse metaclusters celler. For at beskytte mod svigt af en hel zone, understøtter ACK multi-aktive implementeringer i en enkelt region: metaklyngen distribuerer Kubernetes klientklyngemasterkomponenter på tværs af flere zoner og kører dem samtidigt, det vil sige i multiaktiv tilstand. For at sikre masterens pålidelighed og effektivitet optimerer ACK placeringen af ​​komponenter og sikrer, at API-serveren og etcd er tæt på hinanden.

Denne model giver dig mulighed for at administrere Kubernetes effektivt, fleksibelt og pålideligt.

Metacluster ressourceplanlægning

Som vi allerede har nævnt, afhænger antallet af metaclusters i hver region af antallet af klienter. Men på hvilket tidspunkt skal man tilføje en ny metaklynge? Dette er et typisk ressourceplanlægningsproblem. Som regel er det sædvanligt at oprette en ny, når eksisterende metaklynger har opbrugt alle deres ressourcer.

Lad os tage netværksressourcer, for eksempel. I KoK-arkitekturen er Kubernetes-komponenter fra klientklynger implementeret som pods i en metacluster. Vi bruger Terway (Fig. 3) er et højtydende plugin udviklet af Alibaba Cloud til administration af containernetværk. Det giver et rigt sæt sikkerhedspolitikker og giver dig mulighed for at oprette forbindelse til kunders virtuelle private skyer (VPC'er) gennem Alibaba Cloud Elastic Networking Interface (ENI). For effektivt at distribuere netværksressourcer på tværs af noder, pods og tjenester i en metacluster, skal vi nøje overvåge deres brug i metaklyngen af ​​virtuelle private skyer. Når netværksressourcer slutter, oprettes en ny celle.

For at bestemme det optimale antal klientklynger i hver metacluster tager vi også hensyn til vores omkostninger, tæthedskrav, ressourcekvote, pålidelighedskrav og statistik. Beslutningen om at oprette en ny metaklynge tages på baggrund af al denne information. Vær opmærksom på, at små klynger kan udvide sig meget i fremtiden, så ressourceforbruget stiger, selvom antallet af klynger forbliver uændret. Vi efterlader normalt nok ledig plads til, at hver klynge kan vokse.

Ris. 3. Terway netværksarkitektur

Skalering af wizardkomponenter på tværs af klientklynger

Wizard-komponenter har forskellige ressourcebehov. De afhænger af antallet af noder og pods i klyngen, antallet af ikke-standard controllere/operatører, der interagerer med APIServer.

I ACK adskiller hver Kubernetes-klientklynge sig i størrelse og krav til kørselstid. Der er ingen universel konfiguration til placering af wizardkomponenter. Hvis vi ved en fejl sætter en lav ressourcegrænse for en stor klient, vil dens klynge ikke være i stand til at klare belastningen. Hvis du sætter en konservativ høj grænse for alle klynger, vil ressourcer blive spildt.

For at finde en subtil afvejning mellem pålidelighed og pris, bruger ACK et typesystem. Vi definerer nemlig tre typer klynger: lille, mellem og stor. Hver type har en separat ressourceallokeringsprofil. Typen bestemmes ud fra belastningen af ​​wizardkomponenter, antallet af noder og andre faktorer. Klyngetypen kan ændre sig over tid. ACK overvåger løbende disse faktorer og kan skrive op/ned i overensstemmelse hermed. Når klyngetypen er ændret, opdateres ressourceallokeringen automatisk med minimal brugerindblanding.

Vi arbejder på at forbedre dette system med finere skalering og mere præcis typeopdatering, så disse ændringer sker mere smidigt og giver mere økonomisk mening.

Ris. 4. Intelligent multi-stage type switching

Udvikling af klientklynger i skala

De foregående afsnit dækkede nogle aspekter af styring af et stort antal Kubernetes-klynger. Der er dog et andet problem, der skal løses: udviklingen af ​​klynger.

Kubernetes er "Linux" i skyverdenen. Den opdateres løbende og bliver mere modulopbygget. Vi skal konstant levere nye versioner til vores kunder, rette sårbarheder og opdatere eksisterende klynger, samt administrere en lang række relaterede komponenter (CSI, CNI, Device Plugin, Scheduler Plugin og mange andre).

Lad os tage Kubernetes komponentstyring som et eksempel. Til at begynde med udviklede vi et centraliseret system til registrering og styring af alle disse forbundne komponenter.

Ris. 5. Fleksible og pluggbare komponenter

Før du går videre, skal du sikre dig, at opdateringen lykkedes. For at gøre dette har vi udviklet et system til kontrol af komponenternes funktionalitet. Kontrollen udføres før og efter opdateringen.

Ris. 6. Foreløbig kontrol af klyngekomponenter

For hurtigt og pålideligt at opdatere disse komponenter fungerer et kontinuerligt udrulningssystem med understøttelse af delvis fremrykning (gråtoner), pauser og andre funktioner. Standard Kubernetes-controllere er ikke velegnede til denne brug. For at administrere klyngekomponenter har vi derfor udviklet et sæt specialiserede controllere, herunder et plugin og et hjælpekontrolmodul (sidevognsstyring).

For eksempel er BroadcastJob-controlleren designet til at opdatere komponenter på hver arbejdsmaskine eller kontrollere noder på hver maskine. Broadcast-jobbet kører en pod på hver node i klyngen, ligesom et DaemonSet. DaemonSet holder dog altid poden kørende i lang tid, mens BroadcastJob kollapser den. Broadcast-controlleren starter også pods på nyligt sammenføjede noder og initialiserer noderne med de nødvendige komponenter. I juni 2019 åbnede vi kildekoden til OpenKruise automationsmotoren, som vi selv bruger i virksomheden.

Ris. 7. OpenKurise organiserer udførelsen af ​​Broadcast-opgaven på alle noder

For at hjælpe kunderne med at vælge de rigtige klyngekonfigurationer leverer vi også et sæt foruddefinerede profiler, herunder serverløse, Edge-, Windows- og Bare Metal-profiler. Efterhånden som landskabet udvides, og vores kunders behov vokser, vil vi tilføje flere profiler for at forenkle den kedelige opsætningsproces.

Ris. 8. Avancerede og fleksible klyngeprofiler til forskellige scenarier

Global observerbarhed på tværs af datacentre

Som vist i nedenstående fig. 9, Alibaba Cloud Container cloud-tjeneste er blevet implementeret i tyve regioner rundt om i verden. I betragtning af denne skala er et af hovedmålene med ACK nemt at overvåge tilstanden af ​​kørende klynger, så hvis en klientklynge støder på et problem, kan vi hurtigt reagere på situationen. Du skal med andre ord finde på en løsning, der giver dig mulighed for effektivt og sikkert at indsamle statistik i realtid fra klientklynger i alle regioner - og visuelt præsentere resultaterne.

Ris. 9. Global implementering af Alibaba Cloud Container-tjeneste i tyve regioner

Ligesom mange Kubernetes overvågningssystemer bruger vi Prometheus som vores hovedværktøj. For hver metacluster indsamler Prometheus-agenter følgende metrics:

• OS-metrics såsom værtsressourcer (CPU, hukommelse, disk osv.) og netværksbåndbredde.
• Metrics for metacluster- og klientklyngestyringssystemet, såsom kube-apiserver, kube-controller-manager og kube-scheduler.
• Metrics fra kubernetes-state-metrics og cadvisor.
• etcd-metrikker såsom diskskrivetid, databasestørrelse, gennemløb af links mellem noder osv.

Global statistik indsamles ved hjælp af en typisk flerlags aggregeringsmodel. Overvågningsdata fra hver metacluster aggregeres først i hver region og sendes derefter til en central server, som viser det overordnede billede. Alt fungerer gennem føderationsmekanismen. En Prometheus-server i hvert datacenter indsamler metrics fra det pågældende datacenter, og den centrale Prometheus-server er ansvarlig for at samle overvågningsdata. AlertManager forbinder til det centrale Prometheus og sender alarmer efter behov via DingTalk, e-mail, SMS osv. Visualisering - Brug af Grafana.

I figur 10 kan overvågningssystemet opdeles i tre niveauer:

• Grænseniveau

Laget længst fra midten. Prometheus Edge Server kører i hver metacluster og indsamler metrics fra meta- og klientklynger inden for det samme netværksdomæne.

• Kaskade niveau

Funktionen af ​​Prometheus-kaskadelaget er at indsamle overvågningsdata fra flere regioner. Disse servere opererer på niveau med større geografiske enheder som Kina, Asien, Europa og Amerika. Efterhånden som klynger vokser, kan regionen opdeles, og så vil en Prometheus-server på kaskadeniveau dukke op i hver ny stor region. Med denne strategi kan du nemt skalere efter behov.

• Centralt niveau

Den centrale Prometheus-server opretter forbindelse til alle kaskadeservere og udfører den endelige dataaggregering. For pålidelighedens skyld blev to centrale Prometheus-instanser rejst i forskellige zoner, forbundet til de samme kaskadeservere.

Ris. 10. Global multi-level overvågningsarkitektur baseret på Prometheus federationsmekanismen

Resumé

Kubernetes-baserede cloud-løsninger fortsætter med at transformere vores branche. Alibaba Cloud container service giver sikker, pålidelig og højtydende hosting - det er en af ​​de bedste Kubernetes cloud hosting. Alibaba Cloud-teamet tror stærkt på principperne for Open Source og open source-fællesskabet. Vi vil helt sikkert fortsætte med at dele vores viden inden for drift og administration af cloud-teknologier.

Kilde: www.habr.com