Kubernetes: sumber terbuka lwn. khusus vendor

Halo, nama saya Dmitry Krasnov. Selama lebih daripada lima tahun saya telah mentadbir kluster Kubernetes dan membina seni bina perkhidmatan mikro yang kompleks. Pada awal tahun ini, kami melancarkan perkhidmatan untuk mengurus kluster Kubernetes berdasarkan Containerum. Mengambil peluang ini, saya akan memberitahu anda apa itu Kubernetes dan cara penyepaduan dengan vendor berbeza daripada sumber terbuka.

Sebagai permulaan, apa itu Kubernetes. Ini ialah sistem untuk menguruskan bekas pada sebilangan besar hos. Daripada bahasa Yunani, omong-omong, ia diterjemahkan sebagai "juruterbang" atau "jurumudi." Pada asalnya dibangunkan oleh Google dan kemudian didermakan sebagai sumbangan teknologi kepada Cloud Native Computing Foundation, sebuah organisasi bukan untung antarabangsa yang menghimpunkan pembangun terkemuka dunia, pengguna akhir dan penyedia teknologi kontena.

Uruskan sejumlah besar bekas

Sekarang mari kita fikirkan jenis bekas ini. Ini adalah aplikasi dengan keseluruhan persekitarannya - terutamanya perpustakaan tempat program bergantung. Semua ini dibungkus dalam arkib dan dibentangkan dalam bentuk imej yang boleh dijalankan tanpa mengira sistem pengendalian, diuji dan banyak lagi. Tetapi terdapat masalah - menguruskan kontena pada sejumlah besar hos adalah sangat sukar. Itulah sebabnya Kubernetes dicipta.

Imej bekas mewakili aplikasi ditambah kebergantungannya. Aplikasi, kebergantungannya, dan imej sistem fail OS terletak di bahagian imej yang berlainan, yang dipanggil lapisan. Lapisan boleh digunakan semula untuk bekas yang berbeza. Sebagai contoh, semua aplikasi dalam syarikat mungkin menggunakan lapisan asas Ubuntu. Apabila menjalankan bekas, tidak perlu menyimpan berbilang salinan lapisan asas tunggal pada hos. Ini membolehkan anda mengoptimumkan storan dan penghantaran imej.

Apabila kita ingin menjalankan aplikasi dari bekas, lapisan yang diperlukan ditindih antara satu sama lain dan sistem fail tindanan terbentuk. Lapisan rakaman diletakkan di atas, yang dikeluarkan apabila bekas berhenti. Ini memastikan bahawa apabila bekas dijalankan, aplikasi akan sentiasa mempunyai persekitaran yang sama, yang tidak boleh diubah. Ini menjamin kebolehulangan persekitaran pada OS hos yang berbeza. Sama ada Ubuntu atau CentOS, persekitaran akan sentiasa sama. Di samping itu, bekas itu diasingkan daripada hos menggunakan mekanisme yang dibina ke dalam kernel Linux. Aplikasi dalam bekas tidak melihat fail, proses hos dan bekas jiran. Pengasingan aplikasi daripada OS hos ini menyediakan lapisan keselamatan tambahan.

Terdapat banyak alatan yang tersedia untuk mengurus bekas pada hos. Yang paling popular ialah Docker. Ia membolehkan anda menyediakan kitaran hayat penuh bekas. Walau bagaimanapun, ia hanya berfungsi pada satu hos. Jika anda perlu mengurus bekas merentasi berbilang hos, Docker boleh menjadikan kehidupan sebagai neraka bagi jurutera. Itulah sebabnya Kubernetes dicipta.

Permintaan untuk Kubernetes adalah disebabkan oleh keupayaan untuk mengurus kumpulan kontena pada berbilang hos sebagai sejenis entiti tunggal. Populariti sistem memberi peluang untuk membina DevOps atau Operasi Pembangunan, di mana Kubernetes digunakan untuk menjalankan proses DevOps ini.

Rajah 1. Perwakilan skematik cara Kubernetes berfungsi

Automasi penuh

DevOps pada asasnya adalah automasi proses pembangunan. Secara kasarnya, pembangun menulis kod yang dimuat naik ke repositori. Kemudian kod ini boleh dikumpulkan secara automatik ke dalam bekas dengan semua perpustakaan, diuji dan "dilancarkan" ke peringkat seterusnya - Pementasan, dan kemudian ke Pengeluaran.

