Kubus pada kiub, metacluster, sarang lebah, pengagihan sumber

nasi. 1. Ekosistem Kubernetes di Alibaba Cloud

Sejak 2015, Perkhidmatan Kontena Awan Alibaba untuk Kubernetes (ACK) telah menjadi salah satu perkhidmatan awan yang paling pesat berkembang di Alibaba Cloud. Ia memberi perkhidmatan kepada ramai pelanggan dan juga menyokong infrastruktur dalaman Alibaba dan perkhidmatan awan syarikat yang lain.

Seperti perkhidmatan kontena yang serupa daripada penyedia awan bertaraf dunia, keutamaan utama kami ialah kebolehpercayaan dan ketersediaan. Oleh itu, platform berskala dan boleh diakses secara global telah dicipta untuk puluhan ribu kluster Kubernetes.

Dalam artikel ini, kami akan berkongsi pengalaman kami mengurus sejumlah besar kluster Kubernetes pada infrastruktur awan, serta seni bina platform asas.

Entry

Kubernetes telah menjadi standard de facto untuk pelbagai beban kerja dalam awan. Seperti yang ditunjukkan dalam Rajah. 1 di atas, semakin banyak aplikasi Alibaba Cloud kini dijalankan pada kelompok Kubernetes: aplikasi stateful dan stateless, serta pengurus aplikasi. Pengurusan Kubernetes sentiasa menjadi topik perbincangan yang menarik dan serius untuk jurutera yang membina dan menyelenggara infrastruktur. Apabila ia datang kepada pembekal awan seperti Alibaba Cloud, isu penskalaan menjadi perhatian. Bagaimana untuk mengurus kelompok Kubernetes pada skala ini? Kami telah merangkumi amalan terbaik untuk mengurus gugusan Kubernetes 10 nod yang besar. Sudah tentu, ini adalah masalah penskalaan yang menarik. Tetapi ada skala lain: kuantiti kluster itu sendiri.

Kami telah membincangkan topik ini dengan ramai pengguna ACK. Kebanyakan mereka memilih untuk menjalankan berpuluh-puluh, jika tidak beratus-ratus, kumpulan Kubernetes kecil atau sederhana. Terdapat sebab yang baik untuk ini: mengehadkan kemungkinan kerosakan, memisahkan kelompok untuk pasukan yang berbeza, mencipta kelompok maya untuk ujian. Jika ACK menyasarkan untuk menyampaikan khalayak global dengan model penggunaan ini, ia mesti mengurus sebilangan besar kluster merentasi lebih daripada 20 wilayah dengan andal dan cekap.

nasi. 2. Masalah mengurus sejumlah besar kluster Kubernetes

Apakah cabaran utama mengurus kelompok pada skala ini? Seperti yang ditunjukkan dalam rajah, terdapat empat isu yang perlu ditangani:

• Heterogeniti

ACK harus menyokong pelbagai jenis kluster termasuk standard, tanpa pelayan, Edge, Windows dan beberapa yang lain. Kluster yang berbeza memerlukan parameter, komponen dan model pengehosan yang berbeza. Sesetengah klien memerlukan bantuan dengan konfigurasi untuk keperluan khusus mereka.

• Pelbagai saiz kluster

Kluster berbeza dari segi saiz, daripada beberapa nod dengan beberapa pod kepada puluhan ribu nod dengan ribuan pod. Keperluan sumber juga sangat berbeza. Peruntukan sumber yang tidak betul boleh menjejaskan prestasi malah menyebabkan kegagalan.

• Versi berbeza

Kubernetes berkembang sangat cepat. Versi baharu dikeluarkan setiap beberapa bulan. Pelanggan sentiasa bersedia untuk mencuba ciri baharu. Jadi mereka mahu meletakkan beban ujian pada versi baharu Kubernetes dan beban pengeluaran pada versi stabil. Untuk memenuhi keperluan ini, ACK mesti terus menghantar versi baharu Kubernetes kepada pelanggan sambil mengekalkan versi yang stabil.

• Pematuhan Keselamatan

Kelompok diedarkan merentasi wilayah yang berbeza. Oleh itu, mereka mesti mematuhi pelbagai keperluan keselamatan dan peraturan rasmi. Contohnya, kluster di Eropah mestilah mematuhi GDPR, manakala awan kewangan di China mesti mempunyai lapisan perlindungan tambahan. Keperluan ini adalah wajib dan tidak boleh diterima untuk mengabaikannya, kerana ini menimbulkan risiko besar untuk pelanggan platform awan.

