{"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\/da\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"S\u00e5dan forbinder du Kubernetes-klynger i forskellige datacentre","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"S\u00e5dan
\nVelkommen til en serie af korte vejledninger om Kubernetes.<\/strong> Dette er en regelm\u00e6ssig kolonne med de mest interessante sp\u00f8rgsm\u00e5l, vi modtager online og p\u00e5 vores tr\u00e6ninger. Besvaret af en Kubernetes-ekspert.<\/p>\n

<\/p>\n

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

Hvis du vil have svar p\u00e5 dit sp\u00f8rgsm\u00e5l i det n\u00e6ste indl\u00e6g, kan du kontakte os via e-mail<\/a><\/noindex> eller p\u00e5 Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Gik du glip af de tidligere indl\u00e6g? Find dem her<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hvordan forbinder man Kubernetes-klynger i forskellige datacentre?<\/h3>\n

<\/p>\n

Kort fortalt<\/strong>: kommer Kubefed v2 snart<\/a><\/noindex>, og jeg anbefaler ogs\u00e5 at l\u00e6se om Shipper<\/a><\/noindex> og projektet multi-cluster-scheduler<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Ofte bliver infrastrukturen replikeret og distribueret p\u00e5 tv\u00e6rs af forskellige regioner, is\u00e6r i kontrollerede milj\u00f8er.<\/p><\/blockquote>\n

Hvis \u00e9n region er utilg\u00e6ngelig, omdirigeres trafikken til en anden for at undg\u00e5 nedetid.<\/strong><\/p>\n

<\/p>\n

Med Kubernetes kan du bruge en lignende strategi og fordele arbejdsbelastninger p\u00e5 tv\u00e6rs af forskellige regioner.<\/p>\n

<\/p>\n

Du kan have en eller flere klynger pr. team, region, milj\u00f8 eller en kombination af disse elementer.<\/p>\n

<\/p>\n

Dine klynger kan v\u00e6re placeret i forskellige cloud-tjenester og lokalt.<\/p>\n

<\/p>\n

Men hvordan planl\u00e6gger man infrastrukturen til en s\u00e5dan geografisk spredning?
\nSkal man skabe en stor klynge p\u00e5 tv\u00e6rs af flere cloud-milj\u00f8er med et samlet netv\u00e6rk?
\nEller skal man oprette mange sm\u00e5 klynger og finde en m\u00e5de at kontrollere og synkronisere dem p\u00e5?<\/em><\/p>\n

<\/p>\n

En ledende klynge<\/h3>\n

<\/p>\n

At oprette en klynge p\u00e5 et samlet netv\u00e6rk er ikke s\u00e5 nemt.<\/em><\/p>\n

<\/p>\n

Forestil dig, at der sker en uheld, og forbindelsen mellem segmenterne i klyngen er tabt.<\/p>\n

<\/p>\n

Hvis du har \u00e9n masterserver, vil halvdelen af ressourcerne ikke kunne modtage nye kommandoer, fordi de ikke kan oprette forbindelse til masteren.<\/p>\n

<\/p>\n

Og p\u00e5 samme tid har du gamle routing-tabeller (kube-proxy<\/code> kan ikke hente nye) og ingen ekstra pods (kubelet kan ikke anmode om opdateringer).<\/p>\n

<\/p>\n

Det bliver endnu v\u00e6rre; hvis Kubernetes ikke ser en node, markerer den den som tabt og fordeler de manglende pods til de eksisterende noder.<\/p>\n

<\/p>\n

Resultatet er, at du har dobbelt s\u00e5 mange pods.<\/strong><\/p>\n

<\/p>\n

Hvis du opretter \u00e9n masterserver for hver region, vil der v\u00e6re problemer med consensus-algoritmen i etcd-databasen.bem. red. \u2014 Faktisk skal et etcd-database ikke n\u00f8dvendigvis v\u00e6re p\u00e5 masterserverne. Den kan k\u00f8re p\u00e5 en separat gruppe servere i en region. Men s\u00e5 f\u00e5r man ogs\u00e5 et punkt for klyngefejl. Men det er hurtigt.<\/em>)<\/p>\n

<\/p>\n

etcd bruger raft-algoritmen<\/a><\/noindex>, for at blive enige om v\u00e6rdien, f\u00f8r den skrives til disk.
\nDet vil sige, at de fleste instanser skal opn\u00e5 konsensus, f\u00f8r tilstanden kan skrives til etcd.<\/p>\n

<\/p>\n

Hvis forsinkelsen mellem etcd-instanserne pludselig stiger, som i tilf\u00e6ldet med tre etcd-instanser i forskellige regioner, tager det lang tid at blive enige om v\u00e6rdien og skrive den til disk.
\nDette p\u00e5virker ogs\u00e5 Kubernetes-controllere.<\/p>\n

<\/p>\n

Controller-manageren har brug for mere tid til at registrere \u00e6ndringen og skrive svaret til databasen.<\/p>\n

<\/p>\n

Og eftersom der ikke kun er \u00e9n controller, men flere, giver det en k\u00e6dereaktion, og hele klyngen begynder at arbejde meget langsomt.<\/strong>.<\/p>\n

<\/p>\n

etcd er s\u00e5 f\u00f8lsom over for forsinkelse, at det i den officielle dokumentation anbefales at bruge SSD i stedet for almindelige harddiske.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Der findes i \u00f8jeblikket ikke gode eksempler p\u00e5 et stort netv\u00e6rk for \u00e9n klynge.<\/strong><\/p>\n

<\/p>\n

Generelt fors\u00f8ger udviklerf\u00e6llesskabet og SIG-cluster-gruppen at finde ud af, hvordan man orkestrerer klynger, p\u00e5 samme m\u00e5de som Kubernetes orkestrerer containere.<\/p>\n

<\/p>\n

Mulighed 1: klyngefederation med kubefed.<\/h3>\n

<\/p>\n

Det officielle svar fra SIG-cluster er, kubefed2, den nye version af den originale klient og kube federation-operator.<\/a><\/noindex>.<\/p>\n

<\/p>\n

For f\u00f8rste gang fors\u00f8gte man at administrere en samling klynger som \u00e9n enhed ved hj\u00e6lp af v\u00e6rkt\u00f8jet kube federation.<\/p>\n

<\/p>\n

Starten var god, men til slut blev kube federation ikke popul\u00e6r, fordi den ikke underst\u00f8ttede alle ressourcer.<\/p>\n

<\/p>\n

Den underst\u00f8ttede sammenflettede distributionsmetoder og tjenester, men for eksempel ikke StatefulSets.
\nOg desuden blev konfigurationen af federation overf\u00f8rt i form af annotationer, hvilket ikke var s\u00e6rligt fleksibelt.<\/p>\n

<\/p>\n

Forestil dig, hvordan man kan beskrive opdeling af replikaer for hver klynge i federation ved hj\u00e6lp af kun annotationer.<\/em><\/p>\n

<\/p>\n

Det blev en fuldst\u00e6ndig rod.<\/strong><\/p>\n

<\/p>\n

SIG-cluster har lavet et stort stykke arbejde efter kubefed v1 og besluttede at tage en anden tilgang til problemet.<\/p>\n

<\/p>\n

I stedet for annotationer besluttede de at udgive en controller, der installeres p\u00e5 klyngerne. Den kan konfigureres med brugerdefinerede ressourceoplysninger (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