Halo, nama saya Dmitry Krasnov. Selama lebih dari lima tahun saya telah mengelola cluster Kubernetes dan membangun arsitektur layanan mikro yang kompleks. Pada awal tahun ini, kami meluncurkan layanan pengelolaan cluster Kubernetes berbasis Containerum. Pada kesempatan ini, saya akan memberi tahu Anda apa itu Kubernetes dan perbedaan integrasi dengan vendor dengan open source.
Sebagai permulaan, apa itu . Ini adalah sistem untuk mengelola container pada host dalam jumlah besar. Dari bahasa Yunani, kata ini diterjemahkan sebagai "pilot" atau "juru mudi". Awalnya dikembangkan oleh Google dan kemudian didonasikan sebagai kontribusi teknologi kepada Cloud Native Computing Foundation, sebuah organisasi nirlaba internasional yang menyatukan pengembang, pengguna akhir, dan penyedia teknologi container terkemuka di dunia.
Kelola kontainer dalam jumlah besar
Sekarang mari kita cari tahu jenis wadah apa ini. Ini adalah aplikasi dengan seluruh lingkungannya - terutama perpustakaan tempat program bergantung. Semua ini dikemas dalam arsip dan disajikan dalam bentuk gambar yang dapat dijalankan terlepas dari sistem operasinya, diuji dan banyak lagi. Namun ada masalah - mengelola container pada host dalam jumlah besar sangatlah sulit. Itu sebabnya Kubernetes diciptakan.
Gambar kontainer mewakili aplikasi ditambah dependensinya. Aplikasi, dependensinya, dan image sistem file OS terletak di berbagai bagian image, yang disebut lapisan. Lapisan dapat digunakan kembali untuk wadah yang berbeda. Misalnya, semua aplikasi di suatu perusahaan mungkin menggunakan lapisan dasar Ubuntu. Saat menjalankan container, tidak perlu menyimpan banyak salinan dari satu lapisan dasar di host. Ini memungkinkan Anda mengoptimalkan penyimpanan dan pengiriman gambar.
Saat kita ingin menjalankan aplikasi dari sebuah container, lapisan yang diperlukan ditumpangkan satu sama lain dan sistem file overlay terbentuk. Lapisan perekam ditempatkan di atas, yang dihapus ketika wadah berhenti. Hal ini memastikan bahwa ketika container dijalankan, aplikasi akan selalu memiliki lingkungan yang sama, yang tidak dapat diubah. Hal ini menjamin reproduktifitas lingkungan pada OS host yang berbeda. Baik itu Ubuntu atau CentOS, lingkungannya akan selalu sama. Selain itu, container diisolasi dari host menggunakan mekanisme yang dibangun di dalam kernel Linux. Aplikasi dalam sebuah wadah tidak melihat file, proses dari host dan wadah tetangganya. Isolasi aplikasi dari OS host ini memberikan lapisan keamanan tambahan.
Ada banyak alat yang tersedia untuk mengelola container di sebuah host. Yang paling populer adalah Docker. Hal ini memungkinkan Anda untuk menyediakan siklus hidup kontainer secara penuh. Namun, ini hanya berfungsi pada satu host. Jika Anda perlu mengelola container di beberapa host, Docker dapat membuat hidup menjadi sangat sulit bagi para insinyur. Itu sebabnya Kubernetes diciptakan.
Permintaan terhadap Kubernetes justru disebabkan oleh kemampuannya untuk mengelola kelompok container di beberapa host sebagai suatu entitas tunggal. Popularitas sistem memberikan peluang untuk membangun DevOps atau Operasi Pengembangan, di mana Kubernetes digunakan untuk menjalankan proses DevOps ini.
Gambar 1. Representasi skema cara kerja Kubernetes
Otomatisasi penuh
DevOps pada dasarnya adalah otomatisasi proses pengembangan. Secara kasar, pengembang menulis kode yang diunggah ke repositori. Kemudian kode ini dapat dikumpulkan secara otomatis segera ke dalam wadah dengan semua perpustakaan, diuji dan “diluncurkan” ke tahap berikutnya - Penahapan, dan kemudian segera ke Produksi.
Bersama dengan Kubernetes, DevOps memungkinkan Anda mengotomatiskan proses ini sehingga terjadi tanpa partisipasi pengembang itu sendiri. Oleh karena itu, pembuatannya jauh lebih cepat, karena pengembang tidak perlu melakukan ini di komputernya - ia cukup menulis sepotong kode, memasukkan kode tersebut ke repositori, setelah itu pipeline diluncurkan, yang dapat menyertakan proses tersebut. membangun, menguji, dan meluncurkan. Dan ini terjadi pada setiap penerapan, jadi pengujian dilakukan terus-menerus.
Pada saat yang sama, penggunaan wadah memungkinkan Anda memastikan bahwa seluruh lingkungan program ini akan dirilis ke produksi persis dalam bentuk pengujiannya. Artinya, tidak akan ada masalah seperti “ada beberapa versi dalam pengujian, yang lain dalam produksi, tetapi ketika kami menginstalnya, semuanya jatuh”. Dan karena saat ini kita memiliki tren ke arah arsitektur layanan mikro, ketika alih-alih satu aplikasi besar terdapat ratusan aplikasi kecil, maka untuk mengelolanya secara manual, dibutuhkan banyak staf. Itu sebabnya kami menggunakan Kubernetes.
Pro, pro, pro
Jika kita berbicara tentang keunggulan Kubernetes sebagai sebuah platform, maka Kubernetes memiliki keunggulan yang signifikan dalam hal pengelolaan arsitektur layanan mikro.
- Mengelola banyak replika. Yang paling penting adalah mengelola container di banyak host. Lebih penting lagi, kelola beberapa replika aplikasi dalam kontainer sebagai satu kesatuan. Berkat ini, para insinyur tidak perlu mengkhawatirkan setiap kontainer. Jika salah satu container mengalami error, Kubernetes akan melihatnya dan memulai ulang lagi.
- Jaringan cluster. Kubernetes juga memiliki jaringan cluster dengan ruang alamatnya sendiri. Berkat ini, setiap pod memiliki alamatnya sendiri. Subpod dipahami sebagai unit struktural minimum dari sebuah cluster tempat container diluncurkan secara langsung. Selain itu, Kubernetes memiliki fungsionalitas yang menggabungkan penyeimbang beban dan Service Discovery. Hal ini memungkinkan Anda menghilangkan pengelolaan alamat IP manual dan mendelegasikan tugas ini ke Kubernetes. Dan pemeriksaan kesehatan otomatis akan membantu mendeteksi masalah dan mengarahkan lalu lintas ke pod yang berfungsi.
- Manajemen konfigurasi. Saat mengelola aplikasi dalam jumlah besar, mengelola konfigurasi aplikasi menjadi sulit. Untuk tujuan ini, Kubernetes memiliki sumber daya ConfigMap khusus. Mereka memungkinkan Anda menyimpan konfigurasi secara terpusat dan memaparkannya ke pod saat menjalankan aplikasi. Mekanisme ini memungkinkan kami menjamin konsistensi konfigurasi setidaknya pada sepuluh atau seratus replika aplikasi.
- Volume Persisten. Kontainer pada dasarnya tidak dapat diubah dan ketika kontainer dihentikan, semua data yang ditulis ke sistem file akan dimusnahkan. Namun beberapa aplikasi menyimpan data langsung pada disk. Untuk mengatasi masalah ini, Kubernetes memiliki fungsi manajemen penyimpanan disk - Volume Persisten. Mekanisme ini menggunakan penyimpanan eksternal untuk data dan dapat mentransfer penyimpanan persisten, blok atau file, ke dalam wadah. Solusi ini memungkinkan Anda menyimpan data secara terpisah dari pekerja, sehingga menyimpannya jika pekerja yang sama tersebut mogok.
- Penyeimbang Beban. Meskipun di Kubernetes kami mengelola entitas abstrak seperti Deployment, StatefulSet, dll., pada akhirnya container berjalan di mesin virtual biasa atau server perangkat keras. Mereka tidak sempurna dan bisa jatuh kapan saja. Kubernetes akan melihatnya dan mengalihkan lalu lintas internal ke replika lain. Tapi apa hubungannya dengan lalu lintas yang datang dari luar? Jika Anda hanya mengarahkan lalu lintas ke salah satu pekerja, jika macet, layanan tidak akan tersedia. Untuk mengatasi masalah ini, Kubernetes memiliki layanan seperti Load Balancer. Mereka dirancang untuk secara otomatis mengonfigurasi penyeimbang cloud eksternal untuk semua pekerja di cluster. Penyeimbang eksternal ini mengarahkan lalu lintas eksternal ke pekerja dan memantau sendiri status mereka. Jika satu atau lebih pekerja tidak tersedia, lalu lintas dialihkan ke pekerja lain. Hal ini memungkinkan Anda membuat layanan dengan ketersediaan tinggi menggunakan Kubernetes.
Kubernetes berfungsi paling baik saat menjalankan arsitektur layanan mikro. Dimungkinkan untuk mengimplementasikan sistem ke dalam arsitektur klasik, tetapi tidak ada gunanya. Jika suatu aplikasi tidak dapat berjalan di banyak replika, apa bedanya - di Kubernetes atau tidak?
Kubernet sumber terbuka
Kubernetes open source adalah hal yang hebat: Saya menginstalnya dan berfungsi. Anda dapat menyebarkannya di server perangkat keras Anda sendiri, di infrastruktur Anda sendiri, menginstal master dan pekerja di mana semua aplikasi akan berjalan. Dan yang terpenting, semua ini gratis. Namun, ada beberapa perbedaan.
- Yang pertama adalah permintaan akan pengetahuan dan pengalaman administrator dan insinyur yang akan menerapkan dan mendukung semua ini. Karena klien menerima kebebasan penuh untuk bertindak di cluster, dia sendiri yang bertanggung jawab atas kinerja cluster. Dan sangat mudah untuk menghancurkan semuanya di sini.
- Yang kedua adalah kurangnya integrasi. Jika Anda menjalankan Kubernetes tanpa platform virtualisasi yang populer, Anda tidak akan mendapatkan semua manfaat dari program ini. Seperti menggunakan layanan Persistent Volumes dan Load balancer.
Gambar 2. arsitektur k8s
Kubernetes dari vendor
Integrasi dengan penyedia cloud memberikan dua opsi:
- Pertama, seseorang cukup mengklik tombol “buat cluster” dan mendapatkan cluster yang sudah terkonfigurasi dan siap digunakan.
- Kedua, vendor sendiri yang menginstal cluster dan menyiapkan integrasi dengan cloud.
Bagaimana hal itu terjadi di sini. Insinyur yang memulai cluster menentukan berapa banyak pekerja yang dia perlukan dan dengan parameter apa (misalnya, 5 pekerja, masing-masing dengan 10 CPU, 16 GB RAM dan, katakanlah, disk 100 GB). Setelah itu memperoleh akses ke cluster yang sudah terbentuk. Dalam hal ini, pekerja tempat beban diluncurkan sepenuhnya ditransfer ke klien, namun seluruh bidang manajemen tetap berada di bawah tanggung jawab vendor (jika layanan disediakan sesuai dengan model layanan terkelola).
Namun skema ini mempunyai kelemahan. Karena bidang manajemen tetap berada di tangan vendor, vendor tidak memberikan akses penuh kepada klien, dan hal ini mengurangi fleksibilitas dalam bekerja dengan Kubernetes. Terkadang klien ingin menambahkan beberapa fungsi tertentu ke Kubernetes, misalnya, otentikasi melalui LDAP, tetapi konfigurasi bidang manajemen tidak mengizinkan hal ini.
Gambar 3. Contoh cluster Kubernetes dari penyedia cloud
Apa yang harus dipilih: open source atau vendor
Jadi, apakah Kubernetes bersifat open source atau spesifik untuk vendor? Jika kita menggunakan Kubernetes open source, maka pengguna akan melakukan apa yang diinginkannya. Tapi ada peluang besar untuk menembak diri sendiri. Dengan vendor, ini lebih sulit, karena semuanya dipikirkan dan dikonfigurasi untuk perusahaan. Kerugian terbesar dari Kubernetes open source adalah kebutuhan akan spesialis. Dengan adanya opsi vendor, perusahaan terbebas dari masalah ini, namun perusahaan harus memutuskan apakah akan membayar spesialisnya atau vendornya.
Nah, kelebihannya sudah jelas, kekurangannya juga diketahui. Ada satu hal yang tetap: Kubernetes memecahkan banyak masalah dengan mengotomatiskan pengelolaan banyak container. Dan mana yang harus dipilih, open source atau vendor - setiap orang membuat keputusannya sendiri.
Artikel ini disiapkan oleh Dmitry Krasnov, arsitek terkemuka layanan Containerum dari penyedia #CloudMTS
Sumber: www.habr.com