Cube-on-cube, metacluster, sarang lebah, distribusi sumber daya

Beras. 1. Ekosistem Kubernetes di Alibaba Cloud

Sejak tahun 2015, Alibaba Cloud Container Service for Kubernetes (ACK) telah menjadi salah satu layanan cloud dengan pertumbuhan tercepat di Alibaba Cloud. Ini melayani banyak klien dan juga mendukung infrastruktur internal Alibaba dan layanan cloud perusahaan lainnya.

Seperti halnya layanan kontainer serupa dari penyedia cloud kelas dunia, prioritas utama kami adalah keandalan dan ketersediaan. Oleh karena itu, platform yang terukur dan dapat diakses secara global telah diciptakan untuk puluhan ribu cluster Kubernetes.

Pada artikel ini, kami akan berbagi pengalaman kami dalam mengelola sejumlah besar cluster Kubernetes di infrastruktur cloud, serta arsitektur platform yang mendasarinya.

Masuk

Kubernetes telah menjadi standar de facto untuk berbagai beban kerja di cloud. Seperti yang ditunjukkan pada Gambar. 1 di atas, semakin banyak aplikasi Alibaba Cloud yang berjalan di cluster Kubernetes: aplikasi stateful dan stateless, serta pengelola aplikasi. Manajemen Kubernetes selalu menjadi topik diskusi yang menarik dan serius bagi para insinyur yang membangun dan memelihara infrastruktur. Jika berbicara tentang penyedia cloud seperti Alibaba Cloud, masalah penskalaan akan mengemuka. Bagaimana cara mengelola cluster Kubernetes pada skala ini? Kami telah membahas praktik terbaik untuk mengelola cluster Kubernetes yang berjumlah 10 node. Tentu saja, ini merupakan masalah penskalaan yang menarik. Namun ada skala lain: kuantitas cluster itu sendiri.

Kami telah mendiskusikan topik ini dengan banyak pengguna ACK. Kebanyakan dari mereka memilih untuk menjalankan lusinan, bahkan ratusan, cluster Kubernetes berukuran kecil atau menengah. Ada alasan bagus untuk ini: membatasi potensi kerusakan, memisahkan cluster untuk tim yang berbeda, membuat cluster virtual untuk pengujian. Jika ACK bertujuan untuk melayani khalayak global dengan model penggunaan ini, ACK harus mengelola sejumlah besar cluster di lebih dari 20 wilayah secara andal dan efisien.

Beras. 2. Masalah dalam mengelola cluster Kubernetes dalam jumlah besar

Apa tantangan utama dalam mengelola klaster pada skala ini? Seperti yang ditunjukkan pada gambar, ada empat masalah yang harus ditangani:

• Heterogenitas

ACK harus mendukung berbagai jenis cluster, termasuk standar, tanpa server, Edge, Windows, dan beberapa lainnya. Cluster yang berbeda memerlukan opsi, komponen, dan model hosting yang berbeda. Beberapa pelanggan memerlukan bantuan penyesuaian untuk kasus spesifik mereka.

• Berbagai ukuran cluster

Ukuran cluster bervariasi, dari beberapa node dengan beberapa pod hingga puluhan ribu node dengan ribuan pod. Kebutuhan sumber daya juga sangat bervariasi. Alokasi sumber daya yang tidak tepat dapat berdampak pada kinerja atau bahkan menyebabkan kegagalan.

• Versi berbeda

Kubernetes berkembang sangat cepat. Versi baru dirilis setiap beberapa bulan. Pelanggan selalu bersedia mencoba fitur baru. Jadi mereka ingin menempatkan beban pengujian pada Kubernetes versi baru dan beban produksi pada versi stabil. Untuk memenuhi persyaratan ini, ACK harus terus menghadirkan versi baru Kubernetes kepada pelanggan sambil mempertahankan versi stabil.

• Kepatuhan Keamanan

Cluster tersebar di berbagai wilayah. Oleh karena itu, mereka harus mematuhi berbagai persyaratan keselamatan dan peraturan resmi. Misalnya, klaster di Eropa harus mematuhi GDPR, sedangkan cloud finansial di Tiongkok harus memiliki lapisan perlindungan tambahan. Persyaratan ini bersifat wajib dan tidak dapat diterima untuk mengabaikannya, karena hal ini menimbulkan risiko besar bagi klien platform cloud.

