Perusahaan URUS mencoba Kubernetes dalam berbagai bentuk: penerapan independen pada bare metal, di Google Cloud, dan kemudian mentransfer platformnya ke cloud Mail.ru Cloud Solutions (MCS). Igor Shishkin menceritakan bagaimana mereka memilih penyedia cloud baru dan bagaimana mereka berhasil bermigrasi ke penyedia tersebut dalam waktu dua jam (), administrator sistem senior di URUS.
Apa yang URUS lakukan?
Ada banyak cara untuk meningkatkan kualitas lingkungan perkotaan, salah satunya adalah dengan menjadikannya ramah lingkungan. Inilah yang sedang dikerjakan oleh URUS - perusahaan Smart Digital Services. Di sini mereka menerapkan solusi yang membantu perusahaan memantau indikator lingkungan yang penting dan mengurangi dampak negatifnya terhadap lingkungan. Sensor mengumpulkan data tentang komposisi udara, tingkat kebisingan, dan parameter lainnya, lalu mengirimkannya ke platform terpadu URUS-Ekomon untuk dianalisis dan dibuat rekomendasi.
Bagaimana URUS bekerja dari dalam
Klien tipikal URUS adalah perusahaan yang berlokasi di atau dekat kawasan perumahan. Ini bisa berupa pabrik, pelabuhan, depo kereta api atau fasilitas lainnya. Jika klien kami telah menerima peringatan, didenda karena pencemaran lingkungan, atau ingin mengurangi kebisingan, mengurangi jumlah emisi berbahaya, dia mendatangi kami, dan kami telah menawarkan kepadanya solusi siap pakai untuk pemantauan lingkungan.
Grafik pemantauan konsentrasi H2S menunjukkan emisi rutin malam hari dari pembangkit listrik terdekat
Perangkat yang kami gunakan di URUS berisi beberapa sensor yang mengumpulkan informasi tentang kandungan gas tertentu, tingkat kebisingan, dan data lainnya untuk menilai situasi lingkungan. Jumlah pasti sensor selalu ditentukan oleh tugas spesifiknya.
Tergantung pada spesifikasi pengukurannya, perangkat dengan sensor dapat ditempatkan di dinding bangunan, tiang, dan tempat sembarang lainnya. Setiap perangkat tersebut mengumpulkan informasi, mengumpulkannya dan mengirimkannya ke gateway penerima data. Di sana kami menyimpan data untuk penyimpanan jangka panjang dan memprosesnya terlebih dahulu untuk analisis selanjutnya. Contoh paling sederhana yang kami peroleh dari hasil analisis adalah indeks kualitas udara yang disebut juga AQI.
Secara paralel, banyak layanan lain yang beroperasi di platform kami, tetapi sebagian besar layanan tersebut bersifat layanan. Misalnya, layanan notifikasi mengirimkan notifikasi ke klien jika salah satu parameter yang dipantau (misalnya, konten CO2) melebihi nilai yang diizinkan.
Bagaimana kami menyimpan data. Kisah Kubernetes pada bare metal
Proyek pemantauan lingkungan URUS memiliki beberapa gudang data. Di satu perangkat, kami menyimpan data "mentah" - data yang kami terima langsung dari perangkat itu sendiri. Penyimpanan ini adalah pita βmagnetikβ, seperti kaset lama, dengan riwayat semua indikator. Jenis penyimpanan kedua digunakan untuk data yang telah diproses sebelumnya - data dari perangkat, diperkaya dengan metadata tentang hubungan antara sensor dan pembacaan perangkat itu sendiri, afiliasi dengan organisasi, lokasi, dll. Informasi ini memungkinkan Anda menilai secara dinamis bagaimana indikator tertentu memiliki berubah dalam jangka waktu tertentu. Kami menggunakan penyimpanan data βmentahβ, antara lain, sebagai cadangan dan memulihkan data yang telah diproses sebelumnya, jika diperlukan.
Ketika kami ingin menyelesaikan masalah penyimpanan kami beberapa tahun yang lalu, kami memiliki dua pilihan platform: Kubernetes dan OpenStack. Namun karena Kubernetes terlihat cukup mengerikan (lihat saja arsitekturnya untuk yakin akan hal ini), kami memilih Kubernetes. Argumen lain yang mendukungnya adalah kontrol perangkat lunak yang relatif sederhana, kemampuan untuk memotong node perangkat keras secara lebih fleksibel sesuai dengan sumber daya.
Sejalan dengan penguasaan Kubernetes itu sendiri, kami juga mempelajari cara menyimpan data, sementara kami menyimpan semua penyimpanan kami di Kubernetes pada perangkat keras kami sendiri, kami menerima keahlian yang sangat baik. Semua yang kami miliki saat itu ada di Kubernetes: penyimpanan penuh status, sistem pemantauan, CI/CD. Kubernetes telah menjadi platform lengkap bagi kami.
Namun kami ingin bekerja dengan Kubernetes sebagai sebuah layanan, dan tidak terlibat dalam dukungan dan pengembangannya. Selain itu, kami tidak menyukai besarnya biaya yang kami keluarkan untuk mempertahankannya dalam bentuk bare metal, dan kami membutuhkan pengembangan terus-menerus! Misalnya, salah satu tugas pertama adalah mengintegrasikan pengontrol Kubernetes Ingress ke dalam infrastruktur jaringan organisasi kami. Ini adalah tugas yang rumit, terutama mengingat pada saat itu belum ada yang siap untuk pengelolaan sumber daya terprogram seperti data DNS atau alokasi alamat IP. Kemudian kami mulai bereksperimen dengan penyimpanan data eksternal. Kami tidak pernah sempat menerapkan pengontrol PVC, namun demikian menjadi jelas bahwa ini adalah bidang pekerjaan besar yang memerlukan spesialis berdedikasi.
Beralih ke Google Cloud Platform adalah solusi sementara
Kami menyadari bahwa hal ini tidak dapat dilanjutkan, dan memindahkan data kami dari bare metal ke Google Cloud Platform. Faktanya, saat itu tidak banyak pilihan menarik untuk perusahaan Rusia: selain Google Cloud Platform, hanya Amazon yang menawarkan layanan serupa, namun kami tetap memilih solusi dari Google. Kemudian bagi kami tampaknya lebih menguntungkan secara ekonomi, lebih dekat ke Upstream, belum lagi fakta bahwa Google sendiri adalah sejenis PoC Kubernetes dalam Produksi.
Masalah besar pertama muncul seiring pertumbuhan basis pelanggan kami. Saat kami perlu menyimpan data pribadi, kami dihadapkan pada pilihan: kami bekerja sama dengan Google dan melanggar undang-undang Rusia, atau kami mencari alternatif di Federasi Rusia. Pilihannya, secara keseluruhan, dapat diprediksi. π
Bagaimana kami melihat layanan cloud yang ideal
Pada awal pencarian, kami sudah mengetahui apa yang ingin kami dapatkan dari penyedia cloud masa depan. Layanan apa yang kami cari:
- Cepat dan fleksibel. Sehingga kita dapat dengan cepat menambahkan node baru atau menerapkan sesuatu kapan saja.
- Murah. Kami sangat prihatin dengan masalah keuangan, karena sumber daya kami terbatas. Kami sudah mengetahui bahwa kami ingin bekerja dengan Kubernetes, dan sekarang tugasnya adalah meminimalkan biayanya guna meningkatkan atau setidaknya mempertahankan efisiensi penggunaan solusi ini.
- otomatis. Kami berencana untuk bekerja dengan layanan ini melalui API, tanpa manajer dan panggilan telepon atau situasi di mana kami perlu meningkatkan beberapa lusin node secara manual dalam mode darurat. Karena sebagian besar proses kami dilakukan secara otomatis, kami mengharapkan hal yang sama dari layanan cloud.
- Dengan server di Federasi Rusia. Tentu saja, kami berencana untuk mematuhi undang-undang Rusia dan 152-FZ yang sama.
Pada saat itu, hanya ada sedikit penyedia aaS Kubernetes di Rusia, dan ketika memilih penyedia, penting bagi kami untuk tidak mengkompromikan prioritas kami. Tim Solusi Cloud Mail.ru, yang dengannya kami mulai bekerja dan masih berkolaborasi, memberi kami layanan yang sepenuhnya otomatis, dengan dukungan API dan panel kontrol nyaman yang mencakup Horizon - dengan itu kami dapat dengan cepat meningkatkan jumlah node yang berubah-ubah.
Bagaimana kami berhasil bermigrasi ke MCS dalam dua jam
Dalam pergerakan seperti ini, banyak perusahaan menghadapi kesulitan dan kemunduran, namun dalam kasus kami, tidak ada satupun yang mengalami kesulitan dan kemunduran. Kami beruntung: karena kami sudah mengerjakan Kubernetes sebelum migrasi dimulai, kami cukup memperbaiki tiga file dan meluncurkan layanan kami di platform cloud baru, MCS. Izinkan saya mengingatkan Anda bahwa pada saat itu kami akhirnya meninggalkan teknologi bare metal dan hidup di Google Cloud Platform. Oleh karena itu, perpindahan itu sendiri memakan waktu tidak lebih dari dua jam, ditambah sedikit lebih banyak waktu (sekitar satu jam) yang dihabiskan untuk menyalin data dari perangkat kami. Saat itu kami sudah menggunakan Spinnaker (layanan CD multi-cloud untuk menyediakan Pengiriman Berkelanjutan). Kami juga segera menambahkannya ke cluster baru dan terus bekerja seperti biasa.
Berkat otomatisasi proses pengembangan dan CI/CD, Kubernetes di URUS ditangani oleh satu spesialis (dan itu adalah saya). Pada tahap tertentu, administrator sistem lain bekerja dengan saya, tetapi kemudian ternyata kami telah mengotomatiskan seluruh rutinitas utama dan ada lebih banyak tugas dari produk utama kami dan masuk akal untuk mengarahkan sumber daya ke sana.
Kami menerima apa yang kami harapkan dari penyedia cloud, karena kami memulai kerja sama tanpa ilusi. Jika ada insiden, sebagian besar bersifat teknis dan dapat dengan mudah dijelaskan oleh relatif barunya layanan tersebut. Yang penting tim MCS cepat menghilangkan kekurangan dan cepat merespon pertanyaan di messenger.
Jika saya membandingkan pengalaman saya dengan Google Cloud Platform, dalam kasus ini saya bahkan tidak tahu di mana letak tombol masukannya, karena memang hal itu tidak diperlukan. Dan jika memang terjadi masalah, Google sendiri yang mengirimkan notifikasi secara sepihak. Namun dalam kasus MCS, menurut saya keuntungan besarnya adalah mereka sedekat mungkin dengan klien Rusia β baik secara geografis maupun mental.
Bagaimana kami melihat bekerja dengan cloud di masa depan
Sekarang pekerjaan kami terkait erat dengan Kubernetes, dan ini sangat cocok untuk kami dalam hal tugas infrastruktur. Oleh karena itu, kami tidak berencana untuk bermigrasi dari mana pun, meskipun kami terus memperkenalkan praktik dan layanan baru untuk menyederhanakan tugas rutin dan mengotomatiskan tugas baru, meningkatkan stabilitas dan keandalan layanan... Kami sekarang meluncurkan layanan Chaos Monkey (khususnya , kami menggunakan chaoskube, tapi ini tidak mengubah konsep :), yang awalnya dibuat oleh Netflix. Chaos Monkey melakukan satu hal sederhana: ia menghapus pod Kubernetes secara acak pada waktu yang acak. Hal ini diperlukan agar pelayanan kita dapat berjalan normal dengan jumlah instance nβ1, sehingga kita melatih diri kita untuk siap menghadapi masalah apapun.
Sekarang saya melihat penggunaan solusi pihak ketiga β platform cloud yang sama β sebagai satu-satunya hal yang tepat untuk perusahaan muda. Biasanya, pada awal perjalanannya, sumber daya mereka terbatas, baik sumber daya manusia maupun finansial, dan membangun serta memelihara cloud atau pusat data mereka sendiri terlalu mahal dan memakan banyak tenaga. Penyedia cloud memungkinkan Anda meminimalkan biaya-biaya ini; Anda dapat dengan cepat memperoleh dari mereka sumber daya yang diperlukan untuk pengoperasian layanan di sini dan saat ini, dan membayar sumber daya tersebut setelah kejadian tersebut. Sedangkan untuk perusahaan URUS, kami akan tetap setia pada Kubernetes di cloud untuk saat ini. Tapi siapa tahu, kita mungkin harus memperluas secara geografis, atau menerapkan solusi berdasarkan beberapa peralatan tertentu. Atau mungkin jumlah sumber daya yang dikonsumsi akan membenarkan Kubernetes yang berbasis bare-metal, seperti di masa lalu. π
Apa yang kami pelajari dari bekerja dengan layanan cloud
Kami mulai menggunakan Kubernetes pada bare metal, dan bahkan di sana pun Kubernetes tetap bagus dengan caranya sendiri. Namun kelebihannya terungkap justru sebagai komponen aaS di cloud. Jika Anda menetapkan tujuan dan mengotomatiskan segalanya sebanyak mungkin, Anda akan dapat menghindari vendor lock-in dan perpindahan antar penyedia cloud akan memakan waktu beberapa jam, dan sel-sel saraf akan tetap ada pada kami. Kami dapat memberi saran kepada perusahaan lain: jika Anda ingin meluncurkan layanan (cloud) Anda sendiri, dengan sumber daya terbatas dan kecepatan pengembangan maksimum, mulailah sekarang juga dengan menyewa sumber daya cloud, dan bangun pusat data Anda setelah Forbes menulis tentang Anda.
Sumber: www.habr.com