K8S Multicluster nga Panaw

Hoy Habr!

Nagrepresentar kami sa Exness platform team. Kaniadto, ang among mga kauban nagsulat na usa ka artikulo bahin sa Mga hulagway nga andam sa produksiyon para sa k8s. Karon gusto namong ipaambit ang among kasinatian sa paglalin sa mga serbisyo sa Kubernetes.

Sa pagsugod, nagtanyag kami kanimo pipila ka mga numero alang sa usa ka mas maayo nga pagsabut kung unsa ang hisgutan:

• Ang among departamento sa pag-uswag naglangkob sa 100+ ka mga tawo, lakip ang labaw sa 10 nga lainlaing mga koponan nga adunay igo nga kaugalingon nga mga proseso sa QA, DevOps ug Scrum. Development stack - Python, PHP, C++, Java ug Golang. 
• Ang gidak-on sa pagsulay ug mga palibot sa produksiyon mga 2000 nga sulud matag usa. Gipadagan nila ang Rancher v1.6 sa ilang kaugalingong virtualization ug ubos sa VMware. 

Pag-awhag

Sama sa ilang giingon, wala’y molungtad hangtod sa kahangturan, ug gipahibalo ni Rancher ang pagtapos sa suporta alang sa bersyon 1.6 dugay na ang milabay. Oo, sulod sa kapin sa tulo ka tuig nakat-on kita sa pag-andam niini ug pagsulbad sa mga problema nga motumaw, apan mas kanunay nga kita nag-atubang sa mga problema nga dili na matul-id. Ang Rancher 1.6 usab adunay usa ka ossified nga sistema alang sa pag-isyu sa mga katungod, diin mahimo nimo ang halos tanan o wala.

Bisan tuod ang proprietary virtualization naghatag og mas dako nga kontrol sa pagtipig sa datos ug sa seguridad niini, kini nagpahamtang sa mga gasto sa operasyon nga lisud dawaton tungod sa kanunay nga pagtubo sa kompanya, ang gidaghanon sa mga proyekto ug mga kinahanglanon alang kanila.

Gusto namon nga sundon ang mga sumbanan sa IaC ug, kung kinahanglan, dali nga makakuha og kapasidad, sa bisan unsang lokasyon sa heyograpiya ug wala’y kandado sa vendor, ug mahimo usab nga dali nga biyaan kini.

unang lakang

Una sa tanan, gusto namong mosalig sa modernong mga teknolohiya ug mga solusyon nga magtugot sa mga team nga makabaton og mas paspas nga siklo sa pag-uswag ug mamenosan ang mga gasto sa operasyon alang sa pagpakig-uban sa plataporma nga naghatag og gahom. 
 
Siyempre, ang unang butang nga misantop sa among hunahuna mao ang Kubernetes, apan wala kami maghinam-hinam ug naghimo og gamay nga panukiduki aron makita kung kini ba ang husto nga pagpili. Ang mga solusyon sa opensource lang ang among gisusi, ug sa dili patas nga panagsangka, walay kondisyon nga midaog ang Kubernetes.  

Sunod miabut ang pangutana sa pagpili sa usa ka himan alang sa paghimo sa mga pungpong. Gikumpara namon ang labing inila nga mga solusyon: kops, kubespray, kubeadm.

Sa pagsugod, ang kubeadm sa among tan-aw usa ka komplikado kaayo nga dalan, hinoon sama sa usa ka matang sa imbentor sa usa ka "bisikleta," ug ang kops walay igo nga pagka-flexible.

Ug ang nakadaog mao si:

Nagsugod kami sa pag-eksperimento sa among kaugalingon nga virtualization ug AWS, naningkamot sa paghimo pag-usab sa usa ka butang nga halos parehas sa among nangaging sumbanan sa pagdumala sa kapanguhaan, diin ang tanan adunay parehas nga "cluster." Ug karon aduna na kitay una nga pundok sa 10 ka gagmay nga virtual machine, nga ang usa niini nahimutang sa AWS. Nagsugod kami sa pagsulay sa paglalin sa mga team didto, ang tanan ingon og "maayo", ug ang istorya mahimong mahuman, apan ...

Unang mga Problema

Ansible kung unsa ang gitukod sa kubespray, dili kini usa ka himan nga nagtugot kanimo sa pagsunod sa IaC: kung ang pag-commissioning/decommissioning nodes, adunay kanunay nga sayup ug usa ka matang sa interbensyon ang gikinahanglan, ug kung naggamit sa lainlaing mga OS, ang playbook lahi ang paglihok. . Samtang nagkadako ang gidaghanon sa mga team ug node sa cluster, namatikdan namo nga ang playbook nagdugay ug mas dugay aron makompleto, ug isip resulta, ang among record kay 3,5 ka oras, unsa man ang imoha? 🙂

Ug ingon og ang kubespray kay Ansible lang, ug klaro ang tanan sa unang pagtan-aw, apan:

Sa sinugdanan sa panaw, ang tahas mao ang paglansad sa mga kapasidad lamang sa AWS ug sa virtualization, apan unya, sama sa kanunay nga mahitabo, ang mga kinahanglanon nausab.
 


Tungod niini, nahimong tin-aw nga ang atong daan nga sumbanan sa paghiusa sa mga kahinguhaan ngadto sa usa ka sistema sa orkestra dili angay - sa kaso diin ang mga cluster layo kaayo ug gidumala sa lain-laing mga providers. 

