Kocka na kocki, metaklasteri, saće, distribucija resursa

Riža. 1. Kubernetes ekosustav na Alibaba Cloudu

Od 2015. Alibaba Cloud Container Service za Kubernetes (ACK) jedna je od najbrže rastućih cloud usluga u Alibabi Cloudu. Služi brojnim klijentima, a također podržava internu infrastrukturu Alibabe i druge usluge u oblaku tvrtke.

Kao i kod sličnih kontejnerskih usluga vrhunskih pružatelja usluga oblaka, naši glavni prioriteti su pouzdanost i dostupnost. Stoga je stvorena skalabilna i globalno dostupna platforma za desetke tisuća Kubernetes klastera.

U ovom ćemo članku podijeliti naše iskustvo upravljanja velikim brojem Kubernetes klastera na infrastrukturi oblaka, kao i arhitekturu temeljne platforme.

Ulazak

Kubernetes je postao de facto standard za različita radna opterećenja u oblaku. Kao što je prikazano na sl. 1 gore, sve više i više Alibaba Cloud aplikacija sada se izvodi na Kubernetes klasterima: aplikacije s statusom i bez statusa, kao i upravitelji aplikacija. Upravljanje Kubernetesom oduvijek je bila zanimljiva i ozbiljna tema za raspravu inženjera koji grade i održavaju infrastrukturu. Kada je riječ o pružateljima usluga u oblaku kao što je Alibaba Cloud, pitanje skaliranja dolazi u prvi plan. Kako upravljati Kubernetes klasterima na ovoj razini? Već smo pokrili najbolje prakse za upravljanje ogromnim Kubernetes klasterima od 10 čvorova. Naravno, ovo je zanimljiv problem skaliranja. Ali postoji još jedna ljestvica: količina sami grozdovi.

Razgovarali smo o ovoj temi s mnogim korisnicima ACK-a. Većina njih odlučuje pokrenuti desetke, ako ne i stotine, malih ili srednjih Kubernetes klastera. Za to postoje dobri razlozi: ograničavanje potencijalne štete, odvajanje klastera za različite timove, stvaranje virtualnih klastera za testiranje. Ako ACK želi služiti globalnoj publici s ovim modelom upotrebe, mora pouzdano i učinkovito upravljati velikim brojem klastera u više od 20 regija.

Riža. 2. Problemi upravljanja velikim brojem Kubernetes klastera

Koji su glavni izazovi upravljanja klasterima na ovoj razini? Kao što je prikazano na slici, postoje četiri problema s kojima se treba pozabaviti:

• Heterogenost

ACK bi trebao podržavati različite tipove klastera, uključujući standardne, serverless, Edge, Windows i neke druge. Različiti klasteri zahtijevaju različite parametre, komponente i modele hostinga. Nekim klijentima je potrebna pomoć s konfiguracijom za njihove specifične potrebe.

• Različite veličine klastera

Klasteri se razlikuju po veličini, od nekoliko čvorova s ​​nekoliko mahuna do desetaka tisuća čvorova s ​​tisućama mahuna. Zahtjevi za resursima također se jako razlikuju. Nepravilna dodjela resursa može utjecati na performanse ili čak uzrokovati kvar.

• Različite verzije

Kubernetes se razvija vrlo brzo. Nove verzije izlaze svakih nekoliko mjeseci. Kupci su uvijek voljni isprobati nove značajke. Stoga žele staviti testno opterećenje na nove verzije Kubernetesa, a proizvodno opterećenje na stabilne. Kako bi ispunio ovaj zahtjev, ACK mora neprestano isporučivati ​​nove verzije Kubernetesa korisnicima, a istovremeno održavati stabilne verzije.

• Sigurnosna usklađenost

Klasteri su raspoređeni po različitim regijama. Kao takvi, moraju biti u skladu s raznim sigurnosnim zahtjevima i službenim propisima. Na primjer, klaster u Europi mora biti usklađen s GDPR-om, dok financijski oblak u Kini mora imati dodatne slojeve zaštite. Ovi zahtjevi su obvezni i neprihvatljivo ih je ignorirati, jer to stvara velike rizike za klijente cloud platforme.

