Héy Habr!
Kami ngawakilan tim platform Exness. Saméméhna, kolega urang geus nulis artikel ngeunaan . Dinten ieu kami hoyong bagikeun pangalaman migrasi jasa ka Kubernetes.
Pikeun mimitian, kami nawiskeun anjeun sababaraha nomer pikeun langkung ngartos naon anu bakal dibahas:
- Departemén pamekaran kami diwangun ku 100+ jalma, kalebet langkung ti 10 tim anu béda kalayan prosés QA, DevOps sareng Scrum mandiri. Tumpukan pamekaran - Python, PHP, C++, Java sareng Golang.
- Ukuran lingkungan tés sareng produksi sakitar 2000 wadah masing-masing. Aranjeunna ngajalankeun Rancher v1.6 on virtualization sorangan sarta dina VMware.
alesan
Sakumaha aranjeunna nyarios, teu aya anu salamina, sareng Rancher ngumumkeun tungtung dukungan pikeun versi 1.6 parantos lami pisan. Leres, langkung ti tilu taun urang diajar kumaha nyiapkeun sareng ngarengsekeun masalah anu timbul, tapi beuki sering urang disanghareupan ku masalah anu moal pernah dilereskeun. Rancher 1.6 ogé ngagaduhan sistem ossified pikeun ngaluarkeun hak, dimana anjeun tiasa ngalakukeun ampir sadayana atanapi henteu nanaon.
Sanaos virtualisasi proprietary nyayogikeun kontrol anu langkung ageung pikeun panyimpen data sareng kaamananna, biaya operasi anu sesah ditampi kumargi pertumbuhan konstan perusahaan, jumlah proyék sareng syarat pikeun aranjeunna.
Kami hoyong nuturkeun standar IaC sareng, upami diperyogikeun, kéngingkeun kapasitas gancang, di mana waé lokasi geografis sareng tanpa konci ngajual, sareng ogé tiasa gancang ngantunkeunana.
léngkah kahiji
Anu mimiti, urang hoyong ngandelkeun téknologi modéren sareng solusi anu ngamungkinkeun tim gaduh siklus pangembangan anu langkung gancang sareng ngaminimalkeun biaya operasional pikeun berinteraksi sareng platform anu nyayogikeun kakuatan.
Tangtu, hal kahiji anu datang ka pikiran urang éta Kubernetes, tapi urang teu meunang bungah tur ngalakukeun panalungtikan saeutik pikeun nempo naha éta pilihan katuhu. Kami ngan ukur ngevaluasi solusi opensource, sareng dina perang anu teu adil, Kubernetes menang tanpa syarat.
Salajengna sumping patarosan milih alat pikeun nyieun klaster. Kami ngabandingkeun solusi anu pang populerna: kops, kubespray, kubeadm.
Pikeun ngamimitian, kubeadm sigana urang janten jalan anu rumit teuing, sapertos jinis panemu "sapédah," sareng kops henteu ngagaduhan kalenturan anu cukup.
Sareng juara nyaéta:
Urang ngamimitian ékspérimén sareng virtualisasi sareng AWS urang sorangan, nyobian nyiptakeun deui hal anu kasarna sami sareng pola manajemén sumberdaya urang sateuacana, dimana sadayana ngabagi "cluster" anu sami. Sareng ayeuna urang gaduh klaster munggaran 10 mesin virtual leutik, sababaraha anu aya di AWS. Urang mimitian nyoba migrasi tim ka dinya, sagalana sigana "alus", jeung carita bisa réngsé, tapi ...
Masalah munggaran
Ansible mangrupikeun naon anu diwangun ku kubespray, sanés alat anu ngamungkinkeun anjeun nuturkeun IaC: nalika komisioning / decommissioning titik, aya anu salah terus-terusan sareng sababaraha jinis campur anu diperyogikeun, sareng nalika nganggo OS anu béda, playbook kalakuanana béda. . Nalika jumlah tim sareng titik dina kluster naék, urang mimiti perhatikeun yén playbook langkung lami sareng langkung lami pikeun réngsé, sareng salaku hasilna, catetan kami 3,5 jam, kumaha upami anjeun? 🙂
Jeung sigana kawas kubespray ngan Ansible, sarta sagalana jelas dina glance kahiji, tapi:
Dina awal perjalanan, tugasna pikeun ngaluncurkeun kamampuan ngan ukur dina AWS sareng virtualisasi, tapi teras, sakumaha sering kajadian, saratna robih.
Dina lampu ieu, janten jelas yén pola heubeul urang ngagabungkeun sumberdaya kana hiji sistem orkestrasi teu cocog - dina kasus dimana klaster jauh pisan tur dikelola ku panyadia béda.
Salajengna langkung. Nalika sadaya tim damel dina kluster anu sami, sagala rupa jasa sareng NodeSelectors anu teu leres dipasang tiasa ngapung ka host "asing" tim anu sanés sareng ngamangpaatkeun sumber daya di dinya, sareng upami taint diatur, aya paménta konstan yén hiji atanapi jasa sanés henteu jalan, henteu disebarkeun leres kusabab faktor manusa. Masalah anu sanés nyaéta ngitung biaya, khususna mertimbangkeun masalah dina ngadistribusikaeun jasa dina titik-titik.
Carita anu misah nyaéta ngaluarkeun hak ka karyawan: unggal tim hoyong janten "pamimpin" klaster sareng ngatur sacara lengkep, anu tiasa nyababkeun runtuhna lengkep, sabab tim dasarna bebas masing-masing.
Kumaha jadina?
Nganggap hal di luhur sareng kahoyong tim janten langkung mandiri, kami ngadamel kacindekan saderhana: hiji tim - hiji klaster.
Janten urang ngagaduhan anu kadua:
Lajeng klaster katilu:
Teras we mimiti mikir: hayu urang nyebutkeun yén dina sataun tim urang bakal boga leuwih ti hiji klaster? Di wewengkon géografis béda, contona, atawa dina kadali panyadia béda? Sareng sababaraha di antarana bakal hoyong tiasa gancang nyebarkeun klaster samentawis pikeun sababaraha tés.
Kubernetes pinuh bakal datang! Ieu sababaraha jenis MultiKubernetes, tétéla.
Dina waktos anu sami, urang sadayana kedah kumaha waé ngajaga sadaya klaster ieu, tiasa gampang ngatur aksés ka aranjeunna, ogé nyiptakeun anu énggal sareng ngaleungitkeun anu lami tanpa campur tangan manual.
Sababaraha waktu geus kaliwat ti mimiti lalampahan urang di dunya Kubernetes, sarta kami mutuskeun pikeun nalungtik ulang solusi sadia. Tétéla éta parantos aya di pasar - Rancher 2.2.
Dina tahap mimiti panalungtikan urang, Rancher Labs parantos ngadamel sékrési mimiti versi 2, tapi sanaos éta tiasa diangkat gancang pisan ku ngaluncurkeun wadah tanpa katergantungan éksternal sareng sababaraha parameter atanapi nganggo Bagan HELM resmi, éta sigana kasar. ka kami, sarta kami henteu weruh lamun urang bisa ngandelkeun kaputusan ieu naha éta bakal dimekarkeun atawa gancang ditinggalkeun. Kluster = paradigma clicks di UI sorangan ogé teu cocog kami, sarta kami teu hayang jadi dihijikeun ka RKE, saprak éta alat rada heureut fokus.
Vérsi Rancher 2.2 parantos ngagaduhan penampilan anu langkung tiasa dianggo sareng, sareng anu sateuacana, ngagaduhan seueur fitur anu pikaresepeun, sapertos integrasi sareng seueur panyadia éksternal, hiji titik distribusi hak sareng file kubeconfig, ngaluncurkeun kubectl. gambar kalawan hak anjeun dina UI, namespaces nested alias proyék.
Aya ogé komunitas anu parantos dibentuk di sabudeureun Rancher 2, sareng panyadia anu disebut HashiCorp Terraform diciptakeun pikeun ngatur éta, anu ngabantosan urang ngahijikeun sadayana.
Aya naon
Hasilna, urang réngsé nepi ka hiji klaster leutik ngajalankeun Rancher, diaksés ka sadaya klaster séjén, kitu ogé loba klaster disambungkeun ka eta, aksés ka salah sahiji nu bisa dibikeun sagampil nambahkeun pamaké kana diréktori ldap, paduli dimana lokasina sareng sumber panyadia mana anu dianggo.
Nganggo gitlab-ci sareng Terraform, sistem diciptakeun anu ngamungkinkeun anjeun nyiptakeun gugusan konfigurasi naon waé dina panyadia awan atanapi infrastruktur urang sorangan sareng sambungkeun ka Rancher. Sadaya ieu dilakukeun dina gaya IaC, dimana unggal klaster dijelaskeun ku Repository, sareng kaayaanana diversi. Dina waktu nu sarua, lolobana modul disambungkeun ti repositories éksternal, jadi ngan ukur ngalirkeun variabel atawa ngajelaskeun konfigurasi custom Anjeun pikeun instansi, nu mantuan ngurangan persentase pengulangan kode.
Tangtosna, perjalanan urang jauh ti réngsé sareng masih seueur tugas anu pikaresepeun, sapertos hiji titik padamelan sareng log sareng métrik tina klaster naon waé, bolong jasa, gitops pikeun ngatur beban dina multicluster sareng seueur deui. Simkuring miharep anjeun manggihan pangalaman urang metot!
Artikel ieu ditulis ku A. Antipov, A. Ganush, Insinyur Platform.
sumber: www.habr.com