Hoy Habr!
Kinakatawan namin ang Exness platform team. Noong nakaraan, ang aming mga kasamahan ay nagsulat na ng isang artikulo tungkol sa . Ngayon gusto naming ibahagi ang aming karanasan sa paglilipat ng mga serbisyo sa Kubernetes.
Upang magsimula, nag-aalok kami sa iyo ng ilang mga numero para sa isang mas mahusay na pag-unawa sa kung ano ang tatalakayin:
- Binubuo ang aming departamento ng pag-unlad ng 100+ na tao, kabilang ang higit sa 10 iba't ibang team na may mga self-sufficient na proseso ng QA, DevOps at Scrum. Development stack - Python, PHP, C++, Java at Golang.
- Ang laki ng mga kapaligiran sa pagsubok at produksyon ay humigit-kumulang 2000 lalagyan bawat isa. Sila ay nagpapatakbo ng Rancher v1.6 sa kanilang sariling virtualization at sa ilalim ng VMware.
Pagganyak
Tulad ng sinasabi nila, walang nagtatagal magpakailanman, at inihayag ni Rancher ang pagtatapos ng suporta para sa bersyon 1.6 medyo matagal na ang nakalipas. Oo, sa loob ng mahigit tatlong taon ay natutunan natin kung paano ito ihanda at lutasin ang mga problemang lumalabas, ngunit mas madalas tayong nahaharap sa mga problemang hindi na maitatama. Ang Rancher 1.6 ay mayroon ding ossified system para sa pag-isyu ng mga karapatan, kung saan maaari mong gawin ang halos lahat o wala.
Bagama't ang proprietary virtualization ay nagbigay ng higit na kontrol sa pag-iimbak ng data at sa seguridad nito, nagpataw ito ng mga gastos sa pagpapatakbo na mahirap tanggapin dahil sa patuloy na paglago ng kumpanya, ang bilang ng mga proyekto at mga kinakailangan para sa kanila.
Nais naming sundin ang mga pamantayan ng IaC at, kung kinakailangan, makakuha ng kapasidad nang mabilis, sa anumang heyograpikong lokasyon at walang lock ng vendor, at magagawa rin itong mabilis na iwanan.
Unang Hakbang
Una sa lahat, gusto naming umasa sa mga modernong teknolohiya at solusyon na magbibigay-daan sa mga team na magkaroon ng mas mabilis na yugto ng pag-unlad at mabawasan ang mga gastos sa pagpapatakbo para sa pakikipag-ugnayan sa platform na nagbibigay ng kapangyarihan.
Siyempre, ang unang pumasok sa isip namin ay ang Kubernetes, ngunit hindi kami natuwa at nagsagawa ng kaunting pananaliksik upang makita kung ito ang tamang pagpipilian. Sinuri lang namin ang mga solusyon sa opensource, at sa isang hindi patas na labanan, walang kondisyong nanalo ang Kubernetes.
Sumunod na dumating ang tanong ng pagpili ng tool para sa paglikha ng mga kumpol. Inihambing namin ang pinakasikat na solusyon: kops, kubespray, kubeadm.
Upang magsimula, ang kubeadm ay tila sa amin ay masyadong kumplikadong isang landas, sa halip ay isang uri ng imbentor ng isang "bisikleta," at ang kops ay walang sapat na kakayahang umangkop.
At ang nagwagi ay:
Nagsimula kaming mag-eksperimento sa sarili naming virtualization at AWS, sinusubukang muling likhain ang isang bagay na halos katulad ng dati naming pattern sa pamamahala ng mapagkukunan, kung saan ibinahagi ng lahat ang parehong "cluster." At ngayon ay mayroon na tayong unang kumpol ng 10 maliliit na virtual machine, ang ilan sa mga ito ay matatagpuan sa AWS. Sinimulan naming subukang mag-migrate ng mga koponan doon, ang lahat ay tila "mabuti", at ang kuwento ay maaaring matapos, ngunit...
Mga Unang Problema
Ang Ansible ay kung saan itinayo ang kubespray, hindi ito isang tool na nagbibigay-daan sa iyong sundin ang IaC: kapag nag-commissioning/decommissioning nodes, palaging may mali at kailangan ng ilang uri ng interbensyon, at kapag gumagamit ng iba't ibang OS, iba ang kilos ng playbook. iba. . Habang dumarami ang bilang ng mga team at node sa cluster, nagsimula kaming mapansin na ang playbook ay tumatagal at mas matagal upang makumpleto, at bilang isang resulta, ang aming record ay 3,5 oras, paano ang sa iyo? π
At parang Ansible lang ang kubespray, at malinaw ang lahat sa unang tingin, ngunit:
Sa simula ng paglalakbay, ang gawain ay upang ilunsad ang mga kapasidad lamang sa AWS at sa virtualization, ngunit pagkatapos, gaya ng madalas na nangyayari, nagbago ang mga kinakailangan.
Dahil dito, naging malinaw na ang aming lumang pattern ng pagsasama-sama ng mga mapagkukunan sa isang sistema ng orkestrasyon ay hindi angkop - sa kaso kung saan ang mga cluster ay napakalayo at pinamamahalaan ng iba't ibang provider.
At saka. Kapag ang lahat ng mga koponan ay nagtatrabaho sa loob ng parehong kumpol, ang iba't ibang mga serbisyo na may hindi wastong naka-install na NodeSelectors ay maaaring lumipad patungo sa "banyagang" host ng isa pang koponan at gumamit ng mga mapagkukunan doon, at kung ang mantsa ay itinakda, may mga palaging kahilingan na ang isa o isa pang serbisyo ay hindi gumagana, hindi naipamahagi nang tama dahil sa kadahilanan ng tao. Ang isa pang problema ay ang pagkalkula ng gastos, lalo na kung isasaalang-alang ang mga problema sa pamamahagi ng mga serbisyo sa mga node.
Ang isang hiwalay na kuwento ay ang pagbibigay ng mga karapatan sa mga empleyado: ang bawat koponan ay nais na maging "nangunguna" ng cluster at ganap na pamahalaan ito, na maaaring magdulot ng isang kumpletong pagbagsak, dahil ang mga koponan ay karaniwang independyente sa isa't isa.
Ano ang dapat gawin?
Isinasaalang-alang ang nasa itaas at ang mga kagustuhan ng mga koponan na maging mas malaya, gumawa kami ng isang simpleng konklusyon: isang koponan - isang kumpol.
Kaya nakakuha kami ng pangalawa:
At pagkatapos ay ang ikatlong kumpol:
Pagkatapos ay nagsimula kaming mag-isip: sabihin natin na sa isang taon ang aming mga koponan ay magkakaroon ng higit sa isang kumpol? Sa iba't ibang heograpikal na lugar, halimbawa, o sa ilalim ng kontrol ng iba't ibang provider? At gugustuhin ng ilan sa kanila na mabilis na makapag-deploy ng pansamantalang kumpol para sa ilang pagsubok.
Darating ang buong Kubernetes! Ito ay isang uri ng MultiKubernetes, lumalabas.
Kasabay nito, kakailanganin nating lahat na kahit papaano ay mapanatili ang lahat ng mga cluster na ito, madaling pamahalaan ang pag-access sa mga ito, gayundin ang lumikha ng mga bago at alisin ang mga luma nang walang manu-manong interbensyon.
Ilang oras na ang lumipas mula noong simula ng aming paglalakbay sa mundo ng Kubernetes, at nagpasya kaming muling suriin ang mga magagamit na solusyon. Ito ay lumabas na mayroon na ito sa merkado - Rancher 2.2.
Sa unang yugto ng aming pananaliksik, nagawa na ng Rancher Labs ang unang paglabas ng bersyon 2, ngunit bagaman maaari itong mapataas nang napakabilis sa pamamagitan ng paglulunsad ng isang container na walang mga panlabas na dependency na may ilang mga parameter o paggamit ng opisyal na HELM Chart, ito ay tila bastos. sa amin, at hindi namin alam kung maaari kaming umasa sa desisyong ito kung ito ay bubuo o mabilis na abandunahin. Hindi rin nababagay sa amin ang cluster = clicks paradigm sa mismong UI, at hindi namin gustong matali sa RKE, dahil isa itong tool na medyo makitid na nakatutok.
Ang Bersyon ng Rancher 2.2 ay nagkaroon na ng mas maisasagawang hitsura at, kasama ng mga nauna, nagkaroon ng isang grupo ng mga kagiliw-giliw na tampok sa labas ng kahon, tulad ng pagsasama sa maraming mga panlabas na provider, isang solong punto ng pamamahagi ng mga karapatan at mga kubeconfig file, paglulunsad ng isang kubectl larawan kasama ang iyong mga karapatan sa UI, mga nested namespaces aka mga proyekto.
Mayroon ding isang komunidad na nabuo na sa paligid ng Rancher 2, at isang provider na tinatawag na HashiCorp Terraform ang nilikha upang pamahalaan ito, na tumulong sa aming pagsama-samahin ang lahat.
Anong nangyari
Bilang resulta, nagkaroon kami ng isang maliit na kumpol na tumatakbo sa Rancher, naa-access sa lahat ng iba pang mga kumpol, pati na rin sa maraming kumpol na konektado dito, ang access sa alinman sa mga ito ay maaaring ibigay bilang simpleng pagdaragdag ng isang user sa direktoryo ng ldap, anuman ang kung saan ito matatagpuan at kung aling mga mapagkukunan ng provider ang ginagamit nito.
Gamit ang gitlab-ci at Terraform, nilikha ang isang system na nagbibigay-daan sa iyong lumikha ng isang kumpol ng anumang configuration sa mga cloud provider o sa aming sariling imprastraktura at ikonekta ang mga ito sa Rancher. Ginagawa ang lahat ng ito sa istilong IaC, kung saan ang bawat kumpol ay inilalarawan ng isang repositoryo, at ang estado nito ay may bersyon. Kasabay nito, ang karamihan sa mga module ay konektado mula sa mga panlabas na repositoryo upang ang natitira na lang ay magpasa ng mga variable o ilarawan ang iyong custom na configuration para sa mga pagkakataon, na tumutulong na bawasan ang porsyento ng pag-uulit ng code.
Siyempre, malayo pa ang ating paglalakbay at marami pa ring kawili-wiling gawain sa hinaharap, tulad ng isang punto ng trabaho na may mga log at sukatan ng anumang mga kumpol, service mesh, mga gitop para sa pamamahala ng mga load sa isang multicluster at marami pang iba. Umaasa kami na naging kawili-wili ang aming karanasan!
Ang artikulo ay isinulat ni A. Antipov, A. Ganush, Platform Engineers.
Pinagmulan: www.habr.com