Pada akhir bulan Mei mengadakan mesyuarat dalam talian mengenai topik tersebut . Kami bercakap tentang kontena, Kubernetes dan orkestra pada dasarnya, kriteria untuk memilih infrastruktur dan banyak lagi. Peserta berkongsi kes dari amalan mereka sendiri.
Para peserta:
- Evgeniy Potapov, Ketua Pegawai Eksekutif ITSumma. Lebih separuh daripada pelanggannya sama ada sudah berpindah atau mahu beralih kepada Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Mempunyai 10+ tahun pengalaman bekerja dengan sistem kontena.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, bekas RAO UES. Dia berjanji untuk bercakap tentang kes dalam perusahaan "berdarah".
- Andrey Fedorovsky, CTO “News360.com”Selepas membeli syarikat oleh pemain lain, dia bertanggungjawab untuk beberapa projek dan infrastruktur ML dan AI.
- Ivan Kruglov, jurutera sistem, bekas Booking.com.Orang yang sama yang melakukan banyak perkara dengan Kubernetes dengan tangannya sendiri.
Tema:
- Pandangan peserta tentang bekas dan orkestrasi (Docker, Kubernetes, dsb.); apa yang dicuba dalam amalan atau dianalisis.
- Kes: Syarikat sedang membina rancangan pembangunan infrastruktur selama bertahun-tahun. Bagaimanakah keputusan dibuat sama ada untuk membina (atau memindahkan infrastruktur semasa) ke kontena dan Kuber atau tidak?
- Masalah dalam dunia asli awan, apa yang hilang, mari kita bayangkan apa yang akan berlaku esok.
Perbincangan menarik berlaku, pendapat peserta sangat berbeza dan menyebabkan banyak komen yang saya ingin kongsikan dengan anda. makan , dan di bawah ialah ringkasan perbincangan.
Adakah Kubernetes sudah menjadi pemasaran standard atau hebat?
“Kami datang kepadanya (Kubernetes. - Ed.) apabila tiada siapa yang tahu mengenainya lagi. Kami datang kepadanya walaupun dia tiada. Kami mahukannya sebelum ini" - Dmitry Stolyarov
Foto daripada Reddit.com
5-10 tahun yang lalu terdapat sejumlah besar alat, dan tidak ada standard tunggal. Setiap enam bulan produk baharu muncul, atau lebih daripada satu. Pertama Vagrant, kemudian Salt, Chef, Puppet,... “dan anda membina semula infrastruktur anda setiap enam bulan. Anda mempunyai lima pentadbir yang sentiasa sibuk menulis semula konfigurasi,” ingat Andrey Fedorovsky. Dia percaya bahawa Docker dan Kubernetes telah "bersesak-sesak" yang lain. Docker telah menjadi standard dalam tempoh lima tahun yang lalu, Kubernetes dalam dua tahun yang lalu. Dan itu bagus untuk industri..
Dmitry Stolyarov dan pasukannya suka Kuber. Mereka mahukan alat sedemikian sebelum ia muncul, dan datang kepadanya apabila tiada siapa yang mengetahui tentangnya. Pada masa ini, atas sebab kemudahan, mereka tidak mengambil pelanggan jika mereka faham bahawa mereka tidak akan melaksanakan Kubernetes dengannya. Pada masa yang sama, menurut Dmitry, syarikat itu mempunyai "banyak kisah kejayaan besar tentang membuat semula warisan yang mengerikan."
Kubernetes bukan sahaja orkestrasi kontena, ia adalah sistem pengurusan konfigurasi dengan API yang dibangunkan, komponen rangkaian, pengimbangan L3 dan pengawal Ingress, yang menjadikannya agak mudah untuk mengurus sumber, skala dan abstrak daripada lapisan bawah infrastruktur.
Malangnya, dalam hidup kita, kita perlu membayar segala-galanya. Dan cukai ini besar, terutamanya jika kita bercakap tentang peralihan kepada Kubernetes sebuah syarikat dengan infrastruktur yang maju, seperti yang dipercayai oleh Ivan Kruglov. Dia boleh bekerja dengan bebas dalam kedua-dua syarikat dengan infrastruktur tradisional dan dengan Kuber. Perkara utama ialah memahami ciri-ciri syarikat dan pasaran. Tetapi, sebagai contoh, untuk Evgeny Potapov, yang akan menggeneralisasikan Kubernetes kepada mana-mana alat orkestrasi kontena, persoalan seperti itu tidak timbul.
Evgeniy membuat analogi dengan situasi pada tahun 1990-an, apabila pengaturcaraan berorientasikan objek muncul sebagai cara pengaturcaraan aplikasi kompleks. Pada masa itu, perbahasan diteruskan dan alat baharu muncul untuk menyokong OOP. Kemudian perkhidmatan mikro muncul sebagai cara untuk beralih daripada konsep monolitik. Ini, seterusnya, membawa kepada kemunculan bekas dan alat pengurusan kontena. "Saya fikir kita akan tiba pada masa yang tidak lama lagi apabila tidak ada persoalan sama ada ia bernilai menulis aplikasi perkhidmatan mikro kecil, ia akan ditulis sebagai perkhidmatan mikro secara lalai," dia percaya. Begitu juga, Docker dan Kubernetes akhirnya akan menjadi penyelesaian standard tanpa memerlukan pilihan.
Masalah pangkalan data dalam stateless
Gambar oleh
Pada masa kini, terdapat banyak resipi untuk menjalankan pangkalan data dalam Kubernetes. Malah bagaimana untuk memisahkan bahagian yang berfungsi dengan cakera I/O daripada, secara bersyarat, bahagian aplikasi pangkalan data. Adakah mungkin pada masa hadapan pangkalan data akan berubah begitu banyak sehingga ia akan dihantar dalam kotak, di mana satu bahagian akan diatur melalui Docker dan Kubernetes, dan di bahagian lain infrastruktur, melalui perisian berasingan, bahagian storan akan disediakan ? Adakah asas akan berubah sebagai produk?
Penerangan ini serupa dengan pengurusan baris gilir, tetapi keperluan untuk kebolehpercayaan dan penyegerakan maklumat dalam pangkalan data tradisional adalah lebih tinggi, Andrey percaya. Nisbah hit cache dalam pangkalan data biasa kekal pada 99%. Jika pekerja jatuh, pekerja baharu dilancarkan, dan cache "memanaskan" dari awal. Sehingga cache dipanaskan, pekerja berfungsi dengan perlahan, yang bermaksud ia tidak boleh dimuatkan dengan beban pengguna. Walaupun tiada beban pengguna, cache tidak menjadi panas. Ia adalah lingkaran ganas.
Dmitry pada asasnya tidak bersetuju - kuorum dan sharding menyelesaikan masalah. Tetapi Andrey menegaskan bahawa penyelesaian itu tidak sesuai untuk semua orang. Dalam sesetengah situasi, kuorum adalah sesuai, tetapi ia memberi beban tambahan pada rangkaian. Pangkalan data NoSQL tidak sesuai dalam semua kes.
Para peserta pertemuan dibahagikan kepada dua kem.
Denis dan Andrey berhujah bahawa semua yang ditulis ke cakera - pangkalan data dan sebagainya - adalah mustahil untuk dilakukan dalam ekosistem Kuber semasa. Adalah mustahil untuk mengekalkan integriti dan konsistensi data pengeluaran dalam Kubernetes. Ini adalah ciri asas. Penyelesaian: infrastruktur hibrid.
Malah pangkalan data asli awan moden seperti MongoDB dan Cassandra, atau baris gilir mesej seperti Kafka atau RabbitMQ, memerlukan storan data yang berterusan di luar Kubernetes.
Evgeniy membantah: "Pangkalan di Kubera adalah kecederaan hampir Rusia, atau hampir perusahaan, yang dikaitkan dengan fakta bahawa tiada Penggunaan Awan di Rusia." Syarikat kecil atau sederhana di Barat adalah Cloud. Pangkalan data Amazon RDS lebih mudah digunakan daripada mengutak-atik Kubernetes sendiri. Di Rusia mereka menggunakan Kuber "on-premise" dan memindahkan pangkalan kepadanya apabila mereka cuba menyingkirkan zoo.
Dmitry juga tidak bersetuju dengan kenyataan bahawa tiada pangkalan data boleh disimpan dalam Kubernetes: “Base berbeza daripada pangkalan. Dan jika anda menolak pangkalan data hubungan gergasi, maka dalam apa jua keadaan. Jika anda menolak sesuatu yang kecil dan asli awan, yang disediakan secara mental untuk kehidupan separa fana, semuanya akan baik-baik saja.” Dmitry juga menyebut bahawa alat pengurusan pangkalan data tidak bersedia untuk Docker atau Kuber, jadi masalah besar timbul.
Ivan, sebaliknya, yakin bahawa walaupun kita abstrak daripada konsep stateful dan stateless, ekosistem penyelesaian perusahaan di Kubernetes masih belum bersedia. Dengan Kuber, sukar untuk mengekalkan keperluan perundangan dan peraturan. Sebagai contoh, adalah mustahil untuk membuat penyelesaian peruntukan identiti di mana jaminan pengenalan pelayan yang ketat diperlukan, sehingga ke perkakasan yang dimasukkan ke dalam pelayan. Kawasan ini sedang membangun, tetapi belum ada penyelesaian.
Para peserta tidak dapat bersetuju, jadi tiada kesimpulan akan dibuat dalam bahagian ini. Mari kita berikan beberapa contoh praktikal.
Kes 1. Keselamatan siber "pengawal selia mega" dengan pangkalan di luar Kubera
Dalam kes sistem keselamatan siber yang dibangunkan, penggunaan bekas dan orkestrasi memungkinkan untuk melawan serangan dan pencerobohan. Contohnya, dalam satu pengatur mega, Denis dan pasukannya melaksanakan gabungan orkestra dengan perkhidmatan SIEM terlatih yang menganalisis log dalam masa nyata dan menentukan proses serangan, penggodaman atau kegagalan. Sekiranya berlaku serangan, percubaan untuk meletakkan sesuatu, atau sekiranya berlaku pencerobohan virus ransomware, ia, melalui orkestra, mengambil bekas dengan aplikasi lebih cepat daripada dijangkiti, atau lebih cepat daripada penyerang menyerangnya.
Kes 2. Penghijrahan sebahagian pangkalan data Booking.com ke Kubernetes
Di Booking.com, pangkalan data utama ialah MySQL dengan replikasi tak segerak - terdapat tuan dan hierarki keseluruhan hamba. Pada masa Ivan meninggalkan syarikat itu, satu projek telah dilancarkan untuk memindahkan hamba yang boleh "ditembak" dengan kerosakan tertentu.
Sebagai tambahan kepada pangkalan utama, terdapat pemasangan Cassandra dengan orkestrasi bertulis sendiri, yang ditulis sebelum Kuber memasuki arus perdana. Tiada masalah dalam hal ini, tetapi ia berterusan pada SSD tempatan. Storan jauh, walaupun dalam pusat data yang sama, tidak digunakan kerana masalah kependaman yang tinggi.
Kelas ketiga pangkalan data ialah perkhidmatan carian Booking.com, di mana setiap nod perkhidmatan adalah pangkalan data. Percubaan untuk memindahkan perkhidmatan carian ke Kuber gagal, kerana setiap nod adalah 60-80 GB storan tempatan, yang sukar untuk "mengangkat" dan "memanaskan badan".
Akibatnya, enjin carian tidak dipindahkan ke Kubernetes, dan Ivan tidak fikir akan ada percubaan baru dalam masa terdekat. Pangkalan data MySQL telah dipindahkan separuh: hanya Hamba, yang tidak takut untuk "ditembak". Cassandra telah menetap dengan sempurna.
Pemilihan infrastruktur sebagai tugas tanpa penyelesaian umum
Gambar oleh
Katakan kita mempunyai syarikat baharu, atau syarikat di mana sebahagian daripada infrastruktur dibina mengikut cara lama. Ia membina pelan pembangunan infrastruktur selama bertahun-tahun. Bagaimanakah keputusan dibuat sama ada untuk membina infrastruktur pada kontena dan Kuber atau tidak?
Syarikat yang berjuang untuk nanosaat dikecualikan daripada perbincangan. Konservatisme yang sihat membuahkan hasil dari segi kebolehpercayaan, tetapi masih terdapat syarikat yang harus mempertimbangkan pendekatan baharu.
Ivan: "Saya pasti akan memulakan syarikat di awan sekarang, semata-mata kerana ia lebih pantas," walaupun tidak semestinya lebih murah. Dengan perkembangan kapitalisme teroka, syarikat pemula tidak mempunyai masalah besar dengan wang, dan tugas utama adalah untuk menakluki pasaran.
Ivan berpendapat bahawa pembangunan infrastruktur semasa adalah kriteria pemilihan. Sekiranya terdapat pelaburan yang serius pada masa lalu, dan ia berkesan, maka tidak ada gunanya untuk melakukannya semula. Jika infrastruktur tidak dibangunkan, dan terdapat masalah dengan alat, keselamatan dan pemantauan, maka masuk akal untuk melihat infrastruktur yang diedarkan.
Cukai itu perlu dibayar dalam apa jua keadaan, dan Ivan akan membayar cukai yang membolehkannya membayar kurang pada masa hadapan. "Kerana hanya berdasarkan fakta bahawa saya menaiki kereta api yang dinaiki oleh orang lain, saya akan melakukan perjalanan lebih jauh daripada jika saya duduk di atas kereta api lain, yang mana saya perlu mengisi minyak sendiri."kata Ivan. Apabila syarikat itu baharu, dan keperluan kependaman ialah berpuluh-puluh milisaat, maka Ivan akan melihat ke arah "pengendali" di mana pangkalan data klasik "dibungkus" hari ini. Mereka menimbulkan rantai replikasi, yang menukar dirinya sendiri sekiranya berlaku kegagalan, dsb...
Untuk syarikat kecil dengan beberapa pelayan, Kubera tidak masuk akal,” kata Andrey. Tetapi jika ia merancang untuk berkembang kepada ratusan pelayan atau lebih, maka ia memerlukan automasi dan sistem pengurusan sumber. 90% kes berbaloi dengan kosnya. Lebih-lebih lagi, tanpa mengira tahap beban dan sumber. Ia masuk akal untuk semua orang, daripada syarikat permulaan kepada syarikat besar dengan penonton berjuta-juta, untuk secara beransur-ansur melihat ke arah produk orkestrasi kontena. "Ya, ini benar-benar masa depan," Andrey pasti.
Denis menggariskan dua kriteria utama - skalabiliti dan kestabilan operasi. Dia akan memilih alat yang paling sesuai untuk tugas itu. “Ia mungkin bukan nama yang dipasang pada lutut anda, dan ia mempunyai Edisi Komuniti Nutanix padanya. Ini boleh menjadi baris kedua dalam bentuk aplikasi pada Kuber dengan pangkalan data pada bahagian belakang, yang direplikasi dan telah menentukan parameter RTO dan RPO" (objektif masa/titik pemulihan - lebih kurang).
Evgeniy mengenal pasti kemungkinan masalah dengan kakitangan. Pada masa ini, tidak ramai pakar yang berkelayakan tinggi di pasaran yang memahami "keberanian". Sememangnya, jika teknologi yang dipilih itu sudah lama, maka sukar untuk mengupah orang lain selain orang pertengahan umur yang bosan dan bosan dengan kehidupan. Walaupun peserta lain percaya bahawa ini adalah soal latihan personel.
Jika kita meletakkan persoalan pilihan: untuk melancarkan sebuah syarikat kecil di Public Cloud dengan pangkalan data dalam Amazon RDS atau "di premis" dengan pangkalan data dalam Kubernetes, maka walaupun terdapat beberapa kekurangan, Amazon RDS menjadi pilihan peserta.
Oleh kerana majoriti pendengar pertemuan bukan dari perusahaan "berdarah", maka penyelesaian yang diedarkan adalah perkara yang harus kita perjuangkan. Sistem storan data mesti diedarkan, boleh dipercayai dan mencipta kependaman yang diukur dalam unit milisaat, paling banyak berpuluh-puluh", Andrey merumuskan.
Menilai Penggunaan Kubernetes
Pendengar Anton Zhbankov bertanya soalan perangkap kepada pengampu Kubernetes: bagaimana anda memilih dan menjalankan kajian kebolehlaksanaan? Mengapa Kubernetes, mengapa tidak mesin maya, sebagai contoh?
Gambar oleh
Dmitry dan Ivan menjawabnya. Dalam kedua-dua kes, melalui percubaan dan kesilapan, urutan keputusan telah dibuat, akibatnya kedua-dua peserta tiba di Kubernetes. Kini perniagaan mula membangunkan perisian secara bebas yang masuk akal untuk dipindahkan ke Kuber. Kami tidak bercakap tentang sistem pihak ketiga klasik, seperti 1C. Kubernetes membantu apabila pembangun perlu membuat keluaran dengan cepat, dengan Penambahbaikan Berterusan tanpa henti.
Pasukan Andrey cuba mencipta kluster berskala berdasarkan mesin maya. Nod jatuh seperti domino, yang kadangkala membawa kepada keruntuhan kelompok. "Secara teorinya, anda boleh menyelesaikannya dan menyokongnya dengan tangan anda, tetapi ia membosankan. Dan jika terdapat penyelesaian di pasaran yang membolehkan anda bekerja di luar kotak, maka kami gembira untuk melakukannya. Dan kami bertukar sebagai hasilnya, "kata Andrey.
Terdapat piawaian untuk analisis dan pengiraan sedemikian, tetapi tiada siapa yang boleh mengatakan betapa tepatnya ia pada perkakasan sebenar yang beroperasi. Untuk pengiraan, ia juga penting untuk memahami setiap alat dan ekosistem, tetapi ini tidak mungkin.
Apa yang menanti kita
Gambar oleh
Apabila teknologi berkembang, semakin banyak kepingan yang berbeza muncul, dan kemudian peralihan fasa berlaku, seorang vendor muncul yang telah membunuh doh yang cukup untuk semuanya disatukan dalam satu alat.
Adakah anda fikir akan tiba masanya apabila akan ada alat seperti Ubuntu untuk dunia Linux? Mungkin satu alat kontena dan orkestrasi akan termasuk Kuber. Ia akan memudahkan untuk membina awan di premis.
Jawapan diberikan oleh Ivan: "Google kini sedang membina Anthos - ini adalah tawaran pakej mereka yang menggunakan awan dan termasuk Kuber, Service Mesh, pemantauan - semua perkakasan yang diperlukan untuk perkhidmatan mikro di premis." Kita hampir pada masa hadapan."
Denis juga menyebut Nutanix dan VMWare dengan produk Suite vRealize, yang boleh menangani tugas yang sama tanpa kontena.
Dmitry berkongsi pendapatnya bahawa mengurangkan "kesakitan" dan mengurangkan cukai adalah dua bidang di mana kita boleh mengharapkan penambahbaikan.
Untuk meringkaskan perbincangan, kami menyerlahkan masalah infrastruktur moden berikut:
- Tiga peserta segera mengenal pasti masalah dengan stateful.
- Pelbagai isu sokongan keselamatan, termasuk kemungkinan bahawa Docker akan berakhir dengan berbilang versi Python, pelayan aplikasi dan komponen.
Perbelanjaan yang berlebihan, yang lebih baik untuk dibincangkan dalam mesyuarat berasingan.
Cabaran pembelajaran sebagai orkestrasi adalah ekosistem yang kompleks.
Masalah biasa dalam industri ialah penyalahgunaan alatan.Selebihnya kesimpulan terpulang kepada anda. Masih terdapat perasaan bahawa tidak mudah untuk gabungan Docker+Kubernetes untuk menjadi bahagian "pusat" sistem. Sebagai contoh, sistem pengendalian dipasang pada perkakasan terlebih dahulu, yang tidak boleh dikatakan tentang bekas dan orkestrasi. Mungkin pada masa hadapan, sistem pengendalian dan bekas akan bergabung dengan perisian pengurusan awan.
Gambar olehSaya ingin mengambil kesempatan ini untuk bertanya khabar kepada ibu saya dan mengingatkan anda bahawa kami mempunyai kumpulan Facebook , saluran dengan penerbitan menarik daripada pelbagai blog teknologi. Dan saluran saya , di mana saya bercakap tentang mengurus pembangunan dalam syarikat produk.
Sumber: www.habr.com