Get best of the week

K8S Multicluster Journey

Halo, Habr!

Kami mewakili tim platform Exness. Sebelumnya, kolega kami telah menulis artikel tentang gambar siap Produksi untuk k8s . Hari ini kami ingin berbagi pengalaman migrasi layanan di Kubernetes.



Untuk mulai dengan, kami menawarkan beberapa nomor untuk pemahaman yang lebih baik tentang apa yang akan dibahas:

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


Seperti yang mereka katakan, tidak ada yang bertahan selamanya, dan Rancher telah cukup lama mengumumkan penghentian dukungan untuk versi 1.6. Ya, selama lebih dari tiga tahun kami telah belajar cara memasaknya dan memecahkan masalah yang muncul, tetapi semakin sering kita dihadapkan dengan masalah yang tidak akan pernah bisa diperbaiki. Rancher 1.6 juga memiliki sistem keras untuk mengeluarkan hak, di mana Anda bisa melakukan hampir semua atau tidak sama sekali.

Virtualisasi sendiri, meskipun memberikan kontrol yang lebih besar terhadap penyimpanan dan keamanan data, tetapi membebankan biaya operasional, yang sulit untuk bertahan dengan pertumbuhan perusahaan yang konstan, jumlah proyek dan persyaratan untuk itu.

Kami ingin mengikuti standar IaC dan, jika perlu, mendapatkan kekuatan 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 untuk memiliki siklus pengembangan yang lebih cepat dan meminimalkan biaya operasi untuk interaksi dengan platform yang menyediakan daya. 
 
Tentu saja, hal pertama yang muncul di benak kami adalah Kubernetes, tetapi kami tidak merasa senang dan melakukan sedikit riset tentang masalah pilihan yang tepat. Kami hanya mengevaluasi solusi sumber terbuka, dan Kubernet dikalahkan tanpa syarat dalam pertempuran yang tidak adil.  

Selanjutnya muncul pertanyaan memilih alat untuk membuat cluster. Kami membandingkan solusi yang paling populer: kops, kubespray, kubeadm.

Untuk memulai, kubeadm bagi kami tampaknya terlalu rumit, lebih tepatnya, semacam penemu "sepeda", dan polisi tidak memiliki fleksibilitas.

Dan pemenangnya keluar:



Kami mulai bereksperimen dengan virtualisasi dan AWS kami sendiri, mencoba untuk menciptakan kembali kemiripan dengan pola manajemen sumber daya kami sebelumnya, di mana semua orang menggunakan "cluster" yang sama. Dan sekarang kami memiliki cluster pertama dari 10 mesin virtual kecil, beberapa di antaranya ada di AWS. Kami mulai mencoba memigrasi tim di sana, semuanya tampak "baik", dan ceritanya bisa selesai, tetapi ...

Masalah pertama


Kemungkinan adalah apa yang dibangun di atas kubespray, itu bukan alat yang memungkinkan IaC untuk diikuti: sesuatu yang salah selama input / output dari node, dan beberapa intervensi diperlukan, dan ketika menggunakan OS yang berbeda, playbook berperilaku dengan berbagai cara. Dengan semakin banyaknya perintah dan node dalam cluster, kami mulai memperhatikan bahwa playbook itu membutuhkan waktu lebih lama, pada akhirnya, catatan kami adalah 3,5 jam, dan milik Anda? :)

Dan sepertinya kubespray hanya mungkin, dan semuanya jelas pada pandangan pertama, tetapi:



Pada awal perjalanan ada tugas untuk menjalankan kapasitas hanya dalam AWS dan virtualisasi, tetapi kemudian, seperti yang sering terjadi, persyaratan berubah.
 


Mengingat hal ini, menjadi jelas bahwa pola lama kami dalam menggabungkan sumber daya ke dalam satu sistem orkestrasi tidak cocok - dalam kasus ketika kluster jauh dihapus dan dikelola oleh penyedia yang berbeda. 