ACK platforma dizajnirana je za rješavanje većine gore navedenih problema. Trenutno pouzdano i stabilno upravlja s više od 10 tisuća Kubernetes klastera diljem svijeta. Pogledajmo kako je to postignuto, uključujući kroz nekoliko ključnih načela dizajna/arhitekture.

Dizajn

Kocka na kocku i saće

Za razliku od centralizirane hijerarhije, arhitektura temeljena na ćelijama obično se koristi za skaliranje platforme izvan jednog podatkovnog centra ili za proširenje opsega oporavka od katastrofe.

Svaka regija u Alibaba Cloudu sastoji se od nekoliko zona (AZ) i obično odgovara određenom podatkovnom centru. U velikoj regiji (npr. Huangzhou) često postoje tisuće Kubernetesovih klastera klijenata koji pokreću ACK.

ACK upravlja tim Kubernetes klasterima koristeći sam Kubernetes, što znači da imamo Kubernetes metaklaster koji radi za upravljanje klijentskim Kubernetes klasterima. Ova se arhitektura naziva i "kube-on-kube" (KoK). KoK arhitektura pojednostavljuje upravljanje klasterima klijenata jer je implementacija klastera jednostavna i deterministička. Što je još važnije, možemo ponovno koristiti izvorne značajke Kubernetesa. Na primjer, upravljanje API poslužiteljima kroz implementaciju, korištenje operatora etcd za upravljanje više etcd-ova. Takva rekurzija uvijek donosi poseban užitak.

Nekoliko Kubernetes metaklastera raspoređeno je unutar jedne regije, ovisno o broju klijenata. Ove metaklastere nazivamo stanicama. Kako bi se zaštitio od kvara cijele zone, ACK podržava višestruke aktivne implementacije u jednoj regiji: metaklaster distribuira glavne komponente klastera Kubernetes klijenta u više zona i pokreće ih istovremeno, to jest u višestruko aktivnom načinu rada. Kako bi se osigurala pouzdanost i učinkovitost mastera, ACK optimizira smještaj komponenti i osigurava da su API poslužitelj i etcd blizu jedan drugoga.

Ovaj vam model omogućuje učinkovito, fleksibilno i pouzdano upravljanje Kubernetesom.

Planiranje resursa metaklastera

Kao što smo već spomenuli, broj metaklastera u svakoj regiji ovisi o broju klijenata. Ali u kojem trenutku dodati novi metaklaster? Ovo je tipičan problem planiranja resursa. U pravilu je uobičajeno stvoriti novi kada postojeći metaklasteri iscrpe sve svoje resurse.

Uzmimo, na primjer, mrežne resurse. U KoK arhitekturi, Kubernetes komponente iz klastera klijenata raspoređuju se kao podovi u metaklasteru. Koristimo Terway (Sl. 3) dodatak je visokih performansi koji je razvio Alibaba Cloud za upravljanje mrežom spremnika. Pruža bogat skup sigurnosnih pravila i omogućuje vam povezivanje s virtualnim privatnim oblacima (VPC) korisnika putem Alibaba Cloud Elastic Networking Interface (ENI). Kako bismo učinkovito distribuirali mrežne resurse po čvorovima, podovima i uslugama u metaklasteru, moramo pažljivo pratiti njihovu upotrebu unutar metaklastera virtualnih privatnih oblaka. Kada mrežni resursi dođu do kraja, stvara se nova ćelija.

Kako bismo odredili optimalan broj klastera klijenata u svakom metaklasteru, također uzimamo u obzir naše troškove, zahtjeve gustoće, kvotu resursa, zahtjeve pouzdanosti i statistiku. Na temelju svih ovih informacija donosi se odluka o stvaranju novog metaklastera. Imajte na umu da se mali klasteri mogu znatno proširiti u budućnosti, tako da se potrošnja resursa povećava čak i ako broj klastera ostane nepromijenjen. Obično ostavljamo dovoljno slobodnog prostora za rast svakog grozda.

Riža. 3. Arhitektura Terway mreže

