Get best of the week

K8S Multicluster Reise

Hallo Habr!

Wir vertreten das Exness-Plattformteam. Zuvor haben unsere Kollegen bereits einen Artikel über produktionsbereite Bilder für k8s geschrieben . Heute möchten wir die Erfahrungen mit der Service-Migration in Kubernetes teilen.



Zunächst bieten wir Ihnen einige Zahlen an, um besser zu verstehen, was besprochen wird:

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


Wie sie sagen, bleibt nichts für immer und Rancher hat lange genug die Beendigung des Supports für Version 1.6 angekündigt. Ja, seit mehr als drei Jahren haben wir gelernt, wie man es kocht und auftretende Probleme löst, aber immer häufiger sind wir mit Problemen konfrontiert, die niemals behoben werden können. Rancher 1.6 verfügt außerdem über ein verknöchertes System zur Erteilung von Rechten, in dem Sie entweder fast alles oder nichts tun können.

Die eigene Virtualisierung bot zwar eine bessere Kontrolle über Datenspeicherung und -sicherheit, verursachte jedoch Betriebskosten, die mit dem stetigen Wachstum des Unternehmens, der Anzahl der Projekte und den Anforderungen für sie nur schwer zu ertragen waren.

Wir wollten die IaC-Standards befolgen und bei Bedarf schnell, an jedem geografischen Ort und ohne Anbietersperre Strom beziehen und diese auch schnell aufgeben können.

Erste Schritte


Zunächst wollten wir uns auf moderne Technologien und Lösungen verlassen, die es Teams ermöglichen, einen schnelleren Entwicklungszyklus zu erreichen und die Betriebskosten für die Interaktion mit einer Plattform zu minimieren, die Strom liefert. 
 
Das erste, was uns in den Sinn kam, war natürlich Kubernetes, aber wir waren nicht aufgeregt und haben ein wenig über das Thema der richtigen Wahl recherchiert. Wir haben nur OpenSource-Lösungen evaluiert und Kubernetes in einem unfairen Kampf bedingungslos besiegt.  

Als nächstes kam die Frage nach der Auswahl eines Tools zum Erstellen von Clustern. Wir haben die beliebtesten Lösungen verglichen: Kops, Kubespray, Kubeadm.

Zu Beginn schien uns Kubeadm zu kompliziert, eher eine Art Erfinder des "Fahrrads", und Kops mangelte es an Flexibilität.

Und der Gewinner kam heraus:



Wir haben begonnen, mit unserer eigenen Virtualisierung und AWS zu experimentieren, und versucht, eine ungefähre Ähnlichkeit mit unserem vorherigen Ressourcenverwaltungsmuster herzustellen, bei dem jeder denselben „Cluster“ verwendet. Und jetzt haben wir den ersten Cluster von 10 kleinen virtuellen Maschinen, von denen sich einige in AWS befinden. Wir haben versucht, Teams dorthin zu migrieren, alles schien „gut“ zu sein und die Geschichte konnte beendet werden, aber ...

Erste Probleme


Ansible ist das, worauf Kubespray basiert. Es ist nicht das Tool, mit dem IaC befolgt werden kann: Bei der Eingabe / Ausgabe der Knoten ist ein Fehler aufgetreten, und es waren einige Eingriffe erforderlich, und bei Verwendung verschiedener Betriebssysteme hat sich das Playbook verhalten auf veschiedenen Wegen. Mit der wachsenden Anzahl von Befehlen und Knoten im Cluster stellten wir fest, dass das Playbook immer länger dauerte. Am Ende lag unser Rekord bei 3,5 Stunden, und bei Ihnen? :)

Und es scheint, als wäre Kubespray nur Ansible, und auf den ersten Blick ist alles klar, aber:



Am Anfang des Weges gab es eine Aufgabe, Kapazitäten nur in AWS und Virtualisierung auszuführen, aber dann, wie so oft, änderten sich die Anforderungen.
 


Vor diesem Hintergrund wurde deutlich, dass unser altes Muster, Ressourcen in einem Orchestrierungssystem zu kombinieren, nicht geeignet war - für den Fall, dass die Cluster weit entfernt sind und von verschiedenen Anbietern verwaltet werden. 

Außerdem. Wenn alle Teams innerhalb desselben Clusters arbeiten, können verschiedene Dienste, bei denen NodeSelector falsch installiert ist, zum „fremden“ Host eines anderen Teams fliegen und dort Ressourcen nutzen. Im Fall von Taint gab es ständige Aufrufe, dass dieser oder jener Dienst nicht funktioniert, nicht aufgrund des menschlichen Faktors korrekt verteilt. Ein weiteres Problem war die Berechnung der Kosten, insbesondere angesichts der Probleme bei der Verteilung der Dienste nach Knoten.

