Di akhir bulan Mei mengadakan pertemuan online tentang topik tersebut . Kami berbicara tentang container, Kubernetes dan prinsip orkestrasi, kriteria pemilihan infrastruktur, dan banyak lagi. Peserta berbagi kasus dari praktik mereka sendiri.
Peserta:
- Evgeniy Potapov, CEO ITSumma. Lebih dari separuh pelanggannya sudah pindah atau ingin beralih ke Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Memiliki pengalaman lebih dari 10 tahun bekerja dengan sistem kontainer.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, mantan RAO UES. Dia berjanji untuk membicarakan kasus-kasus di perusahaan “berdarah”.
- Andrey Fedorovsky, CTO “News360.com”Setelah membeli perusahaan tersebut oleh pemain lain, dia bertanggung jawab atas sejumlah proyek dan infrastruktur ML dan AI.
- Ivan Kruglov, insinyur sistem, ex-Booking.com.Orang yang sama yang melakukan banyak hal dengan Kubernetes dengan tangannya sendiri.
Tema:
- Wawasan peserta tentang container dan orkestrasi (Docker, Kubernetes, dll.); apa yang dicoba dalam praktik atau dianalisis.
- Kasus: Perusahaan sedang membangun rencana pembangunan infrastruktur selama bertahun-tahun. Bagaimana keputusan dibuat apakah akan membangun (atau memigrasikan infrastruktur yang ada) ke container dan Kuber atau tidak?
- Masalah di dunia cloud-native, apa saja yang kurang, bayangkan saja apa yang akan terjadi besok.
Diskusi menarik pun terjadi, pendapat para peserta sangat berbeda-beda dan menimbulkan banyak komentar sehingga ingin saya bagikan kepada Anda. Makan , dan di bawah ini ringkasan pembahasannya.
Apakah Kubernetes sudah menjadi standar atau pemasaran yang hebat?
“Kami sampai pada hal ini (Kubernetes. - Red.) ketika belum ada yang mengetahuinya. Kami datang kepadanya bahkan ketika dia tidak ada di sana. Kami menginginkannya sebelumnya" - Dmitry Stolyarov
Foto dari Reddit.com
5-10 tahun yang lalu ada banyak sekali alat, dan tidak ada standar tunggal. Setiap enam bulan muncul produk baru, atau bahkan lebih dari satu. Pertama Vagrant, lalu Salt, Chef, Puppet,... “dan Anda membangun kembali infrastruktur Anda setiap enam bulan. Anda memiliki lima administrator yang selalu sibuk menulis ulang konfigurasi,” kenang Andrey Fedorovsky. Dia percaya bahwa Docker dan Kubernetes telah “menyingkirkan” sisanya. Docker telah menjadi standar dalam lima tahun terakhir, Kubernetes dalam dua tahun terakhir. Dan itu bagus untuk industri..
Dmitry Stolyarov dan timnya menyukai Kuber. Mereka menginginkan alat seperti itu sebelum alat itu muncul, dan mendapatkannya ketika tidak ada yang mengetahuinya. Saat ini, demi alasan kenyamanan, mereka tidak menerima klien jika mereka memahami bahwa mereka tidak akan mengimplementasikan Kubernetes bersamanya. Pada saat yang sama, menurut Dmitry, perusahaan tersebut memiliki “banyak kisah sukses besar dalam menciptakan kembali warisan buruk tersebut.”
Kubernetes bukan hanya orkestrasi container, tetapi juga sistem manajemen konfigurasi dengan API yang dikembangkan, komponen jaringan, penyeimbangan L3, dan pengontrol Ingress, yang membuatnya relatif mudah untuk mengelola sumber daya, menskalakan, dan mengabstraksi dari lapisan bawah infrastruktur.
Sayangnya, dalam hidup kita, kita harus membayar semuanya. Dan pajak ini besar, terutama jika kita berbicara tentang transisi ke Kubernetes dari sebuah perusahaan dengan infrastruktur yang maju, seperti yang diyakini Ivan Kruglov. Dia bisa bebas bekerja baik di perusahaan dengan infrastruktur tradisional maupun di Kuber. Yang utama adalah memahami karakteristik perusahaan dan pasar. Namun, misalnya, bagi Evgeny Potapov, yang akan menggeneralisasi Kubernetes ke alat orkestrasi container apa pun, pertanyaan seperti itu tidak muncul.
Evgeniy menganalogikannya dengan situasi di tahun 1990-an, ketika pemrograman berorientasi objek muncul sebagai cara memprogram aplikasi yang kompleks. Pada saat itu, perdebatan terus berlanjut dan muncullah alat-alat baru untuk mendukung OOP. Kemudian layanan mikro muncul sebagai cara untuk menjauh dari konsep monolitik. Hal ini, pada gilirannya, menyebabkan munculnya kontainer dan alat pengelolaan kontainer. “Saya pikir kita akan segera sampai pada suatu waktu ketika tidak akan ada pertanyaan apakah layak untuk menulis aplikasi layanan mikro kecil, itu akan ditulis sebagai layanan mikro secara default,” yakinnya. Demikian pula, Docker dan Kubernetes pada akhirnya akan menjadi solusi standar tanpa memerlukan pilihan.
Masalah database di stateless
Foto oleh
Saat ini, ada banyak resep untuk menjalankan database di Kubernetes. Bahkan cara memisahkan bagian yang berfungsi dengan disk I/O dari, secara kondisional, bagian aplikasi database. Mungkinkah di masa depan database akan berubah begitu banyak sehingga dikirimkan dalam sebuah kotak, di mana satu bagian akan diatur melalui Docker dan Kubernetes, dan di bagian lain infrastruktur, melalui perangkat lunak terpisah, bagian penyimpanan akan disediakan ? Akankah basisnya berubah sebagai sebuah produk?
Deskripsi ini mirip dengan manajemen antrian, namun persyaratan untuk keandalan dan sinkronisasi informasi dalam database tradisional jauh lebih tinggi, Andrey yakin. Rasio cache hit di database normal tetap di 99%. Jika seorang pekerja mati, yang baru diluncurkan, dan cache “menghangat” dari awal. Sampai cache dihangatkan, pekerja bekerja lambat, yang berarti tidak dapat dimuat dengan beban pengguna. Meskipun tidak ada beban pengguna, cache tidak memanas. Ini adalah lingkaran setan.
Dmitry pada dasarnya tidak setuju - kuorum dan sharding menyelesaikan masalah. Namun Andrey menegaskan bahwa solusi tersebut tidak cocok untuk semua orang. Dalam beberapa situasi, kuorum cocok, namun memberikan beban tambahan pada jaringan. Database NoSQL tidak cocok di semua kasus.
Peserta pertemuan dibagi menjadi dua kubu.
Denis dan Andrey berpendapat bahwa segala sesuatu yang ditulis ke disk - database dan sebagainya - tidak mungkin dilakukan di ekosistem Kuber saat ini. Tidak mungkin menjaga integritas dan konsistensi data produksi di Kubernetes. Ini adalah fitur mendasar. Solusi: infrastruktur hybrid.
Bahkan database cloud native modern seperti MongoDB dan Cassandra, atau antrian pesan seperti Kafka atau RabbitMQ, memerlukan penyimpanan data persisten di luar Kubernetes.
Evgeniy keberatan: “Pangkalan di Kubera hampir mengalami cedera Rusia, atau hampir seperti perusahaan, yang disebabkan oleh fakta bahwa tidak ada Adopsi Cloud di Rusia.” Perusahaan kecil atau menengah di Barat adalah Cloud. Basis data Amazon RDS lebih mudah digunakan daripada mengutak-atik Kubernetes sendiri. Di Rusia mereka menggunakan Kuber “on-premise” dan memindahkan basis ke sana ketika mereka mencoba untuk menyingkirkan kebun binatang.
Dmitry juga tidak setuju dengan pernyataan bahwa tidak ada database yang dapat disimpan di Kubernetes: “Base berbeda dengan base. Dan jika Anda mendorong database relasional raksasa, maka dalam keadaan apa pun. Jika Anda mendorong sesuatu yang kecil dan asli cloud, yang secara mental siap untuk kehidupan semi-sementara, semuanya akan baik-baik saja.” Dmitry juga menyebutkan bahwa alat manajemen database belum siap untuk Docker atau Kuber, sehingga timbul kesulitan besar.
Ivan, sebaliknya, yakin bahwa meskipun kita mengabstraksi konsep stateful dan stateless, ekosistem solusi perusahaan di Kubernetes belum siap. Dengan Kuber, sulit untuk memenuhi persyaratan legislatif dan peraturan. Misalnya, tidak mungkin membuat solusi penyediaan identitas yang memerlukan jaminan identifikasi server yang ketat, hingga perangkat keras yang dimasukkan ke dalam server. Kawasan ini sedang berkembang, namun belum ada solusinya.
Para peserta tidak dapat menyetujuinya, sehingga tidak ada kesimpulan yang dapat diambil pada bagian ini. Mari kita berikan beberapa contoh praktis.
Kasus 1. Keamanan siber dari “mega-regulator” yang berbasis di luar Kubera
Dalam kasus sistem keamanan siber yang dikembangkan, penggunaan container dan orkestrasi memungkinkan untuk melawan serangan dan intrusi. Misalnya, di salah satu mega-regulator, Denis dan timnya menerapkan kombinasi orkestrator dengan layanan SIEM terlatih yang menganalisis log secara real-time dan menentukan proses serangan, peretasan, atau kegagalan. Jika terjadi serangan, upaya untuk menempatkan sesuatu, atau jika terjadi invasi virus ransomware, melalui orkestrator, ia mengambil kontainer dengan aplikasi lebih cepat daripada saat mereka terinfeksi, atau lebih cepat daripada penyerang yang menyerangnya.
Kasus 2. Migrasi sebagian database Booking.com ke Kubernetes
Di Booking.com, database utamanya adalah MySQL dengan replikasi asinkron - ada master dan seluruh hierarki budak. Pada saat Ivan keluar dari perusahaan, sebuah proyek diluncurkan untuk memindahkan budak yang dapat “ditembak” dengan kerusakan tertentu.
Selain basis utama, terdapat instalasi Cassandra dengan orkestrasi yang ditulis sendiri, yang ditulis bahkan sebelum Kuber memasuki mainstream. Tidak ada masalah dalam hal ini, tetapi masalah ini tetap ada pada SSD lokal. Penyimpanan jarak jauh, bahkan dalam pusat data yang sama, tidak digunakan karena masalah latensi yang tinggi.
Kelas database ketiga adalah layanan pencarian Booking.com, di mana setiap node layanan adalah database. Upaya untuk mentransfer layanan pencarian ke Kuber gagal, karena setiap node memiliki penyimpanan lokal sebesar 60-80 GB, yang sulit untuk "diangkat" dan "dihangatkan".
Akibatnya, mesin pencari tidak ditransfer ke Kubernetes, dan Ivan tidak berpikir akan ada upaya baru dalam waktu dekat. Basis data MySQL ditransfer menjadi dua: hanya Budak, yang tidak takut “ditembak”. Cassandra telah beradaptasi dengan sempurna.
Pemilihan infrastruktur sebagai tugas tanpa solusi umum
Foto oleh
Katakanlah kita memiliki perusahaan baru, atau perusahaan yang sebagian infrastrukturnya dibangun dengan cara lama. Ini membangun rencana pembangunan infrastruktur selama bertahun-tahun. Bagaimana pengambilan keputusan apakah akan membangun infrastruktur di atas container dan Kuber atau tidak?
Perusahaan yang memperjuangkan nanodetik tidak termasuk dalam diskusi. Konservatisme yang sehat membuahkan hasil dalam hal keandalan, namun masih ada perusahaan yang harus mempertimbangkan pendekatan baru.
Ivan: “Saya pasti akan memulai perusahaan di cloud sekarang, karena lebih cepat,” meski belum tentu lebih murah. Dengan berkembangnya kapitalisme ventura, startup tidak memiliki masalah besar dengan uang, dan tugas utamanya adalah menaklukkan pasar.
Ivan berpendapat demikian pembangunan infrastruktur yang ada saat ini menjadi kriteria seleksi. Jika ada investasi serius di masa lalu dan berhasil, maka tidak ada gunanya mengulanginya. Jika infrastruktur tidak dikembangkan, dan ada masalah dengan alat, keamanan, dan pemantauan, maka masuk akal untuk mempertimbangkan infrastruktur terdistribusi.
Bagaimanapun, pajak harus dibayar, dan Ivan akan membayar pajak yang memungkinkannya membayar lebih sedikit di masa depan. "Karena hanya karena saya naik kereta yang ditumpangi orang lain, saya akan melakukan perjalanan lebih jauh dibandingkan jika saya duduk di kereta lain, yang mana saya harus mengisi bahan bakar sendiri.“kata Ivan. Ketika perusahaan masih baru, dan persyaratan latensi adalah puluhan milidetik, maka Ivan akan melihat ke arah “operator” yang “dibungkus” database klasik saat ini. Mereka meningkatkan rantai replikasi, yang beralih sendiri jika terjadi kegagalan, dll...
Untuk perusahaan kecil dengan beberapa server, Kubera tidak masuk akal,” kata Andrey. Namun jika berencana untuk mengembangkan hingga ratusan server atau lebih, maka diperlukan otomatisasi dan sistem manajemen sumber daya. 90% kasus sepadan dengan biayanya. Apalagi terlepas dari tingkat beban dan sumber daya. Masuk akal bagi semua orang, mulai dari perusahaan rintisan hingga perusahaan besar dengan jutaan audiens, untuk secara bertahap beralih ke produk orkestrasi container. “Ya, ini memang masa depan,” Andrey yakin.
Denis menguraikan dua kriteria utama - skalabilitas dan stabilitas operasi. Dia akan memilih alat yang paling sesuai untuk tugas tersebut. “Bisa jadi ini adalah sebuah produk Noname yang dibuat dengan berlutut, dan terdapat Nutanix Community Edition di dalamnya. Ini bisa berupa baris kedua dalam bentuk aplikasi di Kuber dengan database di backend, yang direplikasi dan telah menentukan parameter RTO dan RPO" (tujuan waktu/titik pemulihan - sekitar).
Evgeniy mengidentifikasi kemungkinan masalah dengan personel. Saat ini, tidak banyak spesialis berkualifikasi tinggi di pasar yang memahami “nyali”. Memang jika teknologi yang dipilih sudah tua, maka sulit untuk mempekerjakan orang lain selain orang paruh baya yang bosan dan lelah dengan hidup. Meski peserta lain berpendapat bahwa ini soal pelatihan personel.
Jika kita mengajukan pertanyaan pilihan: meluncurkan perusahaan kecil di Public Cloud dengan database di Amazon RDS atau “on premise” dengan database di Kubernetes, maka meskipun ada beberapa kekurangan, Amazon RDS menjadi pilihan para peserta.
Karena mayoritas pendengar pertemuan tersebut bukan berasal dari perusahaan yang “berdarah”, maka solusi terdistribusi adalah hal yang harus kita perjuangkan. Sistem penyimpanan data harus terdistribusi, andal, dan menciptakan latensi yang diukur dalam satuan milidetik, paling banyak puluhan“, Andrey menyimpulkan.
Menilai Penggunaan Kubernetes
Pendengar Anton Zhbankov mengajukan pertanyaan jebakan kepada para pembela Kubernetes: bagaimana Anda memilih dan melakukan studi kelayakan? Mengapa Kubernetes, mengapa bukan mesin virtual, misalnya?
Foto oleh
Dmitry dan Ivan menjawabnya. Dalam kedua kasus tersebut, melalui trial and error, serangkaian keputusan dibuat, sebagai hasilnya kedua peserta tiba di Kubernetes. Kini bisnis mulai mengembangkan perangkat lunak secara mandiri yang masuk akal untuk ditransfer ke Kuber. Kami tidak berbicara tentang sistem pihak ketiga klasik, seperti 1C. Kubernetes membantu ketika pengembang perlu membuat rilis dengan cepat, dengan Perbaikan Berkelanjutan tanpa henti.
Tim Andrey mencoba membuat cluster yang dapat diskalakan berdasarkan mesin virtual. Node-node berjatuhan seperti kartu domino, yang terkadang menyebabkan runtuhnya cluster. “Secara teoritis, Anda bisa menyelesaikannya dan menopangnya dengan tangan Anda, tapi itu membosankan. Dan jika ada solusi di pasar yang memungkinkan Anda bekerja secara out of the box, maka kami akan dengan senang hati melakukannya. Dan sebagai hasilnya, kami beralih,” kata Andrey.
Ada standar untuk analisis dan penghitungan seperti itu, tetapi tidak ada yang bisa mengatakan seberapa akurat standar tersebut pada pengoperasian perangkat keras sebenarnya. Untuk perhitungan, penting juga untuk memahami setiap alat dan ekosistem, tetapi hal ini tidak mungkin dilakukan.
Apa yang menanti kita
Foto oleh
Seiring berkembangnya teknologi, semakin banyak bagian yang berbeda muncul, dan kemudian terjadi transisi fase, muncullah vendor yang telah menghabiskan cukup banyak adonan untuk menyatukan semuanya dalam satu alat.
Apakah menurut Anda akan tiba saatnya akan ada alat seperti Ubuntu untuk dunia Linux? Mungkin satu alat containerisasi dan orkestrasi akan menyertakan Kuber. Ini akan memudahkan pembuatan cloud di lokasi.
Jawabannya diberikan oleh Ivan: “Google kini sedang membangun Anthos - ini adalah paket penawaran mereka yang menerapkan cloud dan mencakup Kuber, Service Mesh, pemantauan - semua perangkat keras yang diperlukan untuk layanan mikro di lokasi.” Kita hampir berada di masa depan."
Denis juga menyebut Nutanix dan VMWare dengan produk vRealize Suite, yang dapat mengatasi tugas serupa tanpa containerisasi.
Dmitry menyampaikan pendapatnya bahwa mengurangi “rasa sakit” dan mengurangi pajak adalah dua bidang yang dapat kita harapkan perbaikannya.
Untuk meringkas diskusi, kami menyoroti masalah infrastruktur modern berikut ini:
- Tiga peserta segera mengidentifikasi masalah dengan stateful.
- Berbagai masalah dukungan keamanan, termasuk kemungkinan Docker akan berakhir dengan beberapa versi Python, server aplikasi, dan komponen.
Pengeluaran berlebihan, yang sebaiknya dibicarakan dalam pertemuan tersendiri.
Tantangan pembelajaran sebagai orkestrasi adalah ekosistem yang kompleks.
Masalah umum dalam industri ini adalah penyalahgunaan alat.Kesimpulan selanjutnya terserah Anda. Masih ada perasaan bahwa tidak mudah bagi kombinasi Docker+Kubernetes untuk menjadi bagian “pusat” dari sistem. Misalnya, sistem operasi diinstal pada perangkat keras terlebih dahulu, tidak demikian halnya dengan container dan orkestrasi. Mungkin di masa depan, sistem operasi dan container akan digabungkan dengan perangkat lunak manajemen cloud.
Foto olehSaya ingin menggunakan kesempatan ini untuk menyapa ibu saya dan mengingatkan Anda bahwa kami memiliki grup Facebook , saluran dengan publikasi menarik dari berbagai blog teknologi. Dan saluran saya , di mana saya berbicara tentang mengelola pengembangan di perusahaan produk.
Sumber: www.habr.com