Kuubik-kuubik, metaklastrid, kärjed, ressursside jaotus

Riis. 1. Kubernetese ökosüsteem Alibaba pilvel

Alates 2015. aastast on Alibaba Cloud Container Service for Kubernetes (ACK) olnud Alibaba Cloudi üks kiiremini kasvavaid pilveteenuseid. See teenindab paljusid kliente ning toetab ka Alibaba sisemist infrastruktuuri ja ettevõtte muid pilveteenuseid.

Sarnaselt maailmatasemel pilveteenuse pakkujate sarnaste konteinerteenustega on meie peamised prioriteedid töökindlus ja kättesaadavus. Seetõttu on kümnete tuhandete Kubernetese klastrite jaoks loodud skaleeritav ja globaalselt juurdepääsetav platvorm.

Selles artiklis jagame oma kogemusi suure hulga Kubernetese klastrite haldamisel pilveinfrastruktuuris ja ka aluseks oleva platvormi arhitektuuri.

Kanne

Kubernetesest on saanud de facto standard pilves mitmesuguste töökoormuste jaoks. Nagu on näidatud joonisel fig. 1 ülaltoodud, Kubernetese klastrites töötab nüüd üha rohkem Alibaba Cloudi rakendusi: olekuga ja olekuta rakendused, samuti rakenduste haldurid. Inseneride jaoks, kes ehitavad ja hooldavad infrastruktuuri, on Kubernetese juhtimine alati olnud huvitav ja tõsine aruteluteema. Kui rääkida pilveteenuse pakkujatest, nagu Alibaba Cloud, on skaleerimise küsimus esiplaanil. Kuidas sellises mahus Kubernetese klastreid hallata? Oleme juba käsitlenud parimaid tavasid tohutute 10 000 sõlmega Kubernetese klastrite haldamiseks. Muidugi on see huvitav skaleerimise probleem. Kuid on ka teine ​​skaala: kvantiteet klastrid ise.

Oleme seda teemat arutanud paljude ACK kasutajatega. Enamik neist otsustab juhtida kümneid, kui mitte sadu väikeseid või keskmise suurusega Kubernetese klastreid. Sellel on mõjuvad põhjused: võimalike kahjude piiramine, erinevate meeskondade klastrite eraldamine, testimiseks virtuaalsete klastrite loomine. Kui ACK-i eesmärk on teenindada selle kasutusmudeliga ülemaailmset vaatajaskonda, peab see usaldusväärselt ja tõhusalt haldama suurt hulka klastreid rohkem kui 20 piirkonnas.

Riis. 2. Probleemid suure hulga Kubernetese klastrite haldamisel

Millised on selle mastaabiga klastrite haldamise peamised väljakutsed? Nagu on näidatud joonisel, tuleb lahendada neli probleemi:

• Heterogeensus

ACK peaks toetama erinevat tüüpi klastreid, sealhulgas standardseid, serverita, Edge'i, Windowsi ja mitmeid teisi. Erinevad klastrid nõuavad erinevaid valikuid, komponente ja hostimismudeleid. Mõned kliendid vajavad abi oma konkreetsete juhtumite jaoks kohandamisel.

• Erinevad klastri suurused

Klastrid on erineva suurusega, alates paarist mõne kaunaga sõlmest kuni kümnete tuhandete sõlmedeni tuhandete kaunadega. Ressursinõuded on samuti väga erinevad. Vale ressursside eraldamine võib mõjutada jõudlust või isegi põhjustada tõrkeid.

• Erinevad versioonid

Kubernetes areneb väga kiiresti. Uued versioonid ilmuvad iga paari kuu tagant. Kliendid on alati valmis uusi funktsioone proovima. Seega tahetakse katsekoormus panna Kubernetese uutele versioonidele ja tootmiskoormus stabiilsetele. Selle nõude täitmiseks peab ACK pidevalt tarnima klientidele Kubernetese uusi versioone, säilitades samal ajal stabiilsed versioonid.

• Turvalisuse järgimine

Klastrid on jaotatud erinevatesse piirkondadesse. Sellisena peavad need vastama erinevatele ohutusnõuetele ja ametlikele eeskirjadele. Näiteks peab klaster Euroopas vastama GDPR-ile, samas kui Hiina finantspilvel peab olema täiendav kaitsekiht. Need nõuded on kohustuslikud ja nende eiramine on vastuvõetamatu, kuna see tekitab pilveplatvormi klientidele suuri riske.

