Wie Sie dank Kubernetes und Automatisierung in zwei Stunden in die Cloud migrieren

Die Firma „URUS“ hat Kubernetes in verschiedenen Formaten getestet: von der selbstständigen Bereitstellung auf Bare Metal über Google Cloud bis zur Migration ihrer Plattform in die Mail.ru Cloud Solutions (MCS). Igor Shishkin,t3ran, Senior Systemadministrator bei „URUS“, berichtet, wie sie einen neuen Cloud-Anbieter ausgewählt haben und wie es ihnen gelungen ist, innerhalb von nur zwei Stunden zu migrieren.

Was macht „URUS“?

Es gibt viele Möglichkeiten, die Qualität des städtischen Umfelds zu verbessern, und eine davon besteht darin, es umweltfreundlicher zu gestalten. Genau daran arbeitet die Firma „URUS – Intelligente digitale Dienste“. Hier werden Lösungen entwickelt, die Unternehmen helfen, wichtige ökologische Kennzahlen zu überwachen und negative Auswirkungen auf die Umwelt zu reduzieren. Sensoren sammeln Daten über die Luftzusammensetzung, den Lärmpegel und andere Parameter und senden diese dann an die zentrale Plattform „URUS – Ecomon“ zur Analyse und Erstellung von Empfehlungen.

Wie funktioniert „URUS“ intern?

Ein typischer Kunde von «URUS» ist ein Unternehmen, das in einem Wohngebiet oder in dessen Nähe angesiedelt ist. Das kann eine Fabrik, ein Hafen, ein Bahndepot oder ein anderer Standort sein. Wenn unser Kunde bereits eine Warnung erhalten hat, wegen Umweltverschmutzung bestraft wurde oder selbst den Lärm reduzieren und schädliche Emissionen verringern möchte, kommt er zu uns – und wir bieten ihm bereits eine Lösung für das Umweltmonitoring an.

Im Monitoring-Diagramm der H2S-Konzentration sind regelmäßige nächtliche Emissionen des benachbarten Unternehmens sichtbar.

Die Geräte, die wir bei «URUS» verwenden, sind mit mehreren Sensoren ausgestattet, die Informationen über den Gehalt bestimmter Gase, den Geräuschpegel und andere Daten zur Bewertung der Umweltbedingungen sammeln. Die genaue Anzahl der Sensoren wird immer durch die spezifische Aufgabe bestimmt.

Je nach Art der Messungen können Geräte mit Sensoren an Wänden von Gebäuden, an Masten und an anderen beliebigen Orten platziert werden. Jedes dieser Geräte sammelt Informationen, bündelt sie und sendet sie an das Empfangs-Gateway. Dort speichern wir die Daten langfristig und bereiten sie für die anschließende Analyse vor. Ein einfaches Beispiel für das, was wir nach der Analyse erhalten, ist der Luftqualitätsindex, auch bekannt als AQI.

Parallel dazu laufen viele andere Dienste auf unserer Plattform, die überwiegend unterstützender Natur sind. Beispielsweise sendet der Benachrichtigungsdienst unseren Kunden Mitteilungen, wenn eines der überwachten Parameter (zum Beispiel der CO2-Gehalt) den zulässigen Wert überschreitet.

Wie wir Daten speichern. Die Geschichte mit Kubernetes auf Bare Metal

Im Projekt zur Ekomonitoring "URUS" gibt es mehrere Datenspeicher. In einem von ihnen speichern wir rohe Daten – die Informationen, die wir direkt von den Geräten erhalten haben. Dieser Speicher funktioniert wie ein "magnetisches" Band, ähnlich wie bei alten Kassetten, mit einer Historie aller Messwerte. Der zweite Speichertyp wird für aufbereitete Daten verwendet – Informationen von Geräten, angereichert mit Metadaten über die Beziehungen zwischen den Sensoren und den Messwerten selbst, Zugehörigkeit zu Organisationen, Standorten usw. Diese Informationen ermöglichen es, die zeitliche Entwicklung bestimmter Werte zu bewerten. Den "rohen" Datenspeicher nutzen wir zudem als Backup und zur Wiederherstellung der aufbereiteten Daten, falls dies erforderlich wird.

Als wir vor einigen Jahren nach einer Lösung für unser Speicherproblem suchten, standen uns zwei Plattformen zur Auswahl: Kubernetes und OpenStack. Da OpenStack jedoch recht umfangreich wirkt (sehen Sie sich nur seine Architektur an, um das zu bestätigen), entschieden wir uns für Kubernetes. Ein weiteres Argument für die Wahl war das relativ einfache Management über Programmierung sowie die Möglichkeit, selbst physische Knoten flexibler nach Ressourcen aufzuteilen.

