Cube-on-cube, metacluster, honeycombs, distribusi sumber daya

Gabah. 1. Ekosistem Kubernetes ing Alibaba Cloud

Wiwit 2015, Alibaba Cloud Container Service for Kubernetes (ACK) wis dadi salah sawijining layanan awan sing paling cepet berkembang ing Alibaba Cloud. Iki nglayani akeh klien lan uga ndhukung infrastruktur internal Alibaba lan layanan awan perusahaan liyane.

Kaya layanan wadhah sing padha saka panyedhiya awan kelas donya, prioritas utama kita yaiku linuwih lan kasedhiyan. Mula, platform sing bisa diukur lan diakses sacara global wis digawe kanggo puluhan ewu kluster Kubernetes.

Ing artikel iki, kita bakal nuduhake pengalaman kita ngatur akeh klompok Kubernetes babagan infrastruktur awan, uga arsitektur platform dhasar.

entri

Kubernetes wis dadi standar de facto kanggo macem-macem beban kerja ing awan. Minangka ditampilake ing Fig. 1 ing ndhuwur, luwih akeh aplikasi Alibaba Cloud saiki mlaku ing kluster Kubernetes: aplikasi stateful lan stateless, uga manajer aplikasi. Manajemen Kubernetes tansah dadi topik diskusi sing menarik lan serius kanggo para insinyur sing mbangun lan njaga infrastruktur. Nalika nerangake panyedhiya maya kaya Alibaba Cloud, masalah skala dadi luwih dhisik. Kepiye carane ngatur kluster Kubernetes ing skala iki? Kita wis ngrembug praktik paling apik kanggo ngatur kluster Kubernetes 10-node sing gedhe. Mesthi, iki minangka masalah skala sing menarik. Nanging ana ukuran liyane: jumlah kluster dhewe.

Kita wis ngrembug topik iki karo akeh pangguna ACK. Umume wong-wong mau milih mbukak puluhan, yen ora atusan, kluster Kubernetes cilik utawa medium. Ana alasan sing apik kanggo iki: matesi karusakan potensial, misahake klompok kanggo tim sing beda-beda, nggawe klompok virtual kanggo testing. Yen ACK duwe tujuan kanggo nglayani pamirsa global kanthi model panggunaan iki, kudu dipercaya lan efisien ngatur akeh klompok ing luwih saka 20 wilayah.

Gabah. 2. Masalah ngatur nomer ageng saka klompok Kubernetes

Apa tantangan utama kanggo ngatur klompok ing skala iki? Kaya sing dituduhake ing gambar kasebut, ana papat masalah sing kudu ditangani:

• Heterogenitas

ACK kudu ndhukung macem-macem jinis kluster, kalebu standar, tanpa server, Edge, Windows, lan sawetara liyane. Kluster sing beda mbutuhake opsi, komponen, lan model hosting sing beda. Sawetara pelanggan butuh pitulung babagan kustomisasi kanggo kasus tartamtu.

• Macem-macem ukuran kluster

Kluster ukurane beda-beda, saka saperangan simpul karo sawetara pods nganti puluhan ewu simpul karo ewu pods. Syarat sumber daya uga beda-beda banget. Alokasi sumber daya sing ora cocog bisa nyebabake kinerja utawa malah nyebabake kegagalan.

• versi beda

Kubernetes berkembang cepet banget. Versi anyar dirilis saben sawetara sasi. Pelanggan tansah gelem nyoba fitur anyar. Dadi dheweke pengin nyelehake beban uji ing versi anyar Kubernetes lan beban produksi ing sing stabil. Kanggo nyukupi syarat iki, ACK kudu terus ngirim versi anyar saka Kubernetes menyang pelanggan nalika njaga versi stabil.

• Kepatuhan Keamanan

Kluster disebar ing macem-macem wilayah. Dadi, dheweke kudu tundhuk karo macem-macem syarat safety lan peraturan resmi. Contone, kluster ing Eropa kudu tundhuk karo GDPR, dene awan finansial ing China kudu duwe lapisan perlindungan tambahan. Persyaratan kasebut wajib lan ora bisa ditampa, amarga iki nggawe risiko gedhe kanggo klien platform awan.