Platform ACK dirancang untuk menyelesaikan sebagian besar masalah di atas. Saat ini mereka mengelola lebih dari 10 ribu cluster Kubernetes di seluruh dunia dengan andal dan stabil. Mari kita lihat bagaimana hal ini dicapai, termasuk melalui beberapa prinsip desain/arsitektur utama.

Disain

Kubus-ke-kubus dan sarang lebah

Berbeda dengan hierarki terpusat, arsitektur berbasis sel biasanya digunakan untuk menskalakan platform melampaui satu pusat data atau untuk memperluas cakupan pemulihan bencana.

Setiap wilayah di Alibaba Cloud terdiri dari beberapa zona (AZ) dan biasanya berhubungan dengan pusat data tertentu. Di wilayah yang luas (misalnya Huangzhou), seringkali terdapat ribuan cluster klien Kubernetes yang menjalankan ACK.

ACK mengelola klaster Kubernetes ini menggunakan Kubernetes itu sendiri, artinya kita menjalankan metacluster Kubernetes untuk mengelola klaster Kubernetes klien. Arsitektur ini disebut juga “kube-on-kube” (KoK). Arsitektur KoK menyederhanakan pengelolaan klaster klien karena penerapan klaster sederhana dan deterministik. Yang lebih penting lagi, kami dapat menggunakan kembali fitur-fitur asli Kubernetes. Misalnya, mengelola server API melalui penerapan, menggunakan operatoretcd untuk mengelola beberapaetcds. Pengulangan seperti itu selalu membawa kesenangan tersendiri.

Beberapa metacluster Kubernetes diterapkan dalam satu wilayah, bergantung pada jumlah klien. Kami menyebutnya sel metacluster. Untuk melindungi dari kegagalan seluruh zona, ACK mendukung penerapan multi-aktif di satu wilayah: metacluster mendistribusikan komponen master cluster klien Kubernetes ke beberapa zona dan menjalankannya secara bersamaan, yaitu dalam mode multi-aktif. Untuk menjamin keandalan dan efisiensi master, ACK mengoptimalkan penempatan komponen dan memastikan bahwa server API dan dll berdekatan satu sama lain.

Model ini memungkinkan Anda mengelola Kubernetes secara efisien, fleksibel, dan andal.

Perencanaan sumber daya metacluster

Seperti yang telah kami sebutkan, jumlah metacluster di setiap wilayah bergantung pada jumlah klien. Tapi kapan harus menambahkan metacluster baru? Ini adalah masalah perencanaan sumber daya yang umum. Sebagai aturan, merupakan kebiasaan untuk membuat yang baru ketika metacluster yang ada telah menghabiskan semua sumber dayanya.

Mari kita ambil sumber daya jaringan, misalnya. Dalam arsitektur KoK, komponen Kubernetes dari cluster klien di-deploy sebagai pod di metacluster. Kita gunakan Terway (Gbr. 3) adalah plugin berkinerja tinggi yang dikembangkan oleh Alibaba Cloud untuk manajemen jaringan kontainer. Ini memberikan serangkaian kebijakan keamanan dan memungkinkan Anda terhubung ke virtual private cloud (VPC) pelanggan melalui Alibaba Cloud Elastic Networking Interface (ENI). Untuk mendistribusikan sumber daya jaringan secara efektif ke seluruh node, pod, dan layanan dalam metacluster, kita harus memantau penggunaannya secara cermat dalam metacluster virtual private cloud. Ketika sumber daya jaringan habis, sel baru dibuat.

Untuk menentukan jumlah cluster klien yang optimal di setiap metacluster, kami juga memperhitungkan biaya, persyaratan kepadatan, kuota sumber daya, persyaratan keandalan, dan statistik. Keputusan untuk membuat metacluster baru dibuat berdasarkan semua informasi ini. Harap dicatat bahwa cluster kecil dapat berkembang pesat di masa depan, sehingga konsumsi sumber daya meningkat meskipun jumlah cluster tidak berubah. Kami biasanya memberikan ruang kosong yang cukup untuk setiap cluster untuk berkembang.