Parallel zur Einarbeitung in Kubernetes haben wir auch die Datenspeicherlösungen untersucht. Während wir unsere Speicherlösungen in Kubernetes auf unserer eigenen Hardware betrieben, haben wir hervorragende Expertise gesammelt. Alles, was wir damals hatten, lief auf Kubernetes: Stateful-Storage, ein Überwachungssystem, und CI/CD. Kubernetes wurde für uns zur All-in-One-Plattform.

Wir wollten jedoch mit Kubernetes als Service arbeiten, anstatt uns mit dessen Wartung und Entwicklung zu beschäftigen. Außerdem gefiel uns nicht, wie viel es kostete, dies auf Bare Metal zu betreiben, während wir ständig Entwicklertätigkeiten benötigten! Eine der ersten Aufgaben bestand darin, die Kubernetes Ingress-Controller in die Netzwerkstruktur unserer Organisation zu integrieren. Dies ist eine komplexe Aufgabe, besonders wenn man bedenkt, dass zu diesem Zeitpunkt nichts für die softwarebasierte Verwaltung von Ressourcen wie DNS-Einträgen oder Zuweisungen vorbereitet war. IP-AdressenSpäter begannen wir, mit externem Datenspeicher zu experimentieren. Wir kamen zwar nicht zur Implementierung des PVC-Controllers, aber es wurde bereits klar, dass dies ein erheblicher Arbeitsaufwand ist, für den wir spezielle Fachkräfte einsetzen müssen.

Der Übergang zu Google Cloud Platform ist eine vorübergehende Lösung.

Wir haben erkannt, dass es so nicht weitergehen kann, und haben unsere Daten von Bare Metal auf die Google Cloud Platform migriert. Tatsächlich gab es damals für russische Unternehmen nicht viele interessante Optionen: Neben Google Cloud Platform bot nur Amazon einen ähnlichen Service an. Wir entschieden uns jedoch für die Lösung von Google, da sie uns wirtschaftlich günstiger erschien und näher an Upstream lag. Ganz zu schweigen davon, dass Google selbst eine Art PoC Kubernetes in der Produktion ist.

Das erste ernsthafte Problem tauchte parallel zum Wachstum unserer Kundenbasis auf. Als wir die Notwendigkeit hatten, persönliche Daten zu speichern, standen wir vor der Wahl: entweder arbeiten wir mit Google und verletzen russische Gesetze, oder wir suchen nach Alternativen in Russland. Die Wahl war insgesamt vorhersehbar. 🙂

Wie wir den idealen Cloud-Service sahen

Zu Beginn unserer Suche wussten wir bereits, was wir von unserem zukünftigen Cloud-Anbieter erwarten wollten. Welchen Service suchten wir:

• Schnell und flexibel. So, dass wir jederzeit schnell einen neuen Knoten oder etwas anderes bereitstellen können.
• Kostengünstig. Wir hatten große Bedenken bezüglich der Finanzen, da wir in unseren Ressourcen eingeschränkt waren. Wir wussten bereits, dass wir mit Kubernetes arbeiten wollten, und die Herausforderung bestand nun darin, die Kosten zu minimieren, um die Effizienz dieser Lösung zu steigern oder zumindest beizubehalten.
• Automatisiert. Wir planten, den Service über die API zu nutzen, ohne Manager, Telefonate oder Situationen, in denen wir manuell mehrere Dutzend Nodes im Notfall hochfahren mussten. Da die meisten unserer Prozesse automatisiert sind, erwarteten wir dasselbe von dem Cloud-Service.
• Mit Servern in Russland. Natürlich beabsichtigten wir, die russischen Gesetze und das bekannte 152-FZ einzuhalten.

Zu der Zeit gab es in Russland nur wenige Kubernetes-Anbieter nach dem aaS-Modell, und bei der Auswahl eines Anbieters war es uns wichtig, unsere Prioritäten nicht zu opfern. Das Team von Mail.ru Cloud Solutions, mit dem wir begonnen haben zu arbeiten und das wir bis heute unterstützen, bot uns einen vollständig automatisierten Service mit API-Support und einem benutzerfreundlichen Steuerungs-Panel, das Horizon enthält – damit konnten wir schnell eine beliebige Anzahl von Nodes bereitstellen.

Wie wir in zwei Stunden zu MCS migrieren konnten

Bei solchen Migrationen sehen sich viele Unternehmen Herausforderungen und Rückschlägen gegenüber, aber in unserem Fall gab es keine. Wir hatten Glück: Da wir vor der Migration bereits auf Kubernetes gearbeitet hatten, mussten wir nur drei Dateien anpassen und konnten unsere Dienste auf der neuen Cloud-Plattform MCS starten. Ich erinnere daran, dass wir zu diesem Zeitpunkt vollständig von Bare Metal zu Google Cloud Platform gewechselt waren. Deshalb dauerte die eigentliche Migration nicht länger als zwei Stunden, plus etwas Zeit (ungefähr eine Stunde) für die Datenübertragung von unseren Geräten. Zu diesem Zeitpunkt verwendeten wir bereits Spinnaker (einen Multi-Cloud-CD-Service für Continuous Delivery). Diesen fügten wir ebenfalls schnell zum neuen Cluster hinzu und arbeiteten im gewohnten Modus weiter.

