{"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\/no\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Hvordan koble Kubernetes-klynger i forskjellige datasentre","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvordan
\nVelkommen til en rekke korte guider om Kubernetes.<\/strong> Dette er en regelmessig spalte med de mest interessante sp\u00f8rsm\u00e5lene vi f\u00e5r online og p\u00e5 v\u00e5re kurs. Svar fra Kubernetes-ekspert.<\/p>\n

<\/p>\n

Dagens ekspert er Daniele Polencic (Daniele Polencic<\/a><\/noindex>). Daniele jobber som instrukt\u00f8r og programvareutvikler hos Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Hvis du vil ha svar p\u00e5 sp\u00f8rsm\u00e5let ditt i neste innlegg, kontakt oss via e-post<\/a><\/noindex> eller inn i Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Gikk du glipp av de forrige innleggene? Finn dem her<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hvordan koble Kubernetes-klynger i forskjellige datasentre?<\/h3>\n

<\/p>\n

Kort sagt<\/strong>: kommer Kubefed v2 snart<\/a><\/noindex>, og jeg anbefaler \u00e5 lese om Shipper<\/a><\/noindex> og prosjektet multi-cluster-scheduler.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Det er ganske vanlig at infrastrukturen replikeres og distribueres over forskjellige regioner, spesielt i kontrollerte milj\u00f8er.<\/p><\/blockquote>\n

Hvis \u00e9n region g\u00e5r ned, blir trafikken omdirigert til en annen for \u00e5 unng\u00e5 avbrudd.<\/strong><\/p>\n

<\/p>\n

Med Kubernetes kan vi bruke en lignende strategi og fordele arbeidsbelastninger over forskjellige regioner.<\/p>\n

<\/p>\n

Du kan ha \u00e9n eller flere klynger per team, region, milj\u00f8, eller en kombinasjon av disse elementene.<\/p>\n

<\/p>\n

Klyngene dine kan v\u00e6re plassert i forskjellige skyer og i lokale milj\u00f8er.<\/p>\n

<\/p>\n

Men hvordan planlegger du infrastrukturen for s\u00e5 stort geografisk spredning?
\nBurde du opprette \u00e9n stor klynge over flere skymilj\u00f8er med ett felles nettverk?
\nEller opprette mange sm\u00e5 klynger og finne en m\u00e5te \u00e5 administrere og synkronisere dem p\u00e5?<\/em><\/p>\n

<\/p>\n

\u00c9n styrende klynge<\/h3>\n

<\/p>\n

\u00c5 opprette \u00e9n klynge med ett felles nettverk er ikke s\u00e5 enkelt.<\/em><\/p>\n

<\/p>\n

Tenk deg at du har en feil, og tilkoblingen mellom segmentene av klyngen er tapt.<\/p>\n

<\/p>\n

Hvis du har \u00e9n master-server, vil halve ressursene ikke kunne motta nye kommandoer fordi de ikke kan kontakte masteren.<\/p>\n

<\/p>\n

Og da har du gamle rutetabeller (kube-proxy<\/code> kan ikke laste inn nye) og ingen ekstra pod-er (kubelet kan ikke be om oppdateringer).<\/p>\n

<\/p>\n

Hva verre er, hvis Kubernetes ikke ser noden, merker den den som tapt og fordeler manglende pod-er til eksisterende noder.<\/p>\n

<\/p>\n

Resultatet er at du ender opp med dobbelt s\u00e5 mange pod-er.<\/strong><\/p>\n

<\/p>\n

Hvis du lager \u00e9n master-server i hver region, vil det oppst\u00e5 problemer med algoritmen for \u00e5 oppn\u00e5 konsensus i etcd-databasen.red. \u2014 Faktisk trenger ikke etcd-databasen \u00e5 v\u00e6re p\u00e5 master-serverne. Den kan kj\u00f8res p\u00e5 en egen gruppe servere i \u00e9n region. Men dette f\u00f8rer til et punktsvikt i klyngen. P\u00e5 den positive siden g\u00e5r det raskt.<\/em>)<\/p>\n

<\/p>\n

etcd bruker raft-algoritmen<\/a><\/noindex>, for \u00e5 oppn\u00e5 konsensus f\u00f8r verdien skrives til disk.
\nDet vil si at flertallet av instansene m\u00e5 bli enige f\u00f8r tilstanden kan skrives til etcd.<\/p>\n

<\/p>\n

Hvis forsinkelsen mellom etcd-instansene \u00f8ker betydelig, slik som med tre etcd-instanser i forskjellige regioner, tar det lang tid \u00e5 oppn\u00e5 konsensus og skrive verdien til disk.
\nDette gjenspeiles ogs\u00e5 i Kubernetes-kontrollere.<\/p>\n

<\/p>\n

Kontrollereren trenger mer tid for \u00e5 registrere endringen og skrive svaret til databasen.<\/p>\n

<\/p>\n

Og siden det ikke bare er \u00e9n, men flere controllere, blir det en kjedereaksjon, og hele klyngen begynner \u00e5 fungere veldig sakte.<\/strong>.<\/p>\n

<\/p>\n

etcd er s\u00e5 sensitivt for forsinkelse at den offisielle dokumentasjonen anbefaler \u00e5 bruke SSD-er i stedet for vanlige harddisker.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Det finnes for \u00f8yeblikket ikke gode eksempler p\u00e5 store nettverk for \u00e9n klynge.<\/strong><\/p>\n

<\/p>\n

Hovedsakelig pr\u00f8ver fellesskapet av utviklere og SIG-cluster-gruppen \u00e5 finne ut hvordan man skal orkestrere klynger p\u00e5 samme m\u00e5te som Kubernetes orkestrerer containere.<\/p>\n

<\/p>\n

Alternativ 1: klyngefederasjon med kubefed<\/h3>\n

<\/p>\n

Det offisielle svaret fra SIG-cluster er kubefed2, den nye versjonen av den originale klienten og kube federasjonsoperat\u00f8ren.<\/a><\/noindex>.<\/p>\n

<\/p>\n

For f\u00f8rste gang pr\u00f8vde man \u00e5 administrere en samling klynger som ett objekt med hjelp av verkt\u00f8yet kube federation.<\/p>\n

<\/p>\n

Starten var god, men til slutt ble kube federation ikke popul\u00e6rt fordi det ikke st\u00f8ttet alle ressurser.<\/p>\n

<\/p>\n

Det st\u00f8ttet sammenflettede forsyninger og tjenester, men for eksempel ikke StatefulSets.
\nI tillegg ble konfigurasjonen av fedreasjonen levert som annotasjoner og var ikke spesielt fleksibel.<\/p>\n

<\/p>\n

Tenk deg hvordan man kan beskrive replikeringsdeling for hver klynge i fedreasjonen med bare annotasjoner.<\/em><\/p>\n

<\/p>\n

Det ble et fullstendig kaos.<\/strong><\/p>\n

<\/p>\n

SIG-cluster har gjort et stort arbeid etter kubefed v1 og besluttet \u00e5 n\u00e6rme seg problemet fra en annen vinkel.<\/p>\n

<\/p>\n

I stedet for annotasjoner besluttet de \u00e5 utgi en kontroller som installeres p\u00e5 klyngene. Den kan konfigureres ved hjelp av Custom Resource Definition (CRD).<\/strong><\/p>\n

<\/p>\n

For each resource that will be part of the federation, you have a custom CRD definition consisting of three sections:<\/p>\n

<\/p>\n