{"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\/pl\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Jak po\u0142\u0105czy\u0107 klastry Kubernetes w r\u00f3\u017cnych centrach danych","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Jak
\nWitamy w serii kr\u00f3tkich przewodnik\u00f3w po Kubernetes.<\/strong> To regularna rubryka z najciekawszymi pytaniami, kt\u00f3re otrzymujemy online i podczas naszych szkole\u0144. Odpowiada ekspert od Kubernetes.<\/p>\n

<\/p>\n

Dzisiejszy ekspert \u2014 Daniel Polencic (Daniele Polencic<\/a><\/noindex>). Daniel pracuje jako instruktor i programista w Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Je\u015bli chcesz otrzyma\u0107 odpowied\u017a na swoje pytanie w nast\u0119pnej publikacji, skontaktuj si\u0119 z nami drog\u0105 mailow\u0105<\/a><\/noindex> lub na Twitterze: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Przegapi\u0142e\u015b poprzednie posty? Szukaj ich tutaj<\/a><\/noindex>.<\/p>\n

<\/p>\n

Jak po\u0142\u0105czy\u0107 klastry Kubernetes w r\u00f3\u017cnych data center?<\/h3>\n

<\/p>\n

Kr\u00f3tko<\/strong>: wkr\u00f3tce wychodzi Kubefed v2<\/a><\/noindex>, a tak\u017ce polecam przeczyta\u0107 o Shipper<\/a><\/noindex> i projekcie multi-cluster-scheduler.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Bardzo cz\u0119sto infrastruktura jest replikowana i rozdzielana na r\u00f3\u017cne regiony, szczeg\u00f3lnie w kontrolowanych \u015brodowiskach.<\/p><\/blockquote>\n

Je\u015bli jeden region jest niedost\u0119pny, ruch jest przekierowywany do innego, aby unikn\u0105\u0107 przestoj\u00f3w.<\/strong><\/p>\n

<\/p>\n

Z Kubernetes mo\u017cna u\u017cywa\u0107 podobnej strategii i rozdziela\u0107 obci\u0105\u017cenia robocze na r\u00f3\u017cne regiony.<\/p>\n

<\/p>\n

Mo\u017cesz mie\u0107 jeden lub kilka klastr\u00f3w na zesp\u00f3\u0142, region, \u015brodowisko lub kombinacj\u0119 tych element\u00f3w.<\/p>\n

<\/p>\n

Twoje klastry mog\u0105 by\u0107 hostowane w r\u00f3\u017cnych chmurach i w lokalnym \u015brodowisku.<\/p>\n

<\/p>\n

Ale jak zaplanowa\u0107 infrastruktur\u0119 dla takiego geograficznego rozrzutu?
\nCzy nale\u017cy stworzy\u0107 jeden du\u017cy klaster w kilku chmurach w jednej sieci?
\nCzy mo\u017ce lepiej utworzy\u0107 wiele ma\u0142ych klastr\u00f3w i znalezienie sposobu na ich kontrolowanie i synchronizowanie?<\/em><\/p>\n

<\/p>\n

Jeden klaster nadrz\u0119dny<\/h3>\n

<\/p>\n

Utworzenie jednego klastra w jednej sieci nie jest takie proste.<\/em><\/p>\n

<\/p>\n

Wyobra\u017a sobie, \u017ce masz awari\u0119 i utracon\u0105 \u0142\u0105czno\u015b\u0107 mi\u0119dzy segmentami klastra.<\/p>\n

<\/p>\n

Je\u015bli masz jednego mastera, po\u0142owa zasob\u00f3w nie mo\u017ce otrzyma\u0107 nowych polece\u0144, poniewa\u017c nie uda im si\u0119 po\u0142\u0105czy\u0107 z masterem.<\/p>\n

<\/p>\n

A przy tym masz stare tabele routingu (kube-proxy<\/code> nie mo\u017ce za\u0142adowa\u0107 nowych) i \u017cadnych dodatkowych pod\u00f3w (kubelet nie mo\u017ce \u017c\u0105da\u0107 aktualizacji).<\/p>\n

<\/p>\n

Co gorsza, je\u015bli Kubernetes nie widzi w\u0119z\u0142a, oznacza go jako utracony i rozdziela brakuj\u0105ce pody pomi\u0119dzy istniej\u0105cymi w\u0119z\u0142ami.<\/p>\n

<\/p>\n

W rezultacie masz dwa razy wi\u0119cej pod\u00f3w.<\/strong><\/p>\n

<\/p>\n

Je\u015bli utworzysz po jednym masterze w ka\u017cdym regionie, b\u0119d\u0105 problemy z algorytmem osi\u0105gania konsensusu w bazie danych etcd.przyp. red. \u2014 W rzeczywisto\u015bci baza danych etcd nie musi znajdowa\u0107 si\u0119 na serwerach master. Mo\u017cna j\u0105 uruchomi\u0107 na osobnej grupie serwer\u00f3w w jednym regionie. Wprawdzie w takim przypadku powstaje punkt awarii klastra. Ale dzia\u0142a szybko.<\/em>)<\/p>\n

