{"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\/ro\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Cum s\u0103 conecta\u021bi clustere Kubernetes \u00een centre de date diferite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cum
\nBine a\u021bi venit la seria de ghiduri scurte despre Kubernetes.<\/strong> Aceasta este o coloan\u0103 regulat\u0103 cu cele mai interesante \u00eentreb\u0103ri pe care le primim online \u0219i la cursurile noastre. R\u0103spunde un expert \u00een Kubernetes.<\/p>\n

<\/p>\n

Expertul de ast\u0103zi este Daniele Polencic (Daniele Polencic<\/a><\/noindex>). Daniele este instructor \u0219i dezvoltator de software la Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Dac\u0103 dori\u021bi s\u0103 primi\u021bi un r\u0103spuns la \u00eentrebarea dvs. \u00een urm\u0103toarea postare, contacta\u021bi-ne prin e-mail<\/a><\/noindex> sau pe Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

A\u021bi ratat post\u0103rile anterioare? Le c\u0103uta\u021bi aici<\/a><\/noindex>.<\/p>\n

<\/p>\n

Cum s\u0103 conecta\u021bi clustere Kubernetes \u00een diferite centre de date?<\/h3>\n

<\/p>\n

Pe scurt<\/strong>: Kubefed v2 va fi disponibil \u00een cur\u00e2nd<\/a><\/noindex>, de asemenea, v\u0103 recomand s\u0103 citi\u021bi despre Shipper<\/a><\/noindex> \u0219i proiectul multi-cluster-scheduler<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Destul de frecvent, infrastructura este replicat\u0103 \u0219i distribuit\u0103 \u00een diferite regiuni, \u00een special \u00een medii controlate.<\/p><\/blockquote>\n

Dac\u0103 o regiune devine indisponibil\u0103, traficul este redirec\u021bionat c\u0103tre alta pentru a evita \u00eentreruperile.<\/strong><\/p>\n

<\/p>\n

Cu Kubernetes, se poate folosi o strategie similar\u0103 \u0219i distribuirea sarcinilor de lucru \u00een diferite regiuni.<\/p>\n

<\/p>\n

Pute\u021bi avea un singur cluster sau mai multe pentru echip\u0103, regiune, mediu sau o combina\u021bie a acestor elemente.<\/p>\n

<\/p>\n

Clusterele dvs. pot fi g\u0103zduite \u00een diferite cloud-uri \u0219i \u00een medii locale.<\/p>\n

<\/p>\n

Dar cum s\u0103 planifica\u021bi infrastructura pentru o astfel de dispersie geografic\u0103?
\nEste necesar s\u0103 crea\u021bi un singur cluster mare pe mai multe cloud-uri printr-o re\u021bea unitar\u0103?
\nSau s\u0103 crea\u021bi multe clustere mici \u0219i s\u0103 g\u0103si\u021bi o modalitate de a le controla \u0219i sincroniza?<\/em><\/p>\n

<\/p>\n

Un cluster de conducere<\/h3>\n

<\/p>\n

Crearea unui singur cluster pe o re\u021bea unitar\u0103 nu este at\u00e2t de simpl\u0103.<\/em><\/p>\n

<\/p>\n

Imagina\u021bi-v\u0103 c\u0103 ave\u021bi o defec\u021biune, pierderea conectivit\u0103\u021bii \u00eentre segmentele cluster-ului.<\/p>\n

<\/p>\n

Dac\u0103 ave\u021bi un singur server master, jum\u0103tate din resurse nu vor putea primi comenzi noi, deoarece nu pot comunica cu masterul.<\/p>\n

<\/p>\n

\u0218i \u00een acest caz, ave\u021bi vechile tabele de rutare (kube-proxy<\/code> nu poate \u00eenc\u0103rca altele noi) \u0219i f\u0103r\u0103 pod-uri suplimentare (kubelet nu poate solicita actualiz\u0103ri).<\/p>\n

<\/p>\n

Ce este \u0219i mai r\u0103u, dac\u0103 Kubernetes nu vede un nod, \u00eel marcheaz\u0103 ca fiind pierdut \u0219i redistribuie pod-urile lips\u0103 pe nodurile existente.<\/p>\n

<\/p>\n

\u00cen cele din urm\u0103, ve\u021bi avea de dou\u0103 ori mai multe pod-uri.<\/strong><\/p>\n

<\/p>\n

Dac\u0103 face\u021bi c\u00e2te un server master pentru fiecare regiune, vor ap\u0103rea probleme cu algoritmul de atingere a consensului \u00een baza de date etcd. (editorial note \u2014 De fapt, baza de date etcd nu trebuie s\u0103 fie neap\u0103rat pe serverele master. Poate fi lansat\u0103 pe un grup separat de servere \u00eentr-o singur\u0103 regiune. Totu\u0219i, acest lucru va crea un punct de e\u0219ec al clusterei. \u00cen schimb, va fi rapid.<\/em>)<\/p>\n

<\/p>\n

etcd folose\u0219te algoritmul raft<\/a><\/noindex>, pentru a conveni asupra unei valori \u00eenainte de a o scrie pe disc.
\nAsta \u00eenseamn\u0103 c\u0103 majoritatea instan\u021belor trebuie s\u0103 ajung\u0103 la un consens \u00eenainte ca starea s\u0103 poat\u0103 fi scris\u0103 \u00een etcd.<\/p>\n

<\/p>\n

Dac\u0103 \u00eent\u00e2rzierile \u00eentre instan\u021bele etcd cresc brusc, cum ar fi \u00een cazul a trei instan\u021be etcd \u00een regiuni diferite, este nevoie de mult timp pentru a consensualiza valoarea \u0219i a o scrie pe disc.
\nAcest lucru se reflect\u0103 \u0219i \u00een controlerele Kubernetes.<\/p>\n

<\/p>\n

Managerul de controlere are nevoie de mai mult timp pentru a r\u0103spunde la modific\u0103ri \u0219i a scrie r\u0103spunsul \u00een baza de date.<\/p>\n

<\/p>\n

\u0218i, av\u00e2nd \u00een vedere c\u0103 nu este un singur controler, ci mai multe, se produce un efect de reac\u021bie \u00een lan\u021b, iar \u00eentreaga cluster devine foarte lent\u0103<\/strong>.<\/p>\n

<\/p>\n

etcd este at\u00e2t de sensibil la \u00eent\u00e2rzieri \u00eenc\u00e2t \u00een documenta\u021bia oficial\u0103 se recomand\u0103 utilizarea SSD-urilor \u00een loc de hard disk-uri obi\u0219nuite.<\/a><\/noindex>.<\/p>\n

<\/p>\n

\u00cen prezent, nu exist\u0103 exemple bune de re\u021bea mare pentru un singur cluster.<\/strong><\/p>\n

<\/p>\n

\u00cen principal, comunitatea de dezvoltatori \u0219i grupul SIG-cluster \u00eencearc\u0103 s\u0103 \u00een\u021beleag\u0103 cum s\u0103 orchestreze clusterele a\u0219a cum Kubernetes orchestreaz\u0103 containerele.<\/p>\n

<\/p>\n

Varianta 1: federa\u021bia clusterelor cu kubefed<\/h3>\n

<\/p>\n

R\u0103spunsul oficial din partea SIG-cluster este kubefed2, noua versiune a clientului surs\u0103 \u0219i operatorului kube federation<\/a><\/noindex>.<\/p>\n

<\/p>\n

Pentru prima dat\u0103, gestionarea unei colec\u021bii de clustere ca un singur obiect a fost \u00eencercat\u0103 cu ajutorul instrumentului kube federation.<\/p>\n

<\/p>\n

\u00cenceputul a fost promi\u021b\u0103tor, dar \u00een cele din urm\u0103 kube federation nu a devenit popular, deoarece nu suporta toate resursele.<\/p>\n

<\/p>\n

Sus\u021binea livr\u0103rile \u0219i serviciile combinate, dar, de exemplu, nu suporta StatefulSets.
\n\u00cen plus, configura\u021bia federa\u021biei era transmis\u0103 sub form\u0103 de anot\u0103ri \u0219i nu era flexibil\u0103.<\/p>\n

<\/p>\n

Imagina\u021bi-v\u0103 cum s-ar putea descrie separarea replicilor pentru fiecare cluster \u00een federa\u021bie folosind doar anot\u0103ri.<\/em><\/p>\n

<\/p>\n

A rezultat un haos total.<\/strong><\/p>\n

<\/p>\n

SIG-cluster a depus mult efort dup\u0103 kubefed v1 \u0219i a decis s\u0103 abordeze problema dintr-o alt\u0103 direc\u021bie.<\/p>\n

<\/p>\n

\u00cen loc de anot\u0103ri, au decis s\u0103 lanseze un controller care se instaleaz\u0103 pe clustere. Acesta poate fi configurat folosind defini\u021bii de resurse personalizate (Custom Resource Definition, CRD).<\/strong><\/p>\n

<\/p>\n

Pentru fiecare resurs\u0103 care va face parte din federa\u021bie, ave\u021bi o defini\u021bie CRD personalizat\u0103 din trei sec\u021biuni:<\/p>\n

<\/p>\n