Ende Mai fand ein Online-Meetup zum Thema statt . Wir sprachen über Container, Kubernetes und Orchestrierung im Allgemeinen, über Kriterien für die Auswahl von Infrastruktur und vieles mehr. Die Teilnehmer teilten ihre eigenen Anwendungsfälle.
Teilnehmer:
- Evgenij Potapov, CEO von „ITSumma“. Mehr als die Hälfte seiner Kunden wechselt bereits oder plant den Wechsel zu Kubernetes.
- Dmitrij Stolyarov, CTO von „Flant“. Verfügt über mehr als 10 Jahre Erfahrung mit Containern.
- Denis Remchukov (aka Eric Oldmann), COO von argotech.io, ehemaliger RAO EES. Er versprach, über Anwendungsfälle im „blutigen“ Enterprise zu berichten.
- Andrej Fedorowski, CTO von „News360.com“. Nach dem Kauf des Unternehmens durch einen anderen Akteur ist er für eine Reihe von ML- und AI-Projekten sowie die Infrastruktur verantwortlich.
- Ivan Kruglov, Systemingenieur, ehemaliger Booking.com.Derjenige, der mit seinen Händen viel in Kubernetes erreicht hat.
Themen:
- Einblicke der Teilnehmer zu Containern und Orchestrierung (Docker, Kubernetes und mehr); was sie in der Praxis ausprobiert oder analysiert haben.
- Fallstudie: Das Unternehmen entwickelt einen Infrastrukturentwicklungsplan für die kommenden Jahre. Wie wird entschieden, ob die Infrastruktur auf Containern und Kubernetes aufgebaut oder umgestellt werden soll?
- Herausforderungen in der Cloud-Native-Welt, was fehlt, lassen Sie uns spekulieren, wie die Zukunft aussieht.
Es entstand eine interessante Diskussion, die Meinungen der Teilnehmer waren so unterschiedlich und haben so viele Kommentare ausgelöst, dass ich sie mit Ihnen teilen möchte. Es gibt , und hier ist eine Zusammenfassung der Diskussion.
Ist Kubernetes bereits der Standard oder einfach gutes Marketing?
„Wir sind zu ihm (Kubernetes. — Red.) gekommen, als noch niemand davon wusste. Wir sind zu ihm gekommen, als es noch nicht existierte. Wir wollten es schon vorher“ — Dmitri Stolyarov
Foto von Reddit.com
Vor 5-10 Jahren gab es eine Vielzahl von Tools, aber keinen einheitlichen Standard. Alle sechs Monate erschien ein neues Produkt, manchmal sogar mehrere. Zunächst Vagrant, dann Salt, Chef, Puppet,… „Und du baust deine Infrastruktur alle sechs Monate um. Du hast fünf Admins, die ständig damit beschäftigt sind, Konfigurationen neu zu schreiben“, erinnert sich Andrey Fedorovsky. Er meint, dass Docker und Kubernetes die anderen „überrollt“ haben. Docker hat sich in den letzten fünf Jahren als Standard etabliert, Kubernetes in den letzten zwei Jahren. Und das ist gut für die Branche..
Dmitrij Stoljarov und sein Team lieben Kubernetes. Sie haben nach einem solchen Tool gesucht, bevor es überhaupt auf den Markt kam, und sind darauf gestoßen, als noch niemand darüber wusste. Derzeit nehmen sie keinen Kunden an, wenn sie sich sicher sind, dass sie Kubernetes nicht implementieren können. Laut Dmitrij hat das Unternehmen "eine Vielzahl von riesigen Erfolgen bei der Umwandlung von schrecklichem Legacy".
Kubernetes ist nicht nur eine Container-Orchestrierung, es ist ein Konfigurationsmanagement-System mit einer entwickelten API, Netzwerkkomponenten, L3-Lastenausgleich und Ingress-Controllern, das eine vergleichsweise einfache Verwaltung von Ressourcen, Skalierung und Abstraktion von den unteren Infrastrukturebenen ermöglicht.
Leider muss man für alles im Leben bezahlen. Und diese Steuer ist hoch, besonders wenn es um den Wechsel zu Kubernetes für Unternehmen mit einer entwickelten Infrastruktur geht, wie Ivan Kruglov meint. Er könnte problemlos in einem Unternehmen mit traditioneller Infrastruktur sowie mit Kubernetes arbeiten. Es ist wichtig, die Besonderheiten des Unternehmens und des Marktes zu verstehen. Aber für Evgeny Potapov, der Kubernetes als jedes andere Werkzeug zur Orchestrierung von Containern verallgemeinern würde, stellt sich diese Frage nicht.
Eugene zog eine Parallele zu der Situation in den 1990er Jahren, als objektorientierte Programmierung aufkam, um komplexe Anwendungen zu programmieren. Zu dieser Zeit gab es laufende Debatten und es tauchten neue Werkzeuge auf, die OOP unterstützten. Dann kamen Microservices als Möglichkeit, sich von der monolithischen Konzeption zu lösen. Dies führte wiederum zur Entstehung von Containern und Tools zu deren Verwaltung. "Ich denke, dass wir bald zu der Zeit kommen werden, in der die Frage, ob man eine kleine Anwendung mikroservicebasiert entwickeln sollte, keine Rolle mehr spielen wird; es wird standardmäßig als Microservice geschrieben," meint er. Ähnlich werden Docker und Kubernetes im Laufe der Zeit zur Standardlösung werden, ohne dass eine Wahl notwendig ist.
Das Problem von Datenbanken ist stateless
Foto von
Heutzutage gibt es viele Rezepte, um Datenbanken in Kubernetes zu starten. Auch wie man den Teil, der mit Disk I/O arbeitet, von dem, sagen wir, Anwendungs-Teil der Datenbank trennt. Ist es möglich, dass sich Datenbanken in der Zukunft so weit entwickeln, dass sie in einer Box geliefert werden, in der ein Teil über Docker und Kubernetes orchestriert wird, während der andere Teil der Infrastruktur, über spezielle Software, den Storage-Bereich bereitstellt? Werden Datenbanken sich als Produkt verändern?
Diese Beschreibung ähnelt dem Management von Warteschlangen, aber die Anforderungen an Zuverlässigkeit und Synchronität von Informationen in traditionellen Datenbanken sind erheblich höher, meint Andrey. Die Cache-Trefferquote liegt in normalen Datenbanken bei etwa 99 %. Wenn ein Worker ausfällt, wird ein neuer gestartet und der Cache wird von Grund auf neu „aufgewärmt“. Solange der Cache nicht aufgewärmt ist, arbeitet der Worker langsam, was bedeutet, dass er keine Benutzerlast verarbeiten kann. Solange keine Benutzerlast vorhanden ist, wird der Cache nicht aufgeheizt. Es ist ein Teufelskreis.
Dmitry ist grundsätzlich anderer Meinung — Quoren und Sharding lösen das Problem. Aber Andrey besteht darauf, dass diese Lösung nicht für alle geeignet ist. In einigen Situationen kann ein Quorum geeignet sein, doch es verursacht zusätzliche Belastungen im Netzwerk. Eine NoSQL-Datenbank ist nicht immer die passende Lösung.
Die Teilnehmer des Meetups teilten sich in zwei Lager.
Denis und Andrei behaupten, dass alles, was auf die Festplatte geschrieben wird – Datenbanken und mehr – im aktuellen K8s-Ökosystem unmöglich ist. Es ist unmöglich, die Integrität und Konsistenz produktiver Daten in Kubernetes zu gewährleisten. Das ist eine grundsätzliche Eigenschaft. Lösung: hybride Infrastruktur.
Selbst moderne Cloud-native Datenbanken wie MongoDB und Cassandra oder Messaging-Queues wie Kafka oder RabbitMQ erfordern persistente Datenspeicher außerhalb von Kubernetes.
Eugene widerspricht: „Datenbanken in K8s sind ein Trauma, das mit Russland oder dem Enterprise-Bereich zusammenhängt, was darauf zurückzuführen ist, dass es in Russland keine Cloud-Adoption gibt.“ Kleine oder mittlere Unternehmen im Westen setzen auf Cloud. Amazon RDS-Datenbanken sind einfacher zu nutzen, als sich selbst mit Kubernetes auseinanderzusetzen. In Russland wird K8s „on-premise“ eingesetzt, und Datenbanken werden dorthin verschoben, wenn versucht wird, den Zoo loszuwerden.
Dmitrij war ebenfalls anderer Meinung, dass keine Datenbanken in Kubernetes betrieben werden können: „Es gibt Unterschiede zwischen Datenbanken. Wenn man eine riesige relationale Datenbank verwendet, ist das auf keinen Fall ratsam. Aber wenn es sich um etwas Kleines und Cloud-Native handelt, das mental für eine halb-vergängliche Lebensweise bereit ist, wird alles gut.“ Dmitrij erwähnte außerdem, dass die Datenbankverwaltungstools weder für Docker noch für Kubernetes bereit sind, weshalb große Schwierigkeiten auftreten.
Ivan ist seinerseits überzeugt, dass selbst wenn man abstrahiert von den Begriffen stateful und stateless, das Ökosystem der Unternehmenslösungen in Kubernetes noch nicht vorbereitet ist. Mit Kubernetes ist es schwierig, die Anforderungen von Gesetzen und Regulierungsbehörden aufrechtzuerhalten. Beispielsweise ist es unmöglich, eine Identitätslösung zu schaffen, bei der strenge Identifikationsgarantien des Servers erforderlich sind, bis hin zur Hardware, die in die Server eingebaut wird. Dieser Bereich entwickelt sich, aber eine Lösung gibt es bisher nicht.
Die Teilnehmer konnten sich nicht einigen, daher wird es in diesem Teil der Schlussfolgerungen keine Folge geben. Stattdessen möchten wir einige praktische Beispiele anführen.
Fall 1. Cybersicherheit des „Megaregulierers“ mit Datenbanken außerhalb von Kubernetes.
In einem umfassenden Cybersecurity-System ermöglicht der Einsatz von Containern und Orchestrierung, Angriffe und Eindringungen abzuwehren. Zum Beispiel hat Denis in einem großen Regulator mit seinem Team eine Verbindung zwischen einem Orchestrator und einem intelligenten SIEM-Service implementiert, der Protokolle in Echtzeit analysiert und den Angriffs-, Einbruchs- oder Ausfallprozess identifiziert. Bei einem Angriff, dem Versuch, etwas einzuschleusen, oder im Falle eines Ransomware-Virus aktiviert er über den Orchestrator Container mit Anwendungen schneller, als sie infiziert werden, oder schneller, als der Angreifer sie angreift.
Fall 2. Teilweiser Umzug der Datenbanken von Booking.com nach Kubernetes
Bei Booking.com ist die Hauptdatenbank MySQL mit asynchroner Replikation — es gibt einen Master und eine gesamte Hierarchie von Slaves. Zum Zeitpunkt von Ivans Ausscheiden aus dem Unternehmen wurde ein Projekt gestartet, um Slaves zu transferieren, die mit einem bestimmten Verlust "abgekoppelt" werden können.
Neben der Hauptdatenbank gibt es eine Installation von Cassandra mit einer selbstgeschriebenen Orchestrierung, die bereits vor dem Mainstream-Eintritt von Kubernetes entwickelt wurde. In dieser Hinsicht gibt es keine Probleme, aber sie verwendet persistente lokale SSDs. Remote-Speicher, selbst innerhalb eines Rechenzentrums, werden aufgrund hoher Latenzprobleme nicht verwendet.
Die dritte Klasse von Datenbanken ist der Suchdienst von Booking.com, wobei jeder Knoten des Dienstes eine Datenbank darstellt. Die Versuche, den Suchdienst in Kubernetes zu migrieren, sind gescheitert, da jeder Knoten 60 bis 80 GB lokalen Speicher benötigt, der schwer 'hochzuziehen' und 'aufzuheizen' ist.
Infolgedessen wurde der Suchalgorithmus nicht nach Kubernetes migriert, und Ivan glaubt nicht, dass in naher Zukunft neue Versuche unternommen werden. Die MySQL-Datenbank wurde nur teilweise migriert: nur die Slaves, die man unbesorgt 'abschießen' kann. Cassandra hat sich hervorragend etabliert.
Die Wahl der Infrastruktur als Aufgabe ohne allgemeine Lösung.
Foto von
Angenommen, wir haben ein neues Unternehmen oder ein Unternehmen, dessen Infrastruktur teilweise auf veraltete Weise aufgebaut ist. Dort wird ein langfristiger Infrastrukturentwicklungsplan erstellt. Wie wird entschieden, ob die Infrastruktur auf Containern und Kubernetes basieren soll oder nicht?
Unternehmen, die um Nanosekunden kämpfen, sind aus der Diskussion ausgeschlossen. Ein gesunder Konservatismus zahlt sich in Bezug auf die Zuverlässigkeit aus, dennoch gibt es Unternehmen, die neue Ansätze in Betracht ziehen sollten.
Ivan: „Ich würde jetzt definitiv ein Unternehmen in der Cloud gründen, einfach weil es schneller ist“, auch wenn es nicht unbedingt günstiger ist. Mit dem Aufstieg des Risikokapitals haben Startups keine großen finanziellen Probleme mehr, und die Hauptaufgabe besteht darin, den Markt zu erobern.
Ivan vertritt die Ansicht, dass die Ausgereiftheit der aktuellen Infrastruktur das Auswahlkriterium ist. Wenn in der Vergangenheit erhebliche Investitionen getätigt wurden und dies funktioniert, gibt es keinen Grund, es zu ändern. Ist die Infrastruktur jedoch nicht ausgereift und gibt es Probleme mit Tools, Sicherheit und Monitoring, macht es Sinn, sich eine verteilte Infrastruktur anzusehen.
Die Steuer muss in jedem Fall bezahlt werden, und Ivan würde die bezahlen, die ihm in Zukunft ermöglicht, weniger zu zahlen. „Weil ich einfach mit dem Zug fahre, der von anderen betrieben wird, werde ich viel weiter kommen, als wenn ich in einen anderen Zug steige, in den ich selbst den Treibstoff einfüllen muss.» — sagt Ivan. Wenn ein Unternehmen neu ist und die Anforderungen an die Latenz in den zig Millisekunden liegen, würde Ivan in Richtung 'Provider' schauen, die heutzutage klassische Datenbanken 'unterbringen'. Sie erstellen eine Replikationskette, die sich im Falle eines Fehlschlags selbst umschaltet und so weiter…
Für ein kleines Unternehmen mit ein paar Servern in Kubernetes macht es keinen Sinn, — erklärt Andrei. Aber wenn es plant, auf hundert Server und mehr zu wachsen, dann ist Automatisierung und ein Ressourcenmanagementsystem erforderlich. In 90 % der Fälle rechtfertigen sich die Kosten. Und das unabhängig von der Belastung und den Ressourcen. Jeder, von Startups bis hin zu großen Unternehmen mit Millionen von Nutzern, sollte allmählich Produkte für die Orchestrierung von Containern in Betracht ziehen. 'Ja, das ist wirklich die Zukunft', ist sich Andrei sicher.
Denis nannte zwei Hauptkriterien — Skalierbarkeit und Betriebskontinuität. Er wird die Werkzeuge auswählen, die am besten für diese Aufgabe geeignet sind. «Das könnte ein zusammengebastelter No Name sein, auf dem Nutanix Community Edition läuft. Es könnte auch eine zweite Schicht in Form einer Anwendung auf Kubernetes mit einer Datenbank im Hintergrund sein, die repliziert wird und festgelegte RTO- und RPO-Parameter hat» (Recovery Time/Point Objectives — Beispiele).
Eugene hat ein mögliches Problem mit dem Personal angesprochen. Derzeit gibt es auf dem Markt nicht viele hochqualifizierte Fachkräfte, die sich „in den Tiefen“ auskennen. Tatsächlich, wenn die gewählte Technologie alt ist, ist es schwierig, jemanden einzustellen, außer ältere, gelangweilte und vom Leben müde Menschen. Während andere Teilnehmer der Meinung sind, dass dies ein Ausbildungsproblem ist.
Wenn man die Frage stellt: Ein kleines Unternehmen in der Public Cloud mit Datenbanken in Amazon RDS zu starten oder „on premise“ mit Datenbanken in Kubernetes, dann fiel die Wahl der Teilnehmer trotz gewisser Nachteile auf Amazon RDS.
Da die meisten Zuhörer des Meetups nicht aus der „blutigen“ Unternehmenswelt stammen, sind verteilte Lösungen das Ziel, auf das man hinarbeiten sollte. Datenspeichersysteme müssen verteilt, zuverlässig sein und Latenzen von nur einigen Millisekunden, maximal in Zehnerbereichen, erzeugen., — fasste Andrej zusammen.
Bewertung der Nutzung von Kubernetes
Der Zuhörer Anton Shbankov stellte eine Fangfrage an die Befürworter von Kubernetes: Wie wurde die technische und wirtschaftliche Begründung gewählt und durchgeführt? Warum Kubernetes, warum nicht zum Beispiel virtuelle Maschinen?
Foto von
Dmitrij und Ivan antworteten darauf. In beiden Fällen wurden durch Ausprobieren Entscheidungen getroffen, die beide Teilnehmer zu Kubernetes führten. Jetzt beginnt das Geschäft selbst, Software zu entwickeln, die es sinnvoll ist, nach Kubernetes zu migrieren. Dabei geht es nicht um klassische Fremdsysteme wie 1C. Kubernetes unterstützt, wenn Entwickler schnell Releases durchführen müssen, ohne Unterbrechungen im kontinuierlichen Verbesserungsprozess.
Andrejs Team versuchte, ein skalierbares Cluster auf Basis von virtuellen Maschinen zu erstellen. Die Nodes fielen wie Dominosteine, was manchmal zu einem Ausfall des Clusters führte. „Theoretisch könnte man es manuell fertigstellen und unterstützen, aber das ist mühsam. Und wenn es auf dem Markt eine Lösung gibt, die out-of-the-box funktioniert, gehen wir gerne dorthin. Und schließlich sind wir zu der Lösung übergegangen“, erzählt Andrej.
Es gibt Standards für solche Analysen und Berechnungen, aber niemand kann sagen, wie genau sie sich auf tatsächlicher Hardware im Betrieb verhalten. Für die Berechnungen ist es auch wichtig, sich in jedes Werkzeug und jede Infrastruktur einzuarbeiten, aber das ist nicht möglich.
Was erwartet uns
Foto von
Wenn sich Technologien weiterentwickeln, entstehen immer mehr disparate Stücke, und dann erfolgt ein Phasenübergang, es erscheint ein Anbieter, der genug „Kohle“ investiert hat, damit alles in einem einzigen Werkzeug zusammenkommt.
Glauben Sie nicht, dass der Moment kommen wird, an dem ein Werkzeug entsteht, das so wie Ubuntu für die Linux-Welt wird? Möglicherweise wird ein einheitliches Werkzeug für Containerisierung und Orchestrierung auch Kubernetes integrieren. Es wird einfach sein, On-Premise-Clouds zu erstellen.
Die Antwort gab Ivan: „Google baut derzeit Anthos – das ist ihr Paketangebot, das die Cloud implementiert und Kubernetes, Service Mesh, Monitoring – alles, was für Microservices im On-Premise-Bereich erforderlich ist, einschließt. Wir sind fast im Zukunft.“
Denis erwähnte auch Nutanix und VMware mit dem Produkt vRealize Suite, die ähnliche Aufgaben ohne Containerisierung bewältigen können.
Dmitrij teilte seine Meinung mit, dass die Verringerung von "Schmerzen" und die Senkung der Steuer zwei Bereiche sind, in denen Verbesserungen zu erwarten sind.
Zusammenfassend aus der Diskussion lassen sich folgende Probleme der modernen Infrastruktur hervorheben
- Drei Teilnehmer wiesen sofort auf ein Problem mit stateful hin.
- Verschiedene Arten von Sicherheitsunterstützungsproblemen, einschließlich der Wahrscheinlichkeit, dass mehrere Versionen von Python, Anwendungsservern und Komponenten letztendlich in Docker landen.
Übermäßige Ausgaben, zu denen es besser wäre, ein separates Meeting abzuhalten.
Das Problem der Ausbildung, da die Orchestrierung ein komplexes Ökosystem darstellt.
Ein allgemeines Problem der Branche ist die unsachgemäße Nutzung von Tools.Die weiteren Schlussfolgerungen überlasse ich Ihnen. Es bleibt jedoch das Gefühl, dass die Kombination von Docker und Kubernetes nicht einfach "zentrale" Teile des Systems werden kann. Beispielsweise werden Betriebssysteme zuerst auf die Hardware installiert, was man von Containern und Orchestrierung nicht sagen kann. Möglicherweise werden in Zukunft Betriebssysteme und Container mit Cloud-Management-Software zusammenwachsen.
Foto vonIch möchte die Gelegenheit nutzen, um meiner Mutter zu grüßen und daran zu erinnern, dass wir eine Facebook-Gruppe haben. , Kanal mit interessanten Beiträgen aus verschiedenen Tech-Blogs. Und mein Kanal , auf dem ich über das Management von Entwicklung in Produktunternehmen berichte.
Quelle: habr.com
