Syarikat URUS mencuba Kubernetes dalam bentuk yang berbeza: penggunaan bebas pada logam kosong, dalam Google Cloud, dan kemudian memindahkan platformnya ke awan Mail.ru Cloud Solutions (MCS). Igor Shishkin memberitahu bagaimana mereka memilih penyedia awan baharu dan cara mereka berjaya berhijrah kepadanya dalam rekod dua jam (), pentadbir sistem kanan di URUS.
Apa yang URUS lakukan?
Terdapat banyak cara untuk meningkatkan kualiti persekitaran bandar, dan salah satunya adalah dengan menjadikannya mesra alam. Inilah sebenarnya yang sedang diusahakan oleh syarikat URUS - Smart Digital Services. Di sini mereka melaksanakan penyelesaian yang membantu perusahaan memantau penunjuk alam sekitar yang penting dan mengurangkan kesan negatifnya terhadap alam sekitar. Penderia mengumpul data tentang komposisi udara, tahap hingar dan parameter lain, dan kemudian menghantarnya ke platform URUS-Ekomon bersatu untuk analisis dan membuat cadangan.
Cara URUS berfungsi dari dalam
Pelanggan biasa URUS ialah syarikat yang terletak di dalam atau berhampiran kawasan kediaman. Ini boleh menjadi kilang, pelabuhan, depoh kereta api atau sebarang kemudahan lain. Jika pelanggan kami telah menerima amaran, didenda kerana pencemaran alam sekitar, atau ingin mengurangkan bunyi bising, mengurangkan jumlah pelepasan berbahaya, dia datang kepada kami, dan kami sudah menawarkan penyelesaian siap sedia untuk pemantauan alam sekitar.
Graf pemantauan kepekatan H2S menunjukkan pelepasan waktu malam biasa dari loji berdekatan
Peranti yang kami gunakan di URUS mengandungi beberapa penderia yang mengumpul maklumat tentang kandungan gas tertentu, tahap hingar dan data lain untuk menilai keadaan persekitaran. Bilangan tepat penderia sentiasa ditentukan oleh tugas tertentu.
Bergantung pada spesifikasi ukuran, peranti dengan sensor boleh terletak di dinding bangunan, tiang dan tempat lain yang sewenang-wenangnya. Setiap peranti tersebut mengumpul maklumat, mengagregatkannya dan menghantarnya ke get laluan penerima data. Di sana kami menyimpan data untuk penyimpanan jangka panjang dan pra-memprosesnya untuk analisis seterusnya. Contoh paling mudah daripada apa yang kami dapat hasil analisis ialah indeks kualiti udara, juga dikenali sebagai AQI.
Secara selari, banyak perkhidmatan lain beroperasi pada platform kami, tetapi perkhidmatan tersebut kebanyakannya bersifat perkhidmatan. Contohnya, perkhidmatan pemberitahuan menghantar pemberitahuan kepada pelanggan jika mana-mana parameter yang dipantau (contohnya, kandungan CO2) melebihi nilai yang dibenarkan.
Cara kami menyimpan data. Kisah Kubernetes pada bare metal
Projek pemantauan alam sekitar URUS mempunyai beberapa gudang data. Dalam satu kami menyimpan data "mentah" - apa yang kami terima terus daripada peranti itu sendiri. Storan ini ialah pita "magnet", seperti pada pita kaset lama, dengan sejarah semua penunjuk. Jenis storan kedua digunakan untuk data praproses - data daripada peranti, diperkaya dengan metadata tentang sambungan antara penderia dan bacaan peranti itu sendiri, hubungan dengan organisasi, lokasi, dll. Maklumat ini membolehkan anda menilai secara dinamik bagaimana penunjuk tertentu mempunyai berubah dalam tempoh masa tertentu. Kami menggunakan storan data "mentah", antara lain, sebagai sandaran dan untuk memulihkan data praproses, jika keperluan sedemikian timbul.
Apabila kami ingin menyelesaikan masalah storan kami beberapa tahun yang lalu, kami mempunyai dua pilihan platform: Kubernetes dan OpenStack. Tetapi memandangkan yang terakhir kelihatan agak mengerikan (lihat sahaja seni binanya untuk diyakinkan), kami menetap di Kubernetes. Satu lagi hujah yang memihak kepadanya ialah kawalan perisian yang agak mudah, keupayaan untuk memotong nod perkakasan secara lebih fleksibel mengikut sumber.
Selari dengan menguasai Kubernetes sendiri, kami juga mengkaji cara untuk menyimpan data, sementara kami menyimpan semua storan kami dalam Kubernetes pada perkakasan kami sendiri, kami menerima kepakaran yang sangat baik. Segala-galanya yang kami tinggalkan pada Kubernetes: storan penuh negeri, sistem pemantauan, CI/CD. Kubernetes telah menjadi platform semua-dalam-satu untuk kami.
Tetapi kami mahu bekerjasama dengan Kubernetes sebagai perkhidmatan, dan tidak terlibat dalam sokongan dan pembangunannya. Selain itu, kami tidak menyukai berapa banyak kos kami untuk mengekalkannya pada logam kosong, dan kami memerlukan pembangunan secara berterusan! Sebagai contoh, salah satu tugas pertama adalah untuk menyepadukan pengawal Kubernetes Ingress ke dalam infrastruktur rangkaian organisasi kami. Ini adalah tugas yang menyusahkan, terutamanya memandangkan pada masa itu tiada apa-apa yang sedia untuk pengurusan sumber program seperti rekod DNS atau peruntukan alamat IP. Kemudian kami mula bereksperimen dengan storan data luaran. Kami tidak pernah dapat melaksanakan pengawal PVC, tetapi kemudiannya menjadi jelas bahawa ini adalah bidang kerja yang besar yang memerlukan pakar yang berdedikasi.
Beralih kepada Google Cloud Platform ialah penyelesaian sementara
Kami menyedari bahawa ini tidak dapat diteruskan dan memindahkan data kami daripada logam kosong ke Google Cloud Platform. Malah, pada masa itu tidak ada banyak pilihan menarik untuk syarikat Rusia: selain Google Cloud Platform, hanya Amazon yang menawarkan perkhidmatan serupa, tetapi kami masih menyelesaikan penyelesaian daripada Google. Kemudian nampaknya kami lebih menguntungkan dari segi ekonomi, lebih dekat dengan Hulu, apatah lagi fakta bahawa Google sendiri adalah sejenis PoC Kubernetes dalam Pengeluaran.
Masalah utama pertama muncul di kaki langit apabila pangkalan pelanggan kami berkembang. Apabila kami mempunyai keperluan untuk menyimpan data peribadi, kami berhadapan dengan pilihan: sama ada kami bekerja dengan Google dan melanggar undang-undang Rusia, atau kami sedang mencari alternatif di Persekutuan Rusia. Pilihan itu, secara keseluruhannya, boleh diramalkan. π
Bagaimana kami melihat perkhidmatan awan yang ideal
Pada permulaan carian, kami sudah tahu apa yang kami mahu dapatkan daripada pembekal awan masa hadapan. Perkhidmatan apa yang kami cari:
- Cepat dan fleksibel. Supaya kita boleh menambah nod baharu dengan pantas atau menggunakan sesuatu pada bila-bila masa.
- murah. Kami sangat mengambil berat tentang isu kewangan, kerana kami terhad dalam sumber. Kami sudah tahu bahawa kami ingin bekerjasama dengan Kubernetes, dan kini tugasnya adalah untuk meminimumkan kosnya untuk meningkatkan atau sekurang-kurangnya mengekalkan kecekapan menggunakan penyelesaian ini.
- Automatik. Kami merancang untuk bekerja dengan perkhidmatan melalui API, tanpa pengurus dan panggilan telefon atau situasi di mana kami perlu menaikkan beberapa dozen nod secara manual dalam mod kecemasan. Memandangkan kebanyakan proses kami adalah automatik, kami menjangkakan perkara yang sama daripada perkhidmatan awan.
- Dengan pelayan di Persekutuan Rusia. Sudah tentu, kami merancang untuk mematuhi undang-undang Rusia dan 152-FZ yang sama.
Pada masa itu, terdapat beberapa penyedia Kubernetes aaS di Rusia, dan apabila memilih penyedia, adalah penting bagi kami untuk tidak menjejaskan keutamaan kami. Pasukan Penyelesaian Awan Mail.ru, yang kami mula bekerja dan masih bekerjasama, memberikan kami perkhidmatan automatik sepenuhnya, dengan sokongan API dan panel kawalan mudah yang termasuk Horizon - dengan itu kami boleh menaikkan bilangan nod yang sewenang-wenangnya dengan cepat.
Bagaimana kami berjaya berhijrah ke MCS dalam masa dua jam
Dalam langkah sedemikian, banyak syarikat menghadapi kesukaran dan kemunduran, tetapi dalam kes kami tiada satu pun. Kami bernasib baik: memandangkan kami sudah mengusahakan Kubernetes sebelum migrasi bermula, kami hanya membetulkan tiga fail dan melancarkan perkhidmatan kami pada platform awan baharu, MCS. Biar saya ingatkan anda bahawa pada masa itu kami akhirnya meninggalkan logam kosong dan tinggal di Platform Awan Google. Oleh itu, langkah itu sendiri mengambil masa tidak lebih daripada dua jam, ditambah sedikit masa lagi (kira-kira sejam) telah dibelanjakan untuk menyalin data daripada peranti kami. Pada masa itu kami telah pun menggunakan Spinnaker (perkhidmatan CD berbilang awan untuk menyediakan Penghantaran Berterusan). Kami juga dengan cepat menambahkannya pada kluster baharu dan terus berfungsi seperti biasa.
Terima kasih kepada automasi proses pembangunan dan CI/CD, Kubernetes di URUS dikendalikan oleh seorang pakar (dan itulah saya). Pada peringkat tertentu, pentadbir sistem lain bekerja dengan saya, tetapi ternyata kami telah mengautomasikan semua rutin utama dan terdapat lebih banyak tugas di bahagian produk utama kami dan masuk akal untuk mengarahkan sumber ke ini.
Kami menerima apa yang kami harapkan daripada pembekal awan, sejak kami memulakan kerjasama tanpa ilusi. Sekiranya terdapat sebarang insiden, kebanyakannya adalah teknikal dan yang boleh dijelaskan dengan mudah oleh kesegaran relatif perkhidmatan. Perkara utama ialah pasukan MCS dengan cepat menghapuskan kekurangan dan dengan cepat menjawab soalan dalam messenger.
Jika saya membandingkan pengalaman saya dengan Google Cloud Platform, dalam kes mereka, saya tidak tahu di mana butang maklum balas itu berada, kerana ia tidak diperlukan. Dan jika sebarang masalah berlaku, Google sendiri menghantar pemberitahuan secara unilateral. Tetapi dalam kes MCS, saya fikir kelebihan besar ialah mereka sedekat mungkin dengan pelanggan Rusia - dari segi geografi dan mental.
Bagaimana kita melihat bekerja dengan awan pada masa hadapan
Kini kerja kami berkait rapat dengan Kubernetes, dan ia sangat sesuai dengan kami dari sudut pandangan tugas infrastruktur. Oleh itu, kami tidak merancang untuk berhijrah daripadanya ke mana-mana, walaupun kami sentiasa memperkenalkan amalan dan perkhidmatan baharu untuk memudahkan tugas rutin dan mengautomasikan tugas baharu, meningkatkan kestabilan dan kebolehpercayaan perkhidmatan... Kami kini melancarkan perkhidmatan Chaos Monkey (khususnya , kami menggunakan chaoskube, tetapi ini tidak mengubah konsep: ), yang pada asalnya dicipta oleh Netflix. Chaos Monkey melakukan satu perkara mudah: ia memadam pod Kubernetes rawak pada masa rawak. Ini adalah perlu untuk perkhidmatan kami hidup normal dengan bilangan kejadian nβ1, jadi kami melatih diri kami untuk bersedia menghadapi sebarang masalah.
Sekarang saya melihat penggunaan penyelesaian pihak ketiga - platform awan yang sama - sebagai satu-satunya perkara yang sesuai untuk syarikat muda. Biasanya, pada permulaan perjalanan mereka, mereka terhad dalam sumber, manusia dan kewangan, dan membina dan menyelenggara awan atau pusat data mereka sendiri terlalu mahal dan memerlukan tenaga kerja. Pembekal awan membolehkan anda meminimumkan kos ini; anda boleh mendapatkan daripada mereka sumber yang diperlukan untuk pengendalian perkhidmatan di sini dan sekarang dengan cepat, dan membayar sumber ini selepas fakta tersebut. Bagi syarikat URUS, kami akan tetap setia kepada Kubernetes di awan buat masa ini. Tetapi siapa tahu, kita mungkin perlu mengembangkan secara geografi, atau melaksanakan penyelesaian berdasarkan beberapa peralatan tertentu. Atau mungkin jumlah sumber yang digunakan akan membenarkan Kubernetes sendiri pada logam kosong, seperti pada zaman dahulu. π
Perkara yang kami pelajari daripada bekerja dengan perkhidmatan awan
Kami mula menggunakan Kubernetes pada logam kosong, dan walaupun di sana ia bagus dengan caranya sendiri. Tetapi kekuatannya didedahkan dengan tepat sebagai komponen aaS dalam awan. Jika anda menetapkan matlamat dan mengautomasikan segala-galanya sebanyak mungkin, anda akan dapat mengelakkan sekatan vendor dan bergerak antara penyedia awan akan mengambil masa beberapa jam dan sel saraf akan kekal bersama kami. Kami boleh menasihati syarikat lain: jika anda ingin melancarkan perkhidmatan (awan) anda sendiri, mempunyai sumber terhad dan halaju maksimum untuk pembangunan, mulakan sekarang dengan menyewa sumber awan dan bina pusat data anda selepas Forbes menulis tentang anda.
Sumber: www.habr.com