Dank der Automatisierung der Entwicklungs- und CI/CD-Prozesse wird Kubernetes in "URUS" von einem Spezialisten betreut (und das bin ich). In einer bestimmten Phase arbeitete ein weiterer Systemadministrator mit mir, aber später stellte sich heraus, dass wir die gesamte Routine bereits automatisiert hatten und die Anforderungen unseres Hauptprodukts immer mehr wurden. Daher macht es Sinn, die Ressourcen darauf zu konzentrieren.

Wir haben von dem Cloud-Anbieter das erhalten, was wir erwartet haben, da wir die Zusammenarbeit ohne Illusionen begonnen haben. Falls es irgendwelche Vorfälle gab, waren sie in der Regel technischer Natur und leicht durch die relative Neuheit des Services zu erklären. Das Wichtigste ist, dass das Team von MCS Mängel schnell behebt und zügig auf Fragen in Messengern reagiert.

Im Vergleich zu meiner Erfahrung mit der Google Cloud Platform wusste ich dort nicht einmal, wo sich der Feedback-Button befand, da ich ihn nie gebraucht habe. Wenn Probleme auftraten, verschickte Google einseitig Benachrichtigungen. Bei MCS hingegen betrachte ich es als großen Vorteil, dass sie sowohl geografisch als auch mental sehr nah an den russischen Kunden sind.

Wie wir die Arbeit mit Clouds in der Zukunft sehen

Derzeit ist unsere Arbeit eng mit Kubernetes verbunden, und es erfüllt uns hinsichtlich der infrastrukturellen Aufgaben vollständig. Daher planen wir nicht, irgendwohin zu migrieren, obwohl wir ständig neue Praktiken und Dienstleistungen einführen, um Routineaufgaben zu vereinfachen, neue Aufgaben zu automatisieren und die Stabilität sowie Zuverlässigkeit der Dienste zu erhöhen. Aktuell starten wir den Dienst Chaos Monkey (genauer gesagt verwenden wir chaoskube, aber das ändert nichts an dem Konzept :), der ursprünglich von Netflix entwickelt wurde. Chaos Monkey führt eine einfache Aufgabe aus: Er entfernt zu beliebigen Zeiten einen beliebigen Pod in Kubernetes. Das dient dazu, dass unser Dienst mit n–1 Instanzen reibungslos funktioniert, wodurch wir uns darauf trainieren, auf jegliche Störungen vorbereitet zu sein.

Heute betrachte ich den Einsatz von Drittanbieterlösungen – insbesondere Cloud-Plattformen – als die einzige richtige Wahl für junge Unternehmen. Zu Beginn ihrer Reise sind sie oft in ihren Ressourcen, sowohl personell als auch finanziell, eingeschränkt, und der Aufbau sowie die Pflege einer eigenen Cloud oder eines eigenen Rechenzentrums sind zu kostspielig und arbeitsintensiv. Cloud-Anbieter ermöglichen es, diese Kosten zu minimieren, da man schnell die benötigten Ressourcen für den Betrieb von Services hier und jetzt erhält, und diese Ressourcen nur nach Bedarf bezahlt. Was die Firma „URUS“ betrifft, so bleiben wir vorerst der Kubernetes-Lösung in der Cloud treu. Aber wer weiß, vielleicht müssen wir geografisch expandieren oder Lösungen auf Basis spezifischer Hardware implementieren. Oder vielleicht wird die Menge an benötigten Ressourcen die Anschaffung eines eigenen Kubernetes auf bare-metal rechtfertigen, wie in alten Zeiten. 🙂

Was wir aus der Erfahrung mit Cloud-Services gelernt haben

Wir haben Kubernetes auf Bare-Metal-Servern eingesetzt, und selbst dort war es auf seine Weise gut. Seine Stärken kamen jedoch besonders als aaS-Komponente in der Cloud zur Geltung. Mit einem klaren Ziel und maximaler Automatisierung lässt sich Vendor Lock-in vermeiden, und die Migration zwischen Cloud-Anbietern kann innerhalb von wenigen Stunden erfolgen, ohne dass unsere Nerven dabei leiden. Anderen Unternehmen empfehlen wir: Wenn Sie Ihren (Cloud-)Service mit begrenzten Ressourcen und maximaler Geschwindigkeit für die Entwicklung starten möchten, beginnen Sie jetzt mit der Miete von Cloud-Ressourcen und bauen Sie Ihr Rechenzentrum erst auf, nachdem Ihnen Forbes über die Schulter geschaut hat.

Quelle: habr.com