In Vorfreude Vitaly Chabarow interviewt Dmitri Stolyarov (), technischer Direktor und Mitbegründer der Firma Flant. Vitaly fragte Dmitry nach der Arbeit von Flant, nach Kubernetes, der Entwicklung des Ökosystems und der Unterstützung. Wir haben diskutiert, warum Kubernetes benötigt wird und ob es überhaupt benötigt wird. Und auch über Microservices, Amazon AWS, den DevOps-Ansatz „Ich werde Glück haben“, die Zukunft von Kubernetes selbst, warum, wann und wie es die Welt erobern wird, die Aussichten von DevOps und worauf sich Ingenieure vorbereiten sollten eine glänzende und nahe Zukunft mit Vereinfachung und neuronalen Netzen.
Hören Sie sich den Podcast „DevOps Deflop“ an – einen russischsprachigen Podcast über DevOps. Unten finden Sie die Textversion.
Hier und unten stellt er Fragen Ingenieur von Express42.
Über „Flant“
- Hallo Dima. Sie sind der technische Leiter“" und auch sein Gründer. Bitte sagen Sie uns, was das Unternehmen macht und was Sie darin machen?
Dmitry: Von außen sieht es so aus, als wären wir die Leute, die Kubernetes für alle installieren und etwas damit machen. Aber das ist nicht so. Wir begannen als Unternehmen, das sich mit Linux beschäftigte, aber seit sehr langer Zeit liegt unsere Haupttätigkeit in der Betreuung von schlüsselfertigen Produktions- und Hochlastprojekten. Normalerweise bauen wir die gesamte Infrastruktur von Grund auf auf und sind dann über einen langen, langen Zeitraum dafür verantwortlich. Daher ist die Hauptarbeit, die „Flant“ leistet und für die es Geld erhält, Folgendes: Verantwortung übernehmen und eine schlüsselfertige Produktion realisieren.
Als technischer Direktor und einer der Gründer des Unternehmens verbringe ich Tag und Nacht damit, herauszufinden, wie ich die Zugänglichkeit der Produktion verbessern, ihren Betrieb vereinfachen, das Leben der Administratoren einfacher und das Leben der Entwickler angenehmer machen kann .
Über Kubernetes
— In letzter Zeit habe ich viele Berichte von Flant und gesehen über Kubernetes. Wie bist du dazu gekommen?
Dmitry: Ich habe schon oft darüber gesprochen, aber es macht mir überhaupt nichts aus, es zu wiederholen. Ich denke, es ist richtig, dieses Thema zu wiederholen, da Ursache und Wirkung verwechselt werden.
Wir brauchten wirklich ein Werkzeug. Wir standen vor vielen Problemen, kämpften, überwanden sie mit verschiedenen Krücken und verspürten das Bedürfnis nach einem Werkzeug. Wir haben viele verschiedene Optionen ausprobiert, unsere eigenen Fahrräder gebaut und Erfahrungen gesammelt. Allmählich kamen wir an den Punkt, an dem wir Docker praktisch sofort nach seinem Erscheinen verwendeten – etwa im Jahr 2013. Zum Zeitpunkt seines Erscheinens hatten wir bereits viel Erfahrung mit Containern, wir hatten bereits ein Analogon von „Docker“ geschrieben – einige unserer eigenen Krücken in Python. Mit dem Aufkommen von Docker wurde es möglich, die Krücken wegzuwerfen und eine zuverlässige und von der Community unterstützte Lösung zu verwenden.
Bei Kubernetes ist die Geschichte ähnlich. Als es an Fahrt gewann – für uns ist dies Version 1.2 – hatten wir sowohl bei Shell als auch bei Chef bereits eine Menge Krücken, die wir irgendwie mit Docker zu orchestrieren versuchten. Wir haben ernsthaft nach Rancher und diversen anderen Lösungen gesucht, aber dann kam Kubernetes, in dem alles genau so implementiert ist, wie wir es gemacht hätten oder sogar noch besser. Es gibt nichts zu bemängeln.
Ja, hier gibt es eine Art Unvollkommenheit, da gibt es eine Art Unvollkommenheit – es gibt viele Unvollkommenheiten und 1.2 ist im Allgemeinen schrecklich, aber ... Kubernetes ist wie ein Gebäude im Bau – man schaut sich das Projekt an und versteht dass es cool wird. Wenn das Gebäude jetzt über ein Fundament und zwei Stockwerke verfügt, dann verstehen Sie, dass es besser ist, noch nicht einzuziehen, aber mit der Software gibt es keine derartigen Probleme – Sie können sie bereits nutzen.
Wir hatten keinen Moment, in dem wir darüber nachgedacht haben, ob wir Kubernetes nutzen oder nicht. Wir haben lange vor seinem Erscheinen darauf gewartet und versucht, selbst Analogien zu schaffen.
Über Kubernetes
— Sind Sie direkt an der Entwicklung von Kubernetes selbst beteiligt?
Dmitry: Mittelmäßig. Vielmehr beteiligen wir uns an der Entwicklung des Ökosystems. Wir senden eine bestimmte Anzahl von Pull-Anfragen: an Prometheus, an verschiedene Operatoren, an Helm – an das Ökosystem. Leider bin ich nicht in der Lage, den Überblick über alles zu behalten, was wir tun, und ich könnte mich irren, aber es gibt keinen einzigen Pool von uns in den Kern.
— Entwickeln Sie gleichzeitig viele Ihrer Tools rund um Kubernetes?
Dmitry: Die Strategie ist folgende: Wir ziehen Anfragen an alles, was bereits existiert. Wenn Pull-Anfragen dort nicht akzeptiert werden, forken wir sie einfach selbst und leben, bis sie mit unseren Builds akzeptiert werden. Wenn es dann den Upstream erreicht, kehren wir zur Upstream-Version zurück.
Wir haben zum Beispiel einen Prometheus-Operator, mit dem wir wahrscheinlich schon fünfmal zum Upstream unserer Baugruppe hin- und hergeschaltet haben. Wir brauchen irgendeine Art von Funktion, wir haben eine Pull-Anfrage gesendet, wir müssen sie morgen einführen, aber wir wollen nicht darauf warten, dass sie im Upstream veröffentlicht wird. Dementsprechend bauen wir für uns selbst zusammen und führen unsere Baugruppe mit unserer Funktion, die wir aus irgendeinem Grund benötigen, auf alle unsere Cluster aus. Dann übergeben sie es uns zum Beispiel im Upstream mit den Worten: „Leute, lasst es uns für einen allgemeineren Fall machen“, wir oder jemand anderes beenden es und mit der Zeit verschmilzt es wieder.
Wir versuchen, alles zu entwickeln, was existiert. Viele Elemente, die noch nicht existieren, noch nicht erfunden wurden oder erfunden wurden, aber keine Zeit hatten, sie umzusetzen – wir tun es. Und das nicht, weil uns der Prozess oder der Fahrradbau als Branche gefällt, sondern einfach, weil wir dieses Werkzeug brauchen. Oft wird die Frage gestellt: Warum haben wir dieses oder jenes getan? Die Antwort ist einfach: Ja, denn wir mussten noch weiter gehen und ein praktisches Problem lösen, und das haben wir mit dieser Tula gelöst.
Der Weg ist immer so: Wir suchen sehr sorgfältig und wenn wir keine Lösung finden, wie man aus einem Laib Brot einen Trolleybus machen kann, dann machen wir unseren eigenen Laib und unseren eigenen Trolleybus.
Flanta-Werkzeuge
– Ich weiß, dass Flant jetzt Add-on-Operatoren, Shell-Operatoren und Dapp/Werf-Tools hat. So wie ich es verstehe, handelt es sich um dasselbe Instrument in verschiedenen Inkarnationen. Ich verstehe auch, dass es in Flaunt noch viele weitere verschiedene Tools gibt. Ist das so?
Dmitry: Wir haben noch viel mehr auf GitHub. Soweit ich mich jetzt erinnere, haben wir eine Statusmap – ein Panel für Grafana, das jeder kennt. Es wird in fast jedem zweiten Artikel über die Kubernetes-Überwachung auf Medium erwähnt. Es ist unmöglich, kurz zu erklären, was eine Statusmap ist – es bedarf eines separaten Artikels, aber sie ist eine sehr nützliche Sache für die Überwachung des Status im Zeitverlauf, da wir in Kubernetes oft den Status im Zeitverlauf anzeigen müssen. Wir haben auch LogHouse – eine Sache, die auf ClickHouse und schwarzer Magie zum Sammeln von Protokollen in Kubernetes basiert.
Viele Dienstprogramme! Und es wird noch mehr werden, denn in diesem Jahr werden zahlreiche interne Lösungen veröffentlicht. Von den sehr großen Add-ons, die auf dem Add-on-Operator basieren, gibt es eine Reihe von Add-ons für Kubernetes, darunter die richtige Installation des Sert Managers – ein Tool zum Verwalten von Zertifikaten, die korrekte Installation von Prometheus mit einer Reihe von Zubehörteilen – das sind etwa zwanzig verschiedene Binärdateien, die Daten exportieren und etwas sammeln, dazu bietet Prometheus die erstaunlichsten Grafiken und Warnungen. All dies ist nur eine Reihe von Add-ons für Kubernetes, die in einem Cluster installiert sind, und es wird von einfach zu cool, ausgefeilt, automatisch, wobei viele Probleme bereits gelöst wurden. Ja, wir machen viel.
Ökosystementwicklung
„Mir scheint, dass dies ein sehr großer Beitrag zur Entwicklung dieses Instruments und seiner Einsatzmethoden ist.“ Können Sie grob abschätzen, wer sonst noch den gleichen Beitrag zur Entwicklung des Ökosystems leisten würde?
Dmitry: In Russland ist von den Unternehmen, die auf unserem Markt tätig sind, niemand auch nur annähernd so groß. Das ist natürlich eine laute Aussage, denn es gibt große Player wie Mail und Yandex – die machen auch etwas mit Kubernetes, aber selbst sie kommen nicht annähernd an den Beitrag von Unternehmen auf der ganzen Welt heran, die viel mehr leisten als wir. Es ist schwierig, Flant mit 80 Mitarbeitern und Red Hat mit 300 Ingenieuren allein pro Kubernetes zu vergleichen, wenn ich mich nicht irre. Es ist schwer zu vergleichen. Wir haben 6 Leute in der RnD-Abteilung, einschließlich mir, die alle unsere Werkzeuge schneiden. 6 Personen gegen 300 Red Hat-Ingenieure – das ist irgendwie schwierig zu vergleichen.
- Wenn jedoch selbst diese 6 Menschen etwas wirklich Nützliches und Entfremdendes tun können, wenn sie vor einem praktischen Problem stehen und der Gemeinschaft die Lösung geben – ein interessanter Fall. Ich verstehe, dass in großen Technologieunternehmen, die über ein eigenes Kubernetes-Entwicklungs- und Supportteam verfügen, im Prinzip dieselben Tools entwickelt werden können. Dies ist für sie ein Beispiel dafür, was entwickelt und der Community zur Verfügung gestellt werden kann und der gesamten Community, die Kubernetes nutzt, Impulse gibt.
Dmitry: Dies ist wahrscheinlich ein Merkmal des Integrators, seine Besonderheit. Wir haben viele Projekte und wir sehen viele verschiedene Situationen. Für uns besteht der wichtigste Weg, Mehrwert zu schaffen, darin, diese Fälle zu analysieren, Gemeinsamkeiten zu finden und sie für uns so kostengünstig wie möglich zu machen. Daran arbeiten wir aktiv. Es fällt mir schwer, über Russland und die Welt zu sprechen, aber wir haben etwa 40 DevOps-Ingenieure im Unternehmen, die an Kubernetes arbeiten. Ich glaube nicht, dass es in Russland, wenn überhaupt, viele Unternehmen mit einer vergleichbaren Anzahl an Spezialisten gibt, die sich mit Kubernetes auskennen.
Ich verstehe alles über die Berufsbezeichnung DevOps-Ingenieur, jeder versteht alles und ist es gewohnt, DevOps-Ingenieure DevOps-Ingenieure zu nennen, darüber werden wir nicht diskutieren. All diese 40 großartigen DevOps-Ingenieure stehen jeden Tag vor Problemen und lösen sie. Wir analysieren einfach diese Erfahrung und versuchen, sie zu verallgemeinern. Wir verstehen, dass das Werkzeug in ein oder zwei Jahren unbrauchbar sein wird, wenn es in uns bleibt, weil irgendwo in der Gemeinschaft ein fertiges Tula auftauchen wird. Es macht keinen Sinn, diese Erfahrung intern anzusammeln – es verschlingt lediglich Energie und Zeit in dev/null. Und es tut uns überhaupt nicht leid. Wir veröffentlichen alles mit großer Freude und verstehen, dass es veröffentlicht, entwickelt, beworben, beworben werden muss, damit die Menschen es nutzen und ihre Erfahrungen hinzufügen – dann wächst und lebt alles. Dann landet das Instrument nach zwei Jahren nicht im Müll. Es ist nicht schade, weiterhin Kraft zu investieren, denn es ist klar, dass jemand Ihr Werkzeug benutzt, und nach zwei Jahren benutzt es jeder.
Dies ist Teil unserer großen Strategie mit dapp/werf. Ich kann mich nicht erinnern, wann wir angefangen haben, es zu machen, es kommt mir vor, als wäre es drei Jahre her. Anfangs befand es sich in der Regel auf der Schale. Es war ein super Proof of Concept, wir haben einige unserer speziellen Probleme gelöst – es hat funktioniert! Aber es gibt Probleme mit der Shell, es ist unmöglich, sie weiter auszubauen, das Programmieren auf der Shell ist eine andere Aufgabe. Wir hatten die Angewohnheit, in Ruby zu schreiben, dementsprechend haben wir etwas in Ruby neu gemacht, entwickelt, weiterentwickelt, weiterentwickelt und sind auf die Tatsache gestoßen, dass die Community, die Menge, die nicht sagt: „Wir wollen es oder wir wollen es nicht“, „Rumpft die Nase zu Ruby, wie lustig ist das denn?“ Uns wurde klar, dass wir all diese Dinge in Go schreiben sollten, nur um den ersten Punkt auf der Checkliste zu erfüllen: Das DevOps-Tool sollte eine statische Binärdatei sein. Ob es Go ist oder nicht, ist nicht so wichtig, aber eine in Go geschriebene statische Binärdatei ist besser.
Wir haben unsere Energie aufgewendet, das Dapp in Go umgeschrieben und es werf genannt. Das Dapp wird nicht mehr unterstützt, nicht weiterentwickelt und läuft in einer aktuellen Version, aber es gibt einen absoluten Upgrade-Pfad nach oben, und Sie können diesem folgen.
Warum wurde der Dapp erstellt?
— Können Sie uns kurz sagen, warum das Dapp erstellt wurde und welche Probleme es löst?
Dmitry: Der erste Grund liegt in der Versammlung. Anfangs hatten wir ernsthafte Probleme mit dem Build, als Docker nicht über Multi-Stage-Fähigkeiten verfügte, also haben wir Multi-Stage selbst erstellt. Dann hatten wir noch eine Menge Probleme mit der Bereinigung des Bildes. Jeder, der CI/CD macht, steht eher früher als später vor dem Problem, dass es eine Menge gesammelter Bilder gibt, man muss irgendwie wegräumen, was nicht benötigt wird, und übrig lassen, was benötigt wird.
Der zweite Grund ist die Bereitstellung. Ja, es gibt Helm, aber er löst nur einige der Probleme. Witzigerweise steht geschrieben: „Helm ist der Paketmanager für Kubernetes.“ Genau das, was „der“. Es gibt auch die Worte „Paketmanager“ – was sind die üblichen Erwartungen an einen Paketmanager? Wir sagen: „Paketmanager – Paket installieren!“ und wir erwarten, dass er uns sagt: „Das Paket wurde zugestellt.“
Es ist interessant, dass wir sagen: „Helm, installiere das Paket“, und als er antwortet, dass er es installiert hat, stellt sich heraus, dass er gerade mit der Installation begonnen hat – er hat Kubernetes angezeigt: „Launch this thing!“ und ob es gestartet wurde oder nicht Ob es funktioniert oder nicht, Helm löst dieses Problem überhaupt nicht.
Es stellt sich heraus, dass Helm nur ein Textpräprozessor ist, der Daten in Kubernetes lädt.
Aber im Rahmen jeder Bereitstellung möchten wir wissen, ob die Anwendung für die Produktion freigegeben wurde oder nicht? Rollout to prod bedeutet, dass die Anwendung dorthin verschoben wurde, die neue Version bereitgestellt wurde und dort zumindest nicht abstürzt und korrekt reagiert. Helm löst dieses Problem in keiner Weise. Um es zu lösen, müssen Sie viel Aufwand betreiben, denn Sie müssen Kubernetes den Befehl zum Rollout geben und überwachen, was dort passiert – egal, ob es bereitgestellt oder ausgerollt wurde. Hinzu kommen zahlreiche Aufgaben rund um den Einsatz, die Reinigung und den Zusammenbau.
Pläne
In diesem Jahr werden wir mit der lokalen Entwicklung beginnen. Wir wollen das erreichen, was zuvor in Vagrant war – wir haben „vagrant up“ eingegeben und virtuelle Maschinen bereitgestellt. Wir wollen an den Punkt gelangen, an dem es ein Projekt in Git gibt, wir schreiben dort „werf up“ und es wird eine lokale Kopie dieses Projekts angezeigt, bereitgestellt in einem lokalen Mini-Kub, mit allen für die Entwicklung geeigneten Verzeichnissen verbunden . Je nach Entwicklungssprache erfolgt dies unterschiedlich, aber dennoch so, dass die lokale Entwicklung bequem unter gemounteten Dateien durchgeführt werden kann.
Der nächste Schritt für uns ist Investieren Sie in Komfort für Entwickler. Um ein Projekt schnell lokal mit einem Tool bereitzustellen, entwickeln Sie es, übertragen Sie es in Git, und es wird je nach Pipeline auch in die Phase oder in Tests eingeführt und dann mit demselben Tool in die Produktion gebracht. Diese Einheit, Vereinheitlichung und Reproduzierbarkeit der Infrastruktur von der lokalen Umgebung bis zum Vertrieb ist für uns ein sehr wichtiger Punkt. Aber das ist noch nicht in werf – wir planen es nur.
Aber der Weg zu dapp/werf war immer derselbe wie bei Kubernetes am Anfang. Wir sind auf Probleme gestoßen und haben sie mit Workarounds gelöst – wir haben einige Lösungen für uns selbst gefunden, sowohl für die Shell als auch für alles andere. Dann haben sie versucht, diese Problemumgehungen irgendwie zu begradigen, sie zu verallgemeinern und in diesem Fall in Binärdateien zu konsolidieren, die wir einfach teilen.
Es gibt eine andere Möglichkeit, die ganze Geschichte mit Analogien zu betrachten.
Kubernetes ist ein Autorahmen mit einem Motor. Es gibt keine Türen, kein Glas, kein Radio, keinen Weihnachtsbaum – überhaupt nichts. Nur der Rahmen und der Motor. Und da ist Helm – das ist das Lenkrad. Cool – es gibt ein Lenkrad, aber man braucht auch einen Lenkbolzen, eine Zahnstange, ein Getriebe und Räder, und darauf kann man nicht verzichten.
Im Fall von werf ist dies eine weitere Komponente von Kubernetes. Erst jetzt wird beispielsweise in der Alpha-Version von werf Helm in werf kompiliert, weil wir es satt haben, es selbst zu tun. Dafür gibt es viele Gründe. Ich erzähle Ihnen im Detail, warum wir den gesamten Helm zusammen mit der Pinne in werf zusammengestellt haben .
Jetzt ist werf eine stärker integrierte Komponente. Wir bekommen ein fertiges Lenkrad, einen Lenkbolzen – ich kenne mich nicht besonders gut mit Autos aus, aber das ist ein großer Block, der schon eine ganze Reihe von Problemen löst. Wir müssen nicht selbst den Katalog durchgehen, ein Teil für ein anderes auswählen und darüber nachdenken, wie wir es zusammenschrauben. Wir erhalten einen fertigen Mähdrescher, der viele Probleme auf einmal löst. Aber im Inneren ist es aus denselben Open-Source-Komponenten aufgebaut, es verwendet immer noch Docker für die Assemblierung, Helm für einige Funktionen und es gibt mehrere andere Bibliotheken. Dies ist ein integriertes Tool, mit dem Sie schnell und bequem coole CI/CDs sofort einsatzbereit haben.
Ist Kubernetes schwierig zu warten?
— Sie sprechen über die Erfahrung, dass Sie mit der Nutzung von Kubernetes begonnen haben, das ist ein Rahmen für Sie, ein Motor, und dass Sie viele verschiedene Dinge daran aufhängen können: eine Karosserie, ein Lenkrad, anschraubbare Pedale, Sitze. Es stellt sich die Frage: Wie schwierig ist die Kubernetes-Unterstützung für Sie? Sie haben viel Erfahrung. Wie viel Zeit und Ressourcen investieren Sie in die Unterstützung von Kubernetes isoliert von allem anderen?
Dmitry: Das ist eine sehr schwierige Frage und um sie zu beantworten, müssen wir verstehen, was Unterstützung ist und was wir von Kubernetes wollen. Vielleicht kannst du es verraten?
— Soweit ich weiß und sehe, wollen mittlerweile viele Teams Kubernetes ausprobieren. Jeder spannt sich daran an, legt es auf die Knie. Ich habe das Gefühl, dass die Menschen die Komplexität dieses Systems nicht immer verstehen.
Dmitry: Es ist wie es ist.
— Wie schwierig ist es, Kubernetes von Grund auf zu übernehmen und zu installieren, damit es produktionsbereit ist?
Dmitry: Wie schwierig ist es Ihrer Meinung nach, ein Herz zu transplantieren? Ich verstehe, dass dies eine kompromittierende Frage ist. Ein Skalpell zu benutzen und dabei keinen Fehler zu machen, ist gar nicht so schwer. Wenn Ihnen gesagt wird, wo Sie schneiden und nähen müssen, ist der Vorgang selbst nicht kompliziert. Es ist schwierig, immer wieder zu garantieren, dass alles klappt.
Kubernetes zu installieren und zum Laufen zu bringen ist einfach: Schätzchen! — installiert, es gibt viele Installationsmethoden. Doch was passiert, wenn Probleme auftreten?
Es stellen sich immer Fragen – was haben wir noch nicht berücksichtigt? Was haben wir noch nicht gemacht? Welche Linux-Kernel-Parameter wurden falsch angegeben? Herr, haben wir sie überhaupt erwähnt?! Welche Kubernetes-Komponenten haben wir geliefert und welche nicht? Es stellen sich tausende Fragen, und um sie zu beantworten, muss man 15 bis 20 Jahre in dieser Branche verbringen.
Ich habe ein aktuelles Beispiel zu diesem Thema, das die Bedeutung des Problems „Ist Kubernetes schwer zu warten?“ verdeutlichen könnte. Vor einiger Zeit haben wir ernsthaft darüber nachgedacht, ob wir versuchen sollten, Cilium als Netzwerk in Kubernetes zu implementieren.
Lassen Sie mich erklären, was Cilium ist. Kubernetes verfügt über viele verschiedene Implementierungen des Netzwerksubsystems, und eine davon ist sehr cool – Cilium. Was ist seine Bedeutung? Im Kernel wurde es vor einiger Zeit möglich, Hooks für den Kernel zu schreiben, die auf die eine oder andere Weise in das Netzwerk-Subsystem und verschiedene andere Subsysteme eindringen und es Ihnen ermöglichen, große Teile im Kernel zu umgehen.
Der Linux-Kernel verfügt historisch gesehen über einen IP-Router, einen Überfilter, Bridges und viele verschiedene alte Komponenten, die 15, 20, 30 Jahre alt sind. Im Allgemeinen funktionieren sie, alles ist super, aber jetzt haben sie Container aufgestapelt, und es sieht aus wie ein Turm aus 15 übereinander liegenden Ziegeln, und man steht auf einem Bein darauf – ein seltsames Gefühl. Dieses System hat sich historisch mit vielen Nuancen entwickelt, wie der Blinddarm im Körper. In manchen Situationen gibt es beispielsweise Leistungsprobleme.
Es gibt einen wunderbaren BPF und die Möglichkeit, Hooks für den Kernel zu schreiben – die Jungs haben ihre eigenen Hooks für den Kernel geschrieben. Das Paket kommt in den Linux-Kernel, sie nehmen es direkt am Eingang heraus, verarbeiten es selbst so, wie es sollte, ohne Bridges, ohne TCP, ohne IP-Stack – kurz gesagt, unter Umgehung von allem, was im Linux-Kernel geschrieben ist, und spucken es dann aus es in den Behälter hinaus.
Was ist passiert? Sehr coole Leistung, coole Features – einfach cool! Aber wir schauen uns das an und sehen, dass es auf jeder Maschine ein Programm gibt, das sich mit der Kubernetes-API verbindet und basierend auf den Daten, die es von dieser API erhält, C-Code generiert und Binärdateien kompiliert, die es in den Kernel lädt, damit diese Hooks funktionieren im Kernelraum.
Was passiert, wenn etwas schief geht? Wir wissen nicht. Um dies zu verstehen, müssen Sie den gesamten Code lesen und die gesamte Logik verstehen. Es ist erstaunlich, wie schwierig das ist. Aber auf der anderen Seite gibt es diese Brücken, Netzfilter, IP-Router – ich habe ihren Quellcode nicht gelesen, und die 40 Ingenieure, die in unserem Unternehmen arbeiten, auch nicht. Vielleicht verstehen nur wenige einige Teile.
Und was ist der Unterschied? Es stellt sich heraus, dass es einen IP-Router, den Linux-Kernel und ein neues Tool gibt – welchen Unterschied macht das, wir verstehen das eine oder das andere nicht. Aber wir haben Angst, etwas Neues zu nutzen – warum? Denn wenn das Tool 30 Jahre alt ist, dann wurden in 30 Jahren alle Bugs gefunden, alle Fehler behoben und man muss nicht über alles Bescheid wissen – es funktioniert wie eine Black Box und funktioniert immer. Jeder weiß, welchen Diagnoseschraubendreher er an welcher Stelle anbringen muss, welchen TCP-Dump er zu welchem Zeitpunkt ausführen muss. Jeder kennt sich gut mit Diagnosedienstprogrammen aus und versteht, wie diese Komponenten im Linux-Kernel funktionieren – nicht wie sie funktionieren, sondern wie man sie verwendet.
Und das unglaublich coole Cilium ist keine 30 Jahre alt, es ist noch nicht gealtert. Kubernetes hat das gleiche Problem, kopieren. Dass Cilium perfekt installiert ist, dass Kubernetes perfekt installiert ist, aber wenn in der Produktion etwas schief geht, können Sie dann in einer kritischen Situation schnell verstehen, was schief gelaufen ist?
Wenn wir sagen: Ist es schwierig, Kubernetes zu warten? Nein, es ist sehr einfach und ja, es ist unglaublich schwierig. Kubernetes funktioniert für sich genommen großartig, aber mit einer Milliarde Nuancen.
Über den „Ich werde Glück haben“-Ansatz
— Gibt es Unternehmen, bei denen diese Nuancen fast garantiert auftreten? Angenommen, Yandex verlagert plötzlich alle Dienste auf Kubernetes, dann wird es dort eine enorme Auslastung geben.
Dmitry: Nein, hier geht es nicht um die Last, sondern um die einfachsten Dinge. Wir haben zum Beispiel Kubernetes, wir haben die Anwendung dort bereitgestellt. Woher wissen Sie, dass es funktioniert? Es gibt einfach kein fertiges Tool, um zu verstehen, dass die Anwendung nicht abstürzt. Es gibt kein vorgefertigtes System, das Warnungen sendet; Sie müssen diese Warnungen und jeden Zeitplan konfigurieren. Und wir aktualisieren Kubernetes.
Ich habe Ubuntu 16.04. Man kann sagen, dass dies eine alte Version ist, aber wir sind immer noch dabei, weil es LTS ist. Es gibt systemd, dessen Nuance darin besteht, dass es keine C-Gruppen bereinigt. Kubernetes startet Pods, erstellt C-Gruppen, löscht dann Pods, und irgendwie stellt sich heraus – ich erinnere mich nicht an die Details, tut mir leid –, dass systemd-Slices übrig bleiben. Dies führt dazu, dass jedes Auto mit der Zeit stark langsamer wird. Dies ist nicht einmal eine Frage von Highload. Werden permanente Pods gestartet, beispielsweise wenn es einen Cron-Job gibt, der ständig Pods generiert, dann beginnt die Maschine mit Ubuntu 16.04 nach einer Woche langsamer zu werden. Aufgrund der Tatsache, dass eine Reihe von C-Gruppen erstellt wurden, wird es einen konstant hohen Lastdurchschnitt geben. Dies ist das Problem, mit dem jeder konfrontiert sein wird, der einfach Ubuntu 16 und Kubernetes darüber installiert.
Nehmen wir an, er aktualisiert irgendwie systemd oder etwas anderes, aber im Linux-Kernel bis 4.16 ist es noch lustiger – wenn Sie C-Gruppen löschen, gelangen sie in den Kernel und werden nicht wirklich gelöscht. Daher wird es nach einem Monat Arbeit an dieser Maschine unmöglich sein, die Speicherstatistiken für die Herde einzusehen. Wir nehmen eine Datei heraus, rollen sie im Programm, und eine Datei rollt 15 Sekunden lang, weil der Kernel sehr lange braucht, um eine Million C-Gruppen in sich selbst zu zählen, die gelöscht zu sein scheinen, aber nein – sie sind undicht .
Es gibt hier und da noch viele solcher Kleinigkeiten. Dabei handelt es sich nicht um ein Problem, mit dem große Unternehmen manchmal unter sehr hoher Belastung konfrontiert werden – nein, es handelt sich um alltägliche Dinge. Menschen können monatelang so leben – sie haben Kubernetes installiert, die Anwendung bereitgestellt – es scheint zu funktionieren. Für viele Menschen ist das normal. Sie wissen nicht einmal, dass diese Anwendung aus irgendeinem Grund abstürzen wird, sie erhalten keine Benachrichtigung, aber für sie ist das die Norm. Früher lebten wir auf virtuellen Maschinen ohne Überwachung, jetzt sind wir auf Kubernetes umgestiegen, ebenfalls ohne Überwachung – was ist der Unterschied?
Die Frage ist, dass wir beim Gehen auf Eis nie wissen, wie dick es ist, es sei denn, wir messen es vorher. Viele Menschen gehen und machen sich keine Sorgen, weil sie schon einmal gelaufen sind.
Aus meiner Sicht besteht die Nuance und Komplexität des Betriebs eines Systems darin, sicherzustellen, dass die Dicke des Eises genau ausreicht, um unsere Probleme zu lösen. Darüber reden wir.
In der IT gibt es meines Erachtens zu viele „Ich werde Glück haben“-Ansätze. Viele Menschen installieren Software und nutzen Softwarebibliotheken in der Hoffnung, dass sie Glück haben. Im Allgemeinen haben viele Menschen Glück. Das ist wahrscheinlich der Grund, warum es funktioniert.
— Nach meiner pessimistischen Einschätzung sieht es so aus: Wenn die Risiken hoch sind und die Anwendung funktionieren muss, dann ist Unterstützung von Flaunt erforderlich, vielleicht von Red Hat, oder Sie benötigen Ihr eigenes internes Team speziell für Kubernetes, das bereit ist um es abzuziehen.
Dmitry: Objektiv gesehen ist das so. Für ein kleines Team alleine in die Kubernetes-Geschichte einzusteigen, birgt eine Reihe von Risiken.
Brauchen wir Container?
— Können Sie uns sagen, wie weit verbreitet Kubernetes in Russland ist?
Dmitry: Ich habe diese Daten nicht und bin mir nicht sicher, ob sie jemand anderes hat. Wir sagen: „Kubernetes, Kubernetes“, aber es gibt auch eine andere Sichtweise auf dieses Thema. Ich weiß auch nicht, wie weit verbreitet Container sind, aber ich kenne eine Zahl aus Berichten im Internet, dass 70 % der Container durch Kubernetes orchestriert werden. Es war eine zuverlässige Quelle für eine ziemlich große Stichprobe auf der ganzen Welt.
Dann noch eine Frage: Brauchen wir Container? Mein persönlicher Eindruck und die Gesamtposition des Unternehmens Flant sind, dass Kubernetes ein De-facto-Standard ist.
Es wird nichts anderes geben als Kubernetes.
Dies ist ein absoluter Game-Changer im Bereich des Infrastrukturmanagements. Einfach absolut – das war's, kein Ansible, Chef, virtuelle Maschinen, Terraform mehr. Ich spreche nicht von den alten Methoden der Kollektivwirtschaft. Kubernetes ist ein absoluter Wandel, und jetzt wird es nur noch so sein.
Es ist klar, dass es für einige ein paar Jahre und für andere ein paar Jahrzehnte dauert, bis dies klar wird. Ich habe keinen Zweifel daran, dass es nichts anderes als Kubernetes und diesen neuen Look geben wird: Wir beschädigen das Betriebssystem nicht mehr, sondern nutzen es Infrastruktur als Code, nur nicht mit Code, sondern mit yml – einer deklarativ beschriebenen Infrastruktur. Ich habe das Gefühl, dass es immer so bleiben wird.
— Das heißt, diejenigen Unternehmen, die noch nicht auf Kubernetes umgestiegen sind, werden definitiv darauf umsteigen oder in Vergessenheit geraten. Ich habe dich richtig verstanden?
Dmitry: Das stimmt auch nicht ganz. Wenn wir beispielsweise die Aufgabe haben, einen DNS-Server zu betreiben, dann kann dieser unter FreeBSD 4.10 ausgeführt werden und 20 Jahre lang einwandfrei funktionieren. Einfach arbeiten und das wars. Vielleicht muss in 20 Jahren einmal etwas aktualisiert werden. Wenn es sich um Software in dem von uns eingeführten Format handelt und diese tatsächlich viele Jahre ohne Updates und ohne Änderungen funktioniert, dann wird es natürlich kein Kubernetes geben. Er wird dort nicht gebraucht.
Alles rund um CI/CD – überall dort, wo Continuous Delivery benötigt wird, wo Sie Versionen aktualisieren, aktive Änderungen vornehmen müssen, wo immer Sie Fehlertoleranz aufbauen müssen – nur Kubernetes.
Über Microservices
- Hier habe ich eine leichte Dissonanz. Um mit Kubernetes arbeiten zu können, benötigen Sie externe oder interne Unterstützung – das ist der erste Punkt. Zweitens, wenn wir gerade erst mit der Entwicklung beginnen, sind wir ein kleines Startup, wir haben noch nichts, die Entwicklung für Kubernetes oder Microservice-Architektur im Allgemeinen kann komplex und nicht immer wirtschaftlich gerechtfertigt sein. Mich interessiert Ihre Meinung: Müssen Startups sofort von Grund auf mit dem Schreiben für Kubernetes beginnen oder können sie trotzdem einen Monolithen schreiben und dann erst zu Kubernetes kommen?
Dmitry: Coole Frage. Ich spreche über Microservices Ich habe oft Leute getroffen, die versuchten, Nägel mit einem Mikroskop einzuschlagen. Der Ansatz an sich ist richtig, wir selbst gestalten unsere interne Software so. Aber wenn Sie dies tun, müssen Sie klar verstehen, was Sie tun. Das Wort, das ich an Microservices am meisten hasse, ist „Micro“. Historisch gesehen hat dieses Wort seinen Ursprung dort, und aus irgendeinem Grund denken die Leute, dass Mikro sehr klein ist, weniger als einen Millimeter, wie ein Mikrometer. Das ist nicht so.
Es gibt zum Beispiel einen Monolithen, der von 300 Leuten geschrieben wird, und jeder, der an der Entwicklung beteiligt war, versteht, dass es dort Probleme gibt, und er sollte in Mikrostücke zerlegt werden – etwa 10 Stücke, von denen jedes von 30 Leuten geschrieben wird in einer Minimalversion. Das ist wichtig, notwendig und cool. Aber wenn ein Startup zu uns kommt, bei dem drei sehr coole und talentierte Leute 3 Microservices auf den Knien geschrieben haben, suche ich jedes Mal nach Corvalol.
Es scheint mir, dass darüber bereits tausende Male gesprochen wurde – wir haben in der einen oder anderen Form einen verteilten Monolithen erhalten. Das ist wirtschaftlich nicht gerechtfertigt, es ist generell in allem sehr schwierig. Ich habe das gerade so oft gesehen, dass es mir wirklich wehtut, also rede ich weiter darüber.
Zur Ausgangsfrage gibt es einen Konflikt zwischen der Tatsache, dass einerseits die Verwendung von Kubernetes beängstigend ist, weil nicht klar ist, was dort kaputt gehen oder nicht funktionieren könnte, und andererseits klar ist, dass dort alles funktioniert und nichts außer Kubernetes wird existieren. Antwort - Wägen Sie ab, wie groß der Nutzen ist und wie viele Aufgaben Sie lösen können. Dies ist auf der einen Seite der Skala. Andererseits bestehen Risiken im Zusammenhang mit Ausfallzeiten oder einer Verkürzung der Reaktionszeit, der Verfügbarkeit – mit einer Verschlechterung der Leistungsindikatoren.
Hier ist es: Entweder wir bewegen uns schnell und Kubernetes ermöglicht es uns, viele Dinge viel schneller und besser zu erledigen, oder wir verwenden zuverlässige, bewährte Lösungen, bewegen uns aber viel langsamer. Dies ist eine Entscheidung, die jedes Unternehmen treffen muss. Sie können es sich wie einen Pfad im Dschungel vorstellen – wenn Sie zum ersten Mal gehen, können Sie einer Schlange, einem Tiger oder einem verrückten Dachs begegnen, und wenn Sie zehnmal gelaufen sind, haben Sie den Pfad betreten, entfernt die Äste und das Gehen einfacher. Jedes Mal wird der Weg breiter. Dann ist es eine Asphaltstraße und später ein schöner Boulevard.
Kubernetes steht nicht still. Frage noch einmal: Kubernetes besteht einerseits aus 4-5 Binärdateien, andererseits ist es das gesamte Ökosystem. Dies ist das Betriebssystem, das wir auf unseren Maschinen haben. Was ist das? Ubuntu oder Curios? Dies ist der Linux-Kernel, eine Reihe zusätzlicher Komponenten. All diese Dinge hier, eine Giftschlange wurde von der Straße geworfen, dort wurde ein Zaun errichtet. Kubernetes entwickelt sich sehr schnell und dynamisch, und das Volumen der Risiken, das Volumen des Unbekannten nimmt jeden Monat ab und dementsprechend gleichen sich diese Maßstäbe neu aus.
Auf die Frage, was ein Startup tun sollte, würde ich sagen: Kommen Sie zu Flaunt, zahlen Sie 150 Rubel und erhalten Sie einen schlüsselfertigen DevOps-Easy-Service. Wenn Sie ein kleines Startup mit wenigen Entwicklern sind, funktioniert das. Anstatt Ihre eigenen DevOps einzustellen, die lernen müssen, Ihre Probleme zu lösen und zu diesem Zeitpunkt ein Gehalt zu zahlen, erhalten Sie eine schlüsselfertige Lösung für alle Probleme. Ja, es gibt einige Nachteile. Als Outsourcer können wir nicht so eingebunden sein und schnell auf Veränderungen reagieren. Aber wir verfügen über viel Fachwissen und vorgefertigte Praktiken. Wir garantieren, dass wir es in jeder Situation auf jeden Fall schnell herausfinden und alle Kubernetes von den Toten auferstehen lassen.
Ich empfehle dringend, das Outsourcing an Start-ups und etablierte Unternehmen bis zu einer Größe auszulagern, bei der man ein Team von 10 Leuten für den Betrieb einsetzen kann, denn sonst macht es keinen Sinn. Es ist auf jeden Fall sinnvoll, dies auszulagern.
Über Amazon und Google
— Kann ein Host einer Lösung von Amazon oder Google als Outsourcer betrachtet werden?
Dmitry: Ja, natürlich, das löst eine Reihe von Problemen. Aber auch hier gibt es Nuancen. Sie müssen noch verstehen, wie man es benutzt. Zum Beispiel gibt es in der Arbeit von Amazon AWS tausend Kleinigkeiten: Der Load Balancer muss aufgewärmt werden oder es muss im Voraus eine Anfrage geschrieben werden, dass „Leute, wir werden Verkehr empfangen, den Load Balancer für uns aufwärmen!“ Sie müssen diese Nuancen kennen.
Wenn man sich an Leute wendet, die sich darauf spezialisiert haben, werden fast alle typischen Dinge erledigt. Mittlerweile haben wir 40 Ingenieure, bis Ende des Jahres werden es voraussichtlich 60 sein – all das haben wir auf jeden Fall erlebt. Auch wenn wir bei irgendeinem Projekt wieder auf dieses Problem stoßen, fragen wir uns schnell gegenseitig und wissen, wie wir es lösen können.
Die Antwort lautet wahrscheinlich: Natürlich macht eine gehostete Geschichte einiges einfacher. Die Frage ist, ob Sie bereit sind, diesen Hostern zu vertrauen und ob sie Ihre Probleme lösen werden. Amazon und Google haben sich gut geschlagen. Für alle unsere Fälle – genau. Wir haben keine positiveren Erfahrungen mehr. Alle anderen Clouds, mit denen wir zu arbeiten versuchten, verursachen viele Probleme – Ager und alles, was es in Russland gibt, und alle Arten von OpenStack in verschiedenen Implementierungen: Headster, Overage – was auch immer Sie wollen. Sie alle schaffen Probleme, die Sie nicht lösen möchten.
Daher lautet die Antwort „Ja“, aber tatsächlich gibt es nicht sehr viele ausgereifte gehostete Lösungen.
Wer braucht Kubernetes?
— Und doch, wer braucht Kubernetes? Wer sollte schon auf Kubernetes umsteigen, wer ist der typische Flaunt-Kunde, der speziell für Kubernetes kommt?
Dmitry: Das ist eine interessante Frage, denn gerade jetzt, im Zuge von Kubernetes, kommen viele Leute zu uns: „Leute, wir wissen, dass ihr Kubernetes macht, macht es für uns!“ Wir antworten ihnen: „Meine Herren, wir machen kein Kubernetes, wir machen Prod und alles, was damit zusammenhängt.“ Denn es ist derzeit einfach unmöglich, ein Produkt ohne die gesamte CI/CD und diese ganze Geschichte herzustellen. Jeder hat sich von der Einteilung entfernt, dass wir Entwicklung für Entwicklung und dann Ausbeutung für Ausbeutung haben.
Unsere Kunden erwarten unterschiedliche Dinge, aber jeder wartet auf ein gutes Wunder, dass er bestimmte Probleme hat, und jetzt – hop! – Kubernetes wird sie lösen. Die Menschen glauben an Wunder. In ihren Gedanken verstehen sie, dass es kein Wunder geben wird, aber in ihrer Seele hoffen sie – was wäre, wenn dieses Kubernetes jetzt alles für uns lösen würde, sie reden so viel darüber! Plötzlich – niesen! - und eine Wunderwaffe, niesen! – und wir haben eine Betriebszeit von 100 %, alle Entwickler können alles, was in Produktion geht, 50 Mal veröffentlichen, und es stürzt nicht ab. Im Allgemeinen ein Wunder!
Wenn solche Menschen zu uns kommen, sagen wir: „Tut mir leid, aber es gibt kein Wunder.“ Um gesund zu sein, müssen Sie sich gut ernähren und Sport treiben. Um ein zuverlässiges Produkt zu haben, muss es zuverlässig hergestellt werden. Um ein praktisches CI/CD zu haben, müssen Sie es so gestalten. Das ist eine Menge Arbeit, die erledigt werden muss.
Beantwortung der Frage, wer Kubernetes braucht: Niemand braucht Kubernetes.
Manche Menschen haben die falsche Vorstellung, dass sie Kubernetes brauchen. Die Menschen müssen, sie haben ein tiefes Bedürfnis, aufzuhören, über alle Probleme der Infrastruktur und die Probleme beim Betrieb ihrer Anwendungen nachzudenken, zu studieren und sich dafür zu interessieren. Sie möchten, dass Anwendungen einfach funktionieren und einfach bereitgestellt werden können. Für sie ist Kubernetes die Hoffnung, dass sie nicht mehr die Geschichte hören müssen, „wir lagen da“, oder „wir können nicht einführen“ oder etwas anderes.
Der technische Leiter kommt in der Regel zu uns. Sie verlangen von ihm zwei Dinge: Geben Sie uns einerseits Eigenschaften, andererseits Stabilität. Wir empfehlen Ihnen, es auf sich zu nehmen und es zu tun. Die Wunderwaffe, oder besser gesagt das Silberstück, besteht darin, dass Sie aufhören, über diese Probleme nachzudenken und keine Zeit zu verschwenden. Sie werden besondere Leute haben, die dieses Problem schließen werden.
Die Formulierung, dass wir oder irgendjemand sonst Kubernetes braucht, ist falsch.
Admins brauchen Kubernetes wirklich, denn es ist ein sehr interessantes Spielzeug, mit dem man spielen und basteln kann. Seien wir ehrlich – jeder liebt Spielzeug. Wir sind alle irgendwo Kinder, und wenn wir ein neues sehen, wollen wir damit spielen. Manchen wird davon beispielsweise in der Verwaltung abgeraten, weil sie schon genug gespielt haben und schon so müde sind, dass sie einfach keine Lust mehr haben. Aber das ist niemandem völlig entgangen. Wenn ich zum Beispiel Spielzeug im Bereich Systemadministration und DevOps schon lange satt habe, dann liebe ich das Spielzeug immer noch, ich kaufe immer noch ein paar neue. Alle Menschen wollen auf die eine oder andere Weise immer noch irgendeine Art von Spielzeug.
Sie müssen nicht mit der Produktion herumspielen. Wovon ich kategorisch abraten kann und was ich jetzt massenhaft sehe: „Oh, ein neues Spielzeug!“ – Sie rannten los, um es zu kaufen, kauften es und: „Lass es uns jetzt zur Schule bringen und es allen unseren Freunden zeigen.“ Tu das nicht. Ich entschuldige mich, meine Kinder werden gerade erst erwachsen, ich sehe ständig etwas bei Kindern, bemerke es bei mir selbst und verallgemeinere es dann auf andere.
Die endgültige Antwort lautet: Sie brauchen Kubernetes nicht. Sie müssen Ihre Probleme lösen.
Was Sie erreichen können, ist:
- Produkt fällt nicht;
- Selbst wenn er versucht zu fallen, wissen wir im Voraus Bescheid und können etwas hineinstecken.
- Wir können es in dem Tempo ändern, in dem unser Unternehmen es erfordert, und wir können es bequem tun; es bereitet uns keine Probleme.
Es gibt zwei wirkliche Bedürfnisse: Zuverlässigkeit und Dynamik/Flexibilität des Rollouts. Jeder, der derzeit irgendwelche IT-Projekte durchführt, egal in welcher Branche – weicht der Erleichterung der Welt aus, und wer das versteht, muss diese Bedürfnisse lösen. Mit Kubernetes können Sie diese Probleme mit dem richtigen Ansatz, dem richtigen Verständnis und ausreichend Erfahrung lösen.
Über serverlos
— Wenn Sie etwas weiter in die Zukunft blicken, werden beim Versuch, das Problem der Abwesenheit von Problemen mit der Infrastruktur, der Geschwindigkeit des Rollouts und der Geschwindigkeit von Anwendungsänderungen zu lösen, neue Lösungen auftauchen, beispielsweise serverlose Lösungen. Sehen Sie in dieser Richtung Potenzial und, sagen wir mal, eine Gefahr für Kubernetes und ähnliche Lösungen?
Dmitry: Hier müssen wir noch einmal anmerken, dass ich kein Seher bin, der nach vorne schaut und sagt – so wird es sein! Obwohl ich genau das Gleiche getan habe. Ich schaue auf meine Füße und sehe dort eine Menge Probleme, zum Beispiel die Funktionsweise von Transistoren in einem Computer. Es ist lustig, oder? Wir stoßen auf einige Fehler in der CPU.
Machen Sie Serverless ziemlich zuverlässig, günstig, effizient und bequem und lösen Sie alle Ökosystemprobleme. Hier stimme ich mit Elon Musk überein, dass ein zweiter Planet nötig ist, um Fehlertoleranz für die Menschheit zu schaffen. Obwohl ich nicht weiß, was er sagt, verstehe ich, dass ich nicht bereit bin, selbst zum Mars zu fliegen, und dass es morgen nicht passieren wird.
Bei Serverless ist klar, dass dies eine ideologisch korrekte Sache ist, so wie Fehlertoleranz für die Menschheit – zwei Planeten zu haben ist besser als einer. Aber wie geht das jetzt? Das Entsenden einer einzigen Expedition ist kein Problem, wenn Sie Ihre Kräfte darauf konzentrieren. Mehrere Expeditionen zu schicken und dort mehrere Tausend Menschen anzusiedeln, halte ich auch für realistisch. Aber es völlig fehlertolerant zu machen, so dass die Hälfte der Menschheit dort lebt, scheint mir mittlerweile unmöglich, nicht in Betracht gezogen zu werden.
Mit Serverless One-on-One: Die Sache ist cool, aber weit entfernt von den Problemen von 2019. Das Jahr 2030 rückt näher – wir werden es erleben. Ich habe keinen Zweifel daran, dass wir überleben werden, wir werden auf jeden Fall leben (wiederholen Sie es vor dem Schlafengehen), aber jetzt müssen wir andere Probleme lösen. Es ist, als würde man an das Märchenpony Rainbow glauben. Ja, ein paar Prozent der Fälle werden gelöst, und zwar perfekt, aber subjektiv ist Serverless ein Regenbogen ... Für mich ist dieses Thema zu weit entfernt und zu unverständlich. Ich bin nicht bereit zu reden. Im Jahr 2019 können Sie mit Serverless keine einzige Anwendung schreiben.
Wie sich Kubernetes weiterentwickeln wird
— Wie werden sich Kubernetes und das Ökosystem um ihn herum Ihrer Meinung nach entwickeln, während wir uns dieser möglicherweise wunderbaren fernen Zukunft nähern?
Dmitry: Ich habe viel darüber nachgedacht und habe eine klare Antwort. Die erste ist zustandsbehaftet – schließlich ist staatenlos einfacher. Kubernetes investierte zunächst mehr in diese Sache, damit fing alles an. Stateless funktioniert in Kubernetes nahezu perfekt, es gibt einfach nichts zu bemängeln. Es gibt immer noch viele Probleme bzw. Nuancen. Bei uns funktioniert dort schon alles super, aber das sind wir. Es wird noch mindestens ein paar Jahre dauern, bis dies für alle funktioniert. Dies ist kein berechneter Indikator, sondern mein Gefühl aus meinem Kopf.
Kurz gesagt, Statefull sollte und wird sich sehr stark entwickeln, da alle unsere Anwendungen den Status speichern; es gibt keine zustandslosen Anwendungen. Das ist eine Illusion; man braucht immer eine Art Datenbank und etwas anderes. Bei Statefull geht es darum, alles Mögliche in Ordnung zu bringen, alle Fehler zu beheben und alle Probleme zu verbessern, mit denen man derzeit konfrontiert ist – nennen wir es Einführung.
Der Grad des Unbekannten, der Grad ungelöster Probleme, der Grad der Wahrscheinlichkeit, auf etwas zu stoßen, werden deutlich sinken. Das ist eine wichtige Geschichte. Und Operatoren – alles, was mit der Kodifizierung der Verwaltungslogik und der Steuerlogik zu tun hat, um einen einfachen Dienst zu erhalten: MySQL einfacher Dienst, einfacher RabbitMQ-Dienst, einfacher Memcache-Dienst – im Allgemeinen alle diese Komponenten, mit denen wir garantiert funktionieren müssen die Kiste. Dies löst lediglich das Problem, dass wir eine Datenbank wollen, sie aber nicht verwalten wollen, oder dass wir Kubernetes wollen, es aber nicht verwalten wollen.
Diese Geschichte der Betreiberentwicklung in der einen oder anderen Form wird in den nächsten Jahren wichtig sein.
Ich denke, der Bedienkomfort dürfte stark zunehmen – die Box wird immer schwarzer, immer zuverlässiger, mit immer einfacheren Knöpfen.
Ich habe mir einmal auf YouTube bei Saturday Night Live ein altes Interview mit Isaac Asimov aus den 80ern angehört – eine Sendung wie Urgant, nur interessant. Sie fragten ihn nach der Zukunft der Computer. Er sagte, dass die Zukunft in der Einfachheit liege, genau wie beim Radio. Der Radioempfänger war ursprünglich eine komplexe Sache. Um eine Welle zu fangen, musste man 15 Minuten lang an den Knöpfen drehen, die Spieße drehen und im Allgemeinen wissen, wie alles funktioniert, die Physik der Funkwellenübertragung verstehen. Dadurch war im Radio nur noch ein Knopf übrig.
Jetzt im Jahr 2019, welches Radio? Im Auto findet der Radioempfänger alle Wellen und die Namen der Sender. Die Physik des Prozesses hat sich in 100 Jahren nicht verändert, wohl aber die Benutzerfreundlichkeit. Jetzt und nicht nur jetzt, bereits 1980, als es ein Interview mit Azimov gab, nutzten alle das Radio und niemand dachte darüber nach, wie es funktionierte. Es hat immer funktioniert – das ist klar.
Azimov sagte dann, dass es mit Computern genauso sein würde - Die Benutzerfreundlichkeit wird zunehmen. Während man 1980 noch lernen musste, Tasten am Computer zu drücken, wird das in Zukunft nicht mehr der Fall sein.
Ich habe das Gefühl, dass mit Kubernetes und mit der Infrastruktur auch die Benutzerfreundlichkeit enorm steigen wird. Das ist meiner Meinung nach offensichtlich – es liegt an der Oberfläche.
Was tun mit Ingenieuren?
— Was passiert dann mit den Ingenieuren und Systemadministratoren, die Kubernetes unterstützen?
Dmitry: Was ist mit dem Buchhalter nach der Einführung von 1C passiert? Ungefähr gleich. Davor rechneten sie auf dem Papier – jetzt im Programm. Die Arbeitsproduktivität ist um Größenordnungen gestiegen, aber die Arbeit selbst ist nicht verschwunden. Brauchten es früher zehn Ingenieure, um eine Glühbirne einzuschrauben, reicht jetzt eine aus.
Mir scheint, dass die Menge an Software und die Anzahl der Aufgaben mittlerweile schneller wachsen, als neue DevOps auftauchen und die Effizienz steigt. Derzeit herrscht auf dem Markt ein spezifischer Mangel, der noch lange anhalten wird. Später wird alles zu einer Art Normalität zurückkehren, in der die Arbeitseffizienz steigt, es immer mehr Serverlose gibt, ein Neuron an Kubernetes angehängt wird, das alle Ressourcen genau nach Bedarf auswählt, und zwar im Allgemeinen Machen Sie alles selbst, wie es sollte – die Person tritt einfach zurück und mischt sich nicht ein.
Aber jemand muss trotzdem Entscheidungen treffen. Es ist klar, dass das Qualifikations- und Spezialisierungsniveau dieser Person höher ist. Heutzutage braucht man in der Buchhaltung nicht mehr 10 Mitarbeiter, die Bücher führen, damit ihre Hände nicht müde werden. Es ist einfach nicht notwendig. Viele Dokumente werden automatisch gescannt und vom elektronischen Dokumentenmanagementsystem erkannt. Es reicht ein kluger Hauptbuchhalter, der bereits über viel größere Fähigkeiten und ein gutes Verständnis verfügt.
Generell ist dies in allen Branchen der richtige Weg. Mit Autos ist es genauso: Früher gab es ein Auto mit einem Mechaniker und drei Fahrern. Heutzutage ist das Autofahren ein einfacher Vorgang, an dem wir alle jeden Tag teilnehmen. Niemand denkt, dass ein Auto etwas Kompliziertes ist.
DevOps oder Systems Engineering werden nicht verschwinden – die Arbeit auf hohem Niveau und die Effizienz werden zunehmen.
— Ich habe auch eine interessante Idee gehört, dass die Arbeit tatsächlich zunehmen wird.
Dmitry: Natürlich hundertprozentig! Denn die Menge an Software, die wir schreiben, wächst ständig. Die Anzahl der Probleme, die wir mit Software lösen, wächst ständig. Der Arbeitsaufwand wächst. Jetzt ist der DevOps-Markt furchtbar überhitzt. Dies lässt sich an den Gehaltsvorstellungen ablesen. Im positiven Sinne, ohne ins Detail zu gehen, sollte es Junioren geben, die X wollen, Mittelstufen, die das 1,5-fache wollen, und Senioren, die das 2-fache wollen. Und wenn Sie sich nun den Moskauer DevOps-Gehaltsmarkt ansehen, möchte ein Junior ein Gehalt von X bis 3X und ein Senior von X bis 3X haben.
Niemand weiß, wie viel es kostet. Das Gehaltsniveau wird an Ihrem Selbstvertrauen gemessen – ein völliges Irrenhaus, um ehrlich zu sein, ein furchtbar überhitzter Markt.
Natürlich wird sich diese Situation sehr bald ändern – es sollte eine gewisse Sättigung eintreten. Dies ist bei der Softwareentwicklung nicht der Fall – obwohl jeder Entwickler braucht und jeder gute Entwickler braucht, versteht der Markt, wer was wert ist – die Branche hat sich beruhigt. Das ist bei DevOps heutzutage nicht mehr der Fall.
— Aus dem, was ich gehört habe, bin ich zu dem Schluss gekommen, dass sich der derzeitige Systemadministrator keine allzu großen Sorgen machen sollte, sondern dass es an der Zeit ist, seine Fähigkeiten zu verbessern und sich darauf vorzubereiten, dass es morgen mehr Arbeit geben wird, die jedoch höher qualifiziert sein wird.
Dmitry: Einhundert Prozent. Im Allgemeinen leben wir im Jahr 2019 und die Lebensregel lautet wie folgt: Lebenslanges Lernen – wir lernen unser ganzes Leben lang. Mir kommt es so vor, als ob das jetzt schon jeder weiß und fühlt, aber es reicht nicht aus, es zu wissen – man muss es tun. Jeden Tag müssen wir uns ändern. Wenn wir das nicht tun, werden wir früher oder später an den Rand unseres Berufsstandes geraten.
Seien Sie auf scharfe 180-Grad-Kurven vorbereitet. Ich schließe eine Situation nicht aus, in der sich etwas radikal ändert, etwas Neues erfunden wird – es passiert. Hopp! - und wir handeln jetzt anders. Es ist wichtig, darauf vorbereitet zu sein und sich keine Sorgen zu machen. Es kann vorkommen, dass sich morgen alles, was ich tue, als unnötig herausstellt – nichts, ich habe mein ganzes Leben lang studiert und bin bereit, etwas anderes zu lernen. Das ist kein Problem. Sie müssen keine Angst vor der Arbeitsplatzsicherheit haben, aber Sie müssen bereit sein, ständig etwas Neues zu lernen.
Wünsche und eine Minute Werbung
- Haben Sie einen Wunsch?
Dmitry: Ja, ich habe mehrere Wünsche.
Zuerst und kaufmännisch - abonnieren . Liebe Leserinnen und Leser, gehen Sie auf YouTube und abonnieren Sie unseren Kanal. In etwa einem Monat werden wir mit dem aktiven Ausbau des Videodienstes beginnen. Wir werden viele Bildungsinhalte über Kubernetes haben, offen und abwechslungsreich: von praktischen Dingen bis hin zu Laboren, bis hin zu tiefgreifenden grundlegenden theoretischen Dingen und der Verwendung von Kubernetes im Internet Ebene der Prinzipien und Muster.
Der zweite kaufmännische Wunsch - gehen Sie zu und Sterne setzen, weil wir uns von ihnen ernähren. Wenn Sie uns keine Sterne geben, haben wir nichts zu essen. Es ist wie Mana in einem Computerspiel. Wir tun etwas, wir tun, wir versuchen es, jemand sagt, dass das schreckliche Fahrräder sind, jemand, dass alles völlig falsch ist, aber wir machen weiter und handeln absolut ehrlich. Wir sehen ein Problem, lösen es und teilen unsere Erfahrungen. Deshalb gib uns einen Stern, er wird nicht von dir verschwinden, sondern zu uns kommen, weil wir uns von ihnen ernähren.
Dritter, wichtiger und nicht mehr kaufmännischer Wunsch – Hör auf, an Märchen zu glauben. Sie sind Profis. DevOps ist ein sehr seriöser und verantwortungsvoller Beruf. Hören Sie auf, am Arbeitsplatz zu spielen. Lassen Sie es Klick machen und Sie werden es verstehen. Stellen Sie sich vor, Sie kommen ins Krankenhaus und dort experimentiert der Arzt mit Ihnen. Ich verstehe, dass dies für jemanden beleidigend sein kann, aber höchstwahrscheinlich geht es hier nicht um Sie, sondern um jemand anderen. Sagen Sie auch anderen, sie sollen aufhören. Das ruiniert wirklich das Leben für uns alle – viele fangen an, Betriebsleiter, Admins und DevOps als Typen zu behandeln, die schon wieder etwas kaputt gemacht haben. Dies war meistens deshalb „kaputt“, weil wir zum Spielen gingen und nicht mit dem kalten Bewusstsein hinsahen, dass es so ist, und dass es so ist.
Das bedeutet nicht, dass Sie nicht experimentieren sollten. Wir müssen experimentieren, wir machen es selbst. Ehrlich gesagt spielen wir selbst manchmal Spiele – das ist natürlich sehr schlimm, aber uns ist nichts Menschliches fremd. Erklären wir 2019 zu einem Jahr ernsthafter, gut durchdachter Experimente und nicht zu einem Jahr der Produktion von Spielen. Wahrscheinlich.
- Herzlichen Dank!
Dmitry: Vielen Dank, Vitaly, sowohl für die Zeit als auch für das Interview. Liebe Leserinnen und Leser, vielen Dank, wenn Sie plötzlich an diesem Punkt angelangt sind. Ich hoffe, dass wir Ihnen zumindest ein paar Gedanken mitgebracht haben.
Im Interview ging Dmitry auf das Thema werf ein. Nun ist dies ein universelles Schweizer Messer, das fast alle Probleme löst. Aber das war nicht immer so. An auf dem Festival Dmitry Stolyarov wird Ihnen ausführlich über dieses Tool berichten. im Bericht Es wird alles geben: Probleme und versteckte Nuancen von Kubernetes, Möglichkeiten zur Lösung dieser Schwierigkeiten und die aktuelle Implementierung von werf im Detail. Seien Sie am 27. und 28. Mai dabei, wir entwickeln die perfekten Werkzeuge.
Source: habr.com