Lebih jauh lagi. Ketika semua tim bekerja di dalam kluster yang sama, berbagai layanan dengan NodeSelector yang dipasang secara tidak benar dapat terbang ke host “alien” dari tim lain dan menggunakan sumber daya di sana, dan dalam hal pengaturan noda, ada panggilan konstan bahwa layanan ini atau itu tidak berfungsi, tidak didistribusikan dengan benar karena faktor manusia. Masalah lain adalah perhitungan biaya, terutama mengingat masalah dalam distribusi layanan oleh node.

Sebuah cerita terpisah adalah masalah hak atas karyawan: masing-masing tim ingin menjadi "kepala" gugus dan sepenuhnya mengelolanya, yang dapat menyebabkan keruntuhan total, karena tim sebagian besar independen satu sama lain.

Bagaimana menjadi


Mengingat hal di atas dan keinginan tim untuk lebih mandiri, kami membuat kesimpulan sederhana: satu tim - satu kelompok. 

Jadi kami mendapat yang kedua:



Dan kemudian gugus ketiga: 



Lalu kami mulai berpikir: katakanlah, dalam setahun tim kami akan memiliki lebih dari satu gugus? Di wilayah geografis yang berbeda, misalnya, atau di bawah kendali penyedia yang berbeda? Dan beberapa dari mereka ingin dapat dengan cepat menggunakan cluster sementara untuk setiap tes. 



Akan datang Kubernet penuh! Ini semacam MultiKubernetes, ternyata. 

Pada saat yang sama, kita semua perlu entah bagaimana mendukung semua kluster ini, dapat dengan mudah mengontrol akses ke mereka, serta membuat yang baru dan menonaktifkan yang lama tanpa intervensi manual.

Sejak awal perjalanan kami di dunia Kubernetes, beberapa waktu telah berlalu, dan kami memutuskan untuk memeriksa kembali solusi yang tersedia. Ternyata sudah ada di pasar - Rancher 2.2.



Pada tahap pertama penelitian kami, Rancher Labs sudah membuat rilis pertama versi 2, tetapi meskipun itu bisa dinaikkan dengan sangat cepat dengan menjalankan wadah tanpa ketergantungan eksternal dengan beberapa parameter atau menggunakan Bagan HELM resmi, tampaknya mentah bagi kami, dan kami tidak tahu apakah mengandalkan keputusan ini, apakah akan dikembangkan atau cepat ditinggalkan. Paradigma klik klik itu sendiri di UI juga tidak cocok untuk kita, dan kita tidak ingin terhubung dengan RKE, karena ini adalah alat yang berpikiran sempit. 

Versi Rancher 2.2 sudah memiliki tampilan yang lebih efisien dan, bersama dengan yang sebelumnya, memiliki banyak fitur menarik di luar kotak, seperti integrasi dengan banyak penyedia eksternal, satu titik distribusi hak dan file kubeconfig, meluncurkan gambar kubectl dengan hak Anda di UI, ruang nama alias proyek bersarang. 

Sebuah komunitas telah terbentuk di sekitar Rancher 2, dan penyedia Terraform HashiCorp dibuat untuk mengelolanya, yang membantu kami menyatukan semuanya.

Apa yang terjadi


Akibatnya, kami mendapat satu kluster kecil di mana Rancher diluncurkan, dapat diakses oleh semua kluster lainnya, serta banyak kluster yang terkait dengannya, akses ke mana saja yang dapat dikeluarkan hanya dengan menambahkan pengguna ke direktori ldap, di mana pun ia berada. terletak dan sumber daya yang digunakan penyedia.

Menggunakan gitlab-ci dan Terraform, sistem telah dibuat yang memungkinkan Anda membuat sekelompok konfigurasi 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 diversi. Dalam kasus ini, sebagian besar modul terhubung dari repositori eksternal sehingga modul tersebut hanya mentransfer variabel atau menjelaskan konfigurasi khusus mereka untuk instance, yang membantu mengurangi persentase pengulangan kode.



Tentu saja, perjalanan kami masih jauh dari selesai dan masih ada banyak tugas menarik di depan, seperti satu titik pekerjaan dengan log dan metrik dari setiap cluster, service mesh, gitop untuk mengelola beban dalam multikluster, dan banyak lagi. Kami harap Anda akan tertarik dengan pengalaman kami! 

Artikel ini ditulis oleh A. Antipov, A. Ganush, Platform Engineers. 

More articles:


All Articles