Willkommen zur Kubernetes Quick Start-Reihe. Dies ist eine regelmäßige Kolumne mit den interessantesten Fragen, die uns online und in unseren Schulungen gestellt werden. Antworten von Kubernetes-Experten.
Der heutige Experte ist Daniel Polenchik (). Daniel arbeitet als Ausbilder und Softwareentwickler in .
Wenn Sie im nächsten Beitrag eine Antwort auf Ihre Frage wünschen, oder .
Frühere Beiträge verpasst? .
Wie verbinde ich Kubernetes-Cluster in verschiedenen Rechenzentren?
Kurz gesagt: , und ich rate Ihnen auch, darüber zu lesen и .
Sehr oft wird die Infrastruktur repliziert und über verschiedene Regionen verteilt, insbesondere in kontrollierten Umgebungen.
Wenn eine Region nicht verfügbar ist, wird der Datenverkehr in eine andere umgeleitet, um Unterbrechungen zu vermeiden.
Mit Kubernetes können Sie eine ähnliche Strategie verwenden und Arbeitslasten auf verschiedene Regionen verteilen.
Sie können einen oder mehrere Cluster pro Team, Region, Umgebung oder einer Kombination davon haben.
Ihre Cluster können in mehreren Clouds und vor Ort gehostet werden.
Doch wie plant man die Infrastruktur für eine solche geografische Verteilung?
Müssen Sie einen großen Cluster für mehrere Cloud-Umgebungen über ein einziges Netzwerk erstellen?
Oder haben Sie viele kleine Cluster und finden einen Weg, diese zu steuern und zu synchronisieren?
Ein Führungscluster
Das Erstellen eines Clusters über ein einzelnes Netzwerk ist nicht so einfach.
Stellen Sie sich vor, Sie haben einen Unfall und die Konnektivität zwischen Clustersegmenten geht verloren.
Wenn Sie über einen Master-Server verfügen, kann die Hälfte der Ressourcen keine neuen Befehle empfangen, da sie den Master nicht kontaktieren können.
Und gleichzeitig haben Sie alte Routing-Tabellen (kube-proxy kann keine neuen herunterladen) und keine zusätzlichen Pods (Kubelet kann keine Updates abfragen).
Schlimmer noch: Wenn Kubernetes einen Knoten nicht sehen kann, markiert es ihn als verwaist und verteilt fehlende Pods an vorhandene Knoten.
Dadurch haben Sie doppelt so viele Pods.
Wenn Sie einen Masterserver pro Region erstellen, treten Probleme mit dem Konsensalgorithmus in der etcd-Datenbank auf. (ca. Hrsg. - Tatsächlich muss sich die etcd-Datenbank nicht auf den Master-Servern befinden. Es kann auf einer separaten Gruppe von Servern in derselben Region ausgeführt werden. Allerdings wurde gleichzeitig ein Point of Failure eines Clusters erhalten. Aber schnell.)
etcd verwendet um einen Wert zu vereinbaren, bevor dieser auf die Festplatte geschrieben wird.
Das heißt, die meisten Instanzen müssen einen Konsens erzielen, bevor der Status in etcd geschrieben werden kann.
Wenn die Latenz zwischen etcd-Instanzen sprunghaft ansteigt, wie es bei drei etcd-Instanzen in verschiedenen Regionen der Fall ist, dauert es lange, sich auf einen Wert zu einigen und ihn auf die Festplatte zu schreiben.
Dies spiegelt sich auch in Kubernetes-Controllern wider.
Der Controller-Manager benötigt mehr Zeit, um sich über die Änderung zu informieren und die Antwort in die Datenbank zu schreiben.
Und da der Controller nicht einer ist, sondern mehrere, Es kommt zu einer Kettenreaktion, und der gesamte Cluster beginnt sehr langsam zu arbeiten.
etcd ist so latenzempfindlich, dass .
Derzeit gibt es keine guten Beispiele für ein großes Netzwerk für einen einzelnen Cluster.
Im Grunde versuchen die Entwicklergemeinschaft und die SIG-Cluster-Gruppe herauszufinden, wie man Cluster auf die gleiche Weise orchestriert, wie Kubernetes Container orchestriert.
Option 1: Cluster mit kubefed zusammenschließen
Offizielle Antwort vom SIG-Cluster - .
Zum ersten Mal haben wir versucht, eine Sammlung von Clustern als einzelnes Objekt mithilfe des Kube-Föderationstools zu verwalten.
Der Anfang war gut, aber am Ende wurde die Kube-Föderation nicht populär, da sie nicht alle Ressourcen unterstützte.
Es unterstützte föderierte Lieferungen und Dienste, jedoch beispielsweise keine StatefulSets.
Außerdem wurde die Föderationskonfiguration in Form von Anmerkungen übergeben und war nicht flexibel.
Stellen Sie sich vor, wie Sie die Aufteilung der Replikate für jeden Cluster in einer Föderation mithilfe einer einzigen Anmerkung beschreiben können.
Es stellte sich heraus, dass es ein komplettes Durcheinander war.
SIG-Cluster hat nach kubefed v1 großartige Arbeit geleistet und beschlossen, das Problem aus einem anderen Blickwinkel anzugehen.
Anstelle von Anmerkungen entschieden sie sich für die Veröffentlichung eines Controllers, der auf Clustern installiert wird. Es kann mithilfe benutzerdefinierter Ressourcendefinitionen (Custom Resource Definition, CRD) konfiguriert werden.
Für jede Ressource, die eingebunden werden soll, verfügen Sie über eine benutzerdefinierte CRD-Definition in drei Abschnitten:
- eine Standarddefinition einer Ressource, z. B. „Deploy“;
- Abschnitt
placement, wo Sie definieren, wie die Ressource in der Föderation verteilt wird; - Abschnitt
override, wobei Sie für eine bestimmte Ressource das Gewicht und die Parameter der Platzierung überschreiben können.
Hier ist ein Beispiel für eine gebündelte Lieferung mit Platzierungs- und Überschreibungsabschnitten.
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 das Angebot in zwei Cluster unterteilt: cluster1 и cluster2.
Der erste Cluster stellt drei Replikate bereit und der zweite hat den Wert 5.
Wenn Sie mehr Kontrolle über die Anzahl der Replikate benötigen, stellt kubefed2 ein neues ReplicaSchedulingPreference-Objekt bereit, in dem Replikate gewichtet 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 CRD-Struktur und die API sind noch nicht ganz fertig und im offiziellen Projekt-Repository wird aktiv daran gearbeitet.
Halten Sie Ausschau nach kubefed2, aber bedenken Sie, dass es für eine Produktionsumgebung noch nicht gut genug ist.
Erfahren Sie mehr über kubefed2 unter auf dem Kubernetes-Blog und .
Option 2: Clustering im Booking.com-Stil
Die Entwickler von Booking.com beschäftigten sich nicht mit kubefed v2, sondern entwickelten Shipper, einen Betreiber für die Bereitstellung in mehreren Clustern, mehreren Regionen und mehreren Clouds.
etwas ähnlich wie kubefed2.
Mit beiden Tools können Sie Ihre Multi-Cluster-Bereitstellungsstrategie anpassen (welche Cluster verwendet werden und wie viele Replikate sie haben).
Aber Die Aufgabe des Versenders besteht darin, das Risiko von Versandfehlern zu reduzieren.
In Shipper können Sie eine Reihe von Schritten definieren, die die Aufteilung der Replikate zwischen den vorherigen und aktuellen Bereitstellungen und die Menge des eingehenden Datenverkehrs beschreiben.
Wenn Sie eine Ressource an einen Cluster übertragen, stellt der Shipper-Controller diese Änderung schrittweise auf allen Verbundclustern bereit.
Auch der Versender ist sehr begrenzt.
Zum Beispiel kann die Es werden Helm-Diagramme als Eingabe verwendet und unterstützt keine Vanilla-Ressourcen.
Im Allgemeinen funktioniert Shipper wie folgt.
Anstelle einer Standardverteilung müssen Sie eine Anwendungsressource erstellen, die ein Helm-Diagramm enthält:
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 für die Verwaltung mehrerer Cluster, aber seine enge Beziehung zu Helm stört nur.
Was wäre, wenn wir alle von Helm zu wechseln würden? oder ?
Erfahren Sie mehr über Shipper und seine Philosophie unter .
Wenn Sie sich mit dem Code befassen möchten, .
Option 3: „magische“ Clusterzusammenführung
Kubefed v2 und Shipper arbeiten mit Cluster-Föderation, indem sie Clustern über eine benutzerdefinierte Ressourcendefinition neue Ressourcen bereitstellen.
Aber was ist, wenn Sie nicht alle zusammenzuführenden Lieferungen, StatefulSets, DaemonSets usw. neu schreiben möchten?
Wie binde ich einen vorhandenen Cluster in einen Verbund ein, ohne YAML zu ändern?
, das sich mit der Planung von Arbeitslasten auf Clustern befasst.
Aber anstatt eine neue Art der Interaktion mit dem Cluster zu erfinden und Ressourcen in benutzerdefinierte Definitionen zu verpacken, wird der Multi-Cluster-Scheduler in den standardmäßigen Kubernetes-Lebenszyklus eingefügt und fängt alle Aufrufe ab, die Pods erstellen.
Jeder erstellte Pod wird sofort durch einen Dummy ersetzt.
Multi-Cluster-Scheduler verwendet um den Anruf abzufangen und einen leeren Dummy-Pod zu erstellen.
Der ursprüngliche Pod durchläuft einen weiteren Planungszyklus, in dem nach einer Befragung des gesamten Verbunds eine Hosting-Entscheidung getroffen wird.
Schließlich wird der Pod an den Zielcluster geliefert.
Das Ergebnis ist ein zusätzlicher Pod, der nichts tut, sondern nur Platz beansprucht.
Der Vorteil besteht darin, dass Sie keine neuen Ressourcen schreiben müssen, um Vorräte zu kombinieren.
Jede Ressource, die einen Pod erstellt, ist automatisch für den Verbund bereit.
Das ist interessant, weil Sie plötzlich Vorräte über mehrere Regionen verteilt haben und es Ihnen nicht aufgefallen ist. Allerdings ist das durchaus riskant, denn hier beruht alles auf Magie.
Doch während Shipper hauptsächlich versucht, die Auswirkungen von Sendungen abzumildern, ist Multi-Cluster-Scheduler allgemeiner und möglicherweise besser für Batch-Jobs geeignet.
Es verfügt nicht über einen fortschrittlichen Mechanismus zur schrittweisen Abgabe.
Weitere Informationen zum Multi-Cluster-Scheduler finden Sie unter .
Wenn Sie mehr über Multi-Cluster-Scheduler in Aktion erfahren möchten, ist Admiralty genau das Richtige für Sie - Workflows, Ereignisse, CI und CD Kubernetes.
Weitere Tools und Lösungen
Das Verbinden und Verwalten mehrerer Cluster ist eine komplexe Aufgabe, für die es keine Universallösung gibt.
Wenn Sie mehr über dieses Thema erfahren möchten, finden Sie hier einige Ressourcen:
- ist ein Tool, das Overlay-Netzwerke verschiedener Kubernetes-Cluster verbindet.
- Die Target-Einzelhandelskette verwendet .
- Versuchen Sie es mit IPV6 und .
- Sie können beispielsweise ein Service Mesh verwenden .
- Cilium, ein Container-Netzwerkschnittstellen-Plugin, bietet , wodurch Sie mehrere Cluster kombinieren können
Das ist alles für heute
Vielen Dank, dass Sie bis zum Ende gelesen haben!
Wenn Sie wissen, wie Sie mehrere Cluster effizienter verbinden können, .
Wir werden Ihre Methode zu den Links hinzufügen.
Besonderer Dank geht an Chris Nesbitt-Smith () und Vincent de Sme () (an den Zuverlässigkeitsingenieur in ) für die Lektüre des Artikels und den Austausch nützlicher Informationen über die Funktionsweise des Verbandes.
Source: habr.com