Hey Habr!
Kita makili tim platform Exness. Sadurunge, kolega kita wis nulis artikel babagan . Dina iki kita pengin nuduhake pengalaman layanan migrasi menyang Kubernetes.
Kanggo miwiti, kita menehi sawetara nomer kanggo pangerten sing luwih apik babagan apa sing bakal dibahas:
- Departemen pangembangan kita dumadi saka 100+ wong, kalebu luwih saka 10 tim sing beda karo proses QA, DevOps lan Scrum mandhiri. Tumpukan pangembangan - Python, PHP, C++, Java lan Golang.
- Ukuran lingkungan tes lan produksi kira-kira 2000 kontainer saben. Lagi mlaku Rancher v1.6 ing virtualisasi dhewe lan ing VMware.
Motivasi
Nalika padha ngomong, ora ana sing langgeng, lan Rancher ngumumake pungkasane dhukungan kanggo versi 1.6 cukup suwe. Ya, luwih saka telung taun kita wis sinau carane nyiyapake lan ngrampungake masalah sing muncul, nanging luwih asring kita ngadhepi masalah sing ora bakal didandani. Rancher 1.6 uga duwe sistem ossified kanggo nerbitake hak, ing ngendi sampeyan bisa nindakake meh kabeh utawa ora.
Sanajan virtualisasi kepemilikan nyedhiyakake kontrol sing luwih gedhe babagan panyimpenan data lan keamanan, nanging biaya operasi sing angel ditampa amarga perusahaan terus berkembang, jumlah proyek lan syarat.
Kita pengin ngetutake standar IaC lan, yen perlu, entuk kapasitas kanthi cepet, ing sembarang lokasi geografis lan tanpa kunci vendor, lan uga bisa cepet ninggalake.
langkah pisanan
Kaping pisanan, kita pengin ngandelake teknologi lan solusi modern sing ngidini tim duwe siklus pangembangan sing luwih cepet lan nyuda biaya operasional kanggo sesambungan karo platform sing nyedhiyakake daya.
Mesthi, bab pisanan sing teka ing pikiran kita yaiku Kubernetes, nanging kita ora bungah lan nindakake riset sethithik kanggo ndeleng yen iku pilihan sing tepat. Kita mung ngevaluasi solusi opensource, lan ing perang sing ora adil, Kubernetes menang tanpa syarat.
Sabanjure teka pitakonan milih alat kanggo nggawe kluster. Kita mbandhingake solusi sing paling populer: kops, kubespray, kubeadm.
Kanggo miwiti, kubeadm misale jek kita dadi dalan sing rumit banget, kaya penemu "sepeda", lan kops ora duwe keluwesan sing cukup.
Lan sing menang yaiku:
Kita miwiti eksperimen karo virtualisasi lan AWS kita dhewe, nyoba nggawe maneh babagan sing meh padha karo pola manajemen sumber daya sadurunge, ing ngendi saben wong nuduhake "cluster" sing padha. Lan saiki kita duwe klompok pisanan 10 mesin virtual cilik, sawetara sing ana ing AWS. Kita wiwit nyoba migrasi tim ing kana, kabeh katon "apik", lan critane bisa rampung, nanging ...
Masalah pisanan
Ansible yaiku apa sing dibangun kubespray, dudu alat sing ngidini sampeyan ngetutake IaC: nalika node komisioning / decommissioning, ana sing salah lan sawetara intervensi dibutuhake, lan nalika nggunakake OS sing beda, playbook tumindak kanthi beda. . Nalika jumlah tim lan simpul ing kluster saya tambah akeh, kita wiwit ngerti manawa playbook saya suwe saya suwe rampung, lan minangka asil, rekor kita ana 3,5 jam, kepiye sampeyan? π
Lan misale jek kaya kubespray mung Ansible, lan kabeh katon jelas, nanging:
Ing wiwitan lelungan, tugas kasebut mung mbukak kapasitas ing AWS lan virtualisasi, nanging banjur, kaya sing asring kedadeyan, syarat kasebut diganti.
Ing babagan iki, dadi jelas manawa pola lawas kita nggabungake sumber daya dadi siji sistem orkestrasi ora cocog - yen klompok kasebut adoh banget lan dikelola dening panyedhiya sing beda-beda.
Luwih luwih. Nalika kabeh tim kerja ing kluster sing padha, macem-macem layanan kanthi NodeSelectors sing salah diinstal bisa mabur menyang host "manca" tim liyane lan nggunakake sumber daya ing kana, lan yen taint disetel, ana panjaluk sing terus-terusan yen siji utawa layanan liyane ora bisa digunakake, ora disebarake kanthi bener amarga faktor manungsa. Masalah liyane yaiku ngitung biaya, utamane nimbang masalah distribusi layanan ing simpul.
Crita sing kapisah yaiku penerbitan hak kanggo karyawan: saben tim pengin dadi "ing kepala" kluster lan ngatur kanthi lengkap, sing bisa nyebabake ambruk lengkap, amarga tim kasebut pancen bebas saka siji liyane.
Carane dadi?
Nggatekake ing ndhuwur lan kepinginan tim supaya luwih mandiri, kita nggawe kesimpulan sing gampang: siji tim - siji klompok.
Dadi, kita entuk sing nomer loro:
Banjur klompok katelu:
Banjur kita wiwit mikir: ayo ngomong yen ing setahun tim kita bakal duwe luwih saka siji kluster? Ing wilayah geografis sing beda, contone, utawa ing kontrol panyedhiya sing beda? Lan sawetara wong pengin bisa kanthi cepet masang kluster sementara kanggo sawetara tes.
Kubernetes lengkap bakal teka! Iki sawetara jenis MultiKubernetes, ternyata.
Ing wektu sing padha, kita kabeh kudu njaga kabeh klompok kasebut, bisa gampang ngatur akses menyang dheweke, uga nggawe sing anyar lan ngilangi sing lawas tanpa intervensi manual.
Sawetara wektu wis liwati wiwit wiwitan lelungan ing jagad Kubernetes, lan kita mutusake kanggo nliti maneh solusi sing kasedhiya. Ternyata wis ana ing pasar - Rancher 2.2.
Ing tahap pisanan riset kita, Rancher Labs wis nggawe rilis pisanan versi 2, nanging sanajan bisa diunggahake kanthi cepet kanthi ngluncurake wadhah tanpa ketergantungan eksternal kanthi sawetara paramèter utawa nggunakake Bagan HELM resmi, mula katon kasar. kanggo kita, lan kita ora ngerti yen kita bisa gumantung ing kaputusan iki apa bakal dikembangaké utawa cepet nilar. Kluster = paradigma klik ing UI dhewe uga ora cocog karo kita, lan kita ora pengin diikat karo RKE, amarga alat kasebut rada sempit.
Versi Rancher 2.2 wis katon luwih bisa ditindakake lan, bebarengan karo sing sadurunge, duwe akeh fitur menarik sing metu saka kothak, kayata integrasi karo akeh panyedhiya eksternal, siji titik distribusi hak lan file kubeconfig, ngluncurake kubectl gambar karo hak sampeyan ing UI, nested namespaces alias proyek.
Ana uga komunitas sing wis dibentuk ing sekitar Rancher 2, lan panyedhiya sing diarani HashiCorp Terraform digawe kanggo ngatur, sing mbantu kita nggabungake kabeh.
Ana apa
AkibatΓ©, kita rampung karo siji kluster cilik mlaku Rancher, diakses kanggo kabeh kluster liyane, uga akeh kluster disambungake menyang, akses kanggo samubarang kang bisa diwenehake minangka mung nambah pangguna kanggo direktori ldap, preduli saka ngendi iku dumunung lan sumber panyedhiya kang digunakake.
Nggunakake gitlab-ci lan Terraform, sistem digawe sing ngidini sampeyan nggawe klompok konfigurasi apa wae ing panyedhiya maya utawa infrastruktur kita dhewe lan nyambungake menyang Rancher. Kabeh iki rampung ing gaya IaC, ngendi saben kluster diterangake dening gudang, lan negara sawijining versi. Ing wektu sing padha, umume modul disambungake saka repositori eksternal supaya kabeh sing isih ana yaiku ngliwati variabel utawa njlèntrèhaké konfigurasi khusus kanggo conto, sing mbantu nyuda persentase pengulangan kode.
Mesthine, perjalanan kita isih adoh lan isih ana akeh tugas sing menarik, kayata siji titik kerja kanthi log lan metrik saka klompok apa wae, bolong layanan, gitops kanggo ngatur beban ing multicluster lan liya-liyane. Muga-muga sampeyan nemokake pengalaman sing menarik!
Artikel iki ditulis dening A. Antipov, A. Ganush, Platform Engineers.
Source: www.habr.com