Willkommen zu unserer Reihe von Kurzleitfäden zu Kubernetes. Das ist eine regelmäßige Kolumne 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 über .
Haben Sie die vorherigen Beiträge verpasst? .
Wie verbindet man Kubernetes-Cluster in verschiedenen Rechenzentren?
Zusammenfassung: ich empfehle auch, über das und .
Infrastrukturen werden häufig repliziert und auf verschiedene Regionen verteilt, insbesondere in kontrollierten Umgebungen.
Wenn eine Region nicht verfügbar ist, wird der Datenverkehr umgeleitet, um Unterbrechungen zu vermeiden.
Mit Kubernetes kann eine ähnliche Strategie angewendet werden, um Arbeitslasten über verschiedene Regionen zu 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 in lokalen Umgebungen gehostet werden.
Wie plant man die Infrastruktur für eine so große geografische Streuung?
Soll man einen großen Cluster über mehrere Cloud-Umgebungen in einem gemeinsamen Netzwerk erstellen?
Oder mehrere kleine Cluster einrichten und einen Weg finden, diese zu steuern und zu synchronisieren?
Ein übergeordneter Cluster
Einen Cluster in einem einheitlichen Netzwerk zu erstellen, ist nicht so einfach.
Stellen Sie sich vor, Sie haben einen Ausfall und die Verbindung zwischen den Clustern wird getrennt.
Wenn Sie nur einen Master-Server haben, können die Hälfte der Ressourcen keine neuen Befehle empfangen, da sie nicht mit dem Master kommunizieren können.
Und dabei haben Sie alte Routing-Tabellen (kube-proxy können keine neuen laden) und keine zusätzlichen Pods (kubelet kann keine Aktualisierungen anfordern).
Noch schlimmer ist, dass Kubernetes einen Knoten als verloren markiert, wenn er ihn nicht sieht, und die fehlenden Pods auf die vorhandenen Knoten verteilt.
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 der Redaktion — 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ührt dies zu einem Single Point of Failure im Cluster. Dafür ist es schnell.)
etcd verwendet , um den Wert zu konsensieren, bevor er auf der Festplatte geschrieben wird.
Das bedeutet, dass die Mehrheit der Instanzen einen Konsens erreichen muss, bevor der Zustand in etcd geschrieben werden kann.
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.
Dies wirkt sich auch auf die Kubernetes-Controller aus.
Der Controller-Manager benötigt mehr Zeit, um von der Änderung zu erfahren und die Antwort in die Datenbank zu schreiben.
Da es nicht nur einen, sondern mehrere Controller gibt, entsteht eine Kettenreaktion, und der gesamte Cluster beginnt sehr langsam zu arbeiten..
etcd ist so empfindlich gegenüber Latenz, dass .
Momentan gibt es keine guten Beispiele für ein großes Netzwerk innerhalb eines Clusters.
Im Wesentlichen versucht die Entwicklergemeinschaft sowie die SIG-cluster-Gruppe zu verstehen, wie Cluster ähnlich wie Kubernetes Container orchestrieren können.
Option 1: Cluster-Föderation mit kubefed
Offizielle Antwort von SIG-cluster — .
Erstmals versuchte man, eine Sammlung von Clustern als ein einziges Objekt zu verwalten, mithilfe des Tools kube-Föderation.
Der Anfang war vielversprechend, jedoch wurde kube-Föderation letztlich nicht populär, da nicht alle Ressourcen unterstützt wurden.
Es unterstützte zusammengeführte Bereitstellungen und Dienste, jedoch keine StatefulSets.
Außerdem wurde die Föderationskonfiguration in Form von Annotationen übergeben, die nicht besonders flexibel war.
Stellen Sie sich vor, wie man die Replikateinteilung für jede Cluster in der Föderation nur mit Hilfe von Annotationen beschreiben kann.
Das führte zu einem vollständigen Durcheinander.
Die SIG-cluster-Gruppe hat nach kubefed v1 viel Arbeit geleistet und sich entschieden, das Problem von einer anderen Seite anzugehen.
Statt Annotationen haben sie beschlossen, einen Controller zu veröffentlichen, der auf den Clustern installiert wird und mithilfe von Custom Resource Definitions (CRD) konfiguriert werden kann.
Für jede Ressource, die in die Föderation aufgenommen wird, haben Sie eine benutzerdefinierte CRD, 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 die Gewichte und Parameter aus dem Placement für eine bestimmte Ressource überschrieben werden können.
Hier ist ein Beispiel für ein konsolidiertes Deployment 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, wird das Deployment auf zwei Cluster verteilt: cluster1 und cluster2.
Der erste Cluster stellt drei Repliken zur Verfügung, während der zweite den Wert 5 angibt.
Wenn Sie mehr Kontrolle über die Anzahl der Repliken benötigen, bietet kubefed2 ein neues Objekt ReplicaSchedulingPreference, mit dem Repliken gewichtet 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 fertig, und im offiziellen Projekt-Repository wird aktiv daran gearbeitet.
Behalten Sie kubefed2 im Auge, aber beachten Sie, dass es derzeit nicht für Produktionsumgebungen geeignet ist.
Erfahren Sie mehr über kubefed2 aus in dem Kubernetes-Blog und im .
Option 2: Cluster-Konsolidierung im Stil von Booking.com
Die Entwickler von Booking.com haben sich nicht mit kubefed v2 beschäftigt, haben jedoch Shipper entwickelt – einen Operator für Multi-Cluster-Bereitstellungen in mehreren Regionen und Clouds.
Ähnlich wie kubefed2.
Beide Tools ermöglichen die Konfiguration der Bereitstellungsstrategie über mehrere Cluster (welche Cluster verwendet werden und wie viele Replikate sie haben).
Aber Die Aufgabe von Shipper ist es, das Risiko von Fehlern bei der Bereitstellung zu minimieren.
In Shipper können Sie eine Reihe von Schritten definieren, die beschreiben, wie die Replikate zwischen dem vorherigen und aktuellen Deployment sowie dem Volumen des eingehenden Traffics aufgeteilt werden.
Wenn Sie eine Ressource in einen Cluster senden, implementiert der Shipper-Controller schrittweise diese Änderung in allen zusammengefassten Clustern.
Außerdem ist Shipper sehr begrenzt.
Zum Beispiel Es akzeptiert Helm-Charts als Eingabedaten. und unterstützt keine Vanilla-Ressourcen.
Im Großen und Ganzen funktioniert Shipper folgendermaßen.
Anstelle der Standardbereitstellung muss eine Anwendungsressource erstellt werden, die ein Helm-Chart 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 Lösung für das Management mehrerer Cluster, doch die enge Verknüpfung mit Helm ist hinderlich.
Vielleicht wechseln wir alle von Helm zu oder ?
Erfahren Sie mehr über Shipper und seine Philosophie in .
Wenn Sie den Code durchstöbern möchten, .
Option 3: "magisches" Zusammenführen von Clustern.
Kubefed v2 und Shipper arbeiten mit der Föderation von Clustern zusammen und stellen neuen Ressourcen über benutzerdefinierte Ressourcen bereit.
Aber was, wenn Sie nicht alle Deployments, StatefulSets, DaemonSets usw. für die Federation neu schreiben möchten?
Wie integrieren Sie ein bestehendes Cluster in die Federation, ohne YAML zu ändern?
, das sich mit Workloads in Clustern beschäftigt.
Anstatt jedoch einen neuen Weg zur Interaktion mit dem Cluster zu finden und Ressourcen in benutzerdefinierte Definitionen zu kapseln, integriert sich der multi-cluster-scheduler in den standardmäßigen Lebenszyklus von Kubernetes und fängt alle Aufrufe ab, die Pods erzeugen.
Jeder erzeugte Pod wird sofort durch einen Platzhalter ersetzt.
multi-cluster-scheduler verwendet , um den Aufruf abzufangen und einen inaktiven Pod-Platzhalter zu erstellen.
Der ursprüngliche Pod durchläuft einen weiteren Planungszyklus, in dem nach der Abfrage der gesamten Federation eine Entscheidung über den Standort getroffen wird.
Schließlich wird der Pod in das Ziel-Cluster geliefert.
Am Ende haben Sie einen zusätzlichen Pod, der nichts tut, sondern nur Platz einnimmt.
Der Vorteil ist, dass Sie keine neuen Ressourcen für die Federation schreiben mussten.
Jede Ressource, die einen Pod erzeugt, ist bereits automatisch für die Federation bereit.
Es ist interessant, denn plötzlich haben Sie Lieferungen, die auf mehrere Regionen verteilt sind, ohne es zu merken. Das kann jedoch riskant sein, denn hier hängt alles von einer gewissen Magie ab.
Aber während Shipper hauptsächlich versucht, die Auswirkungen der Lieferungen abzuschwächen, übernimmt der Multi-Cluster-Scheduler allgemeinere Aufgaben und eignet sich möglicherweise besser für Batch-Jobs.
Er verfügt nicht über einen ausgeklügelten Mechanismus für schrittweise Lieferungen.
Mehr über den Multi-Cluster-Scheduler erfahren Sie auf .
Wenn Sie über den Multi-Cluster-Scheduler in der Praxis lesen möchten, hat Admiralty einen — Arbeitsabläufe, Ereignisse, CI und CD in Kubernetes.
Weitere Tools und Lösungen.
Die Verbindung und Verwaltung mehrerer Cluster ist eine komplexe Aufgabe; es gibt keine universelle Lösung.
Wenn Sie dieses Thema eingehender erkunden möchten, finden Sie hier einige Ressourcen:
- — ein Werkzeug, das die Overlay-Netze verschiedener Kubernetes-Cluster verbindet.
- Das Einzelhandelsnetz Target nutzt .
- Versuchen Sie, IPV6 zu verwenden und .
- Sie können ein Service Mesh wie .
- Cilium, ein Container-Netzwerkschnittstellen-Plugin, bietet , die es ermöglicht, mehrere Cluster zu kombinieren.
Das wäre alles für heute.
Vielen Dank, dass Sie bis zum Ende gelesen haben!
Wenn Sie wissen, wie man mehrere Cluster effektiver verbindet, .
Wir werden Ihre Methode zu den Links hinzufügen.
Besonderer Dank gilt Chris Nesbitt-Smith () und Vincent De Smet () (Reliability Engineer bei ) dafür, dass sie den Artikel gelesen und nützliche Informationen darüber geteilt haben, wie die Föderation funktioniert.
Quelle: habr.com
