{"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":"So verbinden Sie Kubernetes-Cluster in verschiedenen Rechenzentren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"So
\nWillkommen zu unserer Reihe von Kurzleitf\u00e4den zu Kubernetes.<\/strong> Das ist eine regelm\u00e4\u00dfige Kolumne 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 \u00fcber bei Twitter: @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

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

Wenn eine Region nicht verf\u00fcgbar ist, wird der Datenverkehr umgeleitet, um Unterbrechungen zu vermeiden.<\/strong><\/p>\n

<\/p>\n

Mit Kubernetes kann eine \u00e4hnliche Strategie angewendet werden, um Arbeitslasten \u00fcber verschiedene Regionen zu 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 in lokalen Umgebungen gehostet werden.<\/p>\n

<\/p>\n

Wie plant man die Infrastruktur f\u00fcr eine so gro\u00dfe geografische Streuung?
\nSoll man einen gro\u00dfen Cluster \u00fcber mehrere Cloud-Umgebungen in einem gemeinsamen Netzwerk erstellen?
\nOder mehrere kleine Cluster einrichten und einen Weg finden, diese zu steuern und zu synchronisieren?<\/em><\/p>\n

<\/p>\n

Ein \u00fcbergeordneter Cluster<\/h3>\n

<\/p>\n

Einen Cluster in einem einheitlichen Netzwerk zu erstellen, ist nicht so einfach.<\/em><\/p>\n

<\/p>\n

Stellen Sie sich vor, Sie haben einen Ausfall und die Verbindung zwischen den Clustern wird getrennt.<\/p>\n

<\/p>\n

Wenn Sie nur einen Master-Server haben, k\u00f6nnen die H\u00e4lfte der Ressourcen keine neuen Befehle empfangen, da sie nicht mit dem Master kommunizieren k\u00f6nnen.<\/p>\n

<\/p>\n

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

<\/p>\n

Noch schlimmer ist, dass Kubernetes einen Knoten als verloren markiert, wenn er ihn nicht sieht, und die fehlenden Pods auf die vorhandenen Knoten verteilt.<\/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 der Redaktion \u2014 Die etcd-Datenbank muss nicht unbedingt auf Master-Servern gehostet werden. Sie kann auf einer separaten Gruppe von Servern innerhalb einer Region betrieben werden. Allerdings f\u00fchrt dies zu einem Single Point of Failure im Cluster. Daf\u00fcr ist es schnell.<\/em>)<\/p>\n

<\/p>\n

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

<\/p>\n

Wenn die Latenz zwischen den etcd-Instanzen stark ansteigt, wie bei drei Instanzen in verschiedenen Regionen, dauert es lange, um den Wert zu konsensieren und auf der Festplatte zu speichern.
\nDies wirkt sich auch auf die Kubernetes-Controller aus.<\/p>\n

<\/p>\n

Der Controller-Manager ben\u00f6tigt mehr Zeit, um von der \u00c4nderung zu erfahren und die Antwort in die Datenbank zu schreiben.<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Momentan gibt es keine guten Beispiele f\u00fcr ein gro\u00dfes Netzwerk innerhalb eines Clusters.<\/strong><\/p>\n

<\/p>\n

Im Wesentlichen versucht die Entwicklergemeinschaft sowie die SIG-cluster-Gruppe zu verstehen, wie Cluster \u00e4hnlich wie Kubernetes Container orchestrieren k\u00f6nnen.<\/p>\n

<\/p>\n

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

<\/p>\n

Offizielle Antwort von SIG-cluster \u2014 kubefed2, die neue Version des urspr\u00fcnglichen Clients und Operators f\u00fcr die kube-F\u00f6deration<\/a><\/noindex>.<\/p>\n

<\/p>\n

Erstmals versuchte man, eine Sammlung von Clustern als ein einziges Objekt zu verwalten, mithilfe des Tools kube-F\u00f6deration.<\/p>\n

<\/p>\n

Der Anfang war vielversprechend, jedoch wurde kube-F\u00f6deration letztlich nicht popul\u00e4r, da nicht alle Ressourcen unterst\u00fctzt wurden.<\/p>\n

<\/p>\n

Es unterst\u00fctzte zusammengef\u00fchrte Bereitstellungen und Dienste, jedoch keine StatefulSets.
\nAu\u00dferdem wurde die F\u00f6derationskonfiguration in Form von Annotationen \u00fcbergeben, die nicht besonders flexibel war.<\/p>\n

<\/p>\n

Stellen Sie sich vor, wie man die Replikateinteilung f\u00fcr jede Cluster in der F\u00f6deration nur mit Hilfe von Annotationen beschreiben kann.<\/em><\/p>\n

<\/p>\n

Das f\u00fchrte zu einem vollst\u00e4ndigen Durcheinander.<\/strong><\/p>\n

<\/p>\n

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

<\/p>\n

Statt Annotationen haben sie beschlossen, einen Controller zu ver\u00f6ffentlichen, der auf den Clustern installiert wird und mithilfe von Custom Resource Definitions (CRD) konfiguriert werden kann.<\/strong><\/p>\n

<\/p>\n

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

<\/p>\n