Platform ACK dirancang kanggo ngatasi masalah ing ndhuwur. Saiki kanthi andal lan stabil ngatur luwih saka 10 ewu kluster Kubernetes ing saindenging jagad. Ayo goleki carane iki bisa ditindakake, kalebu liwat sawetara prinsip desain/arsitektur utama.

Design

Cube-on-cube lan honeycomb

Ora kaya hierarki terpusat, arsitektur basis sel biasane digunakake kanggo skala platform ngluwihi pusat data siji utawa kanggo nggedhekake ruang lingkup pemulihan bencana.

Saben wilayah ing Alibaba Cloud kasusun saka sawetara zona (AZ) lan biasane cocog karo pusat data tartamtu. Ing wilayah gedhe (umpamane Huangzhou), asring ana ewonan kluster klien Kubernetes sing nganggo ACK.

ACK ngatur kluster Kubernetes iki nggunakake Kubernetes dhewe, tegese kita duwe metacluster Kubernetes sing mlaku kanggo ngatur kluster Kubernetes klien. Arsitektur iki uga disebut "kube-on-kube" (KoK). Arsitèktur KoK nyederhanakake manajemen kluster klien amarga panyebaran kluster iku prasaja lan deterministik. Sing luwih penting, kita bisa nggunakake maneh fitur asli Kubernetes. Contone, ngatur server API liwat penyebaran, nggunakake operator etcd kanggo ngatur macem-macem etcds. Rekursi kasebut tansah nggawa kesenengan khusus.

Sawetara metacluster Kubernetes disebarake ing sak wilayah, gumantung saka jumlah klien. Kita nyebut sel metacluster iki. Kanggo nglindhungi saka kegagalan kabeh zona, ACK ndhukung penyebaran multi-aktif ing wilayah siji: metacluster nyebarake komponen master kluster klien Kubernetes ing sawetara zona lan mbukak bebarengan, yaiku, ing mode multi-aktif. Kanggo mesthekake linuwih lan efficiency master, ACK ngoptimalake panggonan seko saka komponen lan mesthekake yen server API lan etcd cedhak saben liyane.

Model iki ngidini sampeyan ngatur Kubernetes kanthi efisien, fleksibel lan andal.

Perencanaan sumber daya Metacluster

Kaya sing wis kasebut, jumlah metacluster ing saben wilayah gumantung saka jumlah klien. Nanging ing titik apa kanggo nambah metacluster anyar? Iki minangka masalah perencanaan sumber daya sing khas. Minangka aturan, umume nggawe sing anyar nalika metacluster sing ana wis kesel kabeh sumber daya.

Ayo njupuk sumber daya jaringan, contone. Ing arsitektur KoK, komponen Kubernetes saka kluster klien disebarake minangka pod ing metacluster. Kita nggunakake Terway (Gambar 3) minangka plugin kinerja dhuwur sing dikembangake dening Alibaba Cloud kanggo manajemen jaringan kontainer. Iki nyedhiyakake macem-macem kabijakan keamanan lan ngidini sampeyan nyambung menyang awan pribadi virtual (VPC) pelanggan liwat Antarmuka Jaringan Elastis Awan Alibaba (ENI). Kanggo nyebarake sumber daya jaringan kanthi efektif ing node, pod lan layanan ing metacluster, kita kudu ngawasi kanthi teliti panggunaane ing metacluster awan pribadi virtual. Nalika sumber daya jaringan rampung, sel anyar digawe.

Kanggo nemtokake jumlah kluster klien sing optimal ing saben metacluster, kita uga nganggep biaya, syarat kepadatan, kuota sumber daya, syarat linuwih lan statistik. Kaputusan kanggo nggawe metacluster anyar digawe adhedhasar kabeh informasi iki. Wigati dimangerteni manawa kluster cilik bisa nggedhekake banget ing mangsa ngarep, mula konsumsi sumber daya mundhak sanajan jumlah kluster tetep ora owah. Kita biasane ninggalake papan sing cukup kanggo saben kluster tuwuh.

Gabah. 3. Arsitektur jaringan Terway

Komponen tuntunan skala ing kluster klien

