Willkommen zu unserer Reihe kurzer Leitfäden zu Kubernetes. Das ist eine regelmäßige Kolonne mit den interessantesten Fragen, die wir online und in unseren Schulungen erhalten. Beantwortet von einem Kubernetes-Experten.
Der heutige Experte ist Daniele Polencic (). Daniele ist Ausbilder und Softwareentwickler bei .
Wenn Sie eine Antwort auf Ihre Frage im nächsten Beitrag erhalten möchten, oder auf .
Haben Sie die vorherigen Beiträge verpasst? .
Wie man Kubernetes-Cluster in verschiedenen Rechenzentren verbindet?
Kurz: , und ich empfehle auch, über das und .
Infrastrukturen werden ziemlich häufig repliziert und über verschiedene Regionen verteilt, besonders in kontrollierten Umgebungen.
Wenn eine Region nicht verfügbar ist, wird der Verkehr in eine andere umgeleitet, um Ausfälle zu vermeiden.
Mit Kubernetes kann man eine ähnliche Strategie verwenden und Arbeitslasten über verschiedene Regionen verteilen.
Sie können ein oder mehrere Cluster pro Team, Region, Umgebung oder eine Kombination dieser Elemente haben.
Ihre Cluster können in verschiedenen Clouds und vor Ort gehostet werden.
Aber wie plant man die Infrastruktur für eine solche geografische Verteilung?
Soll man ein großes Cluster über mehrere Clouds in einem einheitlichen Netzwerk erstellen?
Oder viele kleine Cluster einrichten und einen Weg finden, diese zu steuern und zu synchronisieren?
Ein zentrales Cluster
Es ist nicht so einfach, ein Cluster über ein einheitliches Netzwerk zu erstellen.
Stellen Sie sich vor, Sie haben einen Ausfall, und die Konnektivität zwischen den Segmenten des Clusters geht verloren.
Wenn Sie einen Master-Server haben, können die Hälfte der Ressourcen keine neuen Befehle erhalten, da sie nicht in der Lage sind, Kontakt mit dem Master aufzunehmen.
Und dabei haben Sie alte Routing-Tabellen (kube-proxy kann die neuen nicht laden) und keine zusätzlichen Pods (kubelet kann keine Updates anfordern).
Was noch schlimmer ist, wenn Kubernetes einen Knoten nicht sieht, markiert er ihn als verloren und verteilt die fehlenden Pods auf existierende Knoten.
Am Ende haben Sie doppelt so viele Pods.
Wenn Sie für jede Region einen Master-Server einrichten, gibt es Probleme mit dem Konsensalgorithmus in der etcd-Datenbank. (Hinweis des Redakteurs — Tatsächlich 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ält man dabei einen einzelnen Ausfallpunkt für das Cluster. Dafür geht es schnell.)
etcd verwendet , um den Wert zu vereinbaren, bevor er auf der Festplatte gespeichert wird.
Das bedeutet, dass die meisten Instanzen einen Konsens erreichen müssen, bevor der Zustand in etcd gespeichert werden kann.
Wenn die Verzögerung 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.
Das wirkt sich auch auf die Kubernetes-Controller aus.
Der Controller-Manager benötigt mehr Zeit, um über Änderungen informiert zu werden und die Antwort in die Datenbank zu schreiben.
Da es nicht nur einen Controller, sondern mehrere gibt, entsteht eine Kettenreaktion, und das gesamte Cluster beginnt, sehr langsam zu arbeiten..
etcd ist so empfindlich gegenüber Verzögerungen, dass .
Derzeit gibt es keine guten Beispiele für ein großes Netzwerk mit einem einzigen Cluster.
Im Wesentlichen versuchen die Entwicklergemeinschaft und die SIG-cluster-Gruppe herauszufinden, wie man Cluster orchestrieren kann, ähnlich wie Kubernetes Container orchestriert.
Option 1: Cluster-Föderation mit kubefed
Die offizielle Antwort der SIG-cluster lautet — .
Zum ersten Mal versuchte man mit dem Kube-Föderation-Tool, eine Sammlung von Clustern als ein einziges Objekt zu verwalten.
Der Anfang war vielversprechend, aber letztendlich wurde Kube-Föderation nicht populär, weil nicht alle Ressourcen unterstützt wurden.
Es unterstützte zusammengeführte Bereitstellungen und Dienste, aber zum Beispiel keine StatefulSets.
Zudem wurde die Konfiguration der Föderation in Form von Anmerkungen übermittelt und war nicht besonders flexibel.
Stellen Sie sich vor, wie man die Replikation für jeden Cluster in der Föderation mithilfe von Anmerkungen beschreiben kann.
Das führte zu einem völligen Durcheinander.
Die SIG-cluster hat nach kubefed v1 viel Arbeit geleistet und beschlossen, das Problem von einer anderen Seite anzugehen.
Anstatt Anmerkungen zu verwenden, entschieden sie sich, einen Controller zu veröffentlichen, der in den Clustern installiert wird. Dieser kann mit benutzerdefinierten Ressourcendefinitionen (Custom Resource Definition, CRD) konfiguriert werden.
Für jede Ressource, die in die Föderation aufgenommen wird, haben Sie eine benutzerdefinierte CRD-Definition, die aus drei Abschnitten besteht:
- eine Standardressourcendefinition, zum Beispiel ein Deployment;
- Abschnitt
placement, in dem Sie definieren, wie die Ressource in der Föderation verteilt wird; - Abschnitt
override, in dem für eine bestimmte Ressource Gewicht und Parameter aus dem Placement überschrieben werden können.
Hier ist ein Beispiel für eine kombinierte Bereitstellung mit den Abschnitten Placement und Override.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Wie Sie sehen, ist die Bereitstellung über zwei Cluster verteilt: cluster1 und cluster2.
Der erste Cluster stellt drei Replikate bereit, während beim zweiten der Wert 5 angegeben ist.
Wenn Sie mehr Kontrolle über die Anzahl der Replikate benötigen, bietet kubefed2 ein neues Objekt ReplicaSchedulingPreference, bei dem die Replikate nach Gewicht verteilt werden können:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Die Struktur von CRD und API ist noch nicht ganz bereit, und im offiziellen Repository des Projekts wird aktiv daran gearbeitet.
Behalten Sie kubefed2 im Auge, aber denken Sie daran, dass es für Produktionsumgebungen bisher nicht geeignet ist.
Erfahren Sie mehr über kubefed2 aus im Kubernetes-Blog und im .
Variante 2: Cluster zusammenführen im Stil von Booking.com
Die Entwickler von Booking.com haben sich zwar nicht mit kubefed v2 beschäftigt, haben jedoch Shipper entwickelt – einen Operator für Bereitstellungen in mehreren Clustern, in mehreren Regionen und in mehreren Clouds.
es ist in gewisser Weise ähnlich wie kubefed2.
Beide Tools ermöglichen es, eine Bereitstellungsstrategie über mehrere Cluster hinweg festzulegen (welche Cluster verwendet werden und wie viele Replikate sie haben).
Aber das Ziel von Shipper ist es, das Risiko von Fehlern bei der Bereitstellung zu verringern.
In Shipper können eine Reihe von Schritten definiert werden, die die Verteilung der Replikate zwischen dem vorherigen und dem aktuellen Deployment sowie das gesamte eingehende Trafficvolumen beschreiben.
Wenn Sie eine Ressource in einen Cluster senden, wird diese Änderung schrittweise durch alle zusammengeschlossenen Cluster von dem Shipper-Controller bereitgestellt.
Außerdem ist Shipper sehr eingeschränkt.
Zum Beispiel, er akzeptiert Helm-Charts als Eingabedaten. und unterstützt keine Vanilla-Ressourcen.
Im Allgemeinen funktioniert Shipper wie folgt.
Anstelle der Standardlieferung müssen Sie eine Anwendungsressource erstellen, die ein Helm-Chart umfasst:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper ist eine gute Option zur Verwaltung mehrerer Cluster, aber die enge Verbindung zu Helm ist hinderlich.
Was ist, wenn wir alle von Helm auf oder ?
Erfahren Sie mehr über Shipper und seine Philosophie in .
Wenn Sie im Code stöbern möchten, .
Option 3: „magische“ Clusterzusammenlegung
Kubefed v2 und Shipper arbeiten mit der Federation von Clustern, indem sie den Clustern neue Ressourcen über benutzerdefinierte Ressourcendefinitionen bereitstellen.
Aber was ist, wenn Sie nicht alle Deployments, StatefulSets, DaemonSets usw. für die Zusammenlegung umschreiben möchten?
Wie können Sie einen bestehenden Cluster in die Föderation einbeziehen, ohne YAML zu ändern?
, das sich mit der Planungs-Workload in Clustern befasst.
Aber anstatt einen neuen Weg zu finden, um mit dem Cluster zu interagieren und Ressourcen in benutzerdefinierte Definitionen zu verpacken, integriert sich der multi-cluster-scheduler in den Standardlebenszyklus von Kubernetes und fängt alle Aufrufe ab, die Pods erstellen.
Jeder erstellte Pod wird sofort durch einen Dummy ersetzt.
multi-cluster-scheduler verwendet , um den Aufruf abzufangen und einen inaktiven Dummy-Pod zu erstellen.
Der ursprüngliche Pod durchläuft einen weiteren Planungszyklus, in dem nach der Abfrage der gesamten Föderation eine Entscheidung über die Platzierung getroffen wird.
Schließlich wird der Pod in den Ziel-Cluster geliefert.
Insgesamt haben Sie einen zusätzlichen Pod, der nichts tut, sondern nur Platz einnimmt.
Der Vorteil besteht darin, dass Sie keine neuen Ressourcen für die Zusammenlegung von Deployments schreiben mussten.
Jede Ressource, die einen Pod erstellt, ist automatisch bereit zur Zusammenlegung.
Das ist interessant, denn auf einmal haben Sie Lieferungen, die über mehrere Regionen verteilt sind, und Sie haben es nicht einmal bemerkt. Allerdings ist das ziemlich riskant, denn alles hier beruht auf Magie.
Aber wenn der Shipper versucht, hauptsächlich die Folgen der Lieferungen zu mildern, führt der Multi-Cluster-Scheduler allgemeinere Aufgaben aus und ist möglicherweise besser für Batch-Jobs geeignet.
Er hat keinen ausgeklügelten Mechanismus für schrittweise Lieferungen.
Mehr über den Multi-Cluster-Scheduler erfahren Sie auf .
Wenn Sie sehen möchten, wie der Multi-Cluster-Scheduler in Aktion funktioniert, hat Admiralty einen – Workflows, Ereignissen, CI und CD in Kubernetes.
Andere Werkzeuge und Lösungen
Die Verbindung mehrerer Cluster und deren Verwaltung ist eine komplexe Aufgabe; eine universelle Lösung gibt es nicht.
Wenn Sie dieses Thema näher untersuchen möchten, hier sind einige Ressourcen:
- – ein Tool, das Overlay-Netzwerke verschiedener Kubernetes-Cluster verbindet.
- Die Einzelhandelsgruppe Target verwendet .
- Versuchen Sie, IPV6 zu verwenden und .
- Sie können eine Service Mesh verwenden, wie beispielsweise .
- Cilium, ein Plugin für Container-Netzwerkschnittstellen, bietet , die es ermöglicht, mehrere Cluster zu kombinieren.
Das ist alles für heute.
Vielen Dank, dass Sie bis zum Ende gelesen haben!
Wenn Sie wissen, wie man mehrere Cluster effizient miteinander verbindet, .
Wir werden Ihre Methode in die Links aufnehmen.
Besonderer Dank geht an Chris Nesbitt-Smith () und Vincent De Smet () (Reliability Engineer bei ) dafür, dass sie den Artikel gelesen haben und nützliche Informationen darüber geteilt haben, wie die Föderation funktioniert.
Quelle: habr.com
