{"id":34825,"date":"2019-10-31T22:00:35","date_gmt":"2019-10-31T19:00:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah\/"},"modified":"2019-10-31T22:00:35","modified_gmt":"2019-10-31T19:00:35","slug":"kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Si si lidhin klasterat Kubernetes n\u00eb qendra t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Si
\nMir\u00eb se vini n\u00eb serin\u00eb e udh\u00ebzimeve t\u00eb shkurtra p\u00ebr Kubernetes.<\/strong> Ky \u00ebsht\u00eb nj\u00eb kolumn\u00eb e rregullt me pyetje m\u00eb interesante q\u00eb marrim online dhe n\u00eb trajnimet tona. P\u00ebrgjigjet ekspert i Kubernetes.<\/p>\n

<\/p>\n

Eksperti i sot\u00ebm \u00ebsht\u00eb Daniel Polencic (Daniele Polencic<\/a><\/noindex>). Daniel punon si instruktor dhe zhvillues softueri n\u00eb Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

N\u00ebse d\u00ebshironi t\u00eb merrni p\u00ebrgjigje p\u00ebr pyetjen tuaj n\u00eb postimin e ardhsh\u00ebm, na kontaktoni p\u00ebrmes email-it<\/a><\/noindex> ose n\u00eb Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

E humb\u00ebt postimet e m\u00ebparshme? Shihni ato k\u00ebtu<\/a><\/noindex>.<\/p>\n

<\/p>\n

Si t\u00eb lidhni klasterat Kubernetes n\u00eb qendra t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave?<\/h3>\n

<\/p>\n

Shkurt<\/strong>: kubefed v2 do t\u00eb dal\u00eb s\u00eb shpejti<\/a><\/noindex>, dhe gjithashtu rekomandoj t\u00eb lexoni p\u00ebr Shipper<\/a><\/noindex> dhe projekti multi-cluster-scheduler<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Shpesh, infrastruktura riprodhohet dhe shp\u00ebrndahet n\u00eb rajone t\u00eb ndryshme, ve\u00e7an\u00ebrisht n\u00eb mjedise t\u00eb kontrolluara.<\/p><\/blockquote>\n

N\u00ebse nj\u00eb rajon nuk \u00ebsht\u00eb i qassh\u00ebm, trafiku ridrejtohet n\u00eb nj\u00eb tjet\u00ebr p\u00ebr t\u00eb shmangur ndalesat.<\/strong><\/p>\n

<\/p>\n

Me Kubernetes mund t\u00eb p\u00ebrdorni nj\u00eb strategji t\u00eb ngjashme dhe t\u00eb shp\u00ebrndani ngarkesat e pun\u00ebs n\u00eb rajone t\u00eb ndryshme.<\/p>\n

<\/p>\n

Mund t\u00eb keni nj\u00eb ose disa klastera p\u00ebr ekipin, rajonin, mjedisin, ose p\u00ebr nj\u00eb kombinim t\u00eb k\u00ebtyre elementeve.<\/p>\n

<\/p>\n

Klaster\u00ebt tuaj mund t\u00eb vendosen n\u00eb vende t\u00eb ndryshme cloud dhe n\u00eb ambient lokal.<\/p>\n

<\/p>\n

Por si t\u00eb planifikoni infrastruktur\u00ebn p\u00ebr nj\u00eb shp\u00ebrndarje t\u00eb till\u00eb gjeografike?
\nA duhet t\u00eb krijoni nj\u00eb klaster t\u00eb madh mbi disa cloud n\u00eb nj\u00eb rrjet t\u00eb vet\u00ebm?
\nOse t\u00eb krijoni shum\u00eb klaster\u00eb t\u00eb vegj\u00ebl dhe t\u00eb gjeni nj\u00eb m\u00ebnyr\u00eb p\u00ebr t'i kontrolluar dhe sinkronizuar ato?<\/em><\/p>\n

<\/p>\n

Nj\u00eb klaster udh\u00ebheq\u00ebs<\/h3>\n

<\/p>\n