Eine andere Geschichte betraf die Frage der Rechte der Mitarbeiter: Jedes Team wollte „an der Spitze“ des Clusters stehen und es vollständig verwalten, was zu einem vollständigen Zusammenbruch führen könnte, da die Teams größtenteils unabhängig voneinander sind.

Wie man ist


Angesichts des oben Gesagten und des Wunsches der Teams, unabhängiger zu sein, haben wir eine einfache Schlussfolgerung gezogen: ein Team - ein Cluster. 

Also haben wir einen zweiten:



Und dann einen dritten Cluster: 



Dann haben wir angefangen zu überlegen: Nehmen wir an, in einem Jahr werden unsere Teams mehr als einen Cluster haben? Zum Beispiel in verschiedenen geografischen Gebieten oder unter der Kontrolle verschiedener Anbieter? Einige von ihnen möchten in der Lage sein, schnell einen temporären Cluster für alle Tests bereitzustellen. 



Würde voll Kubernetes kommen! Es stellt sich heraus, dass dies eine Art MultiKubernetes ist. 

Gleichzeitig müssen wir alle diese Cluster irgendwie unterstützen, den Zugriff auf sie einfach steuern sowie neue erstellen und alte außer Betrieb nehmen können, ohne manuell eingreifen zu müssen.

Seit Beginn unserer Reise in die Welt von Kubernetes ist einige Zeit vergangen, und wir haben beschlossen, die verfügbaren Lösungen erneut zu prüfen. Es stellte sich heraus, dass es bereits auf dem Markt ist - Rancher 2.2.



In der ersten Phase unserer Forschung haben Rancher Labs bereits die erste Version von Version 2 veröffentlicht. Obwohl sie sehr schnell durch Ausführen des Containers ohne externe Abhängigkeiten mit einigen Parametern oder mithilfe des offiziellen HELM-Diagramms ausgelöst werden konnte, schien sie uns grob, und wir wussten nicht, ob Verlassen Sie sich auf diese Entscheidung, ob sie entwickelt oder schnell aufgegeben wird. Das Cluster = Clicks-Paradigma selbst in der Benutzeroberfläche passte ebenfalls nicht zu uns, und wir wollten uns nicht an RKE binden, da dies ein ziemlich engstirniges Tool ist. 

Die Rancher 2.2-Version hatte bereits ein effizienteres Erscheinungsbild und neben den vorherigen eine Reihe interessanter Funktionen, wie die Integration mit vielen externen Anbietern, einen zentralen Verteilungspunkt für Rechte und kubeconfig-Dateien, das Starten eines kubectl-Images mit Ihren Rechten in der Benutzeroberfläche sowie verschachtelte Namespaces, auch bekannt als Projekte. 

Um Rancher 2 hat sich bereits eine Community gebildet, und der HashiCorp Terraform-Anbieter wurde gegründet, um diese zu verwalten. Dies hat uns geholfen, alles zusammenzustellen.

Was ist passiert


Als Ergebnis haben wir einen kleinen Cluster, in dem Rancher gestartet wird, auf den alle anderen Cluster sowie viele damit verbundene Cluster zugreifen können. Der Zugriff auf jeden dieser Cluster kann so einfach erfolgen, dass ein Benutzer zum ldap-Verzeichnis hinzugefügt wird, unabhängig davon, wo er sich befindet befindet und die Ressourcen, die der Anbieter verwendet.

Mit gitlab-ci und Terraform wurde ein System erstellt, mit dem Sie einen Cluster einer beliebigen Konfiguration in Cloud-Anbietern oder unserer eigenen Infrastruktur erstellen und mit Rancher verbinden können. All dies erfolgt im IaC-Stil, wobei jeder Cluster von einem Repository beschrieben und sein Status versioniert wird. In diesem Fall sind die meisten Module über externe Repositorys verbunden, sodass nur Variablen übertragen oder ihre benutzerdefinierte Konfiguration für Instanzen beschrieben werden müssen, wodurch der Prozentsatz der Code-Wiederholbarkeit verringert wird.



Natürlich ist unsere Reise noch lange nicht zu Ende und es liegen noch viele interessante Aufgaben vor uns, z. B. ein einziger Arbeitspunkt mit den Protokollen und Metriken von Clustern, Service-Mesh, Gitops für die Verwaltung von Lasten in einem Multicluster und vieles mehr. Wir hoffen, dass Sie an unserer Erfahrung interessiert sind! 

Der Artikel wurde von A. Antipov, A. Ganush, Platform Engineers, verfasst. 

More articles:


All Articles