Hey Habr!
Wir vertreten das Exness-Plattformteam. Zuvor haben unsere Kollegen bereits einen Artikel darüber geschrieben . Heute möchten wir unsere Erfahrungen bei der Migration von Diensten auf Kubernetes teilen.
Zunächst bieten wir Ihnen einige Zahlen an, damit Sie besser verstehen, worüber wir sprechen werden:
- Unsere Entwicklungsabteilung besteht aus über 100 Personen, darunter mehr als 10 verschiedene Teams mit eigenständigen QA-, DevOps- und Scrum-Prozessen. Entwicklungsstack – Python, PHP, C++, Java und Golang.
- Die Größe der Test- und Produktionsumgebung beträgt jeweils etwa 2000 Container. Sie führen Rancher v1.6 auf ihrer eigenen Virtualisierung und unter VMware aus.
Motivation
Wie man so schön sagt, währt nichts ewig und Rancher hat schon vor langer Zeit das Ende des Supports für Version 1.6 angekündigt. Ja, in mehr als drei Jahren haben wir gelernt, uns darauf vorzubereiten und auftretende Probleme zu lösen, aber immer häufiger stehen wir vor Problemen, die nie behoben werden können. Rancher 1.6 verfügt außerdem über ein verknöchertes System zur Rechtevergabe, bei dem man entweder fast alles oder nichts tun kann.
Obwohl die proprietäre Virtualisierung eine bessere Kontrolle über die Datenspeicherung und deren Sicherheit ermöglichte, verursachte sie Betriebskosten, die angesichts des stetigen Wachstums des Unternehmens, der Anzahl der Projekte und der damit verbundenen Anforderungen schwer zu akzeptieren waren.
Wir wollten den IaC-Standards folgen und bei Bedarf schnell, an jedem geografischen Standort und ohne Herstellersperre Kapazitäten erhalten und diese auch schnell wieder aufgeben können.
Erste Schritte
Zunächst wollten wir uns auf moderne Technologien und Lösungen verlassen, die den Teams einen schnelleren Entwicklungszyklus ermöglichen und die Betriebskosten für die Interaktion mit der Plattform, die die Stromversorgung bereitstellt, minimieren.
Natürlich kam uns als Erstes Kubernetes in den Sinn, aber wir waren nicht begeistert und haben ein wenig recherchiert, um herauszufinden, ob es die richtige Wahl war. Wir haben nur Open-Source-Lösungen bewertet und in einem unfairen Kampf hat Kubernetes bedingungslos gewonnen.
Als nächstes stellte sich die Frage nach der Auswahl eines Tools zum Erstellen von Clustern. Wir haben die beliebtesten Lösungen verglichen: kops, kubespray, kubeadm.
Zunächst erschien uns kubeadm als ein zu komplizierter Weg, eher wie eine Art Erfinder eines „Fahrrads“, und kops verfügte nicht über genügend Flexibilität.
Und der Gewinner war:
Wir begannen mit unserer eigenen Virtualisierung und AWS zu experimentieren und versuchten, etwas nachzubilden, das in etwa unserem vorherigen Ressourcenverwaltungsmuster ähnelte, bei dem sich alle den gleichen „Cluster“ teilten. Und jetzt haben wir unseren ersten Cluster aus 10 kleinen virtuellen Maschinen, von denen sich einige in AWS befinden. Wir begannen zu versuchen, Teams dorthin zu migrieren, alles schien „gut“ zu sein und die Geschichte konnte zu Ende gebracht werden, aber ...
Erste Probleme
Auf Ansible basiert Kubespray. Es ist kein Tool, mit dem Sie IaC verfolgen können: Bei der Inbetriebnahme/Außerbetriebnahme von Knoten ging ständig etwas schief und es war ein Eingriff erforderlich, und bei der Verwendung verschiedener Betriebssysteme verhielt sich das Playbook anders. anders . Als die Anzahl der Teams und Knoten im Cluster wuchs, bemerkten wir, dass die Fertigstellung des Playbooks immer länger dauerte. Infolgedessen lag unser Rekord bei 3,5 Stunden. Was ist mit Ihrem? 🙂
Und es scheint, als wäre Kubespray nur Ansible, und auf den ersten Blick ist alles klar, aber:
Zu Beginn der Reise bestand die Aufgabe darin, Kapazitäten nur in AWS und in der Virtualisierung einzuführen, doch dann änderten sich, wie so oft, die Anforderungen.
Vor diesem Hintergrund wurde klar, dass unser altes Muster, Ressourcen in einem Orchestrierungssystem zu bündeln, nicht geeignet war – für den Fall, dass die Cluster sehr weit entfernt sind und von verschiedenen Anbietern verwaltet werden.
Außerdem. Wenn alle Teams innerhalb desselben Clusters arbeiten, könnten verschiedene Dienste mit falsch installierten NodeSelectors zum „fremden“ Host eines anderen Teams fliegen und dort Ressourcen nutzen, und wenn Taint gesetzt war, gab es ständig Anfragen, dass der eine oder andere Dienst nicht funktionierte. aufgrund menschlicher Faktoren nicht korrekt verteilt. Ein weiteres Problem war die Berechnung der Kosten, insbesondere angesichts der Probleme bei der Verteilung von Diensten auf Knoten.
Eine andere Geschichte war die Gewährung von Rechten an Mitarbeiter: Jedes Team wollte „an der Spitze“ des Clusters stehen und ihn vollständig verwalten, was zu einem völligen Zusammenbruch führen könnte, da die Teams grundsätzlich unabhängig voneinander sind.
Was ist zu tun?
Unter Berücksichtigung des oben Gesagten und des Wunsches der Teams nach mehr Unabhängigkeit kamen wir zu einer einfachen Schlussfolgerung: ein Team – ein Cluster.
Also haben wir ein zweites bekommen:
Und dann der dritte Cluster:
Dann begannen wir zu überlegen: Nehmen wir an, dass unsere Teams in einem Jahr mehr als einen Cluster haben werden? Zum Beispiel in unterschiedlichen geografischen Gebieten oder unter der Kontrolle verschiedener Anbieter? Und einige von ihnen möchten für einige Tests schnell einen temporären Cluster bereitstellen.
Vollständiges Kubernetes würde kommen! Es stellt sich heraus, dass es sich hierbei um eine Art MultiKubernetes handelt.
Gleichzeitig müssen wir alle alle diese Cluster irgendwie verwalten, den Zugriff darauf einfach verwalten sowie ohne manuelles Eingreifen neue erstellen und alte stilllegen.
Seit Beginn unserer Reise in die Welt von Kubernetes ist einige Zeit vergangen und wir haben beschlossen, die verfügbaren Lösungen noch einmal zu prüfen. Es stellte sich heraus, dass es ihn bereits auf dem Markt gibt – Rancher 2.2.
In der ersten Phase unserer Recherche hatte Rancher Labs bereits die erste Veröffentlichung von Version 2 erstellt, aber obwohl diese sehr schnell durch den Start eines Containers ohne externe Abhängigkeiten mit ein paar Parametern oder durch die Verwendung des offiziellen HELM-Diagramms erhöht werden konnte, schien sie grob zu sein für uns, und wir wussten nicht, ob wir uns auf diese Entscheidung verlassen können, ob sie entwickelt oder schnell aufgegeben wird. Auch das Cluster = Klicks-Paradigma in der Benutzeroberfläche selbst passte nicht zu uns und wir wollten uns nicht an RKE binden, da es sich um ein eher eng fokussiertes Tool handelt.
Version Rancher 2.2 hatte bereits ein funktionsfähigeres Erscheinungsbild und verfügte zusammen mit den vorherigen über eine Reihe interessanter Funktionen, wie z. B. die Integration mit vielen externen Anbietern, einen einzigen Punkt für die Verteilung von Rechten und kubeconfig-Dateien sowie den Start von kubectl Bild mit Ihren Rechten in der Benutzeroberfläche, verschachtelte Namespaces, auch Projekte genannt.
Es gab auch bereits eine Community rund um Rancher 2, und ein Anbieter namens HashiCorp Terraform wurde gegründet, um sie zu verwalten, was uns dabei half, alles zusammenzustellen.
Was ist passiert
Als Ergebnis hatten wir einen kleinen Cluster, auf dem Rancher ausgeführt wurde und der für alle anderen Cluster sowie für viele damit verbundene Cluster zugänglich war. Der Zugriff auf jeden von ihnen kann einfach durch das Hinzufügen eines Benutzers zum LDAP-Verzeichnis gewährt werden, unabhängig davon wo es sich befindet und welche Ressourcen des Anbieters es nutzt.
Mithilfe von gitlab-ci und Terraform wurde ein System erstellt, mit dem Sie Cluster beliebiger Konfiguration bei Cloud-Anbietern oder unserer eigenen Infrastruktur erstellen und diese mit Rancher verbinden können. All dies geschieht im IaC-Stil, wobei jeder Cluster durch ein Repository beschrieben und sein Zustand versioniert wird. Gleichzeitig sind die meisten Module über externe Repositorys verbunden, sodass nur noch Variablen übergeben oder Ihre benutzerdefinierte Konfiguration für Instanzen beschrieben werden müssen, was dazu beiträgt, den Prozentsatz der Codewiederholungen zu reduzieren.
Natürlich ist unsere Reise noch lange nicht zu Ende und es liegen noch viele interessante Aufgaben vor uns, wie zum Beispiel ein Single Point of Work mit Protokollen und Metriken beliebiger Cluster, Service Mesh, Gitops zur Lastverwaltung in einem Multicluster und vieles mehr. Wir hoffen, dass Sie unsere Erfahrung interessant finden!
Der Artikel wurde von A. Antipov, A. Ganush, Platform Engineers, verfasst.
Source: habr.com