Cube-on-cube, metaclusters, honeycombs, pamamahagi ng mapagkukunan

kanin. 1. Kubernetes ecosystem sa Alibaba Cloud

Mula noong 2015, ang Alibaba Cloud Container Service para sa Kubernetes (ACK) ay isa sa pinakamabilis na lumalagong mga serbisyo sa cloud sa Alibaba Cloud. Nagsisilbi ito sa maraming kliyente at sinusuportahan din ang panloob na imprastraktura ng Alibaba at ang iba pang serbisyo ng cloud ng kumpanya.

Tulad ng mga katulad na serbisyo ng container mula sa mga world-class na cloud provider, ang aming mga pangunahing priyoridad ay ang pagiging maaasahan at availability. Samakatuwid, ang isang nasusukat at naa-access sa buong mundo na platform ay nilikha para sa libu-libong mga kumpol ng Kubernetes.

Sa artikulong ito, ibabahagi namin ang aming karanasan sa pamamahala ng malaking bilang ng mga kumpol ng Kubernetes sa imprastraktura ng ulap, pati na rin ang arkitektura ng pinagbabatayan na platform.

Pagpasok

Ang Kubernetes ay naging de facto na pamantayan para sa iba't ibang workload sa cloud. Gaya ng ipinapakita sa Fig. 1 sa itaas, parami nang parami ang mga Alibaba Cloud application na tumatakbo na ngayon sa mga Kubernetes cluster: stateful at stateless na mga application, pati na rin sa mga application manager. Ang pamamahala ng Kubernetes ay palaging isang kawili-wili at seryosong paksa ng talakayan para sa mga inhinyero na nagtatayo at nagpapanatili ng imprastraktura. Pagdating sa mga cloud provider tulad ng Alibaba Cloud, ang isyu ng scaling ay nauuna. Paano pamahalaan ang mga kumpol ng Kubernetes sa sukat na ito? Nasaklaw na namin ang pinakamahuhusay na kagawian para sa pamamahala ng malalaking 10-node na Kubernetes cluster. Siyempre, ito ay isang kawili-wiling problema sa pag-scale. Ngunit may isa pang sukat: dami ang mga kumpol mismo.

Napag-usapan namin ang paksang ito sa maraming gumagamit ng ACK. Pinipili ng karamihan sa kanila na magpatakbo ng dose-dosenang, kung hindi man daan-daan, ng maliliit o katamtamang laki ng mga kumpol ng Kubernetes. Mayroong magandang dahilan para dito: nililimitahan ang potensyal na pinsala, paghihiwalay ng mga kumpol para sa iba't ibang koponan, paglikha ng mga virtual na kumpol para sa pagsubok. Kung nilalayon ng ACK na maghatid ng pandaigdigang madla gamit ang modelong ito ng paggamit, dapat itong mapagkakatiwalaan at mahusay na pamahalaan ang isang malaking bilang ng mga kumpol sa higit sa 20 rehiyon.

kanin. 2. Mga problema sa pamamahala ng malaking bilang ng mga kumpol ng Kubernetes

Ano ang mga pangunahing hamon ng pamamahala ng mga kumpol sa sukat na ito? Gaya ng ipinapakita sa figure, may apat na isyu na haharapin:

• Heterogenity

Dapat suportahan ng ACK ang iba't ibang uri ng mga cluster, kabilang ang standard, serverless, Edge, Windows, at marami pang iba. Ang iba't ibang cluster ay nangangailangan ng iba't ibang opsyon, bahagi, at modelo ng pagho-host. Ang ilang mga customer ay nangangailangan ng tulong sa pag-customize para sa kanilang mga partikular na kaso.

• Iba't ibang laki ng kumpol

Iba-iba ang laki ng mga cluster, mula sa ilang node na may ilang pod hanggang sampu-sampung libong node na may libu-libong pod. Malaki rin ang pagkakaiba ng mga kinakailangan sa mapagkukunan. Ang hindi wastong paglalaan ng mapagkukunan ay maaaring makaapekto sa pagganap o maging sanhi ng pagkabigo.

• Iba't ibang bersyon

