URUS mencoba Kubernetes dalam berbagai bentuk: penyebaran logam telanjang mandiri di Google Cloud, dan kemudian memindahkan platformnya ke Mail.ru Cloud Solutions (MCS). Bagaimana memilih penyedia cloud baru dan bagaimana mengelola untuk bermigrasi ke sana dalam catatan dua jam diceritakan oleh Igor Shishkin (
t3ran ), administrator sistem senior
URUS .
Apa yang dilakukan Urus
Ada banyak cara untuk meningkatkan kualitas lingkungan perkotaan, dan salah satunya adalah membuatnya ramah lingkungan. Inilah yang sedang dilakukan oleh perusahaan URUS - Smart Digital Services. Ini mengimplementasikan solusi yang membantu perusahaan memantau indikator lingkungan yang penting dan mengurangi dampak lingkungan yang negatif. Sensor mengumpulkan data tentang komposisi udara, tingkat kebisingan dan parameter lainnya, dan kemudian mengirimkannya ke platform tunggal "Urus - Ekomon" untuk analisis dan rekomendasi.
Bagaimana cara kerja "Urus" di dalam
Klien tipikal URUS adalah perusahaan yang berlokasi di atau dekat daerah perumahan. Ini bisa berupa pabrik, pelabuhan, stasiun kereta api atau fasilitas lainnya. Jika klien kami telah menerima peringatan, didenda karena pencemaran lingkungan, atau ingin mengurangi kebisingan, mengurangi jumlah emisi berbahaya, ia mendatangi kami, dan kami sudah menawarkan solusi siap pakai untuk pemantauan lingkungan.
Emisi malam hari reguler dari fasilitas terdekat terlihat pada grafik pemantauan konsentrasi H2S.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 tertentu.
Tergantung pada pengukuran spesifik, perangkat dengan sensor dapat ditemukan di dinding bangunan, kutub, dan tempat sewenang-wenang lainnya. Setiap perangkat tersebut mengumpulkan informasi, mengumpulkannya dan mengirimkannya ke gateway penerima data. Di sana kami menyimpan data untuk penyimpanan jangka panjang dan pra-proses untuk analisis selanjutnya. Contoh paling sederhana dari apa yang kita dapatkan setelah analisis adalah indeks kualitas udara, alias AQI.
Pada saat yang sama, banyak layanan lain bekerja pada platform kami, tetapi pada dasarnya layanan tersebut bersifat layanan. Misalnya, layanan pemberitahuan mengirimkan pemberitahuan kepada pelanggan jika ada parameter yang dipantau (misalnya, konten CO
2 ) telah melebihi nilai yang diijinkan.
Bagaimana cara kita menyimpan data. Kisah Kubernet tentang logam kosong
Proyek pemantauan lingkungan URUS memiliki beberapa gudang data. Dalam satu kami memegang data "mentah" - apa yang kami terima langsung dari perangkat itu sendiri. Penyimpanan ini adalah pita "magnetik", seperti pada kaset lama, dengan riwayat semua indikator. Tipe penyimpanan kedua digunakan untuk data pra-pemrosesan - data dari perangkat yang diperkaya dengan metadata tentang koneksi sensor dan pembacaan perangkat itu sendiri, afiliasi dengan organisasi, lokasi, dll. Informasi ini memungkinkan Anda untuk secara dinamis mengevaluasi bagaimana indikator tertentu berubah selama periode waktu tertentu . Kami menggunakan penyimpanan data mentah, termasuk sebagai cadangan dan untuk memulihkan data yang sudah diproses sebelumnya, jika diperlukan.
Ketika kami mencari cara untuk memecahkan masalah penyimpanan beberapa tahun yang lalu, kami memiliki dua opsi untuk memilih platform: Kubernetes dan OpenStack. Tetapi karena yang terakhir terlihat cukup mengerikan (lihat saja arsitekturnya untuk melihat ini), maka kami menetap di Kubernetes. Argumen lain yang menguntungkannya adalah kontrol perangkat lunak yang relatif sederhana, kemampuan untuk lebih fleksibel memotong simpul besi menjadi sumber daya.
Sejalan dengan pengembangan Kubernetes itu sendiri, kami juga mempelajari cara menyimpan data, sementara kami menyimpan semua penyimpanan kami di Kubernetes pada perangkat keras kami, kami menerima keahlian yang sangat baik. Semua yang kami tinggal di Kubernetes: penyimpanan statefull, sistem pemantauan, CI / CD. Kubernetes telah menjadi platform lengkap kami.
Tetapi kami ingin bekerja dengan Kubernetes sebagai layanan, dan tidak terlibat dalam dukungan dan pengembangannya. Selain itu, kami tidak menyukai berapa banyak kontennya pada bare metal, dan pengembangan selalu diperlukan untuk kami! Misalnya, salah satu tugas pertama adalah mengintegrasikan pengontrol Kubernetes Ingress ke dalam infrastruktur jaringan organisasi kami. Ini adalah tugas yang rumit, terutama jika Anda membayangkan bahwa pada saat itu tidak ada yang siap untuk manajemen sumber daya program seperti catatan DNS atau alokasi IP. Kemudian kami mulai bereksperimen dengan gudang data eksternal. Kami tidak sampai ke implementasi pengontrol PVC, tetapi bahkan kemudian menjadi jelas bahwa ini adalah bidang pekerjaan besar yang diperlukan untuk memilih masing-masing spesialis.
Bermigrasi ke Solusi Sementara Google Cloud Platform
Kami menyadari bahwa ini tidak dapat dilanjutkan lebih jauh, dan mentransfer data kami dari bare metal ke Google Cloud Platform. Faktanya, maka untuk perusahaan Rusia tidak ada banyak pilihan menarik: selain Google Cloud Platform, hanya Amazon yang menawarkan layanan serupa, tetapi kami masih memilih solusi dari Google. Kemudian bagi kami secara ekonomis lebih menguntungkan, lebih dekat dengan Upstream, belum lagi fakta bahwa Google sendiri adalah semacam PoC Kubernetes dalam Produksi.
Masalah serius pertama muncul di cakrawala seiring dengan pertumbuhan basis pelanggan kami. Ketika penting bagi kami untuk menyimpan data pribadi, kami menghadapi pilihan: apakah kami bekerja dengan Google dan melanggar hukum Rusia, atau kami sedang mencari alternatif di Federasi Rusia. Pilihannya, secara umum, dapat diprediksi. :)
Bagaimana kami melihat layanan cloud yang sempurna
Pada awal pencarian, kami sudah tahu apa yang ingin kami dapatkan dari penyedia cloud di masa depan. Layanan apa yang kami cari:
- Cepat dan fleksibel . Sehingga kita dapat dengan cepat menambahkan node baru atau menggunakan sesuatu kapan saja.
- Tidak mahal Kami sangat khawatir tentang masalah keuangan, karena sumber daya kami terbatas. Kami sudah tahu bahwa kami ingin bekerja dengan Kubernetes, dan sekarang tugasnya adalah meminimalkan biaya untuk meningkatkan atau setidaknya mempertahankan efektivitas penggunaan solusi ini.
- Otomatis . Kami berencana untuk bekerja dengan layanan melalui API, tanpa manajer dan panggilan telepon atau situasi di mana Anda perlu secara manual meningkatkan beberapa puluh node dalam mode darurat. Karena sebagian besar proses kami terotomatisasi, kami mengharapkan hal yang sama dari layanan cloud.
- Dengan server di Federasi Rusia . Tentu saja, kami berencana untuk mematuhi hukum Rusia dan 152-FZ yang sama.
Saat itu, penyedia Kubernet aaS sedikit di Rusia, sementara memilih penyedia, penting bagi kami untuk tidak mengkompromikan prioritas kami. Tim Cloud Solutions Mail.ru, yang dengannya kami telah mulai bekerja dan masih bekerja, telah memberikan kami layanan yang sepenuhnya otomatis dengan dukungan API dan panel kontrol yang nyaman dengan Horizon - dengan itu kami dapat dengan cepat meningkatkan jumlah node yang sewenang-wenang.
Bagaimana kami berhasil bermigrasi ke MCS dalam dua jam
Dalam relokasi semacam itu, banyak perusahaan dihadapkan pada kesulitan dan kegagalan, tetapi dalam kasus kami tidak demikian. Kami beruntung: karena kami sudah mengerjakan Kubernetes sebelum dimulainya migrasi, kami hanya memperbaiki tiga file dan meluncurkan layanan kami pada platform cloud baru, di MCS. Biarkan saya mengingatkan Anda bahwa pada saat itu kami akhirnya meninggalkan bare metal dan hidup di Google Cloud Platform. Karena perpindahan itu sendiri tidak lebih dari dua jam, ditambah sedikit waktu (sekitar satu jam) yang diperlukan untuk menyalin data dari perangkat kami. Kemudian kami sudah menggunakan Spinnaker (layanan multi-cloud CD untuk menyediakan Pengiriman Kontinu). Kami juga dengan cepat menambahkannya ke cluster baru dan terus bekerja seperti biasa.
Berkat otomatisasi proses pengembangan dan Kubernetes CI / CD di URUS ditempati oleh satu spesialis (dan ini saya). Pada tahap tertentu, administrator sistem lain bekerja dengan saya, tetapi kemudian ternyata kami telah mengotomatiskan seluruh rutinitas utama, dan dari sisi produk utama kami ada lebih banyak tugas dan masuk akal untuk mengarahkan sumber daya ke ini.
Kami menerima dari penyedia cloud apa yang kami harapkan, karena kami memulai kerja sama tanpa ilusi. Jika ada insiden, maka kebanyakan insiden teknis, yang dapat dengan mudah dijelaskan oleh kesegaran relatif dari layanan. Hal utama adalah bahwa tim MCS dengan cepat menghilangkan kekurangan dan dengan cepat menanggapi pertanyaan dalam pesan instan.
Jika kita membandingkan pengalaman dengan Google Cloud Platform, maka dalam kasus mereka saya bahkan tidak tahu di mana tombol umpan balik, karena itu sama sekali tidak perlu. Dan jika ada masalah yang terjadi, Google sendiri mengirimkan notifikasi secara sepihak. Tetapi dalam kasus MCS, nilai tambah yang besar, saya percaya bahwa mereka sedekat mungkin dengan pelanggan Rusia - baik secara geografis maupun mental.
Seperti yang kita lihat bekerja dengan awan di masa depan
Sekarang pekerjaan kami terkait erat dengan Kubernetes, dan itu sangat cocok untuk kami dalam hal tugas infrastruktur. Oleh karena itu, kami tidak berencana untuk bermigrasi dari suatu tempat, meskipun kami terus-menerus memperkenalkan praktik dan layanan baru untuk menyederhanakan tugas rutin dan mengotomatisasi yang baru, meningkatkan stabilitas dan keandalan layanan ... Sekarang kami meluncurkan layanan Chaos Monkey (khususnya, kami menggunakan chaoskube, tetapi ini tidak mengubah konsep: ), yang awalnya dibuat di Netflix. Chaos Monkey melakukan satu hal sederhana: pada waktu yang sewenang-wenang, ia menghapus arbitrary di bawah Kubernetes. Ini diperlukan agar layanan kami dapat hidup normal dengan jumlah instance n - 1, jadi kami membiasakan diri untuk bersiap-siap menghadapi kerusakan.
Sekarang saya melihat penggunaan solusi pihak ketiga - platform cloud yang sama - sebagai satu-satunya solusi yang tepat untuk perusahaan muda. Biasanya pada awal perjalanan mereka terbatas pada sumber daya, baik manusia dan keuangan, dan membangun dan memelihara cloud atau pusat data Anda sendiri terlalu mahal dan memakan waktu. Penyedia cloud dapat meminimalkan biaya ini, mereka dapat dengan cepat mendapatkan sumber daya yang diperlukan untuk layanan untuk bekerja di sini dan sekarang, dan membayar untuk sumber daya ini sebenarnya. Adapun perusahaan Urus, untuk saat ini kami akan tetap setia kepada Kubernetes di awan. Tapi siapa tahu, mungkin kita harus memperluas secara geografis, atau mengimplementasikan solusi berdasarkan beberapa peralatan tertentu. Atau mungkin jumlah sumber daya yang dikonsumsi akan membenarkan Kubernet-nya sendiri pada logam kosong, seperti di masa lalu yang indah. :)
Apa yang kami pelajari dari pengalaman kami dengan layanan cloud
Kami mulai menggunakan Kubernet pada bare metal, dan bahkan di sana pun bagus dengan caranya sendiri. Tetapi kekuatannya terungkap justru sebagai komponen aaS di cloud. Jika Anda menetapkan tujuan dan mengotomatiskan segala sesuatu sebanyak mungkin, Anda akan dapat menghindari vendor lock-in dan bergerak di antara penyedia cloud akan memakan waktu beberapa jam, dan sel-sel saraf akan tetap bersama kami. Kami dapat memberi saran kepada perusahaan lain: jika Anda ingin memulai layanan (cloud) Anda, memiliki sumber daya terbatas dan kecepatan maksimum untuk pengembangan, mulailah sekarang dengan menyewa sumber daya cloud, dan bangun pusat data Anda setelah Forbes menulis tentang Anda.