Hallo, Habr!
Wir stellen das Team der Plattform von Exness vor. Zuvor haben unsere Kolleg*innen bereits einen Artikel über . Heute möchten wir unsere Erfahrungen mit der Migration von Diensten nach Kubernetes teilen.
Zunächst möchten wir einige Zahlen präsentieren, um ein besseres Verständnis für das Thema zu vermitteln:
- Unser Entwicklungsteam besteht aus über 100 Personen, darunter mehr als 10 verschiedene Teams mit eigenständigen QA-, DevOps- und Scrum-Prozessen. Der Technologiestack umfasst Python, PHP, C++, Java und Golang.
- Die Größe der Test- und Produktionsumgebung liegt bei etwa 2000 Containern in jeder Umgebung. Diese werden von Rancher v1.6 auf eigener Virtualisierung und unter VMware verwaltet.
Motivation
Wie man so schön sagt, nichts ist für immer unter dem Mond, und Rancher hat vor einiger Zeit die Unterstützung von Version 1.6 eingestellt. Ja, wir haben über drei Jahre lang gelernt, es zu konfigurieren und Probleme zu lösen, aber wir hatten immer häufiger mit Schwierigkeiten zu kämpfen, die nie behoben werden. Außerdem hat Rancher 1.6 ein veraltetes System zur Vergabe von Berechtigungen, bei dem man entweder fast alles oder gar nichts machen kann.
Eigene Virtualisierung bot zwar mehr Kontrolle über die Datenspeicherung und -sicherheit, brachte jedoch Betriebskosten mit sich, die schwer zu akzeptieren waren, angesichts des ständigen Wachstums des Unternehmens, der Anzahl der Projekte und der damit verbundenen Anforderungen.
Wir wollten den IaC-Standards folgen und bei Bedarf schnell Kapazitäten in jeder geografischen Lage ohne Vendor Lock-in erhalten sowie die Möglichkeit haben, diese schnell wieder abzulehnen.
Erste Schritte
Vor allem wollten wir auf moderne Technologien und Lösungen setzen, die den Teams schnellere Entwicklungszyklen ermöglichen und die Betriebskosten für die Interaktion mit der Leistungsplattform minimieren.
Natürlich kam uns zuerst Kubernetes in den Sinn, aber wir wollten nicht übereilen und führten eine kleine Untersuchung durch, um die Richtigkeit unserer Wahl zu überprüfen. Wir haben nur Open-Source-Lösungen evaluiert, und in diesem ungleichen Wettkampf gewann Kubernetes ohne Zweifel.
Als Nächstes stellte sich die Frage nach dem Auswahlwerkzeug für die Erstellung von Clustern. Wir verglichen die beliebtesten Lösungen: kops, kubespray, kubeadm.
Für den Start schien uns kubeadm ein zu komplizierter Weg zu sein, eher eine Art Erfinder des „Rades“, während kops an Flexibilität mangelte.
Und der Sieger ist:
Wir haben begonnen, Experimente mit unserer eigenen Virtualisierung und AWS durchzuführen, um eine ungefähre Nachbildung unseres vorherigen Ressourcenverwaltungsansatzes zu schaffen, bei dem alle denselben „Cluster“ nutzen. Und hier ist unser erster Cluster mit 10 kleinen virtuellen Maschinen, von denen sich einige in AWS befinden. Wir haben begonnen, Teams dorthin zu migrieren, anscheinend wurde alles „gut“, und die Geschichte könnte hier enden, aber...
Die ersten Probleme
Ansible – die Grundlage von kubespray – ist nicht das Werkzeug, das es ermöglicht, IaC zu folgen: Bei der Ein- und Ausgabe von Knoten aus der Produktion lief ständig etwas schief, und es erforderte irgendeine Art von Eingreifen, und bei der Verwendung verschiedener Betriebssysteme verhielt sich das Playbook unterschiedlich. Mit der steigenden Anzahl von Teams und Knoten im Cluster stellten wir fest, dass das Playbook immer länger dauerte, unser Rekord lag schließlich bei 3,5 Stunden, und Ihrer? 🙂
Und es scheint, dass kubespray einfach Ansible ist, und alles auf den ersten Blick klar ist, aber:
Zu Beginn lag die Aufgabe darin, die Kapazitäten nur in AWS und Virtualisierungen zu starten, aber wie so oft änderten sich die Anforderungen.
In diesem Licht wurde klar, dass unser altes Muster der Zusammenführung von Ressourcen in ein Orchestrierungssystem nicht geeignet war — insbesondere wenn Cluster weit voneinander entfernt und von verschiedenen Anbietern verwaltet werden.
Es wird noch komplizierter. Wenn alle Teams innerhalb eines Clusters arbeiten, konnten verschiedene Dienste mit falsch konfigurierten NodeSelectors auf „fremde“ Hosts anderer Teams gelangen und dort Ressourcen verbrauchen, während bei einer Taint-Vergabe ständig Beschwerde eingereicht wurde, dass jener oder andere Dienst nicht funktioniert oder aufgrund menschlichen Versagens nicht richtig verteilt wird. Ein weiteres Problem war die Kostenberechnung, insbesondere angesichts der Schwierigkeiten bei der Verteilung von Diensten auf Nodes.
Ein eigenes Kapitel war die Vergabe von Rechten an Mitarbeiter: Jedes Team wollte „an der Spitze“ des Clusters stehen und ihn vollständig verwalten, was zu einem vollständigen Kollaps führen konnte, da die Teams größtenteils unabhängig voneinander sind.
Was tun?
Angesichts der oben genannten Aspekte und den Wünschen der Teams, unabhängiger zu agieren, sind wir zu einer einfachen Schlussfolgerung gekommen: ein Team — ein Cluster.
So haben wir einen zweiten Cluster eingeführt:
Und dann den dritten Cluster:
Hier haben wir angefangen zu überlegen: Angenommen, unsere Teams haben in einem Jahr nicht nur einen Cluster? In verschiedenen geografischen Zonen zum Beispiel, oder unter der Verwaltung verschiedener Anbieter? Und könnte jemand von ihnen wollen, die Möglichkeit zu haben, schnell einen temporären Cluster für Tests einzurichten?
Das wäre der volle Kubernetes! Das klingt nach einem MultiKubernetes.
Zugleich müssen wir alle diese Cluster irgendwie verwalten, den Zugriff darauf einfach steuern und neue erstellen sowie alte außer Betrieb nehmen, ohne manuelles Eingreifen.
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 eine Lösung auf dem Markt gibt — Rancher 2.2.
In der ersten Phase unserer Untersuchungen hatte Rancher Labs bereits die erste Version 2 veröffentlicht. Obwohl sie sich schnell bereitstellen ließ, indem man einen Container ohne externe Abhängigkeiten mit ein paar Parametern oder über das offizielle HELM Chart startete, schien sie uns unausgereift, und wir wussten nicht, ob wir uns auf diese Lösung verlassen konnten und ob sie weiterentwickelt oder schnell aufgegeben würde. Das Konzept, dass ein Cluster = Klicks in der Benutzeroberfläche war, war ebenfalls nicht für uns geeignet, und wir wollten uns nicht an RKE binden, da dies ein recht spezialisierter Tool ist.
Die Version Rancher 2.2 hatte bereits einen funktionierenden Eindruck und bot zusammen mit den vorherigen interessanten Möglichkeiten direkt aus der Box, wie die Integration mit vielen externen Anbietern, einen einheitlichen Verteilungspunkt für Berechtigungen und kubeconfig-Dateien, sowie die Ausführung des kubectl-Images mit Ihren Rechten in der Benutzeroberfläche, inklusive verschachtelter Namespaces aka Projekte.
Um Rancher 2 herum hatte sich bereits eine Community gebildet, und es wurde ein Provider HashiCorp Terraform zur Verwaltung erstellt, der uns half, alles zusammenzuführen.
Was entstanden ist
So entstand ein kleiner Cluster, in dem Rancher läuft, der für alle anderen Cluster zugänglich ist, sowie viele damit verbundene Cluster, auf die man ebenso einfach zugreifen kann, wie man einen Benutzer im LDAP-Verzeichnis hinzufügt, unabhängig davon, wo er sich befindet und welche Ressourcen er von welchem Anbieter nutzt.
Mit GitLab-CI und Terraform wurde ein System geschaffen, das es ermöglicht, Cluster jeder Konfiguration in Cloud-Anbietern oder unserer eigenen Infrastruktur zu erstellen und sie mit Rancher zu verbinden. Das gesamte Verfahren erfolgt im IaC-Stil, wobei jeder Cluster in einem Repository beschrieben und dessen Zustand versioniert wird. Dabei werden die meisten Module aus externen Repositories eingebunden, sodass nur Variablen übergeben oder eine eigene benutzerdefinierte Konfiguration für Instanzen beschrieben werden muss, was hilft, die Code-Wiederholungsquote zu verringern.
Natürlich ist unsere Reise noch lange nicht zu Ende, und es stehen noch viele interessante Aufgaben bevor, wie ein einheitlicher Zugang zu Logs und Metriken aller Cluster, Service Mesh, GitOps zur Lastenverwaltung in Multi-Cluster-Umgebungen und vieles mehr. Wir hoffen, dass Sie an unseren Erfahrungen interessiert sind!
Der Artikel wurde von A. Antipov, A. Ganush, Plattform-Engineers verfasst.
Quelle: habr.com