Mabilis na umuunlad ang Kubernetes. Ang mga bagong bersyon ay inilabas bawat ilang buwan. Ang mga customer ay palaging handang sumubok ng mga bagong feature. Kaya gusto nilang ilagay ang test load sa mga bagong bersyon ng Kubernetes at ang production load sa mga stable. Upang matugunan ang kinakailangang ito, dapat na patuloy na maghatid ang ACK ng mga bagong bersyon ng Kubernetes sa mga customer habang pinapanatili ang mga stable na bersyon.

• Pagsunod sa Seguridad

Ang mga kumpol ay ipinamamahagi sa iba't ibang rehiyon. Dahil dito, dapat silang sumunod sa iba't ibang mga kinakailangan sa kaligtasan at mga opisyal na regulasyon. Halimbawa, ang isang cluster sa Europe ay dapat na sumusunod sa GDPR, habang ang isang financial cloud sa China ay dapat may karagdagang mga layer ng proteksyon. Ang mga kinakailangang ito ay sapilitan at hindi katanggap-tanggap na huwag pansinin ang mga ito, dahil lumilikha ito ng malalaking panganib para sa mga kliyente ng cloud platform.

Ang ACK platform ay idinisenyo upang malutas ang karamihan sa mga problema sa itaas. Ito ay kasalukuyang mapagkakatiwalaan at matatag na namamahala ng higit sa 10 libong Kubernetes cluster sa buong mundo. Tingnan natin kung paano ito nakamit, kabilang ang sa pamamagitan ng ilang pangunahing prinsipyo ng disenyo/arkitektura.

Disenyo

Cube-on-cube at pulot-pukyutan

Hindi tulad ng isang sentralisadong hierarchy, ang arkitektura na nakabatay sa cell ay karaniwang ginagamit upang sukatin ang isang platform na lampas sa isang solong data center o upang palawakin ang saklaw ng pagbawi ng kalamidad.

Ang bawat rehiyon sa Alibaba Cloud ay binubuo ng ilang mga zone (AZ) at karaniwang tumutugma sa isang partikular na data center. Sa isang malaking rehiyon (hal. Huangzhou), madalas mayroong libu-libong mga cluster ng kliyente ng Kubernetes na nagpapatakbo ng ACK.

Pinamamahalaan ng ACK ang mga Kubernetes cluster na ito gamit ang Kubernetes mismo, ibig sabihin, mayroon kaming Kubernetes metacluster na tumatakbo upang pamahalaan ang mga client na Kubernetes cluster. Ang arkitektura na ito ay tinatawag ding “kube-on-kube” (KoK). Pinapasimple ng arkitektura ng KoK ang pamamahala ng mga cluster ng kliyente dahil simple at deterministic ang cluster deployment. Higit sa lahat, maaari naming muling gamitin ang mga native na feature ng Kubernetes. Halimbawa, ang pamamahala ng mga API server sa pamamagitan ng pag-deploy, gamit ang etcd operator upang pamahalaan ang maramihang etcds. Ang ganitong recursion ay palaging nagdudulot ng espesyal na kasiyahan.

Ilang Kubernetes metacluster ang na-deploy sa loob ng isang rehiyon, depende sa bilang ng mga kliyente. Tinatawag namin itong metaclusters cells. Para maprotektahan laban sa kabiguan ng isang buong zone, sinusuportahan ng ACK ang mga multi-active deployment sa isang rehiyon: ang metacluster ay namamahagi ng Kubernetes client cluster master component sa maraming zone at pinapatakbo ang mga ito nang sabay-sabay, iyon ay, sa multi-active mode. Upang matiyak ang pagiging maaasahan at kahusayan ng master, ino-optimize ng ACK ang paglalagay ng mga bahagi at tinitiyak na ang API server at etcd ay malapit sa isa't isa.

Binibigyang-daan ka ng modelong ito na pamahalaan ang Kubernetes nang mahusay, flexible at mapagkakatiwalaan.

Pagpaplano ng mapagkukunan ng Metacluster