Komponen tuntunan duwe kabutuhan sumber daya sing beda. Padha gumantung ing nomer kelenjar lan pods ing kluster, nomer non-standar pengontrol / operator sesambungan karo APIServer.

Ing ACK, saben kluster klien Kubernetes beda-beda ing ukuran lan syarat runtime. Ora ana konfigurasi universal kanggo nempatake komponen tuntunan. Yen kita salah nyetel watesan sumber daya kurang kanggo klien gedhe, kluster sawijining ora bakal bisa kanggo ngrampungake karo mbukak. Yen sampeyan nyetel watesan konservatif dhuwur kanggo kabeh klompok, sumber daya bakal boroske.

Kanggo nemokake trade-off subtle antarane linuwih lan biaya, ACK nggunakake sistem jinis. Yaiku, kita nemtokake telung jinis kluster: cilik, medium lan gedhe. Saben jinis nduweni profil alokasi sumber daya sing kapisah. Jinis kasebut ditemtokake adhedhasar beban komponen tuntunan, jumlah simpul, lan faktor liyane. Jinis kluster bisa owah saka wektu. ACK terus-terusan ngawasi faktor-faktor kasebut lan bisa munggah / mudhun. Sawise jinis kluster diganti, alokasi sumber daya dianyari kanthi otomatis kanthi intervensi pangguna minimal.

Kita ngupayakake nambah sistem iki kanthi skala sing luwih apik lan nganyari jinis sing luwih tepat supaya owah-owahan kasebut kelakon luwih lancar lan luwih ekonomis.

Gabah. 4. Intelligent multi-tataran jinis ngoper

Évolusi kluster klien ing skala

Bagean sadurunge nyakup sawetara aspek ngatur klompok Kubernetes sing akeh. Nanging, ana masalah liyane sing kudu ditanggulangi: evolusi kluster.

Kubernetes minangka "Linux" ing jagad maya. Dianyari terus-terusan lan dadi luwih modular. Kita kudu terus-terusan ngirim versi anyar kanggo para pelanggan, ndandani kerentanan lan nganyari klompok sing wis ana, uga ngatur akeh komponen sing gegandhengan (CSI, CNI, Plugin Piranti, Plugin Penjadwal lan liya-liyane).

Ayo njupuk manajemen komponen Kubernetes minangka conto. Kanggo miwiti, kita ngembangake sistem terpusat kanggo ndhaptar lan ngatur kabeh komponen sing disambungake iki.

Gabah. 5. Komponen fleksibel lan pluggable

Sadurunge maju, sampeyan kudu nggawe manawa nganyari wis sukses. Kanggo nindakake iki, kita wis ngembangake sistem kanggo mriksa fungsi komponen. Priksa ditindakake sadurunge lan sawise nganyari.

Gabah. 6. Priksa pambuka komponen cluster

Kanggo nganyari komponen kasebut kanthi cepet lan andal, sistem penyebaran terus-terusan bisa digunakake kanthi dhukungan kanggo kemajuan parsial (skala abu-abu), ngaso lan fungsi liyane. Pengontrol Kubernetes standar ora cocog kanggo kasus panggunaan iki. Mulane, kanggo ngatur komponen kluster, kita wis ngembangake set pengontrol khusus, kalebu plugin lan modul kontrol tambahan (manajemen sidecar).

Contone, controller BroadcastJob dirancang kanggo nganyari komponen ing saben mesin buruh utawa mriksa kelenjar ing saben mesin. Proyek Broadcast mbukak pod ing saben simpul ing kluster, kaya DaemonSet. Nanging, DaemonSet tansah njaga pod mlaku nganti suwe, nalika BroadcastJob ambruk. Kontroler Broadcast uga ngluncurake pod ing simpul sing mentas digabung lan miwiti simpul kanthi komponen sing dibutuhake. Ing wulan Juni 2019, kita mbukak kode sumber mesin otomatis OpenKruise, sing digunakake dhewe ing perusahaan kasebut.

Gabah. 7. OpenKurise ngatur eksekusi tugas Broadcast ing kabeh kelenjar

