Hai Habr!
Kami mewakili pasukan platform Exness. Sebelum ini, rakan sekerja kami telah pun menulis artikel tentang . Hari ini kami ingin berkongsi pengalaman kami memindahkan perkhidmatan ke Kubernetes.
Sebagai permulaan, kami menawarkan anda beberapa nombor untuk pemahaman yang lebih baik tentang perkara yang akan dibincangkan:
- Jabatan pembangunan kami terdiri daripada 100+ orang, termasuk lebih daripada 10 pasukan berbeza dengan proses QA, DevOps dan Scrum yang mencukupi. Timbunan pembangunan - Python, PHP, C++, Java dan Golang.
- Saiz persekitaran ujian dan pengeluaran ialah kira-kira 2000 bekas setiap satu. Mereka menjalankan Rancher v1.6 pada virtualisasi mereka sendiri dan di bawah VMware.
Motivasi
Seperti yang mereka katakan, tiada apa yang kekal selama-lamanya, dan Rancher mengumumkan penamatan sokongan untuk versi 1.6 agak lama dahulu. Ya, dalam lebih tiga tahun kita telah belajar bagaimana untuk menyediakannya dan menyelesaikan masalah yang timbul, tetapi semakin kerap kita berhadapan dengan masalah yang tidak akan dapat diperbetulkan. Rancher 1.6 juga mempunyai sistem ossified untuk mengeluarkan hak, di mana anda boleh melakukan hampir semua perkara atau tidak.
Walaupun virtualisasi proprietari memberikan kawalan yang lebih besar ke atas penyimpanan data dan keselamatannya, ia mengenakan kos operasi yang sukar diterima memandangkan pertumbuhan berterusan syarikat, bilangan projek dan keperluan untuk mereka.
Kami mahu mengikut piawaian IaC dan, jika perlu, dapatkan kapasiti dengan cepat, di mana-mana lokasi geografi dan tanpa kunci vendor, dan juga boleh meninggalkannya dengan cepat.
Langkah Pertama
Pertama sekali, kami ingin bergantung pada teknologi dan penyelesaian moden yang membolehkan pasukan mempunyai kitaran pembangunan yang lebih pantas dan meminimumkan kos operasi untuk berinteraksi dengan platform yang menyediakan kuasa.
Sudah tentu, perkara pertama yang terlintas di fikiran kami ialah Kubernetes, tetapi kami tidak teruja dan melakukan sedikit penyelidikan untuk melihat sama ada ia adalah pilihan yang tepat. Kami hanya menilai penyelesaian sumber terbuka, dan dalam pertempuran yang tidak adil, Kubernetes menang tanpa syarat.
Seterusnya timbul persoalan memilih alat untuk membuat kluster. Kami membandingkan penyelesaian yang paling popular: kops, kubespray, kubeadm.
Sebagai permulaan, kubeadm nampaknya kami jalan yang terlalu rumit, sebaliknya seperti sejenis pencipta "basikal", dan kops tidak mempunyai fleksibiliti yang mencukupi.
Dan pemenangnya ialah:
Kami mula bereksperimen dengan virtualisasi dan AWS kami sendiri, cuba mencipta semula sesuatu yang hampir serupa dengan corak pengurusan sumber kami sebelum ini, di mana semua orang berkongsi "kelompok" yang sama. Dan kini kami mempunyai kelompok pertama 10 mesin maya kecil kami, beberapa daripadanya terletak di AWS. Kami mula cuba untuk berhijrah pasukan ke sana, semuanya kelihatan "baik", dan cerita itu boleh selesai, tetapi...
Masalah Pertama
Ansible ialah kubespray dibina di atasnya, ia bukan alat yang membolehkan anda mengikuti IaC: apabila mentauliahkan/menyahtauliah nod, sesuatu sentiasa berlaku dan beberapa jenis campur tangan diperlukan, dan apabila menggunakan OS yang berbeza, buku main berkelakuan berbeza. secara berbeza . Apabila bilangan pasukan dan nod dalam gugusan semakin bertambah, kami mula menyedari bahawa buku permainan mengambil masa yang lebih lama dan lebih lama untuk disiapkan, dan akibatnya, rekod kami ialah 3,5 jam, bagaimana dengan rekod anda? π
Dan nampaknya kubespray hanyalah Ansible, dan semuanya jelas pada pandangan pertama, tetapi:
Pada permulaan perjalanan, tugasnya adalah untuk melancarkan kapasiti hanya dalam AWS dan pada virtualisasi, tetapi kemudian, seperti yang sering berlaku, keperluan berubah.
Memandangkan ini, jelaslah bahawa corak lama kami untuk menggabungkan sumber ke dalam satu sistem orkestrasi tidak sesuai - dalam kes di mana kluster sangat jauh dan diuruskan oleh penyedia yang berbeza.
Lebih lanjut lagi. Apabila semua pasukan bekerja dalam kelompok yang sama, pelbagai perkhidmatan dengan NodeSelectors yang dipasang secara salah boleh terbang ke hos "asing" pasukan lain dan menggunakan sumber di sana, dan jika noda ditetapkan, terdapat permintaan berterusan bahawa satu atau perkhidmatan lain tidak berfungsi, tidak diedarkan dengan betul kerana faktor manusia. Masalah lain ialah mengira kos, terutamanya mempertimbangkan masalah dalam mengagihkan perkhidmatan merentasi nod.
Cerita yang berasingan ialah pengeluaran hak kepada pekerja: setiap pasukan mahu menjadi "ketua" kluster dan menguruskannya sepenuhnya, yang boleh menyebabkan keruntuhan sepenuhnya, memandangkan pasukan pada asasnya bebas antara satu sama lain.
Apa yang perlu dilakukan?
Dengan mengambil kira perkara di atas dan hasrat pasukan untuk lebih berdikari, kami membuat kesimpulan mudah: satu pasukan - satu kelompok.
Jadi kami mendapat yang kedua:
Dan kemudian kelompok ketiga:
Kemudian kami mula berfikir: katakan dalam setahun pasukan kami akan mempunyai lebih daripada satu kelompok? Di kawasan geografi yang berbeza, sebagai contoh, atau di bawah kawalan pembekal yang berbeza? Dan sesetengah daripada mereka akan mahu dapat menggunakan kluster sementara dengan cepat untuk beberapa ujian.
Kubernetes penuh akan datang! Ini adalah sejenis MultiKubernetes, ternyata.
Pada masa yang sama, kita semua perlu mengekalkan semua kluster ini, dapat mengurus akses kepada mereka dengan mudah, serta mencipta yang baharu dan menyahtauliah yang lama tanpa campur tangan manual.
Beberapa waktu telah berlalu sejak permulaan perjalanan kami di dunia Kubernetes, dan kami memutuskan untuk meneliti semula penyelesaian yang tersedia. Ternyata ia sudah wujud di pasaran - Rancher 2.2.
Pada peringkat pertama penyelidikan kami, Rancher Labs telah pun membuat keluaran pertama versi 2, tetapi walaupun ia boleh dinaikkan dengan cepat dengan melancarkan bekas tanpa kebergantungan luaran dengan beberapa parameter atau menggunakan Carta HELM rasmi, ia kelihatan kasar. kepada kami, dan kami tidak tahu sama ada kami boleh bergantung pada keputusan ini sama ada ia akan dibangunkan atau ditinggalkan dengan cepat. Paradigma kluster = klik dalam UI itu sendiri juga tidak sesuai dengan kami, dan kami tidak mahu terikat dengan RKE, kerana ia adalah alat yang agak sempit.
Versi Rancher 2.2 sudah pun mempunyai penampilan yang lebih boleh digunakan dan, bersama-sama dengan yang sebelumnya, mempunyai banyak ciri menarik di luar kotak, seperti penyepaduan dengan banyak pembekal luaran, satu titik pengedaran hak dan fail kubeconfig, melancarkan kubectl imej dengan hak anda dalam UI, ruang nama bersarang aka projek.
Terdapat juga komuniti yang telah dibentuk di sekitar Rancher 2, dan penyedia bernama HashiCorp Terraform telah dicipta untuk mengurusnya, yang membantu kami menyusun segala-galanya.
Apa yang berlaku
Akibatnya, kami berakhir dengan satu kluster kecil yang menjalankan Rancher, boleh diakses oleh semua kluster lain, serta banyak kluster yang disambungkan kepadanya, akses kepada mana-mana kluster boleh diberikan hanya seperti menambah pengguna ke direktori ldap, tanpa mengira di mana ia berada dan sumber pembekal yang digunakannya.
Menggunakan gitlab-ci dan Terraform, sistem telah dicipta yang membolehkan anda membuat kluster sebarang konfigurasi dalam pembekal awan atau infrastruktur kami sendiri dan menyambungkannya kepada Rancher. Semua ini dilakukan dalam gaya IaC, di mana setiap kelompok diterangkan oleh repositori, dan keadaannya adalah versi. Pada masa yang sama, kebanyakan modul disambungkan daripada repositori luaran supaya yang tinggal hanyalah untuk menghantar pembolehubah atau menerangkan konfigurasi tersuai anda untuk contoh, yang membantu mengurangkan peratusan pengulangan kod.
Sudah tentu, perjalanan kami masih jauh dari tamat dan masih terdapat banyak tugas menarik di hadapan, seperti satu titik kerja dengan log dan metrik mana-mana kluster, jaringan perkhidmatan, gitops untuk menguruskan beban dalam multicluster dan banyak lagi. Kami harap anda mendapati pengalaman kami menarik!
Artikel itu ditulis oleh A. Antipov, A. Ganush, Jurutera Platform.
Sumber: www.habr.com