Tulad ng nabanggit na namin, ang bilang ng mga metacluster sa bawat rehiyon ay nakasalalay sa bilang ng mga kliyente. Ngunit sa anong punto magdagdag ng bagong metacluster? Ito ay isang karaniwang problema sa pagpaplano ng mapagkukunan. Bilang isang tuntunin, kaugalian na gumawa ng bago kapag naubos na ng mga umiiral na metacluster ang lahat ng kanilang mapagkukunan.

Kunin natin ang mga mapagkukunan ng network, halimbawa. Sa arkitektura ng KoK, ang mga bahagi ng Kubernetes mula sa mga cluster ng kliyente ay naka-deploy bilang mga pod sa isang metacluster. Ginagamit namin Terway (Larawan 3) ay isang mataas na pagganap na plugin na binuo ng Alibaba Cloud para sa pamamahala ng network ng container. Nagbibigay ito ng maraming patakaran sa seguridad at nagbibigay-daan sa iyong kumonekta sa mga virtual private cloud (VPC) ng mga customer sa pamamagitan ng Alibaba Cloud Elastic Networking Interface (ENI). Upang epektibong maipamahagi ang mga mapagkukunan ng network sa mga node, pod, at serbisyo sa isang metacluster, dapat nating maingat na subaybayan ang kanilang paggamit sa loob ng metacluster ng virtual private cloud. Kapag natapos na ang mga mapagkukunan ng network, isang bagong cell ang gagawin.

Upang matukoy ang pinakamainam na bilang ng mga cluster ng kliyente sa bawat metacluster, isinasaalang-alang din namin ang aming mga gastos, kinakailangan sa density, quota ng mapagkukunan, mga kinakailangan sa pagiging maaasahan at istatistika. Ang desisyon na gumawa ng bagong metacluster ay ginawa batay sa lahat ng impormasyong ito. Pakitandaan na ang maliliit na cluster ay maaaring lumawak nang malaki sa hinaharap, kaya ang pagkonsumo ng mapagkukunan ay tumataas kahit na ang bilang ng mga cluster ay nananatiling hindi nagbabago. Karaniwan kaming nag-iiwan ng sapat na libreng espasyo para sa bawat kumpol na lumago.

kanin. 3. Arkitektura ng network ng Terway

Pag-scale ng mga bahagi ng wizard sa mga cluster ng kliyente

Ang mga bahagi ng wizard ay may iba't ibang pangangailangan sa mapagkukunan. Nakadepende ang mga ito sa bilang ng mga node at pod sa cluster, ang bilang ng mga hindi karaniwang controller/operator na nakikipag-ugnayan sa APIServer.

Sa ACK, ang bawat cluster ng kliyente ng Kubernetes ay naiiba sa laki at mga kinakailangan sa runtime. Walang pangkalahatang pagsasaayos para sa paglalagay ng mga bahagi ng wizard. Kung nagkamali kaming nagtakda ng mababang limitasyon ng mapagkukunan para sa isang malaking kliyente, kung gayon ang kumpol nito ay hindi makakayanan ang pagkarga. Kung magtatakda ka ng konserbatibong mataas na limitasyon para sa lahat ng cluster, masasayang ang mga mapagkukunan.

Upang makahanap ng banayad na trade-off sa pagitan ng pagiging maaasahan at gastos, ang ACK ay gumagamit ng isang uri ng sistema. Ibig sabihin, tinukoy namin ang tatlong uri ng mga kumpol: maliit, katamtaman at malaki. Ang bawat uri ay may hiwalay na profile sa paglalaan ng mapagkukunan. Ang uri ay tinutukoy batay sa pag-load ng mga bahagi ng wizard, ang bilang ng mga node, at iba pang mga kadahilanan. Maaaring magbago ang uri ng cluster sa paglipas ng panahon. Patuloy na sinusubaybayan ng ACK ang mga salik na ito at maaaring mag-type ng pataas/pababa nang naaayon. Kapag nabago ang uri ng cluster, awtomatikong ina-update ang paglalaan ng mapagkukunan na may kaunting interbensyon ng user.

Nagsusumikap kaming pahusayin ang system na ito gamit ang mas pinong pag-scale at mas tumpak na pag-update ng uri upang ang mga pagbabagong ito ay mangyari nang mas maayos at magkaroon ng higit na ekonomikong kahulugan.