Beras. 3. Arsitektur jaringan Terway

Menskalakan komponen wizard di seluruh kluster klien

Komponen wizard memiliki kebutuhan sumber daya yang berbeda. Mereka bergantung pada jumlah node dan pod di cluster, jumlah pengontrol/operator non-standar yang berinteraksi dengan APIServer.

Di ACK, setiap cluster klien Kubernetes berbeda dalam ukuran dan persyaratan runtime. Tidak ada konfigurasi universal untuk menempatkan komponen wizard. Jika kita secara keliru menetapkan batas sumber daya yang rendah untuk klien besar, maka clusternya tidak akan mampu mengatasi beban tersebut. Jika Anda menetapkan batas tinggi yang konservatif untuk semua cluster, sumber daya akan terbuang percuma.

Untuk menemukan trade-off halus antara keandalan dan biaya, ACK menggunakan sistem tipe. Yaitu, kami mendefinisikan tiga jenis cluster: kecil, sedang dan besar. Setiap jenis memiliki profil alokasi sumber daya terpisah. Jenisnya ditentukan berdasarkan beban komponen wizard, jumlah node, dan faktor lainnya. Tipe cluster dapat berubah seiring waktu. ACK terus memantau faktor-faktor ini dan dapat mengetik naik/turun sesuai dengan itu. Setelah jenis cluster diubah, alokasi sumber daya diperbarui secara otomatis dengan intervensi pengguna minimal.

Kami berupaya menyempurnakan sistem ini dengan penskalaan yang lebih menyeluruh dan pembaruan tipe yang lebih tepat sehingga perubahan ini terjadi lebih lancar dan lebih masuk akal secara ekonomi.

Beras. 4. Peralihan tipe multi-tahap yang cerdas

Evolusi cluster klien dalam skala besar

Bagian sebelumnya membahas beberapa aspek pengelolaan cluster Kubernetes dalam jumlah besar. Namun, ada masalah lain yang perlu dipecahkan: evolusi klaster.

Kubernetes adalah “Linux” dari dunia cloud. Itu terus diperbarui dan menjadi lebih modular. Kami harus terus-menerus memberikan versi baru kepada pelanggan kami, memperbaiki kerentanan dan memperbarui cluster yang ada, serta mengelola sejumlah besar komponen terkait (CSI, CNI, Device Plugin, Scheduler Plugin, dan banyak lainnya).

Mari kita ambil contoh manajemen komponen Kubernetes. Untuk memulainya, kami mengembangkan sistem terpusat untuk mendaftarkan dan mengelola semua komponen yang terhubung ini.

Beras. 5. Komponen yang fleksibel dan dapat dicolokkan

Sebelum melanjutkan, Anda perlu memastikan pembaruan berhasil. Untuk melakukan ini, kami telah mengembangkan sistem untuk memeriksa fungsionalitas komponen. Pengecekan dilakukan sebelum dan sesudah update.

Beras. 6. Pengecekan awal komponen cluster

Untuk memperbarui komponen ini dengan cepat dan andal, sistem penerapan berkelanjutan bekerja dengan dukungan untuk kemajuan sebagian (skala abu-abu), jeda, dan fungsi lainnya. Pengontrol Kubernetes standar tidak cocok untuk kasus penggunaan ini. Oleh karena itu, untuk mengelola komponen cluster, kami telah mengembangkan seperangkat pengontrol khusus, termasuk plugin dan modul kontrol tambahan (manajemen sespan).

Misalnya, pengontrol BroadcastJob dirancang untuk memperbarui komponen pada setiap mesin pekerja atau memeriksa node pada setiap mesin. Pekerjaan Broadcast menjalankan pod pada setiap node di cluster, seperti DaemonSet. Namun, DaemonSet selalu membuat pod tetap berjalan dalam waktu lama, sementara BroadcastJob menciutkannya. Pengontrol siaran juga meluncurkan pod pada node yang baru bergabung dan menginisialisasi node dengan komponen yang diperlukan. Pada bulan Juni 2019, kami membuka kode sumber mesin otomasi OpenKruise, yang kami gunakan sendiri di dalam perusahaan.

Beras. 7. OpenKurise mengatur pelaksanaan tugas Broadcast di semua node