Bersama-sama dengan Kubernetes, DevOps membenarkan anda mengautomasikan proses ini supaya ia berlaku tanpa penyertaan daripada pembangun itu sendiri. Disebabkan ini, binaan jauh lebih pantas, kerana pembangun tidak perlu melakukan ini pada komputernya - dia hanya menulis sekeping kod, menolak kod ke repositori, selepas itu saluran paip dilancarkan, yang boleh merangkumi proses membina, menguji, dan melancarkan. Dan ini berlaku dengan setiap komitmen, jadi ujian berlaku secara berterusan.

Pada masa yang sama, menggunakan bekas membolehkan anda memastikan bahawa keseluruhan persekitaran program ini akan dikeluarkan ke dalam pengeluaran tepat dalam bentuk di mana ia telah diuji. Iaitu, tidak akan ada masalah seperti "terdapat beberapa versi dalam ujian, yang lain dalam pengeluaran, tetapi apabila kami memasangnya, semuanya jatuh." Dan sejak hari ini kami mempunyai trend ke arah seni bina perkhidmatan mikro, apabila bukannya satu aplikasi besar terdapat ratusan aplikasi kecil, untuk mentadbirnya secara manual, kakitangan yang ramai pekerja akan diperlukan. Itulah sebabnya kami menggunakan Kubernetes.

Kebaikan, kebaikan, kebaikan

Jika kita bercakap tentang kelebihan Kubernetes sebagai platform, maka ia mempunyai kelebihan yang ketara dari sudut pandangan mengurus seni bina perkhidmatan mikro.

• Menguruskan berbilang replika. Perkara yang paling penting ialah mengurus bekas merentas berbilang hos. Lebih penting lagi, uruskan berbilang replika aplikasi dalam bekas sebagai satu entiti. Terima kasih kepada ini, jurutera tidak perlu risau tentang setiap bekas individu. Jika salah satu bekas ranap, Kubernetes akan melihatnya dan memulakannya semula.
• Rangkaian kluster. Kubernetes juga mempunyai rangkaian kluster yang dipanggil dengan ruang alamatnya sendiri. Terima kasih kepada ini, setiap pod mempunyai alamatnya sendiri. Subpod difahami sebagai unit struktur minimum gugusan di mana bekas dilancarkan secara langsung. Selain itu, Kubernetes mempunyai fungsi yang menggabungkan pengimbang beban dan Penemuan Perkhidmatan. Ini membolehkan anda menyingkirkan pengurusan alamat IP manual dan mewakilkan tugas ini kepada Kubernetes. Dan pemeriksaan kesihatan automatik akan membantu mengesan masalah dan mengubah hala trafik ke pod berfungsi.
• Pengurusan konfigurasi. Apabila menguruskan sejumlah besar aplikasi, ia menjadi sukar untuk mengurus konfigurasi aplikasi. Untuk tujuan ini, Kubernetes mempunyai sumber ConfigMap khas. Mereka membenarkan anda menyimpan konfigurasi secara berpusat dan mendedahkannya kepada pod semasa menjalankan aplikasi. Mekanisme ini membolehkan kami menjamin ketekalan konfigurasi dalam sekurang-kurangnya sepuluh atau seratus replika aplikasi.
• Jilid Berterusan. Bekas sememangnya tidak boleh diubah dan apabila bekas dihentikan, semua data yang ditulis pada sistem fail akan dimusnahkan. Tetapi sesetengah aplikasi menyimpan data terus pada cakera. Untuk menyelesaikan masalah ini, Kubernetes mempunyai fungsi pengurusan storan cakera - Jilid Berterusan. Mekanisme ini menggunakan storan luaran untuk data dan boleh memindahkan storan, blok atau fail yang berterusan ke dalam bekas. Penyelesaian ini membolehkan anda menyimpan data secara berasingan daripada pekerja, yang menjimatkan mereka jika pekerja yang sama ini rosak.
• Pengimbang Beban. Walaupun dalam Kubernetes kami menguruskan entiti abstrak seperti Deployment, StatefulSet, dsb., akhirnya bekas dijalankan pada mesin maya biasa atau pelayan perkakasan. Mereka tidak sempurna dan boleh jatuh pada bila-bila masa. Kubernetes akan melihat ini dan mengubah hala trafik dalaman ke replika lain. Tetapi apa yang perlu dilakukan dengan lalu lintas yang datang dari luar? Jika anda hanya mengarahkan trafik kepada salah seorang pekerja, jika ia ranap, perkhidmatan itu akan menjadi tidak tersedia. Untuk menyelesaikan masalah ini, Kubernetes mempunyai perkhidmatan seperti Load Balancer. Mereka direka bentuk untuk mengkonfigurasi pengimbang awan luaran secara automatik untuk semua pekerja dalam kelompok. Pengimbang luaran ini mengarahkan trafik luaran kepada pekerja dan memantau status mereka sendiri. Jika satu atau lebih pekerja tidak tersedia, trafik akan diubah hala kepada orang lain. Ini membolehkan anda membuat perkhidmatan yang sangat tersedia menggunakan Kubernetes.