Platform ACK direka untuk menyelesaikan kebanyakan masalah di atas. Pada masa ini, ia menguruskan lebih daripada 10 ribu kluster Kubernetes di seluruh dunia dengan andal dan stabil. Mari lihat bagaimana ini dicapai, termasuk melalui beberapa prinsip reka bentuk/seni bina utama.

Design

Kubus-pada-kubus dan sarang lebah

Tidak seperti hierarki berpusat, seni bina berasaskan sel biasanya digunakan untuk menskalakan platform melangkaui pusat data tunggal atau untuk mengembangkan skop pemulihan bencana.

Setiap wilayah di Alibaba Cloud terdiri daripada beberapa zon (AZ) dan biasanya sepadan dengan pusat data tertentu. Di rantau yang besar (cth. Huangzhou), selalunya terdapat beribu-ribu kluster pelanggan Kubernetes yang menjalankan ACK.

ACK mengurus kluster Kubernetes ini menggunakan Kubernetes sendiri, bermakna kami mempunyai kluster meta Kubernetes berjalan untuk mengurus kluster Kubernetes pelanggan. Seni bina ini juga dipanggil "kube-on-kube" (KoK). Seni bina KoK memudahkan pengurusan kluster pelanggan kerana penggunaan kluster adalah mudah dan deterministik. Lebih penting lagi, kami boleh menggunakan semula ciri Kubernetes asli. Sebagai contoh, menguruskan pelayan API melalui penggunaan, menggunakan operator etcd untuk mengurus berbilang etcds. Rekursi sedemikian sentiasa membawa keseronokan istimewa.

Beberapa kumpulan meta Kubernetes digunakan dalam satu rantau, bergantung pada bilangan pelanggan. Kami memanggil sel metacluster ini. Untuk melindungi daripada kegagalan keseluruhan zon, ACK menyokong penggunaan berbilang aktif dalam satu rantau: metacluster mengedarkan komponen induk kluster klien Kubernetes merentasi berbilang zon dan menjalankannya secara serentak, iaitu dalam mod berbilang aktif. Untuk memastikan kebolehpercayaan dan kecekapan induk, ACK mengoptimumkan penempatan komponen dan memastikan pelayan API dan etcd berdekatan antara satu sama lain.

Model ini membolehkan anda mengurus Kubernetes dengan cekap, fleksibel dan boleh dipercayai.

Perancangan sumber Metacluster

Seperti yang telah kami nyatakan, bilangan metacluster di setiap rantau bergantung pada bilangan pelanggan. Tetapi pada titik mana untuk menambah metacluster baharu? Ini adalah masalah perancangan sumber biasa. Sebagai peraturan, adalah kebiasaan untuk mencipta yang baharu apabila kumpulan meta sedia ada telah kehabisan semua sumber mereka.

Mari kita ambil sumber rangkaian, sebagai contoh. Dalam seni bina KoK, komponen Kubernetes daripada kluster klien digunakan sebagai pod dalam metacluster. Kami guna Terway (Gamb. 3) ialah pemalam berprestasi tinggi yang dibangunkan oleh Alibaba Cloud untuk pengurusan rangkaian kontena. Ia menyediakan satu set dasar keselamatan yang kaya dan membolehkan anda menyambung ke awan peribadi maya (VPC) pelanggan melalui Antara Muka Rangkaian Elastik Awan Alibaba (ENI). Untuk mengagihkan sumber rangkaian dengan berkesan merentas nod, pod dan perkhidmatan dalam kumpulan meta, kami mesti memantau penggunaannya dengan teliti dalam kumpulan meta awan peribadi maya. Apabila sumber rangkaian berakhir, sel baharu dicipta.

Untuk menentukan bilangan gugusan pelanggan yang optimum dalam setiap kumpulan meta, kami juga mengambil kira kos, keperluan kepadatan, kuota sumber, keperluan kebolehpercayaan dan statistik kami. Keputusan untuk mencipta metacluster baharu dibuat berdasarkan semua maklumat ini. Sila ambil perhatian bahawa kluster kecil boleh berkembang dengan pesat pada masa hadapan, jadi penggunaan sumber meningkat walaupun bilangan kluster kekal tidak berubah. Kami biasanya meninggalkan ruang kosong yang cukup untuk setiap kelompok berkembang.

nasi. 3. Seni bina rangkaian Terway