Skaliranje komponenti čarobnjaka preko klastera klijenata

Komponente čarobnjaka imaju različite potrebe za resursima. Oni ovise o broju čvorova i podova u klasteru, broju nestandardnih kontrolera/operatora koji su u interakciji s APIServerom.

U ACK-u se svaki Kubernetes klijentski klaster razlikuje po veličini i zahtjevima vremena izvođenja. Ne postoji univerzalna konfiguracija za postavljanje komponenti čarobnjaka. Ako greškom postavimo nisko ograničenje resursa za velikog klijenta, tada njegov klaster neće moći podnijeti opterećenje. Ako postavite konzervativno visoku granicu za sve klastere, resursi će biti uzalud potrošeni.

Kako bi pronašao suptilan kompromis između pouzdanosti i cijene, ACK koristi sustav tipa. Naime, definiramo tri vrste klastera: mali, srednji i veliki. Svaki tip ima zasebni profil dodjele resursa. Vrsta se određuje na temelju opterećenja komponenti čarobnjaka, broja čvorova i drugih čimbenika. Vrsta klastera može se promijeniti tijekom vremena. ACK kontinuirano nadzire te faktore i prema tome može tipkati gore/dolje. Nakon što se tip klastera promijeni, dodjela resursa ažurira se automatski uz minimalnu intervenciju korisnika.

Radimo na poboljšanju ovog sustava preciznijim skaliranjem i preciznijim ažuriranjem tipa kako bi se te promjene odvijale glatko i imale više ekonomskog smisla.

Riža. 4. Inteligentno višestupanjsko prebacivanje tipa

Evolucija klastera klijenata na razini

Prethodni odjeljci pokrili su neke aspekte upravljanja velikim brojem Kubernetes klastera. Međutim, postoji još jedan problem koji treba riješiti: evolucija klastera.

Kubernetes je "Linux"u svijetu oblaka. Stalno se ažurira i postaje sve modularniji. Moramo stalno isporučivati ​​nove verzije našim kupcima, zakrpati ranjivosti i ažurirati postojeće klastere, kao i upravljati velikim brojem povezanih komponenti (CSI, CNI, dodatak za uređaje, dodatak za raspoređivanje i mnoge druge)."

Uzmimo upravljanje Kubernetes komponentama kao primjer. Za početak smo razvili centralizirani sustav za registraciju i upravljanje svim tim povezanim komponentama.

Riža. 5. Fleksibilne i priključne komponente

Prije nego krenete dalje, morate provjeriti je li ažuriranje uspješno. Da bismo to učinili, razvili smo sustav za provjeru funkcionalnosti komponenti. Provjera se provodi prije i nakon ažuriranja.

Riža. 6. Preliminarna provjera komponenti klastera

Za brzo i pouzdano ažuriranje ovih komponenti, kontinuirani sustav implementacije radi s podrškom za djelomično napredovanje (u sivim tonovima), pauze i druge funkcije. Standardni Kubernetes kontroleri nisu prikladni za ovaj slučaj upotrebe. Stoga smo za upravljanje komponentama klastera razvili skup specijaliziranih kontrolera, uključujući dodatak i pomoćni kontrolni modul (sidecar management).

Na primjer, kontroler BroadcastJob dizajniran je za ažuriranje komponenti na svakom radnom stroju ili provjeru čvorova na svakom stroju. Posao emitiranja pokreće pod na svakom čvoru u klasteru, poput DaemonSeta. Međutim, DaemonSet uvijek drži modul u radu dulje vrijeme, dok ga BroadcastJob urušava. Broadcast kontroler također pokreće podove na novopridruženim čvorovima i inicijalizira čvorove s potrebnim komponentama. U lipnju 2019. otvorili smo izvorni kod OpenKruise automatizacije, koji i sami koristimo unutar tvrtke.

Riža. 7. OpenKurise organizira izvršenje Broadcast zadatka na svim čvorovima

Kako bismo pomogli korisnicima da odaberu prave konfiguracije klastera, nudimo i skup unaprijed definiranih profila, uključujući Serverless, Edge, Windows i Bare Metal. Kako se područje djelovanja širi i potrebe naših kupaca se razvijaju, dodavat ćemo više profila kako bismo pojednostavili zamoran proces postavljanja.