Kubernetes berfungsi paling baik apabila menjalankan seni bina perkhidmatan mikro. Ia adalah mungkin untuk melaksanakan sistem ke dalam seni bina klasik, tetapi ia tidak berguna. Jika aplikasi tidak boleh dijalankan pada berbilang replika, maka apakah perbezaannya - dalam Kubernetes atau tidak?

Kubernetes sumber terbuka

Kubernetes sumber terbuka adalah perkara yang hebat: Saya memasangnya dan ia berfungsi. Anda boleh menggunakan ia pada pelayan perkakasan anda sendiri, pada infrastruktur anda sendiri, memasang induk dan pekerja di mana semua aplikasi akan dijalankan. Dan yang paling penting, semua ini percuma. Walau bagaimanapun, terdapat nuansa.

• Yang pertama ialah permintaan untuk pengetahuan dan pengalaman pentadbir dan jurutera yang akan menggunakan dan menyokong semua ini. Memandangkan klien menerima kebebasan bertindak sepenuhnya dalam kluster, dia bertanggungjawab ke atas prestasi kluster itu sendiri. Dan sangat mudah untuk memecahkan segala-galanya di sini.
• Yang kedua ialah kekurangan integrasi. Jika anda menjalankan Kubernetes tanpa platform virtualisasi yang popular, anda tidak akan mendapat semua manfaat program tersebut. Seperti menggunakan perkhidmatan Persistent Volumes dan Load balancer.

Rajah 2. seni bina k8s

Kubernetes daripada vendor

Penyepaduan dengan pembekal awan menyediakan dua pilihan:

• Pertama, seseorang hanya boleh mengklik pada butang "buat kluster" dan mendapatkan kluster yang telah dikonfigurasikan dan sedia untuk digunakan.
• Kedua, vendor sendiri memasang kluster dan menyediakan integrasi dengan awan.

Bagaimana ia berlaku di sini. Jurutera yang memulakan kluster menentukan bilangan pekerja yang dia perlukan dan dengan parameter apa (contohnya, 5 pekerja, setiap satu dengan 10 CPU, 16 GB RAM dan, katakan, 100 GB cakera). Selepas itu ia mendapat akses kepada kluster yang telah terbentuk. Dalam kes ini, pekerja di mana beban dilancarkan dipindahkan sepenuhnya kepada pelanggan, tetapi keseluruhan pesawat pengurusan kekal di bawah tanggungjawab vendor (jika perkhidmatan disediakan mengikut model perkhidmatan terurus).

Walau bagaimanapun, skim ini mempunyai kelemahannya. Disebabkan hakikat bahawa pesawat pengurusan kekal dengan vendor, vendor tidak memberikan akses penuh kepada pelanggan, dan ini mengurangkan kefleksibelan dalam bekerja dengan Kubernetes. Kadangkala ia berlaku bahawa pelanggan ingin menambah beberapa fungsi khusus pada Kubernetes, sebagai contoh, pengesahan melalui LDAP, tetapi konfigurasi satah pengurusan tidak membenarkan ini.

Rajah 3. Contoh gugusan Kubernetes daripada pembekal awan

Perkara yang perlu dipilih: sumber terbuka atau vendor

Jadi, adakah Kubernetes sumber terbuka atau vendor khusus? Jika kita mengambil Kubernetes sumber terbuka, maka pengguna melakukan apa yang dia mahu dengannya. Tetapi ada peluang besar untuk menembak diri sendiri di kaki. Dengan vendor ia lebih sukar, kerana semuanya difikirkan dan dikonfigurasikan untuk syarikat. Kelemahan terbesar Kubernetes sumber terbuka ialah keperluan untuk pakar. Dengan pilihan vendor, syarikat dibebaskan daripada sakit kepala ini, tetapi ia perlu memutuskan sama ada untuk membayar pakarnya atau vendor.

Nah, kebaikannya jelas, keburukan juga diketahui. Satu perkara yang berterusan: Kubernetes menyelesaikan banyak masalah dengan mengautomasikan pengurusan banyak kontena. Dan yang mana satu untuk dipilih, sumber terbuka atau vendor - semua orang membuat keputusan mereka sendiri.

Artikel itu disediakan oleh Dmitry Krasnov, arkitek terkemuka perkhidmatan Containerum penyedia #CloudMTS

Sumber: www.habr.com