Ende Mai hielt ein Online-Meeting zu diesem Thema ab . Wir sprachen über Container, Kubernetes und Orchestrierung im Prinzip, Kriterien für die Auswahl der Infrastruktur und vieles mehr. Die Teilnehmer berichteten über Fälle aus ihrer eigenen Praxis.
Teilnehmer:
- Evgeniy Potapov, CEO von ITSumma. Mehr als die Hälfte der Kunden ziehen entweder bereits um oder wollen auf Kubernetes umsteigen.
- Dmitry Stolyarov, CTO „Flant“. Verfügt über mehr als 10 Jahre Erfahrung im Umgang mit Containersystemen.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, ehemaliger RAO UES. Er versprach, über Fälle im „blutigen“ Unternehmen zu sprechen.
- Andrey Fedorovsky, CTO „News360.com“Nachdem er das Unternehmen von einem anderen Spieler gekauft hat, ist er für eine Reihe von ML- und KI-Projekten und -Infrastrukturen verantwortlich.
- Ivan Kruglov, Systemingenieur, ex-Booking.com.Dieselbe Person, die selbst viel mit Kubernetes gemacht hat.
Themen:
- Einblicke der Teilnehmer in Container und Orchestrierung (Docker, Kubernetes usw.); was in der Praxis ausprobiert oder analysiert wurde.
- Fallbeispiel: Das Unternehmen erstellt seit Jahren einen Infrastrukturentwicklungsplan. Wie wird die Entscheidung getroffen, ob eine Infrastruktur auf Container und Kuber aufgebaut (oder migriert) werden soll oder nicht?
- Probleme in der Cloud-nativen Welt, was fehlt, stellen wir uns vor, was morgen passieren wird.
Es entwickelte sich eine interessante Diskussion, die Meinungen der Teilnehmer waren so unterschiedlich und sorgten für so viele Kommentare, dass ich sie gerne mit euch teilen möchte. Essen , und unten finden Sie eine Zusammenfassung der Diskussion.
Ist Kubernetes bereits ein Standard oder großartiges Marketing?
„Wir kamen dazu (Kubernetes. - Red.), als noch niemand davon wusste. Wir kamen zu ihm, auch als er nicht da war. Wir wollten es schon früher“ - Dmitri Stolyarov
Foto von Reddit.com
Vor 5-10 Jahren gab es eine große Anzahl von Werkzeugen und es gab keinen einheitlichen Standard. Alle sechs Monate erschien ein neues Produkt, oder sogar mehr als eines. Zuerst Vagrant, dann Salt, Chef, Puppet, ... „und Sie bauen Ihre Infrastruktur alle sechs Monate neu auf. Sie haben fünf Administratoren, die ständig damit beschäftigt sind, Konfigurationen neu zu schreiben“, erinnert sich Andrey Fedorovsky. Er glaubt, dass Docker und Kubernetes den Rest „verdrängt“ haben. Docker hat sich in den letzten fünf Jahren zum Standard entwickelt, Kubernetes in den letzten zwei Jahren. Und das ist gut für die Branche..
Dmitry Stolyarov und sein Team lieben Kuber. Sie wollten ein solches Werkzeug, bevor es auf den Markt kam, und kamen darauf, als niemand davon wusste. Derzeit nehmen sie aus Bequemlichkeitsgründen keinen Client an, wenn sie verstehen, dass sie Kubernetes nicht mit ihm implementieren werden. Gleichzeitig, so Dmitry, habe das Unternehmen „viele gigantische Erfolgsgeschichten über die Neugestaltung des schrecklichen Erbes“ vorzuweisen.
Kubernetes ist nicht nur Container-Orchestrierung, es ist ein Konfigurationsmanagementsystem mit einer entwickelten API, einer Netzwerkkomponente, L3-Balancing und Ingress-Controllern, was es relativ einfach macht, Ressourcen zu verwalten, zu skalieren und von den unteren Schichten der Infrastruktur zu abstrahieren.
Leider müssen wir in unserem Leben für alles bezahlen. Und diese Steuer ist hoch, insbesondere wenn wir über den Übergang eines Unternehmens mit einer entwickelten Infrastruktur zu Kubernetes sprechen, wie Ivan Kruglov glaubt. Er konnte sowohl in einem Unternehmen mit traditioneller Infrastruktur als auch mit Kuber frei arbeiten. Das Wichtigste ist, die Besonderheiten des Unternehmens und des Marktes zu verstehen. Aber zum Beispiel für Evgeny Potapov, der Kubernetes auf jedes Container-Orchestrierungstool verallgemeinern würde, stellt sich eine solche Frage nicht.
Evgeniy zog eine Analogie zur Situation in den 1990er Jahren, als die objektorientierte Programmierung als Möglichkeit zur Programmierung komplexer Anwendungen auftauchte. Zu diesem Zeitpunkt ging die Debatte weiter und es erschienen neue Tools zur Unterstützung von OOP. Dann entstanden Microservices als eine Möglichkeit, sich vom monolithischen Konzept zu lösen. Dies wiederum führte zur Entstehung von Containern und Container-Management-Tools. „Ich denke, dass wir bald an einem Punkt angelangt sein werden, an dem es keine Frage mehr gibt, ob es sich lohnt, eine kleine Microservice-Anwendung zu schreiben, sondern dass sie standardmäßig als Microservice geschrieben wird“, glaubt er. Ebenso werden Docker und Kubernetes irgendwann zur Standardlösung werden, ohne dass eine Auswahl erforderlich ist.
Das Problem zustandsloser Datenbanken
Photo by
Heutzutage gibt es viele Rezepte für den Betrieb von Datenbanken in Kubernetes. Sogar wie man den Teil, der mit der E/A-Festplatte arbeitet, bedingt vom Anwendungsteil der Datenbank trennt. Ist es möglich, dass sich Datenbanken in Zukunft so stark ändern, dass sie in einer Box bereitgestellt werden, in der ein Teil über Docker und Kubernetes orchestriert wird und in einem anderen Teil der Infrastruktur über separate Software der Speicherteil bereitgestellt wird? ? Werden sich die Basen als Produkt verändern?
Diese Beschreibung ähnelt der Warteschlangenverwaltung, aber die Anforderungen an Zuverlässigkeit und Synchronisierung von Informationen in herkömmlichen Datenbanken sind viel höher, glaubt Andrey. Die Cache-Trefferquote in normalen Datenbanken bleibt bei 99 %. Wenn ein Worker ausfällt, wird ein neuer gestartet und der Cache wird von Grund auf „aufgewärmt“. Bis der Cache aufgewärmt ist, arbeitet der Worker langsam, was bedeutet, dass er nicht mit der Benutzerlast geladen werden kann. Obwohl es keine Benutzerlast gibt, wird der Cache nicht aufgewärmt. Es ist ein Teufelskreis.
Dmitry ist grundsätzlich anderer Meinung – Quoren und Sharding lösen das Problem. Aber Andrey besteht darauf, dass die Lösung nicht für jeden geeignet ist. In manchen Situationen ist Quorum geeignet, belastet das Netzwerk jedoch zusätzlich. Eine NoSQL-Datenbank ist nicht in allen Fällen geeignet.
Die Meetup-Teilnehmer wurden in zwei Lager aufgeteilt.
Denis und Andrey argumentieren, dass alles, was auf die Festplatte geschrieben wird – Datenbanken usw. – im aktuellen Kuber-Ökosystem unmöglich ist. Es ist unmöglich, die Integrität und Konsistenz der Produktionsdaten in Kubernetes aufrechtzuerhalten. Dies ist ein grundlegendes Merkmal. Lösung: Hybride Infrastruktur.
Selbst moderne Cloud-native Datenbanken wie MongoDB und Cassandra oder Nachrichtenwarteschlangen wie Kafka oder RabbitMQ erfordern persistente Datenspeicher außerhalb von Kubernetes.
Evgeniy wendet ein: „Die Stützpunkte in Kubera sind eine nahezu russische oder unternehmensnahe Verletzung, die mit der Tatsache zusammenhängt, dass es in Russland keine Cloud-Einführung gibt.“ Kleine oder mittlere Unternehmen im Westen sind Cloud. Amazon RDS-Datenbanken sind einfacher zu verwenden, als selbst an Kubernetes herumzubasteln. In Russland nutzen sie Kuber „vor Ort“ und übertragen Stützpunkte darauf, wenn sie versuchen, den Zoo loszuwerden.
Dmitry widersprach auch der Aussage, dass in Kubernetes keine Datenbanken gespeichert werden können: „Basis ist anders als Basis.“ Und wenn Sie eine riesige relationale Datenbank pushen, dann auf keinen Fall. Wenn man etwas Kleines und Cloud-Natives vorantreibt, das mental auf ein halbflüchtiges Leben vorbereitet ist, wird alles gut.“ Dmitry erwähnte auch, dass Datenbankverwaltungstools weder für Docker noch für Kuber bereit sind, sodass große Schwierigkeiten auftreten.
Ivan wiederum ist sich sicher, dass das Ökosystem der Unternehmenslösungen in Kubernetes noch nicht fertig ist, selbst wenn wir von den Konzepten zustandsbehaftet und zustandslos abstrahieren. Mit Kuber ist es schwierig, gesetzliche und regulatorische Anforderungen einzuhalten. Beispielsweise ist es unmöglich, eine Identitätsbereitstellungslösung zu entwickeln, bei der strenge Garantien für die Serveridentifizierung erforderlich sind, bis hin zur Hardware, die in die Server eingesetzt wird. Dieser Bereich entwickelt sich, aber es gibt noch keine Lösung.
Da sich die Teilnehmer nicht einigen konnten, werden in diesem Teil keine Schlussfolgerungen gezogen. Lassen Sie uns ein paar praktische Beispiele geben.
Fall 1. Cybersicherheit eines „Mega-Regulators“ mit Stützpunkten außerhalb von Kubera
Bei einem ausgebauten Cybersicherheitssystem ermöglicht der Einsatz von Containern und Orchestrierung die Abwehr von Angriffen und Einbrüchen. Beispielsweise implementierten Denis und sein Team in einer Mega-Regulierungsbehörde eine Kombination aus einem Orchestrator und einem geschulten SIEM-Dienst, der Protokolle in Echtzeit analysiert und den Prozess eines Angriffs, Hackings oder Fehlers bestimmt. Im Falle eines Angriffs, eines Versuchs, etwas zu platzieren, oder im Falle einer Ransomware-Vireninvasion erfasst er über den Orchestrator Container mit Anwendungen schneller, als sie infiziert werden oder schneller, als der Angreifer sie angreift.
Fall 2. Teilweise Migration der Booking.com-Datenbanken auf Kubernetes
Bei Booking.com ist MySQL mit asynchroner Replikation die Hauptdatenbank – es gibt einen Master und eine ganze Hierarchie von Slaves. Als Ivan das Unternehmen verließ, wurde ein Projekt zur Überstellung von Sklaven gestartet, die mit einem gewissen Schaden „erschossen“ werden konnten.
Zusätzlich zur Hauptbasis gibt es eine Cassandra-Installation mit selbstgeschriebener Orchestrierung, die bereits geschrieben wurde, bevor Kuber in den Mainstream eintrat. Diesbezüglich gibt es keine Probleme, es bleibt jedoch auf lokalen SSDs bestehen. Remote-Speicher, selbst innerhalb desselben Rechenzentrums, wird aufgrund des Problems der hohen Latenz nicht verwendet.
Die dritte Klasse von Datenbanken ist der Suchdienst von Booking.com, bei dem jeder Dienstknoten eine Datenbank ist. Versuche, den Suchdienst auf Kuber zu übertragen, schlugen fehl, da jeder Knoten über 60–80 GB lokalen Speicher verfügt, der schwer zu „heben“ und „aufzuwärmen“ ist.
Infolgedessen wurde die Suchmaschine nicht auf Kubernetes übertragen, und Ivan glaubt nicht, dass es in naher Zukunft neue Versuche geben wird. Die MySQL-Datenbank wurde zur Hälfte übertragen: nur Slaves, die keine Angst davor haben, „erschossen“ zu werden. Cassandra hat sich perfekt eingelebt.
Infrastrukturauswahl als Aufgabe ohne allgemeine Lösung
Photo by
Nehmen wir an, wir haben ein neues Unternehmen oder ein Unternehmen, bei dem ein Teil der Infrastruktur auf die alte Art und Weise aufgebaut ist. Es erstellt seit Jahren einen Infrastrukturentwicklungsplan. Wie wird die Entscheidung getroffen, ob eine Infrastruktur auf Containern und Kuber aufgebaut werden soll oder nicht?
Unternehmen, die für Nanosekunden kämpfen, sind von der Diskussion ausgeschlossen. Gesunder Konservatismus zahlt sich in Sachen Verlässlichkeit aus, dennoch gibt es Unternehmen, die über neue Ansätze nachdenken sollten.
Ivan: „Ich würde jetzt auf jeden Fall ein Unternehmen in der Cloud gründen, einfach weil es schneller ist“, wenn auch nicht unbedingt billiger. Mit der Entwicklung des Risikokapitalismus haben Startups keine großen Geldprobleme und die Hauptaufgabe besteht darin, den Markt zu erobern.
Ivan ist der Meinung, dass Die Entwicklung der aktuellen Infrastruktur ist ein Auswahlkriterium. Wenn in der Vergangenheit eine ernsthafte Investition getätigt wurde und diese funktioniert, macht es keinen Sinn, sie noch einmal zu tätigen. Wenn die Infrastruktur nicht ausgebaut ist und es Probleme mit Tools, Sicherheit und Überwachung gibt, ist es sinnvoll, sich mit einer verteilten Infrastruktur zu befassen.
Die Steuer muss auf jeden Fall gezahlt werden, und Ivan würde die Steuer zahlen, die es ihm ermöglicht, in Zukunft weniger zu zahlen. "Denn allein dadurch, dass ich in einem Zug fahre, den andere mitfahren, fahre ich viel weiter, als wenn ich in einem anderen Zug sitze, den ich selbst betanken muss.„sagt Ivan. Wenn das Unternehmen neu ist und die Latenzanforderungen mehrere zehn Millisekunden betragen, würde Ivan nach den „Operatoren“ suchen, in die klassische Datenbanken heute „eingepackt“ sind. Sie erzeugen eine Replikationskette, die sich im Falle eines Failovers usw. selbst umschaltet.
Für ein kleines Unternehmen mit ein paar Servern macht Kubera keinen Sinn“, sagt Andrey. Wenn jedoch ein Wachstum auf Hunderte oder mehr Server geplant ist, sind Automatisierung und ein Ressourcenverwaltungssystem erforderlich. 90 % der Fälle sind die Kosten wert. Darüber hinaus unabhängig von der Auslastung und den Ressourcen. Für jeden, vom Startup bis zum Großunternehmen mit einem Millionenpublikum, ist es sinnvoll, sich nach und nach mit Container-Orchestrierungsprodukten zu beschäftigen. „Ja, das ist wirklich die Zukunft“, ist sich Andrey sicher.
Denis skizzierte zwei Hauptkriterien: Skalierbarkeit und Stabilität des Betriebs. Er wählt die Werkzeuge aus, die für die Aufgabe am besten geeignet sind. „Es könnte ein Noname sein, der auf Ihren Knien versammelt ist und auf dem sich die Nutanix Community Edition befindet. Dies könnte eine zweite Zeile in Form einer Anwendung auf Kuber mit einer Datenbank im Backend sein, die repliziert wird und über spezifizierte RTO- und RPO-Parameter verfügt (Recovery Time/Point Objectives – prim).
Evgeniy identifizierte ein mögliches Problem mit dem Personal. Derzeit gibt es auf dem Markt nicht viele hochqualifizierte Spezialisten, die den „Bauch“ verstehen. Wenn die gewählte Technologie alt ist, ist es tatsächlich schwierig, andere als Menschen mittleren Alters einzustellen, die gelangweilt und lebensmüde sind. Obwohl andere Teilnehmer glauben, dass es sich hierbei um eine Frage der Personalschulung handelt.
Wenn wir die Frage nach der Wahl stellen: ein kleines Unternehmen in der Public Cloud mit Datenbanken in Amazon RDS oder „vor Ort“ mit Datenbanken in Kubernetes zu gründen, dann fiel die Wahl der Teilnehmer trotz einiger Mängel auf Amazon RDS.
Da die Mehrheit der Meetup-Zuhörer also nicht aus dem „verdammten“ Unternehmen stammt Verteilte Lösungen sind das, was wir anstreben sollten. Datenspeichersysteme müssen verteilt und zuverlässig sein und eine Latenz erzeugen, die in Einheiten von Millisekunden, höchstens zehn, gemessen wird“, fasste Andrey zusammen.
Bewertung der Kubernetes-Nutzung
Der Zuhörer Anton Zhbankov stellte den Kubernetes-Apologeten eine Falle: Wie haben Sie eine Machbarkeitsstudie ausgewählt und durchgeführt? Warum Kubernetes, warum nicht zum Beispiel virtuelle Maschinen?
Photo by
Dmitry und Ivan antworteten darauf. In beiden Fällen wurde durch Versuch und Irrtum eine Abfolge von Entscheidungen getroffen, durch die beide Teilnehmer zu Kubernetes gelangten. Jetzt beginnen Unternehmen damit, eigenständig Software zu entwickeln, deren Übertragung auf Kuber sinnvoll ist. Die Rede ist nicht von klassischen Drittsystemen wie 1C. Kubernetes hilft Entwicklern, wenn sie schnell Releases erstellen müssen, und zwar mit ununterbrochener kontinuierlicher Verbesserung.
Andreys Team versuchte, einen skalierbaren Cluster auf Basis virtueller Maschinen zu erstellen. Knoten fielen wie Dominosteine, was manchmal zum Zusammenbruch des Clusters führte. „Theoretisch kann man es fertigstellen und mit den Händen stützen, aber das ist mühsam. Und wenn es auf dem Markt eine Lösung gibt, mit der Sie sofort arbeiten können, dann greifen wir gerne zu. Und deshalb haben wir gewechselt“, sagt Andrey.
Es gibt Standards für solche Analysen und Berechnungen, aber niemand kann sagen, wie genau diese auf realer Hardware im Betrieb sind. Für Berechnungen ist es auch wichtig, jedes Tool und Ökosystem zu verstehen, aber das ist nicht möglich.
Was uns erwartet
Photo by
Während sich die Technologie weiterentwickelt, tauchen immer mehr unterschiedliche Teile auf, und dann kommt es zu einem Phasenübergang, einem Anbieter, der genug Teig geschlachtet hat, damit alles in einem einzigen Werkzeug zusammenkommt.
Glauben Sie, dass es eine Zeit geben wird, in der es ein Tool wie Ubuntu für die Linux-Welt geben wird? Vielleicht wird ein einziges Containerisierungs- und Orchestrierungstool Kuber umfassen. Dadurch wird es einfacher, On-Premise-Clouds aufzubauen.
Die Antwort kam von Ivan: „Google baut jetzt Anthos – das ist ihr Paketangebot, das die Cloud bereitstellt und Kuber, Service Mesh, Monitoring umfasst – die gesamte Hardware, die für On-Premise-Microservices benötigt wird.“ Wir sind fast in der Zukunft.
Denis erwähnte auch Nutanix und VMWare mit dem Produkt vRealize Suite, das eine ähnliche Aufgabe ohne Containerisierung bewältigen kann.
Dmitry teilte seine Meinung mit, dass die Verringerung des „Schmerzes“ und die Senkung der Steuern zwei Bereiche seien, in denen wir mit Verbesserungen rechnen könnten.
Um die Diskussion zusammenzufassen, beleuchten wir die folgenden Probleme der modernen Infrastruktur:
- Drei Teilnehmer erkannten sofort ein Problem mit Stateful.
- Verschiedene Probleme bei der Sicherheitsunterstützung, einschließlich der Möglichkeit, dass Docker am Ende über mehrere Versionen von Python, Anwendungsservern und Komponenten verfügt.
Überhöhte Ausgaben, die besser in einem separaten Treffen besprochen werden sollten.
Eine Lernherausforderung, da Orchestrierung ein komplexes Ökosystem ist.
Ein häufiges Problem in der Branche ist der Missbrauch von Werkzeugen.Die restlichen Schlussfolgerungen liegen bei Ihnen. Es besteht immer noch das Gefühl, dass es für die Kombination aus Docker und Kubernetes nicht einfach ist, ein „zentraler“ Teil des Systems zu werden. Beispielsweise werden Betriebssysteme zuerst auf der Hardware installiert, was bei Containern und Orchestrierung nicht der Fall ist. Vielleicht werden in Zukunft Betriebssysteme und Container mit Cloud-Management-Software verschmelzen.
Photo byIch möchte diese Gelegenheit nutzen, um meiner Mutter Hallo zu sagen und Sie daran zu erinnern, dass wir eine Facebook-Gruppe haben , Kanal mit interessanten Veröffentlichungen aus verschiedenen Tech-Blogs. Und mein Kanal , wo ich über das Management der Entwicklung in Produktunternehmen spreche.
Source: habr.com