Riža. 8. Napredni i fleksibilni profili klastera za različite scenarije

Globalna vidljivost u podatkovnim centrima

Kao što je prikazano na sl. 9, usluga oblaka Alibaba Cloud Container postavljena je u dvadeset regija diljem svijeta. S obzirom na ovu ljestvicu, jedan od ključnih ciljeva ACK-a je jednostavno nadzirati stanje pokrenutih klastera tako da ako klaster klijenata naiđe na problem, možemo brzo odgovoriti na situaciju. Drugim riječima, trebate smisliti rješenje koje će vam omogućiti učinkovito i sigurno prikupljanje statistike u stvarnom vremenu iz klastera klijenata u svim regijama – i vizualno prezentirati rezultate.

Riža. 9. Globalna implementacija usluge Alibaba Cloud Container u dvadeset regija

Kao i mnogi Kubernetes nadzorni sustavi, koristimo Prometheus kao naš glavni alat. Za svaki metaklaster, Prometheus agenti prikupljaju sljedeće metrike:

• Mjerni podaci OS-a kao što su resursi glavnog računala (CPU, memorija, disk itd.) i propusnost mreže.
• Mjerne vrijednosti za sustav upravljanja metaklasterom i klasterom klijenata, kao što su kube-apiserver, kube-controller-manager i kube-scheduler.
• Mjerni podaci iz kubernetes-state-metrics i cadvisora.
• etcd metrike kao što su vrijeme pisanja na disk, veličina baze podataka, propusnost veza između čvorova itd.

Globalna statistika prikuplja se pomoću tipičnog višeslojnog modela agregacije. Podaci praćenja iz svakog metaklastera prvo se skupljaju u svakoj regiji, a zatim šalju na središnji poslužitelj koji prikazuje cjelokupnu sliku. Sve funkcionira kroz mehanizam federacije. Prometheus poslužitelj u svakom podatkovnom centru prikuplja metrike iz tog podatkovnog centra, a središnji Prometheus poslužitelj odgovoran je za agregiranje podataka praćenja. AlertManager se povezuje sa središnjim Prometheusom i po potrebi šalje upozorenja putem DingTalka, e-maila, SMS-a itd. Vizualizacija - pomoću Grafana.

Na slici 10 sustav nadzora može se podijeliti na tri razine:

• Granična razina

Sloj najudaljeniji od središta. Prometheus Edge Server radi u svakom metaklasteru, prikupljajući metriku iz meta i klastera klijenata unutar iste mrežne domene.

• Kaskadna razina

Funkcija kaskadnog sloja Prometheus je prikupljanje podataka praćenja iz više regija. poslužitelji Oni djeluju na razini većih geografskih jedinica, kao što su Kina, Azija, Europa i Amerika. Kako klasteri rastu, regija se može podijeliti, a u svakoj novoj velikoj regiji bit će raspoređen kaskadni Prometheus poslužitelj. Ova strategija omogućuje glatko skaliranje prema potrebi.

• Centralna razina

Centralni Prometheus poslužitelj povezuje se sa svim kaskadnim poslužiteljima i vrši konačnu agregaciju podataka. Radi pouzdanosti, dvije središnje instance Prometheusa podignute su u različitim zonama, povezane s istim kaskadnim poslužiteljima.

Riža. 10. Globalna višerazinska nadzorna arhitektura temeljena na Prometheusovom mehanizmu federacije

Rezime

Rješenja u oblaku temeljena na Kubernetesu nastavljaju transformirati našu industriju. Usluga Alibaba Cloud kontejner pruža sigurno, pouzdano i visokoučinkovito hosting - to je jedno od najboljih Kubernetes cloud hostinga. Alibaba Cloud tim snažno vjeruje u načela otvorenog koda i zajednice otvorenog koda. Svakako ćemo nastaviti dijeliti svoje znanje iz područja rada i upravljanja cloud tehnologijama.

Izvor: www.habr.com