ACK platvorm on loodud enamiku ülaltoodud probleemide lahendamiseks. Praegu haldab see usaldusväärselt ja stabiilselt enam kui 10 tuhat Kubernetese klastrit üle maailma. Vaatame, kuidas see saavutati, sealhulgas mitme peamise disaini/arhitektuuri põhimõtte kaudu.

Disain

Kuubik-kuubik ja kärg

Erinevalt tsentraliseeritud hierarhiast kasutatakse rakupõhist arhitektuuri tavaliselt platvormi skaleerimiseks ühest andmekeskusest kaugemale või katastroofi taastamise ulatuse laiendamiseks.

Iga Alibaba pilve piirkond koosneb mitmest tsoonist (AZ) ja vastab tavaliselt konkreetsele andmekeskusele. Suures piirkonnas (nt Huangzhou) on sageli tuhandeid Kubernetese kliendiklastreid, mis käitavad ACK-i.

ACK haldab neid Kubernetese klastreid Kubernetese enda abil, mis tähendab, et meil töötab Kubernetese metaklaster, mis haldab kliendi Kubernetese klastreid. Seda arhitektuuri nimetatakse ka "kube-on-kube" (KoK). KoK arhitektuur lihtsustab kliendiklastrite haldamist, kuna klastri juurutamine on lihtne ja deterministlik. Veelgi olulisem on see, et saame Kubernetese natiivseid funktsioone uuesti kasutada. Näiteks API-serverite haldamine juurutamise kaudu, operaatori etcd kasutamine mitme etcd haldamiseks. Selline rekursioon pakub alati erilist naudingut.

Sõltuvalt klientide arvust on ühes piirkonnas juurutatud mitu Kubernetese metaklastrit. Me nimetame neid metaklastreid rakkudeks. Terve tsooni rikke eest kaitsmiseks toetab ACK mitmeaktiivset juurutust ühes piirkonnas: metaklaster jaotab Kubernetese kliendiklastri põhikomponendid mitme tsooni vahel ja käitab neid samaaegselt, st multiaktiivses režiimis. Ülemseadme töökindluse ja tõhususe tagamiseks optimeerib ACK komponentide paigutust ning tagab API serveri ja etcd üksteise lähedal.

See mudel võimaldab hallata Kubernetest tõhusalt, paindlikult ja usaldusväärselt.

Metaklustri ressursside planeerimine

Nagu me juba mainisime, sõltub metaklastrite arv igas piirkonnas klientide arvust. Aga mis hetkel lisada uus metaklaster? See on tüüpiline ressursside planeerimise probleem. Reeglina on tavaks luua uus siis, kui olemasolevad metaklastrid on kõik oma ressursid ammendanud.

Võtame näiteks võrguressursid. KoK-arhitektuuris juurutatakse kliendiklastritest pärit Kubernetese komponendid metaklastris kaunadena. Me kasutame Terway (Joonis 3) on Alibaba Cloudi poolt välja töötatud suure jõudlusega pistikprogramm konteinerivõrgu haldamiseks. See pakub rikkalikku turbepoliitikat ja võimaldab teil Alibaba pilve elastse võrguliidese (ENI) kaudu luua ühenduse klientide virtuaalsete privaatpilvedega (VPC). Võrguressursside tõhusaks jaotamiseks metaklastri sõlmede, kaustade ja teenuste vahel peame hoolikalt jälgima nende kasutamist virtuaalsete privaatpilvede metaklastris. Kui võrguressursid lõppevad, luuakse uus lahter.

Igas metaklastris optimaalse kliendiklastrite arvu määramiseks võtame arvesse ka oma kulusid, tihedusnõudeid, ressursikvooti, ​​töökindlusnõudeid ja statistikat. Kogu selle teabe põhjal tehakse otsus uue metaklastri loomiseks. Pange tähele, et väikesed klastrid võivad tulevikus oluliselt laieneda, seega suureneb ressursside tarbimine isegi siis, kui klastrite arv jääb muutumatuks. Tavaliselt jätame iga klastri kasvamiseks piisavalt vaba ruumi.