Dugang pa. Kung ang tanan nga mga koponan nagtrabaho sa parehas nga kumpol, ang lainlaing mga serbisyo nga adunay dili husto nga pagka-install nga NodeSelectors mahimong molupad sa "langyaw" nga host sa laing team ug mogamit mga kapanguhaan didto, ug kung ang mantsa gibutang, adunay kanunay nga mga hangyo nga ang usa o lain nga serbisyo wala molihok, wala giapod-apod sa husto tungod sa hinungdan sa tawo. Ang laing problema mao ang pagkalkulo sa gasto, ilabi na sa pagkonsiderar sa mga problema sa pag-apod-apod sa mga serbisyo sa tibuok node.

Ang usa ka bulag nga istorya mao ang pag-isyu sa mga katungod sa mga empleyado: ang matag team gusto nga mahimong "sa ulo" sa cluster ug hingpit nga pagdumala niini, nga mahimong hinungdan sa usa ka bug-os nga pagkahugno, tungod kay ang mga koponan sa panguna independente sa usag usa.

Unsaon nga mahimo?

Gikonsiderar ang naa sa ibabaw ug ang mga pangandoy sa mga koponan nga mahimong labi ka independente, naghimo kami usa ka yano nga konklusyon: usa ka team - usa ka kumpol. 

Mao nga nakakuha kami usa ka ikaduha:

Ug unya ang ikatulo nga cluster: 

Dayon nagsugod kami sa paghunahuna: ingnon ta nga sa usa ka tuig ang among mga team adunay labaw pa sa usa ka cluster? Sa lain-laing geographical nga mga dapit, pananglitan, o ubos sa kontrol sa lain-laing mga providers? Ug ang uban kanila gusto nga dali nga mag-deploy sa usa ka temporaryo nga kumpol alang sa pipila nga mga pagsulay. 

Ang bug-os nga Kubernetes moabot! Kini usa ka matang sa MultiKubernetes, kini nahimo. 

Sa samang higayon, kitang tanan kinahanglan nga sa usa ka paagi mamentinar ang tanan niini nga mga pungpong, makahimo sa dali nga pagdumala sa pag-access niini, ingon man usab sa paghimo og mga bag-o ug pag-decommission sa mga daan nga walay manual nga interbensyon.

Pipila ka oras ang milabay sukad sa pagsugod sa among panaw sa kalibutan sa Kubernetes, ug nakahukom kami nga susihon pag-usab ang mga magamit nga solusyon. Kini nahimo nga kini anaa na sa merkado - Rancher 2.2.

Sa una nga yugto sa among panukiduki, ang Rancher Labs nakahimo na sa una nga pagpagawas sa bersyon 2, apan bisan kung mahimo kini mapataas sa kadali pinaagi sa paglansad sa usa ka sudlanan nga wala’y mga eksternal nga dependency nga adunay usa ka pares nga mga parameter o paggamit sa opisyal nga HELM Chart, ingon og dili maayo. kanamo, ug wala kami kahibalo kung makasalig ba kami niini nga desisyon kung kini mapalambo o dali nga gibiyaan. Ang cluster = clicks paradigm sa UI mismo dili usab angay kanamo, ug dili namo gusto nga mahigot sa RKE, tungod kay kini usa ka gamay nga naka-focus nga himan. 

Ang Bersyon nga Rancher 2.2 adunay usa ka labi ka magamit nga hitsura ug, kauban ang mga nauna, adunay daghang mga makapaikag nga bahin sa gawas sa kahon, sama sa panagsama sa daghang mga eksternal nga tighatag, usa ka punto sa pag-apod-apod sa mga katungod ug mga file sa kubeconfig, paglansad sa usa ka kubectl hulagway uban sa imong mga katungod sa UI, nested namespaces aka mga proyekto. 

Adunay usab usa ka komunidad nga naporma sa palibot sa Rancher 2, ug usa ka tighatag nga gitawag nga HashiCorp Terraform ang gihimo aron madumala kini, nga nakatabang kanamo nga mahiusa ang tanan.

Unsay nahitabo

Ingon usa ka sangputanan, nakuha namon ang usa ka gamay nga kumpol nga nagdagan nga Rancher, nga ma-access sa tanan nga uban nga mga pungpong, ingon man daghang mga pungpong nga konektado niini, ang pag-access sa bisan unsa niini mahimong ihatag sama ra sa pagdugang usa ka tiggamit sa direktoryo sa ldap, bisan pa sa asa kini nahimutang ug unsa nga mga kapanguhaan sa provider ang gigamit niini.

Gamit ang gitlab-ci ug Terraform, usa ka sistema ang gihimo nga nagtugot kanimo sa paghimo og usa ka cluster sa bisan unsang configuration sa cloud providers o sa atong kaugalingong imprastraktura ug ikonektar sila sa Rancher. Kining tanan gihimo sa IaC style, diin ang matag cluster gihulagway sa usa ka repository, ug ang estado niini gi-bersyon. Sa parehas nga oras, kadaghanan sa mga module konektado gikan sa mga eksternal nga repositoryo aron ang nahabilin mao ang pagpasa sa mga variable o paghulagway sa imong naandan nga pag-configure alang sa mga higayon, nga makatabang sa pagkunhod sa porsyento sa pagbalik-balik sa code.

Siyempre, layo pa ang atong panaw ug aduna pay daghang makaiikag nga buluhaton sa unahan, sama sa usa ka punto sa trabaho nga adunay mga log ug metrics sa bisan unsang clusters, service mesh, gitops para sa pagdumala sa mga load sa multicluster ug daghan pa. Kami nanghinaut nga imong makit-an ang among kasinatian nga makapaikag! 

Ang artikulo gisulat ni A. Antipov, A. Ganush, Platform Engineers. 

Source: www.habr.com