Menskalakan komponen wizard merentas kelompok pelanggan

Komponen wizard mempunyai keperluan sumber yang berbeza. Mereka bergantung pada bilangan nod dan pod dalam kelompok, bilangan pengawal/pengendali bukan standard yang berinteraksi dengan APIServer.

Dalam ACK, setiap kluster pelanggan Kubernetes berbeza dari segi saiz dan keperluan masa jalan. Tiada konfigurasi universal untuk meletakkan komponen wizard. Jika kami tersilap menetapkan had sumber yang rendah untuk pelanggan yang besar, maka klusternya tidak akan dapat menampung beban. Jika anda menetapkan had yang tinggi secara konservatif untuk semua kluster, sumber akan dibazirkan.

Untuk mencari pertukaran halus antara kebolehpercayaan dan kos, ACK menggunakan sistem jenis. Iaitu, kami mentakrifkan tiga jenis kluster: kecil, sederhana dan besar. Setiap jenis mempunyai profil peruntukan sumber yang berasingan. Jenis ditentukan berdasarkan beban komponen wizard, bilangan nod dan faktor lain. Jenis kluster mungkin berubah dari semasa ke semasa. ACK sentiasa memantau faktor-faktor ini dan boleh menaip atas/bawah dengan sewajarnya. Sebaik sahaja jenis kluster ditukar, peruntukan sumber dikemas kini secara automatik dengan campur tangan pengguna yang minimum.

Kami sedang berusaha untuk menambah baik sistem ini dengan penskalaan yang lebih halus dan pengemaskinian jenis yang lebih tepat supaya perubahan ini berlaku dengan lebih lancar dan lebih ekonomis.

nasi. 4. Pensuisan jenis pelbagai peringkat pintar

Evolusi kelompok pelanggan pada skala

Bahagian sebelumnya merangkumi beberapa aspek mengurus sejumlah besar kluster Kubernetes. Walau bagaimanapun, terdapat satu lagi masalah yang perlu diselesaikan: evolusi kelompok.

Kubernetes ialah "Linux"dalam dunia awan. Ia sentiasa dikemas kini dan menjadi lebih modular. Kita mesti sentiasa menyampaikan versi baharu kepada pelanggan kita, menampal kelemahan dan mengemas kini kluster sedia ada, serta mengurus sebilangan besar komponen berkaitan (CSI, CNI, Pemalam Peranti, Pemalam Penjadual dan banyak lagi).

Mari kita ambil pengurusan komponen Kubernetes sebagai contoh. Sebagai permulaan, kami membangunkan sistem berpusat untuk mendaftar dan mengurus semua komponen yang bersambung ini.

nasi. 5. Komponen fleksibel dan boleh pasang

Sebelum bergerak ke hadapan, anda perlu memastikan kemas kini berjaya. Untuk melakukan ini, kami telah membangunkan sistem untuk menyemak kefungsian komponen. Semakan dilakukan sebelum dan selepas kemas kini.

nasi. 6. Semakan awal komponen kluster

Untuk mengemas kini komponen ini dengan cepat dan boleh dipercayai, sistem penggunaan berterusan berfungsi dengan sokongan untuk kemajuan separa (skala kelabu), jeda dan fungsi lain. Pengawal Kubernetes standard tidak sesuai untuk kes penggunaan ini. Oleh itu, untuk mengurus komponen kluster, kami telah membangunkan satu set pengawal khusus, termasuk pemalam dan modul kawalan tambahan (pengurusan kereta sisi).

Contohnya, pengawal BroadcastJob direka untuk mengemas kini komponen pada setiap mesin pekerja atau memeriksa nod pada setiap mesin. Tugas Penyiaran menjalankan pod pada setiap nod dalam kelompok, seperti DaemonSet. Walau bagaimanapun, DaemonSet sentiasa memastikan pod berjalan untuk masa yang lama, manakala BroadcastJob meruntuhkannya. Pengawal Penyiaran juga melancarkan pod pada nod yang baru dicantumkan dan memulakan nod dengan komponen yang diperlukan. Pada Jun 2019, kami membuka kod sumber enjin automasi OpenKruise, yang kami sendiri gunakan dalam syarikat.

nasi. 7. OpenKurise mengatur pelaksanaan tugas Penyiaran pada semua nod