Riis. 3. Terway võrgu arhitektuur

Nõustaja komponentide skaleerimine kliendiklastrite lõikes

Nõustaja komponentidel on erinevad ressursivajadused. Need sõltuvad sõlmede ja kaustade arvust klastris, APIServeriga suhtlevate mittestandardsete kontrollerite/operaatorite arvust.

ACK-is on iga Kubernetese kliendiklaster erinev suuruse ja käitusaja nõuete poolest. Nõustaja komponentide paigutamiseks pole universaalset konfiguratsiooni. Kui seame suurele kliendile ekslikult madala ressursilimiidi, siis tema klaster ei tule koormusega toime. Kui seate kõikidele klastritele konservatiivselt kõrge limiidi, lähevad ressursid raisku.

Peene kompromissi leidmiseks usaldusväärsuse ja kulude vahel kasutab ACK tüübisüsteemi. Nimelt defineerime kolme tüüpi klastreid: väikesed, keskmised ja suured. Igal tüübil on eraldi ressursside eraldamise profiil. Tüüp määratakse viisardi komponentide koormuse, sõlmede arvu ja muude tegurite põhjal. Klastri tüüp võib aja jooksul muutuda. ACK jälgib neid tegureid pidevalt ja saab vastavalt üles/alla trükkida. Kui klastri tüüpi on muudetud, värskendatakse ressursside eraldamist automaatselt minimaalse kasutaja sekkumisega.

Töötame selle süsteemi täiustamise nimel peenema skaleerimise ja täpsema tüübivärskendusega, et need muudatused toimuksid sujuvamalt ja oleksid majanduslikult mõttekamad.

Riis. 4. Arukas mitmeastmeline tüübivahetus

Kliendiklastrite areng mastaabis

Eelmistes jaotistes käsitleti suure hulga Kubernetese klastrite haldamise mõningaid aspekte. Siiski on veel üks probleem, mis vajab lahendamist: klastrite areng.

Kubernetes on pilvemaailma Linux. Seda uuendatakse pidevalt ja see muutub modulaarsemaks. Peame oma klientidele pidevalt uusi versioone tarnima, haavatavusi parandama ja olemasolevaid klastreid uuendama, samuti haldama suurt hulka seotud komponente (CSI, CNI, Device Plugin, Scheduler Plugin ja paljud teised).

Võtame näiteks Kubernetese komponentide haldamise. Alustuseks töötasime välja tsentraliseeritud süsteemi kõigi nende ühendatud komponentide registreerimiseks ja haldamiseks.

Riis. 5. Paindlikud ja ühendatavad komponendid

Enne edasiliikumist peate veenduma, et värskendus õnnestus. Selleks oleme välja töötanud süsteemi komponentide funktsionaalsuse kontrollimiseks. Kontrollimine toimub enne ja pärast värskendamist.

Riis. 6. Klastri komponentide eelkontroll

Nende komponentide kiireks ja usaldusväärseks värskendamiseks töötab pidev juurutamise süsteem, mis toetab osalist edasiliikumist (hallitoonid), pause ja muid funktsioone. Standardsed Kubernetese kontrollerid ei sobi selle kasutusjuhtumi jaoks hästi. Seetõttu oleme klastri komponentide haldamiseks välja töötanud spetsiaalsete kontrollerite komplekti, sealhulgas pistikprogrammi ja lisajuhtimismooduli (külgkorvi haldus).

Näiteks BroadcastJobi kontroller on loodud iga töötaja masina komponentide värskendamiseks või iga masina sõlmede kontrollimiseks. Broadcast töö käivitab klastri igas sõlmes podi, nagu DaemonSet. Kuid DaemonSet hoiab podi alati pikka aega töös, samal ajal kui BroadcastJob ahendab selle. Broadcast-kontroller käivitab ka äsja ühendatud sõlmede podid ja lähtestab sõlmed vajalike komponentidega. 2019. aasta juunis avasime OpenKruise automaatikamootori lähtekoodi, mida ise ettevõtte sees kasutame.

Riis. 7. OpenKurise korraldab Broadcast ülesande täitmise kõigis sõlmedes

