Hei Habr!
Kami mewakili tim platform Exness. Sebelumnya rekan-rekan kami sudah menulis artikel tentang . Hari ini kami ingin berbagi pengalaman migrasi layanan ke Kubernetes.
Untuk memulainya, kami menawarkan kepada Anda beberapa angka untuk pemahaman yang lebih baik tentang apa yang akan dibahas:
- Departemen pengembangan kami terdiri dari 100+ orang, termasuk lebih dari 10 tim berbeda dengan proses QA, DevOps, dan Scrum mandiri. Tumpukan pengembangan - Python, PHP, C++, Java dan Golang.
- Ukuran lingkungan pengujian dan produksi masing-masing sekitar 2000 kontainer. Mereka menjalankan Rancher v1.6 pada virtualisasi mereka sendiri dan di bawah VMware.
Motivasi
Seperti yang mereka katakan, tidak ada yang bertahan selamanya, dan Rancher mengumumkan penghentian dukungan untuk versi 1.6 beberapa waktu yang lalu. Ya, selama lebih dari tiga tahun kita telah belajar bagaimana mempersiapkannya dan menyelesaikan masalah yang muncul, namun semakin sering kita dihadapkan pada masalah yang tidak akan pernah bisa diperbaiki. Rancher 1.6 juga memiliki sistem keras untuk mengeluarkan hak, di mana Anda dapat melakukan hampir semua hal atau tidak melakukan apa pun.
Meskipun virtualisasi berpemilik memberikan kontrol yang lebih besar atas penyimpanan data dan keamanannya, hal ini menimbulkan biaya operasional yang sulit diterima mengingat pertumbuhan perusahaan yang konstan, jumlah proyek, dan persyaratannya.
Kami ingin mengikuti standar IaC dan, jika perlu, memperoleh kapasitas dengan cepat, di lokasi geografis mana pun dan tanpa kunci vendor, dan juga dapat dengan cepat meninggalkannya.
Langkah Pertama
Pertama-tama, kami ingin mengandalkan teknologi dan solusi modern yang memungkinkan tim memiliki siklus pengembangan yang lebih cepat dan meminimalkan biaya operasional untuk berinteraksi dengan platform yang menyediakan daya.
Tentu saja, hal pertama yang terlintas di benak kami adalah Kubernetes, namun kami tidak terlalu bersemangat dan melakukan sedikit riset untuk melihat apakah itu pilihan yang tepat. Kami hanya mengevaluasi solusi sumber terbuka, dan dalam pertarungan yang tidak adil, Kubernetes menang tanpa syarat.
Berikutnya adalah pertanyaan tentang memilih alat untuk membuat cluster. Kami membandingkan solusi paling populer: kops, kubespray, kubeadm.
Pada awalnya, kubeadm bagi kami tampaknya merupakan jalur yang terlalu rumit, seperti semacam penemu “sepeda”, dan kops tidak memiliki fleksibilitas yang cukup.
Dan pemenangnya adalah:
Kami mulai bereksperimen dengan virtualisasi dan AWS kami sendiri, mencoba menciptakan kembali sesuatu yang kira-kira mirip dengan pola pengelolaan sumber daya kami sebelumnya, di mana setiap orang berbagi “cluster” yang sama. Dan sekarang kami memiliki cluster pertama yang terdiri dari 10 mesin virtual kecil, beberapa di antaranya berlokasi di AWS. Kami mulai mencoba memigrasikan tim ke sana, semuanya tampak “baik”, dan ceritanya bisa saja selesai, tapi...
Masalah Pertama
Ansible adalah dasar dari kubespray, ini bukan alat yang memungkinkan Anda untuk mengikuti IaC: ketika menjalankan/menonaktifkan node, selalu ada yang tidak beres dan diperlukan semacam intervensi, dan ketika menggunakan OS yang berbeda, pedoman berperilaku berbeda. . Seiring bertambahnya jumlah tim dan node dalam klaster, kami mulai menyadari bahwa penyelesaian pedoman semakin lama semakin lama, dan sebagai hasilnya, rekor kami adalah 3,5 jam, bagaimana dengan rekor Anda? 🙂
Dan sepertinya kubespray hanya mungkin dilakukan, dan semuanya terlihat jelas pada pandangan pertama, namun:
Pada awal perjalanan, tugasnya adalah meluncurkan kapasitas hanya di AWS dan virtualisasi, namun kemudian, seperti yang sering terjadi, persyaratannya berubah.
Mengingat hal ini, menjadi jelas bahwa pola lama kami yang menggabungkan sumber daya ke dalam satu sistem orkestrasi tidak cocok - dalam kasus di mana cluster sangat jauh dan dikelola oleh penyedia yang berbeda.
Lebih-lebih lagi. Ketika semua tim bekerja dalam cluster yang sama, berbagai layanan dengan NodeSelectors yang tidak diinstal dengan benar dapat terbang ke host "asing" dari tim lain dan memanfaatkan sumber daya di sana, dan jika noda disetel, selalu ada permintaan bahwa satu atau beberapa layanan tidak berfungsi, tidak terdistribusi dengan benar karena faktor manusia. Masalah lainnya adalah menghitung biaya, terutama mengingat masalah dalam mendistribusikan layanan antar node.
Cerita terpisah adalah pemberian hak kepada karyawan: setiap tim ingin menjadi “pemimpin” cluster dan mengelolanya sepenuhnya, yang dapat menyebabkan keruntuhan total, karena tim pada dasarnya independen satu sama lain.
Apa yang harus dilakukan?
Mempertimbangkan hal di atas dan keinginan tim untuk lebih mandiri, kami membuat kesimpulan sederhana: satu tim - satu cluster.
Jadi kami mendapat yang kedua:
Dan kemudian cluster ketiga:
Lalu kami mulai berpikir: katakanlah dalam setahun tim kami akan memiliki lebih dari satu cluster? Misalnya, di wilayah geografis yang berbeda, atau di bawah kendali penyedia yang berbeda? Dan beberapa dari mereka ingin dapat dengan cepat menyebarkan cluster sementara untuk beberapa pengujian.
Kubernetes penuh akan hadir! Ternyata ini semacam MultiKubernetes.
Pada saat yang sama, kita semua perlu memelihara semua klaster ini, dapat dengan mudah mengelola akses ke klaster tersebut, serta membuat klaster baru dan menonaktifkan klaster lama tanpa intervensi manual.
Beberapa waktu telah berlalu sejak awal perjalanan kami di dunia Kubernetes, dan kami memutuskan untuk mengkaji ulang solusi yang tersedia. Ternyata sudah ada di pasaran - Rancher 2.2.
Pada tahap pertama penelitian kami, Rancher Labs telah membuat rilis pertama versi 2, namun meskipun dapat ditingkatkan dengan sangat cepat dengan meluncurkan container tanpa ketergantungan eksternal dengan beberapa parameter atau menggunakan HELM Chart resmi, hal tersebut terkesan kasar. kepada kami, dan kami tidak tahu apakah kami dapat mengandalkan keputusan ini apakah keputusan ini akan dikembangkan atau segera ditinggalkan. Paradigma cluster = klik di UI sendiri juga tidak cocok untuk kami, dan kami tidak ingin terikat dengan RKE, karena ini adalah alat yang fokusnya sempit.
Versi Rancher 2.2 sudah memiliki tampilan yang lebih bisa diterapkan dan, bersama dengan versi sebelumnya, memiliki banyak fitur menarik, seperti integrasi dengan banyak penyedia eksternal, satu titik distribusi hak dan file kubeconfig, meluncurkan kubectl gambar dengan hak Anda di UI, ruang nama bersarang alias proyek.
Ada juga komunitas yang sudah terbentuk di sekitar Rancher 2, dan penyedia bernama HashiCorp Terraform diciptakan untuk mengelolanya, yang membantu kami menyatukan semuanya.
Apa yang terjadi
Hasilnya, kami mendapatkan satu cluster kecil yang menjalankan Rancher, dapat diakses oleh semua cluster lainnya, serta banyak cluster yang terhubung dengannya, akses ke cluster mana pun dapat diberikan hanya dengan menambahkan pengguna ke direktori ldap, apa pun yang terjadi. di mana lokasinya dan sumber daya penyedia mana yang digunakannya.
Menggunakan gitlab-ci dan Terraform, sebuah sistem dibuat yang memungkinkan Anda membuat cluster konfigurasi apa pun di penyedia cloud atau infrastruktur kami sendiri dan menghubungkannya ke Rancher. Semua ini dilakukan dalam gaya IaC, di mana setiap cluster dijelaskan oleh repositori, dan statusnya dibuat berdasarkan versi. Pada saat yang sama, sebagian besar modul terhubung dari repositori eksternal sehingga yang tersisa hanyalah meneruskan variabel atau menjelaskan konfigurasi khusus Anda misalnya, yang membantu mengurangi persentase pengulangan kode.
Tentu saja, perjalanan kita masih jauh dari selesai dan masih banyak tugas menarik yang akan datang, seperti satu titik kerja dengan log dan metrik cluster mana pun, mesh layanan, gitop untuk mengelola beban dalam multicluster, dan banyak lagi. Kami harap pengalaman kami menarik bagi Anda!
Artikel ini ditulis oleh A. Antipov, A. Ganush, Platform Engineers.
Sumber: www.habr.com