Willkommen zur Kubernetes-Kurzanleitung. Dies ist eine regelmäßige Kolumne mit den interessantesten Fragen, die wir online und bei unseren Schulungen erhalten. Der Experte für Kubernetes antwortet.
Der heutige Experte ist Daniele Polencic . Daniel ist Dozent und Softwareentwickler bei Learnk8s .
Wenn Sie Ihre Frage im nächsten Beitrag beantworten möchten, kontaktieren Sie uns bitte per E-Mail oder auf Twitter: @ learnk8s .
Vorherige Beiträge übersprungen? Suchen Sie hier nach ihnen .
Wie verbinde ich Kubernetes-Cluster in verschiedenen Rechenzentren?
Kurz gesagt : Kubefed v2 ist in Kürze verfügbar. Ich empfehle Ihnen außerdem, mehr über Shipper und das Multi-Cluster-Scheduler-Projekt zu erfahren .
Sehr oft wird die Infrastruktur repliziert und auf 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 Workloads auf verschiedene Regionen verteilen.
Sie können einen oder mehrere Cluster pro Team, Region, Umgebung oder eine Kombination dieser Elemente haben.
Ihre Cluster können in verschiedenen Clouds und in einer lokalen Umgebung gehostet werden.
Aber wie plant man die Infrastruktur für eine solche geografische Verbreitung?
Müssen Sie einen großen Cluster in mehreren Cloud-Umgebungen über ein einziges Netzwerk erstellen?
Oder viele kleine Cluster starten und einen Weg finden, sie zu steuern und zu synchronisieren?
Ein Lead-Cluster
Das Erstellen eines einzelnen Clusters in einem einzelnen Netzwerk ist nicht so einfach.
Stellen Sie sich vor, Sie haben einen Unfall und verlieren die Verbindung zwischen den Segmenten des Clusters.
Wenn Sie einen Master-Server haben, kann die Hälfte der Ressourcen keine neuen Befehle empfangen, da sie den Master nicht kontaktieren können.
Gleichzeitig haben Sie alte Routing-Tabellen ( kube-proxy kann keine neuen laden) und keine zusätzlichen Pods (kubelet kann keine Updates anfordern).
Wenn Kubernetes den Knoten nicht sieht, markiert er ihn als verloren und verteilt die fehlenden Pods an die vorhandenen Knoten.
Infolgedessen haben Sie doppelt so viele Pods.
Wenn Sie für jede Region einen Master-Server erstellen, treten Probleme mit dem Konsensalgorithmus in der etcd-Datenbank auf. ( ca. Ed. - Tatsächlich muss sich die etcd-Datenbank nicht auf den Masterservern befinden. Sie kann auf einer separaten Gruppe von Servern in derselben Region ausgeführt werden. Sie hat jedoch einen Clusterfehlerpunkt erhalten. Aber schnell. )
etcd verwendet den Raft-Algorithmus , um den Wert auszuhandeln, bevor er auf die Festplatte geschrieben wird.
Das heißt, die meisten Instanzen müssen einen Konsens erzielen, bevor der Staat an etcd geschrieben werden kann.
Wenn die Verzögerung zwischen Instanzen von etcd dramatisch zunimmt, wie dies bei drei Instanzen von etcd in verschiedenen Regionen der Fall ist, dauert es lange, den Wert abzustimmen und auf die Festplatte zu schreiben.
Dies spiegelt sich 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 wenn der Controller nicht einer, sondern mehrere ist, wird eine Kettenreaktion erhalten, und der gesamte Cluster beginnt sehr langsam zu arbeiten .
etcd reagiert so empfindlich auf Latenz, dass in der offiziellen Dokumentation die Verwendung von SSDs anstelle von normalen Festplatten empfohlen wird .
Derzeit gibt es keine guten Beispiele für ein großes Netzwerk für einen einzelnen Cluster.
Grundsätzlich versuchen die Entwicklergemeinschaft und die SIG-Cluster-Gruppe herauszufinden, wie Cluster auf dieselbe Weise orchestriert werden können, wie Kubernetes Container orchestriert.
Option 1: Cluster-Verbund mit Kubefed
Die offizielle Antwort von SIG-cluster lautet kubefed2, eine neue Version des ursprünglichen Client- und Operator-Kube-Verbunds .
Zum ersten Mal versuchten sie, die Sammlung von Clustern als einzelnes Objekt mit dem Kube-Verbund-Tool zu verwalten.
Der Anfang war gut, aber am Ende wurde der Kube-Verband nicht populär, weil er nicht alle Ressourcen unterstützte.
Er unterstützte gemeinsame Lieferungen und Dienstleistungen, zum Beispiel jedoch nicht StatefulSets.
Und die Konfiguration des Verbandes wurde in Form von Anmerkungen übertragen und unterschied sich nicht in der Flexibilität.
Stellen Sie sich vor, wie Sie die Trennung von Replikaten für jeden Cluster in einem Verbund nur mit Anmerkungen 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 von der anderen Seite aus anzugehen.
Anstelle von Anmerkungen haben sie beschlossen, einen Controller freizugeben, der auf den Clustern installiert ist. Sie kann mithilfe der benutzerdefinierten Ressourcendefinition (CRD) konfiguriert werden.
Für jede Ressource, die Teil des Verbunds sein wird, haben Sie eine benutzerdefinierte CRD-Definition aus drei Abschnitten:
- Standarddefinition einer Ressource, z. B. Bereitstellen;
placement , in dem Sie festlegen, wie die Ressource im Verbund verteilt wird;- Abschnittsüberschreibung, bei der Sie für eine bestimmte Ressource das Gewicht und die Parameter aus der Platzierung überschreiben können.
Hier ist ein Beispiel für eine kombinierte 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: 5
Wie Sie sehen können, ist das Angebot auf zwei Cluster verteilt: cluster1 und cluster2 .
Der erste Cluster liefert drei Replikate, während der zweite auf 5 gesetzt ist.
Wenn Sie mehr Kontrolle über die Anzahl der Replikate benötigen, bietet kubefed2 ein neues ReplicaSchedulingPreference-Objekt, mit 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: 2
Die CRD-Struktur und die API sind noch nicht fertig, und im offiziellen Projekt-Repository wird aktiv gearbeitet.
Achten Sie auf kubefed2, aber denken Sie daran, dass es noch nicht für die Arbeitsumgebung geeignet ist.
Weitere Informationen zu kubefed2 finden Sie im offiziellen kubefed2- Artikel im Kubernetes- Blog und im offiziellen kubefed-Projekt-Repository .
Option 2: Clustering von Clustern 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, in mehreren Regionen und in mehreren Clouds.
Shipper ähnelt kubefed2.
Mit beiden Tools können Sie die Bereitstellungsstrategie für mehrere Cluster konfigurieren (welche Cluster verwendet werden und wie viele Replikate sie haben).
Ziel des Versenders ist es jedoch, das Risiko von Lieferfehlern zu verringern.
In Shipper können Sie eine Reihe von Schritten definieren, die die Trennung von Replikaten zwischen der vorherigen und der aktuellen Bereitstellung und die Menge des eingehenden Datenverkehrs beschreiben.
Wenn Sie eine Ressource an einen Cluster senden, stellt der Shipper-Controller diese Änderung schrittweise für alle kombinierten Cluster bereit.
Und der Versender ist sehr begrenzt.
Beispielsweise akzeptiert es Helmdiagramme als Eingabe und unterstützt keine Vanille-Ressourcen.
Im Allgemeinen arbeitet der Versender wie folgt.
Anstelle der Standardlieferung müssen Sie eine Anwendungsressource erstellen, die das Helmdiagramm 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: 3
Der Versender ist eine gute Option für die Verwaltung mehrerer Cluster, aber seine enge Beziehung zu Helm stört nur.
Was ist, wenn wir alle von Helm zu kustomize oder kapitan wechseln ?
Erfahren Sie mehr über Shipper und seine Philosophie in dieser offiziellen Pressemitteilung .
Wenn Sie sich mit dem Code befassen möchten, rufen Sie das offizielle Projekt-Repository auf .
Option 3: Beitritt zum „magischen“ Cluster
Kubefed v2 und Shipper arbeiten mit dem Cluster-Verbund zusammen und stellen Clustern durch benutzerdefinierte Ressourcendefinitionen neue Ressourcen zur Verfügung.
Was aber, wenn Sie nicht alle Verbrauchsmaterialien, StatefulSets, DaemonSets usw. zum Kombinieren neu schreiben möchten?
Wie kann ein vorhandener Cluster in einen Verbund aufgenommen werden, ohne dass YAML geändert wird?
Multi-Cluster-Scheduler ist ein Admirality-Projekt , das die Planung von Workloads in Clustern übernimmt.
Anstatt eine neue Methode für die Interaktion mit dem Cluster zu entwickeln und Ressourcen in benutzerdefinierte Definitionen zu verpacken, ist der Multi-Cluster-Scheduler in den Standard-Kubernetes-Lebenszyklus eingebettet und fängt alle von den Pods erstellten Aufrufe ab.
Jeder unter erstellt sofort durch einen Dummy ersetzt.
Der Multi-Cluster-Scheduler verwendet Web-Hooks, um den Zugriff zu ändern , um den Anruf abzufangen und einen Leerlauf-Pod-Dummy zu erstellen.
Der Quell-Pod durchläuft einen weiteren Planungszyklus, in dem nach einer Umfrage des gesamten Verbandes eine Entscheidung über die Platzierung getroffen wird.
Schließlich wird der Pod an den Zielcluster geliefert.
Als Ergebnis haben Sie einen zusätzlichen Pod, der nichts tut, sondern nur Platz beansprucht.
Der Vorteil ist, dass Sie keine neuen Ressourcen schreiben mussten, um Vorräte zu kombinieren.
Jede Ressource, die einen Pod erstellt, kann automatisch zusammengeführt werden.
Dies ist interessant, da Sie plötzlich Lieferungen auf mehrere Regionen verteilt haben, dies aber nicht bemerkt haben. Dies ist jedoch ziemlich riskant, da hier alles auf Magie beruht.
Wenn Shipper jedoch hauptsächlich versucht, die Auswirkungen von Lieferungen zu mildern, führt der Multi-Cluster-Scheduler allgemeinere Aufgaben aus und ist wahrscheinlich besser für Batch-Jobs geeignet.
Es gibt keinen fortschrittlichen Mechanismus für die schrittweise Versorgung.
Weitere Informationen zum Multi-Cluster-Scheduler finden Sie auf der offiziellen Repository-Seite .
Wenn Sie mehr über Multi-Cluster-Scheduler in Aktion erfahren möchten, hat Admiralty einen interessanten Anwendungsfall mit Argo - Workflows, Ereignisse, CI- und Kubernetes-CDs.
Andere Tools und Lösungen
Das Verbinden und Verwalten mehrerer Cluster ist eine komplexe Aufgabe, es gibt keine universelle Lösung.
Wenn Sie mehr über dieses Thema erfahren möchten, finden Sie hier einige Ressourcen:
Das ist alles für heute
Vielen Dank für das Lesen bis zum Ende!
Wenn Sie wissen, wie Sie mehrere Cluster effizienter verbinden können, teilen Sie uns dies mit .
Wir werden Ihre Methode zu den Links hinzufügen.
Besonderer Dank geht an Chris Nesbitt-Smith und Vincent De Smet (Zuverlässigkeitsingenieur bei swatmobile.io ) für das Lesen dieses Artikels und den Austausch nützlicher Informationen über die Funktionsweise des Verbandes.