Das Unternehmen âURUSâ hat Kubernetes in verschiedenen Varianten ausprobiert: eigenstĂ€ndige Bereitstellung auf Bare Metal, in Google Cloud, und hat dann seine Plattform in die Mail.ru Cloud Solutions (MCS) migriert. Wie sie einen neuen Cloud-Anbieter auswĂ€hlten und wie es gelang, innerhalb von rekordverdĂ€chtigen zwei Stunden zu migrieren, erzĂ€hlt Igor Shishkin (), leitender Systemadministrator bei âURUSâ.
Womit beschĂ€ftigt sich âURUSâ
Es gibt viele Möglichkeiten, die QualitĂ€t des urbanen Raums zu verbessern, und eine davon ist, ihn ökologisch sicher zu gestalten. Genau daran arbeitet die Firma âURUS â Intelligente digitale Dienstleistungenâ. Hier werden Lösungen implementiert, die Unternehmen helfen, wichtige Umweltindikatoren zu ĂŒberwachen und negative Auswirkungen auf die Umwelt zu reduzieren. Sensoren sammeln Daten ĂŒber die Luftzusammensetzung, den GerĂ€uschpegel und andere Parameter, die dann an die einheitliche Plattform âURUS â Ecomonâ zur Analyse und Erstellung von Empfehlungen gesendet werden.
Wie die Arbeit von âURUSâ intern organisiert ist
Ein typischer Kunde von âURUSâ ist ein Unternehmen, das sich in oder in der NĂ€he eines Wohngebiets befindet. Das kann eine Fabrik, ein Hafen, ein Bahndepot oder ein anderes Objekt sein. Wenn unser Kunde bereits eine Warnung erhalten hat, wegen Umweltverschmutzung bestraft wurde oder selbst weniger LĂ€rm erzeugen und die Menge schĂ€dlicher Emissionen reduzieren möchte, kommt er zu uns, und wir bieten ihm bereits eine fertige Lösung zur ökologischen Ăberwachung an.
Im Ăberwachungsdiagramm der H2S-Konzentration sind regelmĂ€Ăige nĂ€chtliche Emissionen eines benachbarten Unternehmens sichtbar.
Die GerĂ€te, die wir bei âURUSâ verwenden, enthalten mehrere Sensoren, die Informationen ĂŒber den Gehalt bestimmter Gase, den GerĂ€uschpegel und andere Daten zur Bewertung der ökologischen Situation 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, Pfosten und an anderen beliebigen Orten platziert werden. Jedes dieser GerĂ€te sammelt Informationen, aggregiert sie und sendet sie an das DatenannahmGateway. Dort speichern wir die Daten fĂŒr die Langzeitarchivierung und bereiten sie fĂŒr die spĂ€tere Analyse auf. Ein einfaches Beispiel fĂŒr das, was wir nach der Analyse erhalten â ist der LuftqualitĂ€tsindex, auch bekannt als AQI.
Parallel zu unserer Plattform arbeiten viele andere Dienste, die jedoch hauptsĂ€chlich unterstĂŒtzender Natur sind. Zum Beispiel sendet der Benachrichtigungsdienst den Kunden Mitteilungen, wenn einer der ĂŒberwachten Parameter (zum Beispiel CO2-Gehalt) den zulĂ€ssigen Wert ĂŒberschreitet.
Wie wir Daten speichern. Die Geschichte mit Kubernetes auf Bare Metal.
Im Projekt zur ökologischen Ăberwachung 'URUS' gibt es mehrere Datenspeicher. In einem bewahren wir die "rohen" Daten auf â das, was wir direkt von den GerĂ€ten erhalten haben. Dieser Speicher fungiert wie ein "magnetisches" Band, wie bei alten Kassetten, mit der Geschichte aller Indikatoren. Der zweite Speicher wird fĂŒr die vorverarbeiteten Daten verwendet â Daten von GerĂ€ten, die durch Metadaten ĂŒber die Beziehungen zwischen Sensoren und den eigentlichen GerĂ€temessungen, Zugehörigkeit zu Organisationen, Standorte usw. angereichert sind. Diese Informationen ermöglichen es uns, dynamisch zu bewerten, wie sich ein bestimmter Indikator ĂŒber einen bestimmten Zeitraum verĂ€ndert hat. Den "rohen" Datenspeicher verwenden wir auch als Backup und zur Wiederherstellung der vorverarbeiteten Daten, falls dies erforderlich wird.
Als wir vor einigen Jahren nach einer Lösung fĂŒr das Speicherproblem suchten, hatten wir zwei Optionen fĂŒr die Plattformwahl: Kubernetes und OpenStack. Da letzterer jedoch ziemlich monströs aussieht (schauen Sie sich einfach seine Architektur an, um sich davon zu ĂŒberzeugen), entschieden wir uns fĂŒr Kubernetes. Ein weiteres Argument fĂŒr Kubernetes war die relativ einfache Programmverwaltung und die Möglichkeit, sogar physische Nodes flexibler nach Ressourcen zu partitionieren.
Parallel zur Einarbeitung in Kubernetes haben wir auch die Datenspeichermethoden untersucht. Solange wir alle unsere Speicherlösungen auf Kubernetes auf unserer eigenen Hardware betrieben, haben wir hervorragende Expertise gewonnen. Alles, was wir damals hatten, lebte auf Kubernetes: stateful Storage, Ăberwachungssystem, CI/CD. Kubernetes wurde fĂŒr uns zur All-in-One-Plattform.
Aber wir wollten mit Kubernetes als Service arbeiten und uns nicht um dessen Wartung und Entwicklung kĂŒmmern. AuĂerdem gefiel uns nicht, wie teuer es war, es auf Bare Metal zu betreiben, wĂ€hrend wir stĂ€ndig Entwicklungsbedarf hatten! Zum Beispiel war eine der ersten Aufgaben, die Ingress-Controller von Kubernetes in die Netzwerkstruktur unserer Organisation zu integrieren. Das ist eine umfangreiche Aufgabe, besonders wenn man bedenkt, dass zu diesem Zeitpunkt noch nichts fĂŒr das Software-Management von Ressourcen wie DNS-EintrĂ€gen oder Zuteilungen bereit war. IP-AdressenSpĂ€ter begannen wir, mit externem Datenspeicher zu experimentieren. Wir haben die Implementierung des PVC-Controllers nicht erreicht, aber schon damals war klar, dass dies ein groĂes Arbeitsfeld ist, fĂŒr das spezialisierte FachkrĂ€fte benötigt werden.
Der Wechsel zur 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 verschoben. TatsĂ€chlich gab es damals fĂŒr ein russisches Unternehmen nicht viele interessante Alternativen: Neben der Google Cloud Platform bot Amazon einen Ă€hnlichen Service an, aber wir haben uns letztendlich fĂŒr die Lösung von Google entschieden. Es schien uns wirtschaftlich vorteilhafter zu sein, nĂ€her am Upstream und nicht zu vergessen, dass Google an sich eine Art PoC fĂŒr Kubernetes in Produktion ist.
Das erste ernsthafte Problem tauchte auf, wĂ€hrend unsere Kundenbasis wuchs. Als wir die Notwendigkeit erkannten, persönliche Daten zu speichern, standen wir vor der Wahl: Entweder arbeiten wir mit Google und verletzen russische Gesetze oder wir suchen nach einer Alternative in Russland. Die Entscheidung war im GroĂen und Ganzen vorhersehbar. đ
Wie wir den idealen Cloud-Service sahen.
Zu Beginn unserer Suche wussten wir bereits, was wir von unserem zukĂŒnftigen Cloud-Anbieter erwarten. Welche Art von Service suchten wir:
- Schnell und flexibel.So, dass wir jederzeit schnell einen neuen Node hinzufĂŒgen oder etwas bereitstellen können.
- GĂŒnstig.. Wir waren sehr besorgt ĂŒber die finanziellen Aspekte, da wir in unseren Ressourcen eingeschrĂ€nkt waren. Wir wussten bereits, dass wir mit Kubernetes arbeiten wollten, und nun stand die Aufgabe im Raum, die Kosten zu minimieren, um die Effizienz bei der Nutzung dieser Lösung zu erhöhen oder zumindest zu erhalten.
- Automatisiert. Wir planten, ĂŒber die API mit dem Service zu arbeiten, ohne Manager, Telefonanrufe oder Situationen, in denen wir manuell mehrere Dutzend Knoten im Eiltempo hochfahren mussten. Da die meisten unserer Prozesse automatisiert sind, erwarteten wir das Gleiche von dem Cloud-Service.
- Mit Servern in der RF. NatĂŒrlich planten wir, die russischen Gesetze und das besagte 152-FZ einzuhalten.
Zu der Zeit gab es nur wenige Kubernetes-Anbieter nach dem aaS-Modell in Russland, und es war uns wichtig, bei der Auswahl des Anbieters nicht von unseren PrioritĂ€ten abzuweichen. Das Team von Mail.ru Cloud Solutions, mit dem wir zu arbeiten begonnen haben und das wir bis heute weiterhin unterstĂŒtzen, stellte uns einen vollstĂ€ndig automatisierten Service mit API-UnterstĂŒtzung und einem benutzerfreundlichen Control Panel zur VerfĂŒgung, in dem sich Horizon befindet â damit konnten wir eine beliebige Anzahl von Knoten schnell in Betrieb nehmen.
Wie wir in nur zwei Stunden in MCS migrieren konnten
Viele Unternehmen stoĂen bei Ă€hnlichen UmzĂŒgen auf Schwierigkeiten und Misserfolge, aber in unserem Fall gab es keine. Wir hatten GlĂŒck: Da wir vor der Migration bereits auf Kubernetes gearbeitet haben, mussten wir nur drei Dateien anpassen und unsere Dienste auf der neuen Cloud-Plattform, in MCS, starten. Ich erinnere daran, dass wir zu diesem Zeitpunkt endgĂŒltig von bare metal umgezogen waren und auf Google Cloud Platform lebten. Daher nahm der Umzug nicht mehr als zwei Stunden in Anspruch; dazu kam noch etwas Zeit (etwa eine Stunde) fĂŒr die DatenĂŒbertragung von unseren GerĂ€ten. Zu diesem Zeitpunkt nutzten wir bereits Spinnaker (einen multi-cloud CD-Service fĂŒr Continuous Delivery). Dies hatten wir auch zĂŒgig in den neuen Cluster integriert und konnten im gewohnten Modus weiterarbeiten.
Dank der Automatisierung der Entwicklungs- und CI/CD-Prozesse wird Kubernetes bei âURUSâ von nur einem Spezialisten betreut (und das bin ich). Zu einem bestimmten Zeitpunkt arbeitete ein anderer Systemadministrator mit mir zusammen, aber es stellte sich heraus, dass wir die gesamte Routine bereits automatisiert hatten und die Aufgaben in unserem Hauptprodukt immer mehr wurden, weshalb es sinnvoll war, die Ressourcen darauf zu konzentrieren.
Wir haben von unserem Cloud-Anbieter das erhalten, was wir erwartet haben, da wir die Zusammenarbeit ohne Illusionen begonnen haben. Wenn es einige VorfĂ€lle gab, waren sie in erster Linie technischer Natur und leicht durch die relative Neuheit des Services zu erklĂ€ren. Das Wichtigste ist, dass das MCS-Team schnell MĂ€ngel beseitigt und zĂŒgig auf Fragen in Messengern reagiert.
Verglichen mit der Arbeitserfahrung mit Google Cloud Platform wusste ich bei ihnen nicht einmal, wo sich der Feedback-Button befindet, da es einfach nicht nötig war. Und wenn es irgendwelche Probleme gab, hat Google einseitig Benachrichtigungen verschickt. Im Fall von MCS halte ich es fĂŒr einen groĂen Vorteil, dass sie rĂ€umlich und mental so 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 vollstĂ€ndig in Bezug auf infrastrukturelle Aufgaben. Daher planen wir nicht, davon irgendwohin zu migrieren, obwohl wir stĂ€ndig neue Praktiken und Dienstleistungen einfĂŒhren, um Routineaufgaben zu vereinfachen und neue zu automatisieren sowie die StabilitĂ€t und ZuverlĂ€ssigkeit der Services zu erhöhen⊠Momentan starten wir den Service Chaos Monkey (konkret nutzen wir chaoskube, aber das Ă€ndert nichts an der Konzeption :), der ursprĂŒnglich bei Netflix entwickelt wurde. Chaos Monkey macht eine einfache Sache: Er löscht zu beliebiger Zeit einen beliebigen Pod in Kubernetes. Das ist nötig, damit unser Service mit der Anzahl Instanzen nâ1 stabil funktioniert; so gewöhnen wir uns daran, auf alle Störungen vorbereitet zu sein.
Heute sehe ich die Nutzung von Drittanbieter-Lösungen â denselben Cloud-Plattformen â als den einzig richtigen Weg fĂŒr junge Unternehmen. Zu Beginn sind sie oft mangels Ressourcen, sowohl personell als auch finanziell, eingeschrĂ€nkt, und ein eigenes Cloud- oder Rechenzentrum aufzubauen und zu betreiben ist zu kostspielig und arbeitsintensiv. Cloud-Anbieter ermöglichen es, diese Ausgaben zu minimieren, da man schnell die benötigten Ressourcen fĂŒr den sofortigen Betrieb der Dienste erhalten kann und nur nach Bedarf bezahlt. Was die Firma âURUSâ betrifft, so bleiben wir vorerst Kubernetes in der Cloud treu. Aber wer weiĂ, vielleicht mĂŒssen wir geografisch expandieren oder Lösungen basierend auf spezifischer Hardware implementieren. Oder vielleicht wird die Menge an verbrauchten Ressourcen ein eigenes Kubernetes auf bare-metal rechtfertigen, wie in den guten alten Zeiten. đ
Was wir aus der Erfahrung mit Cloud-Diensten gelernt haben
Wir haben begonnen, Kubernetes auf bare metal zu verwenden, und selbst dort war es auf seine Weise hervorragend. Aber seine StĂ€rken konnten insbesondere als aaS-Komponente in der Cloud voll zur Geltung kommen. Wenn man ein Ziel setzt und alles maximal automatisiert, kann man Vendor Lock-in vermeiden, und der Umzug zwischen Cloud-Anbietern dauert nur ein paar Stunden, wĂ€hrend unsere Nervenzellen erhalten bleiben. Anderen Unternehmen können wir empfehlen: Wenn ihr euren (Cloud-)Dienst mit begrenzten Ressourcen und maximaler Entwicklungsgeschwindigkeit starten möchtet, beginnt jetzt sofort mit der Anmietung von Cloud-Ressourcen und baut euer Rechenzentrum erst, nachdem Forbes ĂŒber euch geschrieben hat.
Quelle: habr.com
