Nola konektatu Kubernetes klusterrak datu-zentro desberdinetan
Ongi etorri Kubernetes Quick Start Series-era. Sarean eta gure entrenamenduetan jasotzen ditugun galdera interesgarrienen zutabe arrunta da hau. Kubernetes adituen erantzunak.
Gaurko aditua Daniel Polenchik da (Daniele Polencic). Danielek irakasle eta software garatzaile gisa lan egiten du Learnk8s.
Askotan, azpiegiturak eskualde ezberdinetan errepikatu eta banatzen dira, batez ere ingurune kontrolatuetan.
Eskualde bat erabilgarri ez badago, trafikoa beste batera birbideratzen da etenaldiak saihesteko.
Kubernetes-ekin, antzeko estrategia bat erabil dezakezu eta lan-kargak eskualde ezberdinetan banatu ditzakezu.
Talde, eskualde, ingurune edo hauen konbinazio bakoitzeko kluster bat edo gehiago izan ditzakezu.
Zure klusterrak hainbat hodeitan eta lokaletan ostata daitezke.
Baina nola planifikatu azpiegiturak halako hedapen geografiko baterako?
Kluster handi bat sortu behar al duzu sare bakarrean hainbat hodei-ingurunetarako?
Edo kluster txiki asko dituzu eta haiek kontrolatzeko eta sinkronizatzeko modua aurkitu?
Lidergo kluster bat
Sare bakarrean kluster bat sortzea ez da hain erraza.
Imajinatu istripu bat duzula, kluster-segmentuen arteko konexioa galtzen dela.
Zerbitzari nagusi bat baduzu, baliabideen erdiak ezin izango ditu komando berriak jaso, ezin izango baitute maisuarekin harremanetan jarri.
Eta, aldi berean, bideratze-taula zaharrak dituzu (kube-proxy ezin ditu berririk deskargatu) eta ez dago osagarririk (kubelet-ek ezin du eguneratzerik eskatu).
Are okerragoa dena, Kubernetes-ek ezin badu nodorik ikusten, umezurtz gisa markatzen du eta falta diren lekak lehendik dauden nodoetara banatzen ditu.
Ondorioz, leka bikoitza duzu.
Eskualde bakoitzeko zerbitzari nagusi bat egiten baduzu, etcd datu-basean adostasun algoritmoarekin arazoak izango dira. (gutxi gorabehera. ed. - Izan ere, etcd datu-basea ez da zertan zerbitzari nagusietan kokatu. Eskualde bereko zerbitzari talde bereizi batean exekutatu daiteke. Hala ere, kluster baten hutsegite puntu bat aldi berean jaso izana. Baina azkar.)
etcd erabilerak baltsa algoritmoabalio bat adosteko diskoan idatzi aurretik.
Hau da, kasu gehienek adostasuna lortu behar dute estatua etcd-i idatzi aurretik.
Etcd instantzien arteko latentzia gora egiten badu, eskualde ezberdinetako hiru etcd instantziekin gertatzen den bezala, denbora asko behar da balio bat adosteko eta diskoan idazteko.
Hau Kubernetes kontrolagailuetan ere islatzen da.
Kontrolatzaileen kudeatzaileak denbora gehiago behar du aldaketari buruz ikasteko eta erantzuna datu-basean idazteko.
Eta kontrolatzailea ez denez bat, hainbat baizik, kate-erreakzio bat lortzen da, eta kluster osoa oso poliki hasten da lanean.
Gaur egun ez dago sare handi baten adibide onik kluster bakarrerako.
Funtsean, garatzaileen komunitatea eta SIG-kluster taldea klusterrak nola antolatu Kubernetes-ek edukiontziak antolatzen dituen modu berean saiatzen ari dira.
Lehen aldiz, kluster bilduma bat objektu bakar gisa kudeatzen saiatu gara kube federazio tresna erabiliz.
Hasiera ona izan zen, baina azkenean kube federazioa ez zen ezagun egin, baliabide guztiak onartzen ez zituelako.
Federatutako hornikuntzak eta zerbitzuak onartzen zituen, baina ez StatefulSets, adibidez.
Gainera, federazioaren konfigurazioa oharpen moduan pasa zen eta ez zen malgua.
Imajinatu nola deskriba dezakezun federazio bateko kluster bakoitzaren errepliken zatiketa oharpen bakarra erabiliz.
Nahaspila osoa izan zen.
SIG-cluster-ek lan bikaina egin zuen kubefed v1-en ondoren eta arazoari beste angelu batetik jorratzea erabaki zuen.
Oharpenen ordez, klusterretan instalatuta dagoen kontrolagailu bat kaleratzea erabaki zuten. Baliabideen definizio pertsonalizatuak (Custom Resource Definition, CRD) erabiliz konfigura daiteke.
Federatuko den baliabide bakoitzeko, CRD definizio pertsonalizatua duzu hiru ataletan:
Baliabide baten definizio estandarra, esaterako, hedatzea;
atala placement, non federazioan baliabidea nola banatuko den definitzen duzun;
atala override, non baliabide zehatz baterako pisua eta parametroak kokapenetik gainidatzi ditzakezu.
Hona hemen kokapen eta gainidazteko atalekin bateratutako entrega baten adibide bat.
Ikus dezakezunez, hornidura bi multzotan banatzen da: cluster1 ΠΈ cluster2.
Lehenengo klusterrak hiru erreplika hornitzen ditu, eta bigarrenak 5 balio du.
Erreplika kopuruaren gaineko kontrol gehiago behar baduzu, kubefed2-k ReplicaSchedulingPreference objektu berri bat eskaintzen du, non erreplikak haztatu daitezkeen:
Booking.com-en garatzaileek ez zuten kubefed v2-rekin jorratu, baina Shipper-ekin sortu zuten, hainbat kluster, eskualde eta hodei anitzetan entregatzeko operadorea.
Bi tresnek aukera ematen dizute zure kluster anitzeko inplementazio estrategia pertsonalizatzeko (zein kluster erabiltzen diren eta zenbat erreplika dituzten).
Baina Bidaltzailearen lana entrega akatsen arriskua murriztea da.
Shipper-en, aurreko eta egungo inplementazioen arteko errepliken banaketa eta sarrerako trafikoaren zenbatekoa deskribatzen duten urrats batzuk defini ditzakezu.
Baliabide bat kluster batera bultzatzen duzunean, Shipper kontrolatzaileak pixkanaka zabaltzen du aldaketa hori federatutako kluster guztietan.
Bidaltzailea ere oso mugatua da.
Esate baterako, Helm diagramak hartzen ditu sarrera gisa eta ez ditu bainila baliabideak onartzen.
Orokorrean, Shipper honela funtzionatzen du.
Banaketa estandar baten ordez, Helm diagrama barne duen aplikazio-baliabide bat sortu behar duzu:
Kubefed v2 eta Shipper-ek kluster federazioarekin lan egiten dute klusterrei baliabide berriak eskainiz baliabide pertsonalizatuen definizio baten bidez.
Baina zer gertatzen da batu beharreko hornigai guztiak, StatefulSets, DaemonSets eta abar berridatzi nahi ez badituzu?
Nola sartu lehendik dagoen kluster bat federazioan YAML aldatu gabe?
Baina klusterrekin elkarreragiteko modu berri bat asmatu beharrean eta baliabideak definizio pertsonalizatuetan biltzeko, multi-cluster-scheduler Kubernetes-en bizi-ziklo estandarrean sartzen da eta podak sortzen dituzten dei guztiak atzematen ditu.
Sortutako pod bakoitza maniki batekin ordezkatzen da berehala.
multi-cluster-scheduler erabilerak sarbidea aldatzeko web kakoakdeia atzemateko eta inaktibo finko pod bat sortzeko.
Jatorrizko podak beste programazio-ziklo batetik pasatzen du, non, federazio osoari galdeketa egin ondoren, anfitrioiaren erabakia hartzen den.
Azkenik, pod-a xede-klusterera entregatzen da.
Ondorioz, ezer egiten ez duen leka gehigarri bat duzu, lekua hartzen duena.
Abantaila da ez duzula baliabide berririk idatzi behar hornikuntzak konbinatzeko.
Pod bat sortzen duen baliabide bakoitza automatikoki prest dago federatzeko.
Hau interesgarria da, bat-batean hainbat eskualdetan banatuta dituzulako hornigaiak, eta ez zarete ohartu. Hala ere, hau nahiko arriskutsua da, hemen dena magian oinarritzen delako.
Baina Shipper batik bat bidalketen ondorioak arintzen saiatzen ari den arren, multi-cluster-scheduler orokorragoa da eta agian hobeto egokitzen da loteetako lanetarako.
Ez du mailakako entrega mekanismo aurreraturik.
Multi-cluster-scheduler-ari buruzko informazio gehiago hemen aurki daiteke biltegiko orri ofiziala.
Multi-cluster-scheduler ekintzan irakurri nahi baduzu, Admiralty-k du Argoren erabilera kasu interesgarria - lan-fluxuak, gertaerak, CI eta CD Kubernetes.
Beste tresna eta irtenbide batzuk
Hainbat kluster konektatzea eta kudeatzea zeregin konplexua da, eta ez dago soluzio bakarra.
Gai honi buruz gehiago jakin nahi baduzu, hona hemen baliabide batzuk:
Submariner Rancher-ek Kubernetes kluster ezberdinen gainjarri sareak lotzen dituen tresna da.
Cilium, edukiontzi sareko interfazearen plugina eskaintzen du cluster sarearen funtzioa, hainbat kluster konbinatzeko aukera ematen duena
Hori da dena gaurko
Eskerrik asko amaiera arte irakurtzeagatik!
Hainbat kluster modu eraginkorragoan konektatzen badakizu, esaiguzu.
Zure metodoa gehituko dugu esteketan.
Esker berezia Chris Nesbitt-Smith-i (Chris Nesbitt-Smith) eta Vincent de Sme (Vincent De Smet) (fidagarritasun ingeniariari swatmobile.io) artikulua irakurtzeagatik eta federazioaren funtzionamenduari buruzko informazio erabilgarria partekatzeko.