Untuk membantu pelanggan memilih konfigurasi kluster yang betul, kami juga menyediakan satu set profil yang telah ditetapkan, termasuk Serverless, Edge, Windows dan Bare Metal. Seiring dengan perkembangan landskap dan keperluan pelanggan kami yang berubah, kami akan menambah lebih banyak profil untuk memudahkan proses persediaan yang membosankan.

nasi. 8. Profil kluster lanjutan dan fleksibel untuk pelbagai senario

Kebolehmerhatian global merentas pusat data

Seperti yang ditunjukkan dalam rajah di bawah. 9, perkhidmatan awan Kontena Awan Alibaba telah digunakan di dua puluh wilayah di seluruh dunia. Memandangkan skala ini, salah satu matlamat utama ACK adalah untuk memantau keadaan kluster berjalan dengan mudah supaya jika kluster pelanggan menghadapi masalah, kita boleh bertindak balas dengan cepat kepada situasi tersebut. Dalam erti kata lain, anda perlu menghasilkan penyelesaian yang membolehkan anda mengumpul statistik secara cekap dan selamat dalam masa nyata daripada kelompok pelanggan di semua wilayah - dan mempersembahkan hasilnya secara visual.

nasi. 9. Penggunaan global perkhidmatan Kontena Awan Alibaba di dua puluh wilayah

Seperti kebanyakan sistem pemantauan Kubernetes, kami menggunakan Prometheus sebagai alat utama kami. Untuk setiap metacluster, ejen Prometheus mengumpul metrik berikut:

• Metrik OS seperti sumber hos (CPU, memori, cakera, dll.) dan lebar jalur rangkaian.
• Metrik untuk sistem pengurusan kluster metacluster dan pelanggan, seperti kube-apiserver, kube-controller-manager dan kube-scheduler.
• Metrik daripada kubernetes-state-metrics dan cadvisor.
• metrik etcd seperti masa tulis cakera, saiz pangkalan data, daya pemprosesan sambungan antara nod, dsb.

Statistik global dikumpul menggunakan model pengagregatan berbilang lapisan biasa. Data pemantauan daripada setiap metacluster mula-mula diagregatkan di setiap rantau dan kemudian dihantar ke pelayan pusat yang menunjukkan gambaran keseluruhan. Semuanya berfungsi melalui mekanisme persekutuan. Pelayan Prometheus di setiap pusat data mengumpul metrik daripada pusat data tersebut dan pelayan Prometheus pusat bertanggungjawab untuk mengagregatkan data pemantauan. AlertManager bersambung ke pusat Prometheus dan, jika perlu, menghantar makluman melalui DingTalk, e-mel, SMS, dsb. Visualisasi - menggunakan Grafana.

Dalam Rajah 10, sistem pemantauan boleh dibahagikan kepada tiga peringkat:

• Aras sempadan

Lapisan paling jauh dari pusat. Pelayan Prometheus Edge berjalan dalam setiap metacluster, mengumpul metrik daripada meta dan kluster klien dalam domain rangkaian yang sama.

• Tahap lata

Fungsi lapisan lata Prometheus adalah untuk mengumpul data pemantauan daripada pelbagai rantau. Ini pelayan Mereka beroperasi pada peringkat unit geografi yang lebih besar, seperti China, Asia, Eropah dan Amerika. Apabila kluster berkembang, sesebuah rantau boleh dibahagikan, dan pelayan Prometheus yang bertingkat kemudiannya akan digunakan di setiap rantau besar yang baharu. Strategi ini membolehkan penskalaan yang lancar mengikut keperluan.

• Peringkat pusat

Pelayan Prometheus pusat menyambung kepada semua pelayan lata dan melaksanakan pengagregatan data akhir. Untuk kebolehpercayaan, dua contoh Prometheus pusat telah dibangkitkan di zon berbeza, disambungkan ke pelayan lata yang sama.

nasi. 10. Seni bina pemantauan pelbagai peringkat global berdasarkan mekanisme persekutuan Prometheus

Ringkasan

Penyelesaian awan berasaskan Kubernetes terus mengubah industri kami. Perkhidmatan kontena Alibaba Cloud menyediakan pengehosan yang selamat, boleh dipercayai dan berprestasi tinggi - ia adalah salah satu pengehosan awan Kubernetes terbaik. Pasukan Alibaba Cloud sangat percaya pada prinsip Sumber Terbuka dan komuniti sumber terbuka. Kami pasti akan terus berkongsi pengetahuan kami dalam bidang mengendalikan dan mengurus teknologi awan.

Sumber: www.habr.com