{"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\/nl\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Hoe clusters van Kubernetes in verschillende datacenters te verbinden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hoe
\nWelkom bij de serie korte handleidingen over Kubernetes.<\/strong> Dit is een reguliere kolom met de meest interessante vragen die we online en tijdens onze trainingen ontvangen. Beantwoord door een Kubernetes-expert.<\/p>\n

<\/p>\n

De expert van vandaag is Daniele Polencic (Daniele Polencic<\/a><\/noindex>). Daniele werkt als instructeur en softwareontwikkelaar bij Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Als u een antwoord op uw vraag wilt krijgen in de volgende post, neem dan contact met ons op via e-mail<\/a><\/noindex> of naar Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Heeft u eerdere berichten gemist? Zoek ze hier<\/a><\/noindex>.<\/p>\n

<\/p>\n

Hoe verbindt u Kubernetes-clusters in verschillende datacentra?<\/h3>\n

<\/p>\n

Kort<\/strong>: Kubefed v2 komt binnenkort uit<\/a><\/noindex>, en ik raad ook aan om te lezen over Shipper<\/a><\/noindex> en het project multi-cluster-scheduler<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Infrastructuur wordt vaak gerepliceerd en verspreid over verschillende regio's, vooral in gecontroleerde omgevingen.<\/p><\/blockquote>\n

Als \u00e9\u00e9n regio niet beschikbaar is, wordt het verkeer omgeleid naar een andere om onderbrekingen te voorkomen.<\/strong><\/p>\n

<\/p>\n

Met Kubernetes kunt u een soortgelijke strategie gebruiken en werkbelasting over verschillende regio's verdelen.<\/p>\n

<\/p>\n

U kunt \u00e9\u00e9n of meerdere clusters hebben per team, regio, omgeving of een combinatie van deze elementen.<\/p>\n

<\/p>\n

Uw clusters kunnen worden gehost in verschillende clouds en op een lokale omgeving.<\/p>\n

<\/p>\n

Maar hoe plant u de infrastructuur voor een dergelijke geografische spreiding?
\nMoet u \u00e9\u00e9n grote cluster cre\u00ebren over meerdere clouds via een enkel netwerk?
\nOf meerdere kleine clusters maken en een manier vinden om deze te beheren en te synchroniseren?<\/em><\/p>\n

<\/p>\n

E\u00e9n leidende cluster<\/h3>\n

<\/p>\n

Een cluster over een enkel netwerk cre\u00ebren is niet zo eenvoudig.<\/em><\/p>\n

<\/p>\n

Stel je voor dat er een storing optreedt, de connectiviteit tussen segmenten van de cluster is verloren gegaan.<\/p>\n

<\/p>\n

Als u \u00e9\u00e9n masterserver heeft, kunnen de helft van de bronnen geen nieuwe opdrachten ontvangen, omdat ze geen contact kunnen opnemen met de master.<\/p>\n

<\/p>\n

En ondertussen heeft u oude routetabellen (kube-proxy<\/code> kan geen nieuwe laden) en geen extra pods (kubelet kan geen updates aanvragen).<\/p>\n

<\/p>\n

Wat nog erger is, als Kubernetes een knooppunt niet ziet, markeert het het als verloren en verspreidt het de ontbrekende pods over de bestaande knooppunten.<\/p>\n

<\/p>\n

U heeft uiteindelijk dubbel zoveel pods.<\/strong><\/p>\n

<\/p>\n

Als u voor elke regio een masterserver maakt, ontstaan er problemen met het consensusalgoritme in de etcd-database. (op. red. \u2014 Eigenlijk hoeft de etcd-database niet per se op de masterservers te staan. Deze kan worden uitgevoerd op een aparte groep servers in dezelfde regio. Dit cre\u00ebert echter wel een enkel punt van falen in de cluster. Maar het is snel.<\/em>)<\/p>\n

<\/p>\n

etcd gebruikt het raft-algoritme<\/a><\/noindex>, om een waarde te bevestigen voordat deze op schijf wordt vastgelegd.
\nDat wil zeggen dat de meeste instanties consensus moeten bereiken voordat de status in etcd kan worden vastgelegd.<\/p>\n

<\/p>\n

Als de vertraging tussen de etcd-instanties plotseling toeneemt, zoals bij drie etcd-instanties in verschillende regio's, duurt het lang om een waarde te bevestigen en deze op schijf vast te leggen.
\nDit heeft ook invloed op de Kubernetes-controllers.<\/p>\n

<\/p>\n

De manager van de controllers heeft meer tijd nodig om op een wijziging te reageren en deze in de database vast te leggen.<\/p>\n

<\/p>\n

En aangezien er niet \u00e9\u00e9n maar meerdere controllers zijn, ontstaat er een kettingreactie en begint de hele cluster erg langzaam te werken.<\/strong>.<\/p>\n

<\/p>\n

etcd is zo gevoelig voor vertraging dat in de offici\u00eble documentatie wordt aanbevolen om SSD's in plaats van gewone harde schijven te gebruiken.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Momenteel bestaan er geen goede voorbeelden van een groot netwerk voor \u00e9\u00e9n cluster.<\/strong><\/p>\n

<\/p>\n

Over het algemeen proberen de ontwikkelaarsgemeenschap en de SIG-clustergroep te begrijpen hoe clusters te orkestreren, net zoals Kubernetes containers orkestreert.<\/p>\n

<\/p>\n

Optie 1: federatie van clusters met kubefed<\/h3>\n

<\/p>\n

Het offici\u00eble antwoord van SIG-cluster is kubefed2, de nieuwe versie van de oorspronkelijke client en operator voor kube federation.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Voor het eerst werd geprobeerd een verzameling clusters als \u00e9\u00e9n object te beheren met behulp van het hulpmiddel kube federation.<\/p>\n

<\/p>\n

Het begin was goed, maar uiteindelijk werd kube federation niet populair, omdat het niet alle bronnen ondersteunde.<\/p>\n

<\/p>\n

Het ondersteunde gecombineerde afleveringen en services, maar bijvoorbeeld geen StatefulSets.
\nBovendien werd de configuratie van de federatie doorgegeven in de vorm van annotaties en had deze niet de noodzakelijke flexibiliteit.<\/p>\n

<\/p>\n

Stel je voor hoe je de splitsing van replica's voor elke cluster in de federatie zou kunnen beschrijven met behulp van slechts enkele annotaties.<\/em><\/p>\n

<\/p>\n

Het resulteerde in totale chaos.<\/strong><\/p>\n

<\/p>\n

SIG-cluster heeft veel werk verzet na kubefed v1 en besloot het probleem vanuit een andere hoek aan te pakken.<\/p>\n

<\/p>\n

In plaats van annotaties besloten ze een controller uit te geven die op de clusters wordt ge\u00efnstalleerd. Deze kan worden geconfigureerd met behulp van Custom Resource Definitions (CRD).<\/strong><\/p>\n

<\/p>\n

Voor elke resource die deel uitmaakt van de federatie, heeft u een aangepaste definitie CRD bestaande uit drie secties:<\/p>\n

<\/p>\n