<\/p>\n

etcd u\u017cywa algorytmu raft<\/a><\/noindex>, aby uzgodni\u0107 warto\u015b\u0107, zanim zapisze j\u0105 na dysku.
\nTo znaczy, \u017ce wi\u0119kszo\u015b\u0107 instancji musi osi\u0105gn\u0105\u0107 konsensus, zanim stan b\u0119dzie mo\u017cna zapisa\u0107 w etcd.<\/p>\n

<\/p>\n

Je\u015bli op\u00f3\u017anienie mi\u0119dzy instancjami etcd nagle wzrasta, jak w przypadku trzech instancji etcd w r\u00f3\u017cnych regionach, zajmuje to du\u017co czasu, aby uzgodni\u0107 warto\u015b\u0107 i zapisa\u0107 j\u0105 na dysku.
\nTo ma r\u00f3wnie\u017c wp\u0142yw na kontrolery Kubernetes.<\/p>\n

<\/p>\n

Menad\u017cer kontroler\u00f3w potrzebuje wi\u0119cej czasu, aby dowiedzie\u0107 si\u0119 o zmianie i zapisa\u0107 odpowied\u017a w bazie danych.<\/p>\n

<\/p>\n

A poniewa\u017c kontroler\u00f3w jest wi\u0119cej ni\u017c jeden, powstaje reakcja \u0142a\u0144cuchowa, a ca\u0142y klaster zaczyna dzia\u0142a\u0107 bardzo wolno.<\/strong>.<\/p>\n

<\/p>\n

etcd jest tak wra\u017cliwy na op\u00f3\u017anienia, \u017ce w oficjalnej dokumentacji zaleca si\u0119 u\u017cycie SSD zamiast tradycyjnych dysk\u00f3w twardych.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Obecnie nie ma dobrych przyk\u0142ad\u00f3w du\u017cej sieci dla jednego klastra.<\/strong><\/p>\n

<\/p>\n

G\u0142\u00f3wnie spo\u0142eczno\u015b\u0107 deweloper\u00f3w i grupa SIG-cluster staraj\u0105 si\u0119 zrozumie\u0107, jak orkiestracja klastr\u00f3w dzia\u0142a podobnie jak orkiestracja kontener\u00f3w w Kubernetes.<\/p>\n

<\/p>\n

Opcja 1: federacja klastr\u00f3w z kubefed<\/h3>\n

<\/p>\n

Oficjalna odpowied\u017a od SIG-cluster to kubefed2, nowa wersja klienta \u017ar\u00f3d\u0142owego i operatora kube federation.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Po raz pierwszy pr\u00f3bowano zarz\u0105dza\u0107 kolekcj\u0105 klastr\u00f3w jako jednym obiektem przy u\u017cyciu narz\u0119dzia kube federation.<\/p>\n

<\/p>\n

Pocz\u0105tek by\u0142 obiecuj\u0105cy, ale ostatecznie kube federation nie zdoby\u0142 popularno\u015bci, poniewa\u017c nie obs\u0142ugiwa\u0142 wszystkich zasob\u00f3w.<\/p>\n

<\/p>\n

Obs\u0142ugiwa\u0142 zbiory zewn\u0119trzne i us\u0142ugi, ale na przyk\u0142ad nie StatefulSets.
\nPonadto konfiguracja federacji by\u0142a przekazywana w postaci adnotacji i nie r\u00f3\u017cni\u0142a si\u0119 elastyczno\u015bci\u0105.<\/p>\n

<\/p>\n

Wyobra\u017a sobie, jak mo\u017cna opisa\u0107 podzia\u0142 replik dla ka\u017cdego klastra w federacji za pomoc\u0105 tylko jednych adnotacji.<\/em><\/p>\n

<\/p>\n

Powsta\u0142 kompletny ba\u0142agan.<\/strong><\/p>\n

<\/p>\n

SIG-cluster wykona\u0142 du\u017c\u0105 prac\u0119 po wersji kubefed v1 i postanowi\u0142 podej\u015b\u0107 do problemu z innej strony.<\/p>\n

<\/p>\n

Zamiast adnotacji zdecydowali si\u0119 na wydanie kontrolera, kt\u00f3ry zostaje zainstalowany na klastrach. Mo\u017cna go konfigurowa\u0107 za pomoc\u0105 niestandardowych definicji zasob\u00f3w (Custom Resource Definition, CRD).<\/strong><\/p>\n

<\/p>\n

Dla ka\u017cdego zasobu, kt\u00f3ry wejdzie do federacji, masz do dyspozycji niestandardow\u0105 definicj\u0119 CRD sk\u0142adaj\u0105c\u0105 si\u0119 z trzech sekcji:<\/p>\n

<\/p>\n