kanin. 4. Matalinong multi-stage type switching

Ebolusyon ng mga kumpol ng kliyente sa sukat

Ang mga nakaraang seksyon ay sumasaklaw sa ilang aspeto ng pamamahala ng malaking bilang ng mga kumpol ng Kubernetes. Gayunpaman, may isa pang problema na kailangang lutasin: ang ebolusyon ng mga kumpol.

Ang Kubernetes ay ang "Linux" ng cloud world. Ito ay patuloy na ina-update at nagiging mas modular. Dapat tayong patuloy na maghatid ng mga bagong bersyon sa ating mga customer, ayusin ang mga kahinaan at i-update ang mga umiiral na cluster, pati na rin pamahalaan ang isang malaking bilang ng mga nauugnay na bahagi (CSI, CNI, Device Plugin, Scheduler Plugin at marami pang iba).

Kunin natin ang Kubernetes component management bilang isang halimbawa. Upang magsimula, bumuo kami ng isang sentralisadong sistema para sa pagrehistro at pamamahala sa lahat ng mga konektadong bahagi na ito.

kanin. 5. Flexible at pluggable na mga bahagi

Bago sumulong, kailangan mong tiyaking matagumpay ang pag-update. Upang gawin ito, bumuo kami ng isang sistema para sa pagsuri sa pag-andar ng mga bahagi. Isinasagawa ang pagsusuri bago at pagkatapos ng pag-update.

kanin. 6. Paunang pagsusuri ng mga bahagi ng cluster

Upang mabilis at mapagkakatiwalaang i-update ang mga bahaging ito, gumagana ang tuluy-tuloy na deployment system na may suporta para sa bahagyang pagsulong (grayscale), mga pag-pause at iba pang mga function. Ang mga karaniwang Kubernetes controllers ay hindi angkop para sa use case na ito. Samakatuwid, upang pamahalaan ang mga bahagi ng cluster, bumuo kami ng isang set ng mga dalubhasang controller, kabilang ang isang plugin at isang auxiliary control module (pamamahala ng sidecar).

Halimbawa, ang controller ng BroadcastJob ay idinisenyo upang i-update ang mga bahagi sa bawat makina ng manggagawa o suriin ang mga node sa bawat makina. Ang trabaho sa Broadcast ay nagpapatakbo ng pod sa bawat node sa cluster, tulad ng isang DaemonSet. Gayunpaman, palaging pinapanatili ng DaemonSet ang pod na tumatakbo nang mahabang panahon, habang kino-collapse ito ng BroadcastJob. Ang Broadcast controller ay naglulunsad din ng mga pod sa mga bagong pinagsamang node at sinisimulan ang mga node gamit ang mga kinakailangang bahagi. Noong Hunyo 2019, binuksan namin ang source code ng OpenKruise automation engine, na ginagamit namin mismo sa loob ng kumpanya.

kanin. 7. Inaayos ng OpenKurise ang pagpapatupad ng gawain sa Broadcast sa lahat ng node

Upang matulungan ang mga customer na piliin ang mga tamang configuration ng cluster, nagbibigay din kami ng set ng mga paunang natukoy na profile, kabilang ang Serverless, Edge, Windows, at Bare Metal na mga profile. Habang lumalawak ang landscape at lumalaki ang mga pangangailangan ng aming mga customer, magdaragdag kami ng higit pang mga profile para pasimplehin ang nakakapagod na proseso ng pag-setup.

kanin. 8. Mga advanced at flexible na cluster profile para sa iba't ibang mga sitwasyon

Global observability sa mga data center

Gaya ng ipinapakita sa ibaba ng fig. 9, ang Alibaba Cloud Container cloud service ay na-deploy sa dalawampung rehiyon sa buong mundo. Dahil sa sukat na ito, ang isa sa mga pangunahing layunin ng ACK ay ang madaling masubaybayan ang estado ng pagpapatakbo ng mga cluster upang kung ang isang cluster ng kliyente ay makatagpo ng isang problema, maaari kaming mabilis na tumugon sa sitwasyon. Sa madaling salita, kailangan mong makabuo ng solusyon na magbibigay-daan sa iyong mahusay at secure na mangolekta ng mga istatistika sa real time mula sa mga cluster ng kliyente sa lahat ng rehiyon - at biswal na ipakita ang mga resulta.