Et aidata klientidel valida õigeid klastri konfiguratsioone, pakume ka komplekti eelmääratletud profiile, sealhulgas serverita, Edge'i, Windowsi ja Bare Metal profiilid. Maastiku laienedes ja klientide vajaduste kasvades lisame tüütu seadistamisprotsessi lihtsustamiseks rohkem profiile.

Riis. 8. Täiustatud ja paindlikud klastriprofiilid erinevate stsenaariumide jaoks

Globaalne jälgitavus andmekeskustes

Nagu on näidatud alloleval joonisel fig. 9, Alibaba Cloud Container pilveteenust on kasutusele võetud kahekümnes piirkonnas üle maailma. Seda skaalat arvestades on ACK-i üks peamisi eesmärke hõlpsalt jälgida töötavate klastrite olekut, et kui kliendiklastril tekib probleem, saaksime olukorrale kiiresti reageerida. Teisisõnu, peate leidma lahenduse, mis võimaldab tõhusalt ja turvaliselt koguda reaalajas statistikat kliendiklastritest kõigis piirkondades – ja tulemusi visuaalselt esitada.

Riis. 9. Alibaba Cloud Containeri teenuse ülemaailmne juurutamine kahekümnes piirkonnas

Nagu paljud Kubernetese seiresüsteemid, kasutame ka meie peamise tööriistana Prometheust. Iga metaklastri kohta koguvad Prometheuse agendid järgmised mõõdikud:

• OS-i mõõdikud, nagu hostiressursid (CPU, mälu, ketas jne) ja võrgu ribalaius.
• Metaklastri ja kliendiklastri haldussüsteemi mõõdikud, nagu kube-apiserver, kube-controller-manager ja kube-scheduler.
• Kubernetes-state-metrics ja cadvisorist pärit mõõdikud.
• etcd mõõdikud, nagu ketta kirjutamisaeg, andmebaasi suurus, sõlmede vaheliste ühenduste läbilaskevõime jne.

Globaalset statistikat kogutakse tüüpilise mitmekihilise koondamismudeli abil. Iga metaklastri seireandmed koondatakse esmalt igas piirkonnas ja saadetakse seejärel keskserverisse, mis näitab üldpilti. Kõik toimib föderatsioonimehhanismi kaudu. Igas andmekeskuses olev Prometheuse server kogub sellest andmekeskusest mõõdikuid ja keskne Prometheuse server vastutab seireandmete koondamise eest. AlertManager ühendub keskse Prometheusega ja vajadusel saadab teateid DingTalki, e-posti, SMSi jne kaudu. Visualiseerimine – Grafana abil.

Joonisel 10 võib seiresüsteemi jagada kolmeks tasemeks:

• Piiritase

Keskmest kõige kaugemal asuv kiht. Prometheus Edge Server töötab igas metaklastris, kogudes mõõdikuid meta- ja kliendiklastritest samas võrgudomeenis.

• Kaskaadi tase

Prometheuse kaskaadikihi ülesanne on koguda seireandmeid mitmest piirkonnast. Need serverid töötavad suuremate geograafiliste üksuste, nagu Hiina, Aasia, Euroopa ja Ameerika tasandil. Klastrite kasvades saab piirkonda jagada ja seejärel ilmub igasse uude suurde piirkonda kaskaaditasemel Prometheuse server. Selle strateegiaga saate sujuvalt vastavalt vajadusele skaleerida.

• Keskne tase

Keskne Prometheuse server loob ühenduse kõigi kaskaadserveritega ja teostab lõpliku andmete koondamise. Töökindluse huvides tõsteti erinevatesse tsoonidesse kaks keskset Prometheuse eksemplari, mis olid ühendatud samade kaskaadserveritega.

Riis. 10. Prometheuse föderatsioonimehhanismil põhinev globaalne mitmetasandiline seirearhitektuur

Kokkuvõte

Kubernetesel põhinevad pilvelahendused muudavad meie tööstust jätkuvalt. Alibaba Cloud konteinerteenus pakub turvalist, usaldusväärset ja suure jõudlusega hostimist – see on üks parimaid Kubernetese pilvemajutusi. Alibaba Cloudi meeskond usub kindlalt avatud lähtekoodi ja avatud lähtekoodiga kogukonna põhimõtetesse. Kindlasti jätkame oma teadmiste jagamist pilvetehnoloogiate opereerimise ja haldamise vallas.

Allikas: www.habr.com