Kanggo bantuan pelanggan milih konfigurasi kluster tengen, kita uga nyedhiyani pesawat saka profil predefined, kalebu Serverless, Edge, Windows, lan profil Bare Metal. Nalika lanskap ngembang lan kabutuhan pelanggan saya tambah akeh, kita bakal nambah profil liyane kanggo nyederhanakake proses persiyapan sing angel.

Gabah. 8. Profil kluster majeng lan fleksibel kanggo macem-macem skenario

Pengamatan global ing pusat data

Minangka ditampilake ing ngisor anjir. 9, layanan maya Alibaba Cloud Container wis disebarake ing rong puluh wilayah ing saindenging jagad. Kanthi skala iki, salah sawijining tujuan utama ACK yaiku kanthi gampang ngawasi kahanan kluster sing mlaku supaya yen kluster klien nemoni masalah, kita bisa kanthi cepet nanggapi kahanan kasebut. Kanthi tembung liyane, sampeyan kudu nggawe solusi sing ngidini sampeyan ngumpulake statistik kanthi efisien lan aman kanthi wektu nyata saka klompok klien ing kabeh wilayah - lan nampilake asil kanthi visual.

Gabah. 9. Penyebaran global layanan Alibaba Cloud Container ing rong puluh wilayah

Kaya akeh sistem pemantauan Kubernetes, kita nggunakake Prometheus minangka alat utama. Kanggo saben metacluster, agen Prometheus ngumpulake metrik ing ngisor iki:

• Metrik OS kayata sumber daya host (CPU, memori, disk, lsp) lan bandwidth jaringan.
• Metrik kanggo sistem manajemen kluster metacluster lan klien, kayata kube-apiserver, kube-controller-manager lan kube-scheduler.
• Metrik saka kubernetes-state-metrics lan cadvisor.
• etcd metrik kayata wektu nulis disk, ukuran database, throughput sambungan antarane simpul, etc.

Statistik global diklumpukake nggunakake model agregasi multi-lapisan sing khas. Data ngawasi saka saben metacluster pisanan dikumpulake ing saben wilayah banjur dikirim menyang server pusat sing nuduhake gambar sakabèhé. Kabeh dianggo liwat mekanisme federasi. Server Prometheus ing saben pusat data nglumpukake metrik saka pusat data kasebut, lan server Prometheus pusat tanggung jawab kanggo nglumpukake data pemantauan. AlertManager nyambung menyang Prometheus tengah lan, yen perlu, ngirim tandha liwat DingTalk, email, SMS, etc. Visualisasi - nggunakake Grafana.

Ing Gambar 10, sistem pemantauan bisa dipérang dadi telung tingkat:

• Tingkat wates

Lapisan paling adoh saka tengah. Server Prometheus Edge mlaku ing saben metacluster, ngumpulake metrik saka meta lan klompok klien ing domain jaringan sing padha.

• Tingkat kaskade

Fungsi lapisan kaskade Prometheus yaiku kanggo ngumpulake data pemantauan saka pirang-pirang wilayah. Server kasebut beroperasi ing tingkat unit geografis sing luwih gedhe kayata China, Asia, Eropa lan Amerika. Nalika kluster tuwuh, wilayah kasebut bisa dipérang, banjur server Prometheus tingkat kaskade bakal katon ing saben wilayah gedhe anyar. Kanthi strategi iki, sampeyan bisa nggedhekake kanthi lancar yen perlu.

• Tingkat tengah

Server Prometheus tengah nyambung menyang kabeh server cascade lan nindakake pengumpulan data pungkasan. Kanggo linuwih, loro kedadean Prometheus tengah padha wungu ing zona beda, disambungake menyang server cascade padha.

Gabah. 10. Arsitektur pemantauan multi-tingkat global adhedhasar mekanisme federasi Prometheus

Ringkesan

Solusi awan basis Kubernetes terus ngowahi industri kita. Layanan wadhah Alibaba Cloud nyedhiyakake hosting sing aman, dipercaya lan berkinerja dhuwur - iki minangka salah sawijining hosting awan Kubernetes sing paling apik. Tim Alibaba Cloud percaya banget marang prinsip Open Source lan komunitas open source. Kita mesthi bakal terus nuduhake kawruh babagan ngoperasikake lan ngatur teknologi awan.

Source: www.habr.com