T\u00eb krijoni nj\u00eb klaster mbi nj\u00eb rrjet t\u00eb vet\u00ebm nuk \u00ebsht\u00eb aq e leht\u00eb.<\/em><\/p>\n

<\/p>\n

Imagjinoni, keni nj\u00eb katastrof\u00eb, \u00ebsht\u00eb humbur lidhja midis segmenteve t\u00eb klasterit.<\/p>\n

<\/p>\n

N\u00ebse keni nj\u00eb server master, gjysma e burimeve nuk do t\u00eb mund t\u00eb merrni komanda t\u00eb reja, sepse nuk do t\u00eb arrij\u00eb t\u00eb lidh\u00ebt me masterin.<\/p>\n

<\/p>\n

Dhe me k\u00ebt\u00eb, keni tabela t\u00eb vjetra t\u00eb rrug\u00ebve (kube-proxy<\/code> nuk mund t\u00eb ngarkoj\u00eb t\u00eb rejat) dhe nuk ka pod t\u00eb tjera (kubelet nuk mund t\u00eb k\u00ebrkoj\u00eb azhurnime).<\/p>\n

<\/p>\n

Ajo q\u00eb \u00ebsht\u00eb m\u00eb keq, n\u00ebse Kubernetes nuk sheh nj\u00eb nyje, ai e etiketon at\u00eb si t\u00eb humbur dhe shp\u00ebrndan pod\u00ebt e munguar n\u00eb nyjat ekzistuese.<\/p>\n

<\/p>\n

Si rezultat, keni dyfish pod-\u00ebsh.<\/strong><\/p>\n

<\/p>\n

N\u00ebse b\u00ebni nga nj\u00eb server master p\u00ebr \u00e7do rajon, do t\u00eb ket\u00eb probleme me algoritmin p\u00ebr arritjen e konsensusit n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave etcd.sh\u00ebn. red. \u2014 N\u00eb fakt, baza e t\u00eb dh\u00ebnave etcd nuk duhet domosdoshm\u00ebrisht t\u00eb ndodhet n\u00eb serverat master. Ajo mund t\u00eb ekzekutohet n\u00eb nj\u00eb grup t\u00eb ve\u00e7ant\u00eb server\u00ebsh n\u00eb nj\u00eb rajon. Megjithat\u00eb, k\u00ebt\u00eb b\u00ebjm\u00eb me nj\u00eb pik\u00eb d\u00ebshtimi t\u00eb klasht\u00ebr. Por \u00ebsht\u00eb e shpejt\u00eb.<\/em>)<\/p>\n

<\/p>\n

etcd p\u00ebrdor algoritmin raft<\/a><\/noindex>, p\u00ebr t\u00eb arritur nj\u00eb marr\u00ebveshje mbi vler\u00ebn, para se ta shkruaj\u00eb at\u00eb n\u00eb disk.
\nK\u00ebshtu, shumica e instancave duhet t\u00eb arrijn\u00eb konsensusin, p\u00ebrpara se gjendja t\u00eb mund t\u00eb shkruhet n\u00eb etcd.<\/p>\n

<\/p>\n

N\u00ebse vonesa midis instancave etcd rritet ndjesh\u00ebm, si n\u00eb rastin e tre instancave etcd n\u00eb rajone t\u00eb ndryshme, merr shum\u00eb koh\u00eb p\u00ebr t\u00eb arritur nj\u00eb marr\u00ebveshje mbi vler\u00ebn dhe p\u00ebr ta shkruar at\u00eb n\u00eb disk.
\nKjo ndikon edhe te kontrolluesit e Kubernetes.<\/p>\n

<\/p>\n

Menaxherit t\u00eb kontrolluesve iu nevojitet m\u00eb shum\u00eb koh\u00eb p\u00ebr t\u00eb m\u00ebsuar mbi ndryshimin dhe p\u00ebr t\u00eb shkruar p\u00ebrgjigjen n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave.<\/p>\n

<\/p>\n