Untuk membantu pelanggan memilih konfigurasi cluster yang tepat, kami juga menyediakan serangkaian profil yang telah ditentukan sebelumnya, termasuk profil Tanpa Server, Edge, Windows, dan Bare Metal. Seiring dengan perluasan lanskap dan kebutuhan pelanggan kami yang meningkat, kami akan menambahkan lebih banyak profil untuk menyederhanakan proses penyiapan yang membosankan.

Beras. 8. Profil cluster yang canggih dan fleksibel untuk berbagai skenario

Observabilitas global di seluruh pusat data

Seperti yang ditunjukkan pada gambar di bawah ini. Pada tanggal 9 September, layanan cloud Alibaba Cloud Container telah diterapkan di dua puluh wilayah di seluruh dunia. Mengingat skala ini, salah satu tujuan utama ACK adalah dengan mudah memantau keadaan cluster yang berjalan sehingga jika cluster klien mengalami masalah, kami dapat dengan cepat merespons situasi tersebut. Dengan kata lain, Anda perlu menemukan solusi yang memungkinkan Anda mengumpulkan statistik secara real-time secara efisien dan aman dari cluster klien di semua wilayah - dan menyajikan hasilnya secara visual.

Beras. 9. Penyebaran global layanan Alibaba Cloud Container di dua puluh wilayah

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

• Metrik OS seperti sumber daya host (CPU, memori, disk, dll.) dan bandwidth jaringan.
• Metrik untuk sistem manajemen metacluster dan cluster klien, seperti kube-apiserver, kube-controller-manager, dan kube-scheduler.
• Metrik dari kubernetes-state-metrics dan cadvisor.
• metrik dlld seperti waktu penulisan disk, ukuran database, throughput koneksi antar node, dll.

Statistik global dikumpulkan menggunakan model agregasi multi-lapisan yang khas. Data pemantauan dari setiap metacluster pertama-tama dikumpulkan di setiap wilayah dan kemudian dikirim ke server pusat yang menunjukkan gambaran keseluruhan. Semuanya berjalan melalui mekanisme federasi. Server Prometheus di setiap pusat data mengumpulkan metrik dari pusat data tersebut, dan server Prometheus pusat bertanggung jawab untuk mengumpulkan data pemantauan. AlertManager terhubung ke pusat Prometheus dan, jika perlu, mengirimkan peringatan melalui DingTalk, email, SMS, dll. Visualisasi - menggunakan Grafana.

Pada Gambar 10, sistem pemantauan dapat dibagi menjadi tiga tingkatan:

• Tingkat batas

Lapisan yang paling jauh dari pusat. Prometheus Edge Server berjalan di setiap metacluster, mengumpulkan metrik dari meta dan cluster klien dalam domain jaringan yang sama.

• Tingkat kaskade

Fungsi lapisan kaskade Prometheus adalah mengumpulkan data pemantauan dari berbagai wilayah. Server-server ini beroperasi pada tingkat unit geografis yang lebih besar seperti Tiongkok, Asia, Eropa, dan Amerika. Seiring pertumbuhan cluster, wilayah dapat dibagi, dan server Prometheus tingkat kaskade akan muncul di setiap wilayah besar baru. Dengan strategi ini, Anda dapat melakukan penskalaan dengan lancar sesuai kebutuhan.

• Tingkat pusat

Server Prometheus pusat terhubung ke semua server kaskade dan melakukan agregasi data akhir. Untuk keandalan, dua instance Prometheus pusat dibangun di zona berbeda, terhubung ke server kaskade yang sama.

Beras. 10. Arsitektur pemantauan multi-level global berdasarkan mekanisme federasi Prometheus

Ringkasan

Solusi cloud berbasis Kubernetes terus mentransformasi industri kami. Layanan kontainer Alibaba Cloud menyediakan hosting yang aman, andal, dan berkinerja tinggi - ini adalah salah satu hosting cloud Kubernetes terbaik. Tim Alibaba Cloud sangat percaya pada prinsip Open Source dan komunitas open source. Kami pasti akan terus berbagi ilmu di bidang pengoperasian dan pengelolaan teknologi cloud.

Sumber: www.habr.com