{"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\/de\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Wie man Kubernetes-Cluster in verschiedenen Rechenzentren verbindet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wie
\nWillkommen zu unserer Reihe kurzer Leitf\u00e4den zu Kubernetes.<\/strong> Das ist eine regelm\u00e4\u00dfige Kolonne mit den interessantesten Fragen, die wir online und in unseren Schulungen erhalten. Beantwortet von einem Kubernetes-Experten.<\/p>\n

<\/p>\n

Der heutige Experte ist Daniele Polencic (Daniele Polencic<\/a><\/noindex>). Daniele ist Ausbilder und Softwareentwickler bei Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Wenn Sie eine Antwort auf Ihre Frage im n\u00e4chsten Beitrag erhalten m\u00f6chten, kontaktieren Sie uns per E-Mail<\/a><\/noindex> oder auf Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Haben Sie die vorherigen Beitr\u00e4ge verpasst? Suchen Sie sie hier<\/a><\/noindex>.<\/p>\n

<\/p>\n

Wie man Kubernetes-Cluster in verschiedenen Rechenzentren verbindet?<\/h3>\n

<\/p>\n

Kurz<\/strong>: bald erscheint Kubefed v2<\/a><\/noindex>, und ich empfehle auch, \u00fcber das Shipper<\/a><\/noindex> und Projekt multi-cluster-scheduler zu lesen.<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Infrastrukturen werden ziemlich h\u00e4ufig repliziert und \u00fcber verschiedene Regionen verteilt, besonders in kontrollierten Umgebungen.<\/p><\/blockquote>\n

Wenn eine Region nicht verf\u00fcgbar ist, wird der Verkehr in eine andere umgeleitet, um Ausf\u00e4lle zu vermeiden.<\/strong><\/p>\n

<\/p>\n

Mit Kubernetes kann man eine \u00e4hnliche Strategie verwenden und Arbeitslasten \u00fcber verschiedene Regionen verteilen.<\/p>\n

<\/p>\n

Sie k\u00f6nnen ein oder mehrere Cluster pro Team, Region, Umgebung oder eine Kombination dieser Elemente haben.<\/p>\n

<\/p>\n

Ihre Cluster k\u00f6nnen in verschiedenen Clouds und vor Ort gehostet werden.<\/p>\n

<\/p>\n

Aber wie plant man die Infrastruktur f\u00fcr eine solche geografische Verteilung?
\nSoll man ein gro\u00dfes Cluster \u00fcber mehrere Clouds in einem einheitlichen Netzwerk erstellen?
\nOder viele kleine Cluster einrichten und einen Weg finden, diese zu steuern und zu synchronisieren?<\/em><\/p>\n

<\/p>\n

Ein zentrales Cluster<\/h3>\n

<\/p>\n

Es ist nicht so einfach, ein Cluster \u00fcber ein einheitliches Netzwerk zu erstellen.<\/em><\/p>\n

<\/p>\n

Stellen Sie sich vor, Sie haben einen Ausfall, und die Konnektivit\u00e4t zwischen den Segmenten des Clusters geht verloren.<\/p>\n

<\/p>\n

Wenn Sie einen Master-Server haben, k\u00f6nnen die H\u00e4lfte der Ressourcen keine neuen Befehle erhalten, da sie nicht in der Lage sind, Kontakt mit dem Master aufzunehmen.<\/p>\n

<\/p>\n

Und dabei haben Sie alte Routing-Tabellen (kube-proxy<\/code> kann die neuen nicht laden) und keine zus\u00e4tzlichen Pods (kubelet kann keine Updates anfordern).<\/p>\n

<\/p>\n

Was noch schlimmer ist, wenn Kubernetes einen Knoten nicht sieht, markiert er ihn als verloren und verteilt die fehlenden Pods auf existierende Knoten.<\/p>\n

<\/p>\n

Am Ende haben Sie doppelt so viele Pods.<\/strong><\/p>\n

<\/p>\n

Wenn Sie f\u00fcr jede Region einen Master-Server einrichten, gibt es Probleme mit dem Konsensalgorithmus in der etcd-Datenbank. (Hinweis des Redakteurs \u2014 Tats\u00e4chlich muss die etcd-Datenbank nicht unbedingt auf den Master-Servern laufen. Sie kann in einer separaten Gruppe von Servern in einer Region gestartet werden. Allerdings erh\u00e4lt man dabei einen einzelnen Ausfallpunkt f\u00fcr das Cluster. Daf\u00fcr geht es schnell.<\/em>)<\/p>\n

<\/p>\n

etcd verwendet den Raft-Algorithmus<\/a><\/noindex>, um den Wert zu vereinbaren, bevor er auf der Festplatte gespeichert wird.
\nDas bedeutet, dass die meisten Instanzen einen Konsens erreichen m\u00fcssen, bevor der Zustand in etcd gespeichert werden kann.<\/p>\n

<\/p>\n

Wenn die Verz\u00f6gerung zwischen den etcd-Instanzen stark ansteigt, wie im Fall von drei etcd-Instanzen in verschiedenen Regionen, dauert es lange, um einen Wert zu vereinbaren und auf die Festplatte zu schreiben.
\nDas wirkt sich auch auf die Kubernetes-Controller aus.<\/p>\n

<\/p>\n

Der Controller-Manager ben\u00f6tigt mehr Zeit, um \u00fcber \u00c4nderungen informiert zu werden und die Antwort in die Datenbank zu schreiben.<\/p>\n

<\/p>\n

Da es nicht nur einen Controller, sondern mehrere gibt, entsteht eine Kettenreaktion, und das gesamte Cluster beginnt, sehr langsam zu arbeiten.<\/strong>.<\/p>\n

<\/p>\n

etcd ist so empfindlich gegen\u00fcber Verz\u00f6gerungen, dass in der offiziellen Dokumentation empfohlen wird, SSDs anstelle von herk\u00f6mmlichen Festplatten zu verwenden.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Derzeit gibt es keine guten Beispiele f\u00fcr ein gro\u00dfes Netzwerk mit einem einzigen Cluster.<\/strong><\/p>\n

<\/p>\n

Im Wesentlichen versuchen die Entwicklergemeinschaft und die SIG-cluster-Gruppe herauszufinden, wie man Cluster orchestrieren kann, \u00e4hnlich wie Kubernetes Container orchestriert.<\/p>\n

<\/p>\n

Option 1: Cluster-F\u00f6deration mit kubefed<\/h3>\n

<\/p>\n

Die offizielle Antwort der SIG-cluster lautet \u2014 kubefed2, die neue Version des urspr\u00fcnglichen Clients und Operators f\u00fcr die Kube-F\u00f6deration.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Zum ersten Mal versuchte man mit dem Kube-F\u00f6deration-Tool, eine Sammlung von Clustern als ein einziges Objekt zu verwalten.<\/p>\n

<\/p>\n

Der Anfang war vielversprechend, aber letztendlich wurde Kube-F\u00f6deration nicht popul\u00e4r, weil nicht alle Ressourcen unterst\u00fctzt wurden.<\/p>\n

<\/p>\n

Es unterst\u00fctzte zusammengef\u00fchrte Bereitstellungen und Dienste, aber zum Beispiel keine StatefulSets.
\nZudem wurde die Konfiguration der F\u00f6deration in Form von Anmerkungen \u00fcbermittelt und war nicht besonders flexibel.<\/p>\n

<\/p>\n

Stellen Sie sich vor, wie man die Replikation f\u00fcr jeden Cluster in der F\u00f6deration mithilfe von Anmerkungen beschreiben kann.<\/em><\/p>\n

<\/p>\n

Das f\u00fchrte zu einem v\u00f6lligen Durcheinander.<\/strong><\/p>\n

<\/p>\n

Die SIG-cluster hat nach kubefed v1 viel Arbeit geleistet und beschlossen, das Problem von einer anderen Seite anzugehen.<\/p>\n

<\/p>\n

Anstatt Anmerkungen zu verwenden, entschieden sie sich, einen Controller zu ver\u00f6ffentlichen, der in den Clustern installiert wird. Dieser kann mit benutzerdefinierten Ressourcendefinitionen (Custom Resource Definition, CRD) konfiguriert werden.<\/strong><\/p>\n

<\/p>\n

F\u00fcr jede Ressource, die in die F\u00f6deration aufgenommen wird, haben Sie eine benutzerdefinierte CRD-Definition, die aus drei Abschnitten besteht:<\/p>\n

<\/p>\n