Dhe pasi q\u00eb kontrolluesit nuk jan\u00eb vet\u00ebm nj\u00eb, por disa, at\u00ebher\u00eb ndodh nj\u00eb reaksion zinxhir, dhe i gjith\u00eb klasht\u00ebri fillon t\u00eb punoj\u00eb shum\u00eb ngadal\u00eb.<\/strong>.<\/p>\n

<\/p>\n

etcd \u00ebsht\u00eb aq i ndjesh\u00ebm ndaj vones\u00ebs, saq\u00eb n\u00eb dokumentacionin zyrtar rekomandohet t\u00eb p\u00ebrdoren SSD n\u00eb vend t\u00eb disqeve t\u00eb zakonshme.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Aktualisht nuk ka shembuj t\u00eb mir\u00eb t\u00eb nj\u00eb rrjeti t\u00eb madh p\u00ebr nj\u00eb klasht\u00ebr.<\/strong><\/p>\n

<\/p>\n

N\u00eb p\u00ebrgjith\u00ebsi, komuniteti i zhvilluesve dhe grupi SIG-cluster po p\u00ebrpiqen t\u00eb kuptojn\u00eb se si t\u00eb orkestrojn\u00eb klaster\u00ebt ashtu si Kubernetes orkestrojn\u00eb kontejner\u00ebt.<\/p>\n

<\/p>\n

Opsioni 1: federata e klaster\u00ebve me kubefed<\/h3>\n

<\/p>\n

P\u00ebrgjigjja zyrtare nga SIG-cluster \u2014 kubefed2, versioni i ri i klientit burimor dhe operatorit t\u00eb federat\u00ebs kube<\/a><\/noindex>.<\/p>\n

<\/p>\n

P\u00ebr her\u00eb t\u00eb par\u00eb, p\u00ebr t\u00eb menaxhuar nj\u00eb koleksion klaster\u00ebsh si nj\u00eb objekt t\u00eb vet\u00ebm u provua t\u00eb p\u00ebrdorej mjeti kube federation.<\/p>\n

<\/p>\n

Fillimi ishte i mir\u00eb, por n\u00eb fund kube federation nuk u b\u00eb popullor, sepse mb\u00ebshteste jo t\u00eb gjitha burimet.<\/p>\n

<\/p>\n

Ai mb\u00ebshteti \u00e7mimet e bashkuara dhe sh\u00ebrbimet, por, p\u00ebr shembull, jo StatefulSets.
\nPo ashtu, konfigurimi i federat\u00ebs ishte i transmetuar n\u00eb form\u00eb anotacionesh dhe nuk ishte fleksib\u00ebl.<\/p>\n

<\/p>\n

Imagjinoni se si mund t\u00eb p\u00ebrshkruhet ndarja e replicave p\u00ebr \u00e7do klaster n\u00eb federat\u00eb duke p\u00ebrdorur vet\u00ebm anotacione.<\/em><\/p>\n

<\/p>\n

K\u00ebshtu u krijua nj\u00eb kaos i plot\u00eb.<\/strong><\/p>\n

<\/p>\n

SIG-cluster b\u00ebri nj\u00eb pun\u00eb t\u00eb madhe pas kubefed v1 dhe vendosi t\u00eb qaset problemit nga nj\u00eb k\u00ebndv\u00ebshtrim tjet\u00ebr.<\/p>\n

<\/p>\n

N\u00eb vend t\u00eb anotacioneve, ata vendos\u00ebn t\u00eb l\u00ebshonin nj\u00eb kontrollues q\u00eb instalohet n\u00eb klaster\u00ebt. Ai mund t\u00eb konfigurohet me definicionet e burimeve t\u00eb personalizuara (Custom Resource Definition, CRD).<\/strong><\/p>\n

<\/p>\n

P\u00ebr \u00e7do burim q\u00eb do t\u00eb jet\u00eb pjes\u00eb e federat\u00ebs, keni nj\u00eb p\u00ebrcaktim t\u00eb personalizuar CRD me tri seksione:<\/p>\n

<\/p>\n