kanin. 9. Global deployment ng Alibaba Cloud Container service sa dalawampung rehiyon

Tulad ng maraming sistema ng pagsubaybay sa Kubernetes, ginagamit namin ang Prometheus bilang aming pangunahing tool. Para sa bawat metacluster, kinokolekta ng mga ahente ng Prometheus ang mga sumusunod na sukatan:

• Mga sukatan ng OS gaya ng mga mapagkukunan ng host (CPU, memory, disk, atbp.) at bandwidth ng network.
• Mga sukatan para sa metacluster at client cluster management system, gaya ng kube-apiserver, kube-controller-manager at kube-scheduler.
• Mga sukatan mula sa kubernetes-state-metrics at cadvisor.
• etcd metrics gaya ng oras ng pagsulat ng disk, laki ng database, throughput ng mga koneksyon sa pagitan ng mga node, atbp.

Kinokolekta ang mga pandaigdigang istatistika gamit ang isang tipikal na modelo ng multi-layer aggregation. Ang data ng pagsubaybay mula sa bawat metacluster ay unang pinagsama-sama sa bawat rehiyon at pagkatapos ay ipinadala sa isang sentral na server na nagpapakita ng pangkalahatang larawan. Gumagana ang lahat sa pamamagitan ng mekanismo ng federation. Ang isang Prometheus server sa bawat data center ay nangongolekta ng mga sukatan mula sa data center na iyon, at ang gitnang Prometheus server ay may pananagutan para sa pagsasama-sama ng data ng pagsubaybay. Kumokonekta ang AlertManager sa gitnang Prometheus at, kung kinakailangan, nagpapadala ng mga alerto sa pamamagitan ng DingTalk, email, SMS, atbp. Visualization - gamit ang Grafana.

Sa Figure 10, ang monitoring system ay maaaring nahahati sa tatlong antas:

• Antas ng hangganan

Ang layer na pinakamalayo mula sa gitna. Gumagana ang Prometheus Edge Server sa bawat metacluster, nangongolekta ng mga sukatan mula sa meta at mga cluster ng kliyente sa loob ng parehong domain ng network.

• Antas ng kaskad

Ang function ng Prometheus cascade layer ay upang mangolekta ng data ng pagsubaybay mula sa maraming rehiyon. Gumagana ang mga server na ito sa antas ng mas malalaking heograpikal na unit gaya ng China, Asia, Europe at America. Habang lumalaki ang mga kumpol, maaaring hatiin ang rehiyon, at pagkatapos ay lilitaw ang isang cascade-level na Prometheus server sa bawat bagong malaking rehiyon. Gamit ang diskarteng ito, maaari mong maayos na sukatin kung kinakailangan.

• Gitnang antas

Ang gitnang Prometheus server ay kumokonekta sa lahat ng cascade server at nagsasagawa ng panghuling pagsasama-sama ng data. Para sa pagiging maaasahan, dalawang instance ng gitnang Prometheus ang itinaas sa magkaibang mga zone, na konektado sa parehong mga cascade server.

kanin. 10. Global multi-level monitoring architecture batay sa Prometheus federation mechanism

Buod

Patuloy na binabago ng mga solusyon sa cloud na nakabase sa Kubernetes ang ating industriya. Nagbibigay ang serbisyo ng lalagyan ng Alibaba Cloud ng secure, maaasahan at mahusay na pagho-host - isa ito sa pinakamahusay na cloud hosting ng Kubernetes. Ang pangkat ng Alibaba Cloud ay lubos na naniniwala sa mga prinsipyo ng Open Source at ang open source na komunidad. Tiyak na ipagpapatuloy namin ang pagbabahagi ng aming kaalaman sa larangan ng pagpapatakbo at pamamahala ng mga teknolohiya sa cloud.

Pinagmulan: www.habr.com