Wird Kubernetes die Welt erobern? Wann und wie?

Im Vorfeld DevOpsConf Vitaliy Chabarov führte ein Interview mit Dmitry Stolyarov (distol), dem technischen Direktor und Mitbegründer des Unternehmens „Flant“. Vitaliy fragte Dmitry, womit sich „Flant“ beschäftigt, über Kubernetes, die Entwicklung des Ökosystems und den Support. Sie besprachen, warum Kubernetes nötig ist und ob es überhaupt benötigt wird. Außerdem ging es um Mikrodienste, Amazon AWS, den Ansatz „Es wird schon klappen“ in DevOps, die Zukunft von Kubernetes, wann, wie und warum es die Welt erobern wird, die Perspektiven für DevOps und worauf sich Ingenieure in naher Zukunft mit Vereinfachungen und neuronalen Netzen vorbereiten sollten.

Das Originalinterview im Podcastformat können Sie auf DevOps Defloop - einem russischsprachigen Podcast über DevOps - hören, und weiter unten finden Sie die Textversion.

Hier und im Folgenden stellt Vitaliy Chabarov ein Ingenieur von Express42.

Über „Flant“

— Dima, hallo. Du bist der technische Direktor von „Flant“ und auch dessen Gründer. Bitte erzähl uns, womit beschäftigt sich das Unternehmen und was ist deine Rolle darin?

Dmitry: Von außen sieht es so aus, als wären wir die Art von Typen, die überall Kubernetes implementieren und damit experimentieren. Aber das stimmt nicht. Wir haben als Linux-Company begonnen, aber seit langem konzentrieren wir uns hauptsächlich auf die Betreuung von Produktions- und Highload-Projekten aus einer Hand. Normalerweise bauen wir die gesamte Infrastruktur von Grund auf neu und sind dann lange dafür verantwortlich. Daher ist die Hauptarbeit von «Flant», für die wir auch bezahlt werden, die Übernahme von Verantwortung und die Implementierung von Produktionslösungen aus einer Hand..




Ich, als technischer Direktor und einer der Gründer des Unternehmens, beschäftige mich rund um die Uhr damit, mir zu überlegen, wie die Verfügbarkeit der Produktion erhöht, die Nutzung vereinfacht und das Leben der Admins erleichtert werden kann, um das Leben der Entwickler angenehmer zu gestalten.

Über Kubernetes

— In letzter Zeit sehe ich viele Vorträge von «Flant» Artikel über Kubernetes. Wie sind Sie dazu gekommen?

Dmitry: Ich habe schon oft darüber gesprochen, aber ich habe nichts dagegen, das zu wiederholen. Ich halte es für wichtig, dieses Thema erneut anzusprechen, denn es herrscht häufig Verwirrung zwischen Ursache und Wirkung.

Wir benötigten dringend ein Werkzeug. Wir hatten mit vielen Problemen zu kämpfen, suchten nach Lösungen und erlebten den Bedarf an einem passenden Tool. Wir durchforsteten zahlreiche Optionen, bauten unsere eigenen Lösungen und sammelten Erfahrung. Allmählich kamen wir dazu, Docker fast sofort nach seiner Veröffentlichung 2013 zu nutzen. Zu diesem Zeitpunkt hatten wir bereits viel Erfahrung mit Containern gesammelt und selbst eine Art "Docker" mit eigenen Notlösungen in Python entwickelt. Mit der Einführung von Docker konnten wir unsere provisorischen Lösungen endlich beiseitelegen und ein zuverlässiges, von der Community unterstütztes Produkt nutzen.

Die Geschichte mit Kubernetes ist ähnlich. Als es anfing, populär zu werden – für uns war das die Version 1.2 – hatten wir bereits viele provisorische Lösungen, sowohl in Shell als auch in Chef, mit denen wir versuchten, Docker zu orchestrieren. Wir schauten uns ernsthaft Rancher und verschiedene andere Lösungen an, aber dann kam Kubernetes, das genau so umgesetzt wurde, wie wir es auch gemacht hätten – oder sogar besser. Da gab es nichts zu beanstanden.

Ja, hier gibt es einige unfertige Aspekte, dort gibt es etwas Unvollständiges – viele Unvollkommenheiten, und 1.2 ist wirklich schrecklich, aber... Kubernetes ist wie ein Gebäude im Bau – man schaut auf das Projekt und versteht, dass es großartig wird. Wenn das Gebäude jetzt ein Fundament und zwei Etagen hat, weiß man, dass man am besten noch nicht einziehen sollte, während es mit der Software solche Probleme nicht gibt – man kann sie bereits nutzen.

Wir hatten keinen Moment, in dem wir darüber nachgedacht haben, ob wir Kubernetes verwenden sollten oder nicht. Wir haben darauf gewartet, lange bevor es erschien, und haben versucht, eigene Analogien zu entwickeln.

Über Kubernetes

— Nehmen Sie direkt an der Entwicklung von Kubernetes teil?

Dmitry: Indirekt. Wir tragen eher zur Entwicklung des Ökosystems bei. Wir senden eine bestimmte Anzahl von Pull-Requests: in Prometheus, an verschiedene Operatoren, in Helm – ins Ökosystem. Leider bin ich nicht in der Lage, alles, was wir tun, zu verfolgen und könnte irren, aber von uns gibt es noch keinen einzigen Pull-Request zum Kern.

— Entwickeln Sie dabei auch viele eigene Tools rund um Kubernetes?

Dmitry: Die Strategie ist folgendermaßen: Wir gehen und erstellen Pull-Requests für alles, was bereits existiert. Wenn Pull-Requests dort nicht angenommen werden, forken wir sie einfach für uns und leben damit, bis sie mit unseren Builds akzeptiert werden. Dann, wenn das bei Upstream ankommt, kehren wir zur Upstream-Version zurück.

Zum Beispiel haben wir den Prometheus-Operator, mit dem wir bereits fünfmal hin und her gewechselt sind zwischen unserem Upstream-Build. Wir brauchen ein bestimmtes Feature, wir haben einen Pull-Request geschickt, wir müssen es morgen ausrollen, und wir wollen nicht warten, bis es im Upstream veröffentlicht wird. Daher bauen wir uns das selbst und rollen unseren Build mit unserem benötigten Feature auf all unseren Clustern aus. Dann wird das zum Beispiel im Upstream mit den Worten zurückgebracht: 'Leute, lasst uns das für einen allgemeineren Fall machen', wir oder jemand anderer machen das fertig, und im Laufe der Zeit wird es wieder zusammengeführt.

Alles, was existiert, streben wir an, weiterzuentwickeln.. Viele Elemente, die noch nicht existieren, wurden entweder noch nicht erfunden oder zwar erdacht, aber noch nicht umgesetzt – und genau das tun wir. Nicht, weil uns der Prozess oder das Fahrradbauen als Branche gefällt, sondern einfach, weil wir dieses Werkzeug brauchen. Oft wird die Frage gestellt, warum wir das eine oder andere gemacht haben. Die Antwort ist einfach – weil wir vorankommen und ein praktisches Problem lösen mussten, und wir haben es mit diesem Tool gelöst.

Der Weg ist immer der gleiche: Wir suchen sehr gründlich und, wenn wir keine Lösung finden, wie man aus einem Laib Brot einen Oberleitungsbus macht, dann machen wir unser eigenes Brot und unseren eigenen Oberleitungsbus.

Die „Flant“-Werkzeuge

– Mir ist bekannt, dass es bei „Flant“ jetzt Addon-Operatoren, Shell-Operatoren und dapp/werf-Werkzeuge gibt. Soweit ich verstehe, handelt es sich um dasselbe Werkzeug in verschiedenen Inkarnationen. Auch verstehe ich, dass es innerhalb von „Flant“ noch viele verschiedene Werkzeuge gibt. Ist das so?

Dmitry: Auf unserem GitHub gibt es noch viele weitere Dinge. Unter anderem haben wir statusmap – ein Dashboard für Grafana, das bei allen gut angekommen ist. Es wird in fast jedem zweiten Artikel über das Monitoring von Kubernetes auf Medium erwähnt. Es ist schwierig, statusmap kurz zu erklären – dafür bräuchte man einen eigenen Artikel, aber es ist ein sehr nützliches Tool für die zeitliche Statusüberwachung, da wir in Kubernetes häufig den Status in Echtzeit anzeigen müssen. Außerdem haben wir LogHouse – ein Tool auf Basis von ClickHouse und ein bisschen Magie zur Log-Erfassung in Kubernetes.

Viele nützliche Tools! Und es werden noch mehr kommen, da einige interne Lösungen in diesem Jahr veröffentlicht werden. Von den großen Entwicklungen gibt es eine Vielzahl von Add-ons für Kubernetes, wie zum Beispiel, wie man einen Zertifikatsmanager richtig einrichtet – ein Tool zur Verwaltung von Zertifikaten, oder wie man Prometheus mit vielen Erweiterungen installiert – es sind etwa zwanzig verschiedene Binaries, die Daten exportieren und sammeln, dazu bietet Prometheus hervorragende Grafiken und Alarme. All dies sind einfach zahlreiche Add-ons für Kubernetes, die in das Cluster installiert werden und es von einem einfachen in ein fortgeschrittenes, automatisiertes System verwandeln, in dem viele Fragen bereits gelöst sind. Ja, es wird viel getan.

Entwicklung des Ökosystems

— Ich denke, das ist ein sehr großer Beitrag zur Entwicklung dieses Werkzeugs und seiner Anwendungsmethoden. Kannst du ungefähr abschätzen, wer ebenfalls einen solchen Beitrag zur Entwicklung des Ökosystems leisten würde?

Dmitry: In Russland, von den Unternehmen, die auf unserem Markt tätig sind – niemand kommt auch nur annähernd daran.. Natürlich ist das eine gewagte Aussage, denn es gibt große Akteure wie Mail und Yandex – sie arbeiten ebenfalls mit Kubernetes, aber selbst sie sind nicht ansatzweise mit dem Beitrag der Unternehmen weltweit vergleichbar, die viel mehr leisten als wir. Es ist schwierig, Flant mit einem Team von 80 Personen mit Red Hat zu vergleichen, bei dem, wenn ich mich nicht irre, allein für Kubernetes 300 Ingenieure arbeiten. Ein Vergleich ist nicht wirklich fair. In unserer R&D-Abteilung haben wir 6 Personen, einschließlich mir, die alle unsere Tools entwickeln. 6 Personen im Vergleich zu 300 Ingenieuren bei Red Hat – das lässt sich nur schwer vergleichen.

– Dennoch ist es bemerkenswert, dass selbst diese 6 Personen etwas wirklich Nützliches und Übertragbares schaffen können, wenn sie mit einer praktischen Herausforderung konfrontiert werden und eine Lösung in die Community einbringen – das ist ein interessanter Fall. Ich verstehe, dass in großen Technologieunternehmen, in denen es eigene Entwicklungen und Unterstützungsteams für Kubernetes gibt, ähnliche Tools entwickelt werden können. Das ist ein Beispiel dafür, dass man etwas entwickeln und der Community zur Verfügung stellen kann, um der gesamten Kubernetes-Community einen Impuls zu geben.

Dmitry: Das könnte eine spezielle Fähigkeit des Integrators sein, seine Besonderheit. Wir haben viele Projekte und begegnen unterschiedlichen Situationen. Für uns besteht der Hauptweg zur Schaffung von Mehrwert darin, diese Fälle zu analysieren, das Gemeinsame zu finden und sie für uns möglichst kostengünstig zu gestalten. Damit beschäftigen wir uns aktiv. Es ist schwierig, über Russland und die Welt zu sprechen, aber wir haben etwa 40 DevOps-Ingenieure in unserem Unternehmen, die sich mit Kubernetes beschäftigen. Ich glaube nicht, dass es in Russland viele Unternehmen gibt, die mit einer vergleichbaren Anzahl von Fachleuten aufwarten können, die sich mit Kubernetes auskennen, falls es sie überhaupt gibt.

Ich verstehe alles über den Jobtitel DevOps-Ingenieur, jeder kennt ihn und wir haben uns daran gewöhnt, DevOps-Ingenieure DevOps-Ingenieuren zu nennen, darüber wollen wir nicht diskutieren. Diese 40 großartigen DevOps-Ingenieure stehen täglich vor Herausforderungen und lösen sie; wir analysieren einfach diese Erfahrungen und versuchen, sie zusammenzufassen. Wir wissen, dass, wenn dieses Wissen bei uns bleibt, das Tool in ein oder zwei Jahren nutzlos wird, weil irgendwo in der Community bereits ein passendes Tool verfügbar sein wird. Es macht keinen Sinn, diese Erfahrungen anzusammeln – es ist einfach eine Verschwendung von Ressourcen und Zeit. Wir nehmen das Risiko jedoch gerne in Kauf. Wir veröffentlichen alles mit großer Freude und verstehen, dass wir es veröffentlichen, weiterentwickeln, bekannt machen und fördern müssen, damit die Menschen es nutzen und ihre Erfahrungen einbringen – dann wächst und lebt alles weiter. In zwei Jahren landet das Tool nicht im Müll. Es ist keine Schande, weiter Ressourcen zu investieren, da man sieht, dass jemand dein Tool nutzt, und in zwei Jahren nutzen es schon alle.

Das ist Teil unserer großen Strategie mit dapp/werf. Ich kann mich nicht erinnern, wann wir damit angefangen haben, ich glaube, vor etwa 3 Jahren. Ursprünglich wurde es überhaupt in Shell geschrieben. Es war ein super Prototyp, wir haben einige unserer eigenen Probleme gelöst – es hat funktioniert! Aber mit Shell gibt es Probleme, es ist unmöglich, weiter auszubauen, in Shell zu programmieren ist eine echte Herausforderung. Wir hatten die Gewohnheit, in Ruby zu schreiben, also haben wir etwas umgeschrieben und weiterentwickelt, aber wir sind auf das Problem gestoßen, dass die Community, die Leute, die nicht sagen „wir wollen oder wollen nicht“, die Nase rümpfen, wenn es um Ruby geht, so komisch das auch ist. Wir haben verstanden, dass wir das Ganze in Go schreiben müssen, um einfach den ersten Punkt auf der Liste zu erfüllen: Das DevOps-Tool sollte ein statisches Binary sein. Ob in Go oder nicht, das ist nicht so wichtig, aber ein besseres statisches Binary, das in Go geschrieben ist.

Wir haben viel Aufwand betrieben, haben dapp in Go neu geschrieben und es werf genannt. Dapp wird nicht mehr unterstützt, wird nicht weiterentwickelt, arbeitet in einer aktuellen Version, aber es gibt einen klaren Upgrade-Weg nach oben, dem man folgen kann.

Warum wurde dapp erstellt

— Kannst du in Kürze erzählen, warum dapp erstellt wurde, welche Probleme es löst?

Dmitry: Der erste Grund betrifft das Bauen. Zunächst hatten wir erhebliche Probleme mit dem Bauen, als Docker das Multi-Stage-Deployment nicht unterstützte, und wir mussten es selbst umsetzen. Danach hatten wir eine ganze Reihe von Fragen zur Bereinigung von Images. Jeder, der CI/CD einrichtet, muss früher oder später das Problem lösen, dass viele gebaute Images existieren, aus denen wir diejenigen entfernen müssen, die nicht benötigt werden, und die benotigen behalten müssen.

Der zweite Grund betrifft das Deployen. Ja, es gibt Helm, aber er löst nur einen Teil der Probleme. Komisch, aber wahr, es steht geschrieben, dass „Helm der Paketmanager für Kubernetes“ ist. Genau, „der“. Zudem erwarten wir als Nutzer eines „Paketmanagers“ in der Regel, dass, wenn wir sagen: „Paket installieren!“, er uns auch mitteilt: „Paket installiert.“

Interessanterweise sagen wir: „Helm, installiere das Paket“, und wenn er antwortet, dass es installiert wurde, stellt sich heraus, dass er nur den Installationsprozess gestartet hat – er hat Kubernetes gesagt: „Starte dieses Ding!“, aber ob es tatsächlich gestartet wurde oder funktioniert, das klärt Helm überhaupt nicht.

Es stellt sich heraus, dass Helm einfach ein textbasierter Preprocessor ist, der Daten in Kubernetes hochlädt.

Doch bei jedem Deployment wollen wir wissen – ist die Anwendung in Produktion gegangen oder nicht? In Produktion bedeutet, dass die Anwendung dort angekommen ist, eine neue Version bereitgestellt wurde, und sie zumindest nicht ausfällt und korrekt reagiert. Helm löst dieses Problem nicht. Um es zu lösen, müssen wir viel Aufwand betreiben, denn wir müssen Kubernetes anweisen, die Anwendung bereitzustellen und beobachten, was passiert – ob es bereitgestellt wurde, ob es ausgerollt wurde. Und es gibt viele Aufgaben im Zusammenhang mit dem Deployment, der Bereinigung und dem Zusammenbau.

Pläne

Noch in diesem Jahr werden wir in die lokale Entwicklung gehen. Wir möchten zu dem zurückkehren, was früher mit Vagrant möglich war – man gab "vagrant up" ein und die virtuellen Maschinen wurden gestartet. Wir wollen zu einem Zustand kommen, in dem es ein Projekt in Git gibt, wir dort "werf up" eingeben und es eine lokale Kopie dieses Projekts in einem lokalen Mini-Kub hochfährt, mit allen Verzeichnissen, die für die Entwicklung praktisch sind. Je nach Programmiersprache wird dies unterschiedlich umgesetzt, aber dennoch soll es bequem sein, die lokale Entwicklung mit eingebundenen Dateien fortzuführen.

Der nächste Schritt für uns ist es, deutlich in die Benutzerfreundlichkeit für Entwickler investieren. Um ein Projekt mit einem einzigen Tool schnell lokal aufzusetzen, weiterzuentwickeln, in Git zu pushen, und es dann genau so auf die Stage oder für Tests abzurufen, je nachdem, wie die Pipelines konfiguriert sind, und danach mit demselben Tool in die Produktion zu gehen. Diese Einheitlichkeit, Vereinheitlichung und Reproduzierbarkeit der Infrastruktur vom lokalen Umfeld bis zur Produktion ist für uns ein sehr wichtiger Aspekt. Aber das gibt es derzeit noch nicht in werf – wir planen, das zu implementieren.

Der Weg zu dapp/werf war schon immer der gleiche wie der Anfang mit Kubernetes. Wir sind auf Probleme gestoßen und haben sie mit Umgehungslösungen gelöst – wir haben uns irgendwelche Lösungen auf Shell überlegt, auf was auch immer. Dann haben wir versucht, diese Umgehungslösungen zu straffen, zu verallgemeinern und in Binärdateien zu konsolidieren, die wir dann einfach teilen.

Es gibt auch eine andere Sichtweise auf diese ganze Geschichte, mit Analogien.

Kubernetes ist das Chassis eines Autos mit Motor. Es gibt keine Türen, keine Fenster, kein Radio, keinen Duftbaum – überhaupt nichts. Nur das Gestell und der Motor. Und da ist Helm – das ist das Lenkrad. Cool – es gibt ein Lenkrad, aber wir brauchen auch eine Lenksäule, eine Lenkung, ein Getriebe und Räder, und ohne die geht es nicht.

Im Fall von werf handelt es sich um einen weiteren Bestandteil von Kubernetes. Aktuell haben wir eine Alpha-Version von werf, in der Helm beispielsweise vollständig in werf integriert ist, weil wir keine Lust mehr haben, dies selbst zu tun. Es gibt viele Gründe dafür, weshalb wir Helm zusammen mit Tiller in werf integriert haben, und ich werde das ausführlich erläutern. bei dem Vortrag auf RIT++.

Jetzt ist werf ein deutlich integrierteres Modul. Wir haben ein fertiges Steuerrad, einen Steuerstift – ich bin kein großer Autoexperte, aber das ist ein großes Modul, das bereits ein breites Spektrum an Aufgaben löst. Wir müssen nicht selbst durch den Katalog blättern, um ein Teil zum anderen zu finden und darüber nachdenken, wie man sie verbindet. Wir erhalten einen kompletten Kombi, der auf einmal eine Vielzahl von Aufgaben bewältigt. Intern besteht es aus denselben Open-Source-Komponenten, nutzt Docker für den Build, Helm für einen Teil der Funktionalität und hat auch noch einige andere Bibliotheken. Es ist ein integriertes Tool, um schnell und einfach eine großartige CI/CD-Lösung direkt aus der Box zu erhalten.

Ist es schwierig, Kubernetes zu unterstützen?

— Sie sprechen über Ihre Erfahrungen mit Kubernetes, das für Sie wie ein Chassis oder Motor ist, an dem man viele verschiedene Komponenten anbringen kann: Karosserie, Lenkrad, Pedale, Sitze. Die Frage ist: Wie schwierig ist es für Sie, Kubernetes zu verwalten? Sie haben umfangreiche Erfahrungen, wie viel Zeit und Ressourcen verwenden Sie spezifisch für die Verwaltung von Kubernetes im Vergleich zu anderen Aufgaben?

Dmitry: Das ist eine sehr komplexe Frage, und um sie zu beantworten, müssen wir verstehen, was wir unter Verwaltung verstehen und was wir von Kubernetes erwarten. Könnten Sie das näher erläutern?

— Soweit ich weiß und das, was ich beobachte, wollen viele Teams Kubernetes ausprobieren. Alle setzen es hastig auf, einfach mal schnell. Ich habe das Gefühl, dass die Leute nicht immer die Komplexität dieses Systems verstehen.

Dmitry: Das stimmt.

— Wie schwierig ist es, Kubernetes von Grund auf zu installieren, sodass es produktionsbereit ist?

Dmitry: Wie denken Sie, wie schwierig ist es, ein Herz zu transplantieren? Ich verstehe, das ist eine heikle Frage. Mit einem Skalpell zu hantieren und keinen Fehler zu machen, ist eigentlich nicht so kompliziert. Wenn Sie wissen, wo man schneiden und wo man nähen muss, dann ist der Vorgang an sich nicht schwierig. Es ist jedoch schwierig, jedes Mal zu garantieren, dass alles gelingt.

Kubernetes zu installieren und zum Laufen zu bringen ist einfach: Klick! — schon installiert, es gibt viele Installationsmethoden. Aber was passiert, wenn Probleme auftreten?

Es tauchen immer Fragen auf — was haben wir noch nicht berücksichtigt? Was haben wir noch nicht getan? Welche Parameter des Linux-Kernels haben wir falsch angegeben? Oh Gott, haben wir sie überhaupt angegeben?! Welche Komponenten von Kubernetes haben wir installiert und welche nicht? Tausende von Fragen entstehen, und um sie zu beantworten, braucht man 15-20 Jahre Erfahrung in dieser Branche.

Ich habe ein aktuelles Beispiel zu diesem Thema, das die Essenz der Frage ‚Ist es schwierig, Kubernetes zu warten?‘ beleuchten kann. Vor einiger Zeit haben wir ernsthaft in Betracht gezogen, Cilium als Netzwerk für Kubernetes einzuführen.

Ich erkläre, was Cilium ist. In Kubernetes gibt es viele verschiedene Implementierungen des Netzwerk-Subsystems, und eine davon ist wirklich großartig — das ist Cilium. Worauf basiert es? Vor einiger Zeit wurden im Kernel Hooks eingeführt, die in das Netzwerk-Subsystem und andere Subsysteme eingreifen können und es ermöglichen, große Teile des Kernels zu umgehen.

Im Linux-Kernel gibt es historisch gesehen ip rout, Netfilter, Brücken und viele verschiedene alte Komponenten, die 15, 20 oder sogar 30 Jahre alt sind. Im Großen und Ganzen funktionieren sie gut, alles ist klasse, aber jetzt gibt es viele Container, und das sieht aus wie ein Turm aus 15 Ziegeln, auf dem du auf einem Bein stehst – ein seltsames Gefühl. Dieses System hat sich historisch mit vielen Nuancen entwickelt, ähnlich einem Appendix im Körper. In einigen Situationen gibt es Performance-Probleme, zum Beispiel.

Es gibt ein beeindruckendes BPF und die Möglichkeit, Hooks für den Kernel zu schreiben – die Leute haben ihre eigenen Hooks für den Kernel geschrieben. Ein Paket kommt in den Linux-Kernel, sie ziehen es direkt am Eingang heraus, verarbeiten es nach ihren Bedürfnissen, ohne Brücken, ohne TCP, ohne IP-Stack – kurz gesagt, komplett um alles herum, was im Linux-Kernel geschrieben ist, und spucken es sofort in den Container aus.

Was ist daraus geworden? Eine sehr gute Performance, tolle Features – einfach großartig! Aber wir sehen, dass auf jeder Maschine ein Programm läuft, das sich mit dem Kubernetes-API verbindet und basierend auf den Daten, die es von dieser API erhält, C-Code generiert und Binärdateien kompiliert, die im Kernel geladen werden, damit diese Hooks im Kernel-Space funktionieren.

Was passiert, wenn etwas schiefgeht? Das wissen wir nicht. Um das zu verstehen, müsste man den gesamten Code lesen und die gesamte Logik begreifen, was unglaublich kompliziert ist. Andererseits gibt es diese Brücken, Netfilter, IP-Routen – ich habe ihren Quellcode nicht gelesen, und 40 Ingenieure, die in unserer Firma arbeiten, ebenfalls nicht. Vielleicht verstehen nur wenige davon einzelne Teile.

Und was macht das für einen Unterschied? Es gibt IP-Routen und den Linux-Kernel, und es gibt dieses neue Werkzeug – was spielt das für eine Rolle, wir verstehen weder das eine noch das andere. Aber wir fürchten, das Neue zu benutzen – warum? Weil, wenn das Werkzeug 30 Jahre alt ist, in 30 Jahren alle Bugs gefunden wurden, und man nicht alles wissen muss – es funktioniert wie ein schwarzer Kasten und läuft immer. Jeder weiß, welchen Diagnoseschraubendreher man an welcher Stelle ansetzen und welchen Tcpdump man zu welchem Zeitpunkt starten sollte. Alle kennen die Diagnosetools gut und wissen, wie diese Komponenten im Linux-Kernel zusammenarbeiten – nicht wie sie funktionieren, sondern wie man sie benutzt.

Cilium ist noch nicht 30 Jahre alt und ist noch nicht ausgereift. Das gleiche gilt für Kubernetes – es ist eine Kopie. Sowohl Cilium als auch Kubernetes lassen sich problemlos installieren, aber wenn etwas im Produktivbetrieb schiefgeht, sind Sie dann in der Lage, in einer kritischen Situation schnell zu verstehen, was falsch gelaufen ist?

Wenn wir darüber sprechen, ob es schwierig ist, Kubernetes zu unterstützen – die Antwort ist: Nein, es ist sehr einfach, und ja, es ist unglaublich kompliziert. Kubernetes funktioniert für sich allein hervorragend, aber es gibt eine Billion Nuancen.

Zur Philosophie "Mir wird schon alles gelingen"

Gibt es Unternehmen, in denen diese Nuancen fast garantiert auftreten? Stellen wir uns vor, Yandex würde plötzlich alle Dienste auf Kubernetes umstellen – das wäre eine gewaltige Belastung.

DmitryDas ist nicht das Thema der Belastung, sondern der grundlegendsten Dinge. Zum Beispiel haben wir Kubernetes und haben eine Anwendung dort bereitgestellt. Wie können wir sicherstellen, dass sie funktioniert? Es gibt kein fertiges Tool, um herauszufinden, ob die Anwendung stabil läuft. Ein fertiges System, das Alarme sendet, gibt es nicht – Sie müssen diese Alarme und jeden einzelnen Graphen einrichten. Und wir sind dabei, Kubernetes zu aktualisieren.

Wir verwenden Ubuntu 16.04. Man könnte sagen, dass das eine ältere Version ist, aber wir nutzen sie weiterhin, weil es sich um eine LTS-Version handelt. Sie enthält systemd, dessen Besonderheit darin besteht, dass es die C-Gruppen nicht bereinigt. Kubernetes startet Pods, erstellt C-Gruppen, und wenn die Pods gelöscht werden, bleibt irgendwie etwas von systemd übrig – ich erinnere mich nicht an die Einzelheiten, entschuldigen Sie bitte –, was dazu führt, dass im Laufe der Zeit jede Maschine stark langsamer wird. Das ist nicht einmal eine Frage des Hochlastbetriebs. Wenn ständig Pods gestartet werden, zum Beispiel wenn es einen Cron-Job gibt, der kontinuierlich Pods generiert, wird eine Maschine mit Ubuntu 16.04 nach einer Woche langsam werden. Es wird ständig eine hohe mittlere Last geben, weil eine Menge C-Gruppen erstellt wurden. Das ist ein Problem, mit dem jeder konfrontiert ist, der einfach Ubuntu 16 installiert und Kubernetes darüber setzt.

Angenommen, er aktualisiert irgendwie systemd oder etwas anderes, aber im Linux-Kernel bis zur Version 4.16 ist es noch absurder – beim Löschen von C-Gruppen treten sie im Kernel wieder auf und werden tatsächlich nicht entfernt. Nach einem Monat Betrieb mit dieser Maschine ist es unmöglich, Statistiken zu RAM bei den Pods zu sehen. Wir holen eine Datei heraus, testen sie im Programm, und eine Datei benötigt 15 Sekunden, weil das Kernel sehr lange braucht, um intern mit Millionen von C-Gruppen zu rechnen, die angeblich gelöscht sind, aber nicht – sie bleiben bestehen.

Es gibt immer noch viele solcher Kleinigkeiten da und dort. Das ist kein Problem, mit dem große Unternehmen manchmal bei sehr hohen Belastungen konfrontiert werden können – nein, es ist eine Frage des täglichen Lebens. Menschen können monatelang so leben – sie haben Kubernetes installiert, eine Anwendung bereitgestellt – es scheint zu funktionieren. Für viele ist das in Ordnung. Sie erfahren nicht einmal, dass diese Anwendung irgendwann aus irgendeinem Grund ausfällt; ein Alarm kommt nicht, aber für sie ist das normal. Früher lebten sie auf virtuellen Maschinen ohne Überwachung, jetzt sind sie auch ohne Überwachung in Kubernetes umgezogen – wo ist der Unterschied?

Die Frage ist, dass wir, wenn wir über das Eis gehen, nie wissen, wie dick es ist, wenn wir es nicht im Voraus gemessen haben. Viele gehen einfach und machen sich keinen Kopf darüber, weil sie es schon früher gemacht haben.

Aus meiner Sicht besteht die Nuance und Komplexität im Betrieb eines Systems darin, sicherzustellen, dass die Dicke des Eises genau ausreicht, um unsere Anforderungen zu erfüllen. Darum geht es.

Im IT-Bereich gibt es, meiner Meinung nach, zu viele Ansätze mit dem Motto „Mir wird schon Glück zuteil“. Viele installieren Software und nutzen Programmierbibliotheken in der Hoffnung, dass sie Erfolg haben. Insgesamt haben viele tatsächlich Glück. Wahrscheinlich funktioniert es deshalb.

— Aus meiner pessimistischen Perspektive sieht es so aus: Wenn die Risiken hoch sind und die Anwendung laufen muss, dann ist Unterstützung von ‚Flant‘ notwendig, womöglich von Red Hat, oder es wird ein eigenes internes Team benötigt, das speziell für Kubernetes zuständig ist und bereit ist, es zu betreuen.

Dmitry: Objektiv betrachtet ist das so. Sich als kleines Team selbst in die Kubernetes-Thematik einzuarbeiten, birgt einige Risiken.

Brauchen wir Container?

— Kannst du mir erzählen, wie verbreitet Kubernetes überhaupt in Russland ist?

Dmitry: Ich habe diese Daten nicht und bin mir nicht sicher, ob sie überhaupt jemand hat. Wir reden über: „Kubernetes, Kubernetes“, aber es gibt ja auch eine andere Sichtweise zu diesem Thema. Wie verbreitet Container sind, weiß ich ebenfalls nicht, aber ich kenne die Zahl aus Berichten im Internet, dass 70 % der Container von Kubernetes orchestriert werden. Das war eine verlässliche Quelle auf einer ausreichend großen Stichprobe weltweit.

Eine weitere Frage ist - brauchen wir Container? Mein persönliches Empfinden und insgesamt die Position des Unternehmens ‚Flant‘ ist, dass Kubernetes der De-facto-Standard ist.

Nichts außer Kubernetes wird es geben.

Das ist ein absoluter Game-Changer im Bereich Infrastrukturmanagement. Einfach absolut - Schluss mit Ansible, Chef, virtuellen Maschinen, Terraform. Ich spreche schon gar nicht mehr über die alten, veralteten Methoden. Kubernetes ist der absolute Changer, und jetzt wird es nur noch so sein.

Es ist klar, dass einige Jahre nötig sind, um das zu erkennen, während andere Jahrzehnte brauchen. Ich habe keine Zweifel, dass es nichts geben wird außer Kubernetes und dieser neuen Sichtweise: Wir greifen nicht mehr auf das Betriebssystem zu, sondern nutzen infrastructure as code, allerdings nicht mit Code, sondern mit YML - einer deklarativ beschriebenen Infrastruktur. Ich habe das Gefühl, dass es immer so sein wird.

Das bedeutet, dass die Unternehmen, die noch nicht auf Kubernetes umgestiegen sind, entweder auf Kubernetes wechseln oder in Vergessenheit geraten werden. Habe ich dich richtig verstanden?

DmitryDas ist auch nicht ganz korrekt. Wenn wir zum Beispiel einen DNS-Server betreiben möchten, können wir ihn auf FreeBSD 4.10 installieren und er kann 20 Jahre lang hervorragend funktionieren. Einfach nur funktionieren, und das war's. Vielleicht muss nach 20 Jahren einmal etwas aktualisiert werden. Wenn wir über Software sprechen, die wir in einem Zustand gestartet haben und die viele Jahre ohne irgendwelche Updates oder Änderungen funktioniert, dann wird Kubernetes dort sicherlich nicht benötigt. Es ist einfach nicht notwendig.

Alles, was CI/CD betrifft – überall dort, wo Continuous Delivery erforderlich ist, wo Versionsupdates notwendig sind, wo aktive Änderungen vorgenommen werden müssen, wo Ausfallsicherheit aufgebaut werden muss – ist Kubernetes unerlässlich.

Über Mikrodienste

— Hier habe ich ein kleines Dissonanzgefühl. Um mit Kubernetes zu arbeiten, braucht man externe oder interne Unterstützung – das ist der erste Punkt. Der zweite – wenn wir gerade erst mit der Entwicklung beginnen, sind wir ein kleines Start-up, wir haben noch nichts, und die Entwicklung für Kubernetes oder überhaupt für eine Microservices-Architektur kann herausfordernd und nicht immer wirtschaftlich sinnvoll sein. Ich bin gespannt auf deine Meinung – sollten Start-ups von Anfang an direkt für Kubernetes entwickeln, oder ist es besser, zuerst ein Monolith zu erstellen und später zu Kubernetes zu wechseln?

Dmitry: Gute Frage. Ich habe einen Vortrag über Microservices. „Microservices: Die Größe macht den Unterschied“. Ich habe oft erlebt, dass Leute versuchen, mit einem Mikroskop Nägel einzuschlagen. Der Ansatz an sich ist richtig, wir gestalten unsere interne Software tatsächlich auf diese Weise. Aber wenn man das macht, muss man genau wissen, was man tut. Was ich an Microservices am meisten hasse, ist das Wort „micro“. Historisch hat sich dieses Wort entwickelt, und aus irgendeinem Grund denken die Leute, dass mikro sehr klein ist, kleiner als ein Millimeter, wie ein Mikrometer. Das ist nicht richtig.

Zum Beispiel gibt es ein Monolith, an dem 300 Personen arbeiten, und alle, die an der Entwicklung beteiligt waren, wissen, dass es Probleme gibt und dieser in etwa 10 Mikro-Teile aufgeteilt werden muss, wobei jeder Teil von mindestens 30 Personen bearbeitet wird. Das ist wichtig, notwendig und gut. Doch wenn ein Startup zu uns kommt, bei dem 3 sehr talentierte Jungs 60 Mikroservices hibbelig erstellt haben, benötige ich jedes Mal Beruhigungsmittel.

Es scheint, als wäre darüber schon tausend Mal gesprochen worden - wir haben einen verteilten Monolithen in der einen oder anderen Form. Das ist wirtschaftlich nicht tragbar und äußerst kompliziert. Ich habe es einfach so oft gesehen, dass es mir schmerzt, weshalb ich weiter darüber spreche.

Zur eingangs gestellten Frage: Es gibt einen Konflikt zwischen der Tatsache, dass Kubernetes furchtbar schwer zu nutzen ist, weil unklar bleibt, was dort kaputtgehen oder nicht funktionieren könnte, und der Erkenntnis, dass der gesamte Trend dorthin geht und nichts anderes als Kubernetes sein wird. Die Antwort ist - den Nutzen, der entsteht, und das Volumen der Aufgaben, die Sie lösen können, abzuwägen.. Dies ist die eine Seite der Waagschale. Auf der anderen Seite stehen die Risiken, die mit Ausfallzeiten oder längeren Reaktionszeiten und Verfügbarkeitsproblemen verbunden sind – ein Rückgang der Leistungskennzahlen.

Hier ist es so – entweder wir bewegen uns schnell, und Kubernetes ermöglicht viele Dinge viel schneller und besser, oder wir ziehen zuverlässige, bewährte Lösungen vor, bewegen uns aber deutlich langsamer. Diese Entscheidung muss jedes Unternehmen treffen. Man kann das als einen Pfad im Dschungel betrachten – wenn man das erste Mal geht, kann man einer Schlange, einem Tiger oder einem wilden Dachs begegnen, und nach dem zehnten Mal ist der Weg klarer – man hat den Pfad geebnet, Äste entfernt und es wird einfacher. Mit jedem Mal wird der Pfad breiter. Schließlich wird es zu einer asphaltierten Straße und später zu einem schönen Boulevard.

Kubernetes entwickelt sich ständig weiter. Die Frage bleibt: Ist Kubernetes, auf der einen Seite, nur eine Ansammlung von 4-5 Binärdateien, oder ist es auf der anderen Seite eine umfassende Ecosystem? Es ist ein Betriebssystem, das auf unseren Maschinen läuft. Was ist es genau? Ubuntu oder Curios? Es basiert auf dem Linux-Kernel, ergänzt durch zahlreiche Komponenten. Während hier eine giftige Schlange von der Straße verbannt wurde und ein Zaun errichtet wurde, entwickelt sich Kubernetes sehr schnell und dynamisch. Mit jedem Monat verringert sich das Risiko und das Unbekannte, wodurch die Balance sich allmählich verschiebt.

Wenn ich auf die Frage antworte, was ein Startup tun sollte, würde ich sagen: Kommen Sie zu "Flant", zahlen Sie 150.000 Rubel und erhalten Sie einen schlüsselfertigen DevOps-Service. Wenn Sie ein kleines Team von Entwicklern sind, funktioniert das. Anstatt einen eigenen DevOps-Mitarbeiter einzustellen, der lernen muss, Ihre Probleme zu lösen, und während dieser Zeit Gehalt zu kosten, erhalten Sie eine schlüsselfertige Lösung für alle Ihre Anliegen. Ja, es gibt einige Nachteile. Als Outsourcing-Anbieter können wir nicht so engagiert sein und schnell auf Änderungen reagieren. Aber wir haben dafür jede Menge Expertise und bewährte Praktiken. Wir garantieren, dass wir in jeder Situation schnell reagieren und jedes Kubernetes Problem lösen können.

Ich empfehle Outsourcing für Startups und etablierte Unternehmen kategorisch bis zu dem Punkt, an dem Sie ein Team von 10 Personen für den Betrieb bereitstellen können, denn anders macht es keinen Sinn. Es ist absolut sinnvoll, auszulagern.

Über Amazon und Google

Kann man Hosting-Lösungen von Amazon oder Google als Outsourcing betrachten?

Dmitry: Ja, das löst selbstverständlich einige Fragen. Aber es gibt wieder Nuancen. Man muss dennoch verstehen, wie man das anwendet. Zum Beispiel gibt es eine Vielzahl von Details bei der Arbeit mit Amazon AWS: Den Load Balancer muss man aufwärmen oder im Voraus eine Anfrage stellen: „Leute, wir erwarten Traffic, bitte wärmt unseren Load Balancer auf!“ Diese Nuancen sollte man kennen.

Wenn Sie sich an Fachleute wenden, die in diesem Bereich spezialisiert sind, erhalten Sie fast alle typischen Dinge fixiert. Wir haben derzeit 40 Ingenieure, und bis zum Ende des Jahres werden es wahrscheinlich 60 sein – wir sind bereits mit all diesen Themen konfrontiert gewesen. Selbst wenn wir in einem bestimmten Projekt erneut auf dieses Problem stoßen, fragen wir uns schnell untereinander und wissen bereits, wie wir es lösen können.

Wahrscheinlich lautet die Antwort: Ja, die Hosted-Lösung erleichtert einen Teil davon. Die Frage ist, ob Sie diesen Hostern vertrauen können und ob sie Ihre Probleme lösen werden. Amazon und Google haben sich gut bewährt. In all unseren Fällen – definitiv. Weitere positive Erfahrungen haben wir nicht gemacht. Alle anderen Clouds, mit denen wir versucht haben zu arbeiten, verursachen viele Probleme – sowohl Ager als auch alles, was es in Russland gibt, und diverse OpenStack-Implementierungen: Headster, Overage – alles, was Sie wollen. Sie alle erzeugen Schwierigkeiten, die man nicht lösen möchte.

Deshalb ist die Antwort: Ja, aber tatsächlich gibt es nicht viele ausgereifte Hosted-Lösungen.

Wer braucht Kubernetes?

Aber wer braucht Kubernetes wirklich? Wer sollte bereits auf Kubernetes umsteigen, wer ist der typische Kunde von "Flanta", der genau für Kubernetes kommt?

Dmitry: Eine interessante Frage, denn gerade jetzt, im Zuge des Kubernetes-Trends, kommen viele zu uns: „Leute, wir wissen, dass ihr Kubernetes macht – macht es für uns!“ Unsere Antwort darauf: „Meine Damen und Herren, wir bieten kein Kubernetes an, wir bieten Produktionslösungen und alles, was damit zusammenhängt.“ Denn ein Produktionssystem einzurichten, ohne dabei die gesamte CI/CD-Pipeline und all diese Dinge zu berücksichtigen, ist heutzutage einfach unmöglich. Jeder hat Abstand davon genommen, Entwicklung und Betrieb strikt zu trennen.

Unsere Kunden haben unterschiedliche Erwartungen, aber alle hoffen auf ein gewisses Wunder, dass sie Probleme haben und dass jetzt – schwupp! – Kubernetes sie lösen wird. Die Leute glauben an Wunder. Sie verstehen mit dem Verstand, dass es kein Wunder geben wird, haben aber tief im Herzen die Hoffnung, dass Kubernetes jetzt alles für uns löst, über das so viel gesprochen wird! Vielleicht ist es jetzt – huch! – die silberne Kugel, huch! – und wir haben 100% Uptime, alle Entwickler können 50 Mal willkürlich etwas in die Produktion bringen, und es fällt nicht aus. Kurz gesagt, ein Wunder!

Wenn solche Menschen zu uns kommen, sagen wir: „Entschuldigung, aber Wunder gibt es nicht.“ Um gesund zu sein, muss man sich gut ernähren und Sport treiben. Um eine zuverlässige Produktionsumgebung zu haben, muss man sie zuverlässig aufbauen. Um eine komfortable CI/CD-Pipeline zu haben, muss man sie entsprechend gestalten. Das erfordert viel Arbeit.

Bezüglich der Frage, wer Kubernetes benötigt – niemand benötigt Kubernetes.

Einige Menschen haben das falsche Gefühl, dass sie Kubernetes brauchen. Was sie wirklich brauchen, ist der tiefgreifende Wunsch, sich nicht mehr mit allen Infrastrukturproblemen und dem Start ihrer Anwendungen auseinandersetzen zu müssen. Sie wollen, dass ihre Anwendungen einfach funktionieren und ohne Probleme bereitgestellt werden. Für sie ist Kubernetes die Hoffnung, dass sie nicht mehr hören müssen, dass „wir irgendwo stecken geblieben sind“ oder „nicht ausrollen können“ oder etwas Ähnliches.

In der Regel kommt der technische Direktor zu uns. Von ihm werden zwei Dinge erwartet: Einerseits die neuen Funktionen, andererseits die Stabilität. Wir bieten an, das für Sie zu übernehmen. Der Schlüssel liegt darin, dass Sie nicht mehr über diese Probleme nachdenken und Zeit verschwenden müssen. Sie haben spezielle Personen, die sich um diese Fragen kümmern.

Die Aussage, dass wir oder jemand anderes Kubernetes benötigen, ist falsch.

Kubernetes ist für Administratoren sehr wichtig, denn es ist ein wirklich interessantes Instrument, mit dem man spielen und experimentieren kann. Lassen Sie uns ehrlich sein – jeder liebt Spielzeuge. In uns allen steckt ein Kind, und wenn wir etwas Neues sehen, wollen wir damit spielen. Einige haben das vielleicht verloren, zum Beispiel in der Systemadministration, weil sie damit schon ausgiebig gespielt haben und es ihnen einfach langweilig geworden ist. Aber das Interesse ist nie ganz verschwunden. Auch wenn ich Spielzeuge im Bereich Systemadministration und DevOps schon lange nicht mehr spannend finde, liebe ich trotzdem neues Spielzeug und kaufe mir immer wieder etwas Neues. Jeder Mensch will auf die eine oder andere Weise immer noch etwas Neues ausprobieren.

Spielen Sie nicht mit dem Produktionssystem. Was ich kategorisch nicht empfehlen würde und was ich gerade massenhaft sehe: „Oh, ein neues Spielzeug!“ – dann laufen alle los, um es zu kaufen, kaufen es und: „Lass uns das jetzt in die Schule mitnehmen, um es allen Freunden zu zeigen.“ Machen Sie das nicht. Entschuldigung, ich habe einfach Kinder, die aufwachsen, und ich sehe ständig etwas bei den Kindern, nehme es bei mir wahr und verallgemeinere das dann auf andere.

Die endgültige Antwort: Kubernetes ist nicht erforderlich. Sie müssen Ihre Probleme lösen.

Erreichen kann man Folgendes:

• die Produktion fällt nicht aus;
• selbst wenn sie zu fallen versucht, wissen wir im Voraus Bescheid und können etwas unterlegen;
• wir können sie mit der Geschwindigkeit ändern, die unser Geschäft erfordert, und das bequem tun, ohne dass es Probleme verursacht.

Die tatsächlichen Bedürfnisse sind zwei: Zuverlässigkeit und Dynamik/Flexibilität beim Rollout. Allen, die derzeit IT-Projekte umsetzen, egal in welcher Branche – Software zur Verbesserung der Welt – und die das verstehen, müssen diese Bedürfnisse gelöst werden. Mit dem richtigen Ansatz, dem richtigen Verständnis und ausreichend Erfahrung ermöglicht Kubernetes, diese zu erfüllen.

Über serverless

Wenn wir einen Blick in die Zukunft werfen, stellen wir fest, dass neue Lösungen wie serverless aufkommen, um die Herausforderungen im Bereich der Infrastruktur, der Bereitstellungsgeschwindigkeit und der Änderungsrate von Anwendungen zu bewältigen. Siehst du in diese Richtung Potenzial und möglicherweise eine Bedrohung für Kubernetes und ähnliche Systeme?

DmitryIch möchte anmerken, dass ich kein Wahrsager bin, der in die Zukunft blickt und behauptet: So wird es sein! Auch wenn ich gerade das Gleiche getan habe. Ich schaue nach unten und sehe eine Reihe von Problemen, zum Beispiel, wie Transistoren in Computern arbeiten. Fast schon zum Schmunzeln, oder? Wir stoßen auf einige Bugs in der CPU.

Um serverless ausreichend zuverlässig, kostengünstig, effizient und benutzerfreundlich zu gestalten, müssen alle ökosystemischen Fragen gelöst werden. Ich stimme Elon Musk zu, dass eine zweite Planet nötig ist, um Ausfallsicherheit für die Menschheit zu schaffen. Auch wenn ich nicht weiß, was er konkret meint, verstehe ich, dass ich nicht bereit bin, selbst nach Mars zu fliegen, und dass dies nicht morgen geschehen wird.

Mit Serverless ist es klar: Es ist ideologisch richtig, genauso wie die Resilienz für die Menschheit – zwei Planeten sind besser als einer. Aber wie macht man das jetzt? Eine Expedition zu schicken – kein Problem, wenn man sich darauf konzentriert. Mehrere Expeditionen zu senden und dort einige Tausend Menschen anzusiedeln, halte ich auch für realistisch. Aber eine vollständige Resilienz zu schaffen, damit die Hälfte der Menschheit dort lebt, erscheint mir derzeit unmöglich und nicht durchführbar.

Mit Serverless ist es ähnlich: Eine tolle Sache, aber sie ist weit entfernt von den Problemen des Jahres 2019. Näher zum Jahr 2030 – lassen Sie uns bis dahin durchhalten. Ich habe keinen Zweifel, dass wir durchhalten werden (wiederholen Sie das vor dem Schlafengehen), aber im Moment müssen wir andere Probleme angehen. Das ist wie an ein märchenhaftes Einhorn zu glauben. Ja, ein paar Prozent der Fälle werden gelöst, und das großartig, aber subjektiv ist Serverless – es ist wie ein Regenbogen… Für mich ist dieses Thema zu weit entfernt und zu unverständlich. Ich bin nicht bereit, darüber zu sprechen. Im Jahr 2019 kann man mit Serverless keine Anwendung schreiben.

Wie wird sich Kubernetes entwickeln?

— Während wir uns auf diese potenziell großartige entfernte Zukunft zubewegen, wie denkst du, wird sich Kubernetes und das Ökosystem darum herum entwickeln?

Dmitry: Ich habe viel darüber nachgedacht und habe eine klare Antwort. Erstens – stateful – es ist auf jeden Fall einfacher, stateless zu machen. Kubernetes hat ursprünglich mehr dafür investiert, damit hat alles angefangen. Stateless funktioniert praktisch perfekt in Kubernetes, da gibt es einfach nichts auszusetzen. Bei stateful gibt es noch eine Menge Probleme, besser gesagt, Nuancen. Bei uns funktioniert alles dort bereits hervorragend, aber das sind wir. Damit es überall funktioniert, werden wir noch mindestens ein paar Jahre brauchen. Das ist kein berechneter Wert, sondern mein Gefühl aus dem Kopf.

Kurz gesagt, stateful muss sich erheblich weiterentwickeln – und wird es auch – denn alle unsere Anwendungen speichern Status, es gibt keine stateless Anwendungen. Das ist eine Illusion, es wird immer eine Art DB und noch etwas benötigt. Stateful bedeutet, alles zu optimieren, Fehler zu beheben und alle Probleme zu verbessern, mit denen wir jetzt konfrontiert sind – nennen wir es Adoption.

Das Niveau des Unbekannten, das Niveau ungelöster Probleme und das Risiko, mit etwas konfrontiert zu werden, wird stark sinken. Das ist eine wichtige Angelegenheit. Und die Operatoren – alles, was mit der Kodifizierung der Administrationslogik und der Managementlogik zu tun hat, um einen einfachen Service zu erhalten: MySQL Easy Service, RabbitMQ Easy Service, Memcache Easy Service – all diese Komponenten, die wir benötigen, um garantierte Funktionalität direkt ab Werk zu erhalten. Damit werden genau die Probleme gelöst, bei denen wir eine Datenbank wollen, sie aber nicht administrieren möchten, oder Kubernetes wollen, aber nicht selbst damit arbeiten möchten.

Die Entwicklung der Operatoren wird in den kommenden Jahren in irgendeiner Form von Bedeutung sein.

Ich denke, die Benutzerfreundlichkeit wird erheblich steigen – der Kasten wird immer mehr zur Black Box, immer zuverlässiger, mit immer einfacheren Steuerungen.

Ich habe mir neulich ein altes Interview mit Isaac Asimov aus den 80er Jahren auf YouTube in der Show Saturday Night Live angeschaut – eine Art von Urgant-Show, nur interessanter. Dort wurde er über die Zukunft der Computer befragt. Er sagte, die Zukunft liege in der Einfachheit, so wie es beim Radio war. Ursprünglich war das Radio eine komplexe Angelegenheit. Um einen Sender zu empfangen, musste man 15 Minuten lang an Reglern drehen und die Funktionsweise verstehen, die Physik der Übertragung von Radiowellen. Am Ende blieb im Radio nur ein Regler übrig.

Jetzt, im Jahr 2019, welches Radio? Im Auto findet das Radio alle Frequenzen und zeigt die Namen der Sender an. Die Physik des Prozesses hat sich in 100 Jahren nicht verändert, aber die Benutzerfreundlichkeit hat sich verbessert. Heutzutage, und schon 1980, als das Interview mit Asimov stattfand, benutzten alle Radios, ohne sich Gedanken darüber zu machen, wie es funktionierte. Es hat immer funktioniert – das war eine Gegebenheit.

Asimov sagte damals, dass es mit Computern ähnlich sein wird – die Benutzerfreundlichkeit wird zunehmen. Wenn man 1980 eine spezielle Ausbildung brauchte, um die Knöpfe am Computer zu drücken, wird das in der Zukunft nicht mehr nötig sein.

Ich habe das Gefühl, dass die Benutzerfreundlichkeit von Kubernetes und der Infrastruktur erheblich zunehmen wird. Das ist, meiner Meinung nach, offensichtlich – es liegt auf der Hand.

Was passiert mit den Ingenieuren?

— Was wird dann aus den Ingenieuren und Systemadministratoren, die Kubernetes unterstützen?

Dmitry: Was ist mit Buchhaltern passiert, als 1C aufkam? Ähnlich ist es. Früher wurde alles auf Papier gerechnet – jetzt läuft es über Software. Die Produktivität ist exponentiell gestiegen, aber die Arbeit ist dadurch nicht verschwunden. Wenn früher für das Eindrehen einer Glühbirne 10 Ingenieure benötigt wurden, reicht jetzt einer.

Die Menge an Software und Aufgaben scheint mir derzeit schneller zu wachsen als die Anzahl neuer DevOps-Profis und die Effizienz steigt. Auf dem Markt gibt es momentan einen akuten Mangel, und dieser wird lange anhalten. Später wird sich das alles in eine gewisse Norm einpendeln, in der die Effizienz der Arbeit steigen wird. Es wird immer mehr Serverless-Lösungen geben, und KI wird Kubernetes so unterstützen, dass alle Ressourcen genau nach Bedarf bereitgestellt werden und automatisch alles funktioniert – der Mensch kann sich zurückziehen und nicht eingreifen.

Aber solche Entscheidungen müssen letztendlich getroffen werden. Es ist klar, dass das Qualifikationsniveau und die Spezialisierung dieser Person höher sind. Derzeit benötigen Sie in der Buchhaltungsabteilung keine 10 Mitarbeiter, die Buchhaltungsunterlagen führen, nur damit ihnen nicht die Hand müde wird. Das ist einfach nicht notwendig. Viele Dokumente werden automatisch gescannt und von einem elektronischen Dokumentenmanagementsystem erkannt. Es reicht aus, einen intelligenten Hauptbuchhalter zu haben, der bereits über weitaus bessere Fähigkeiten und ein gutes Verständnis verfügt.

Im Allgemeinen ist dieser Weg branchenübergreifend. So ist es auch bei Autos: Früher gehörten ein Mechaniker und drei Fahrer zu jedem Auto. Heute ist das Fahren eines Autos ein einfacher Prozess, an dem wir alle täglich teilnehmen. Niemand denkt daran, dass ein Auto etwas Komplexes ist.

DevOps oder Systemengineering werden nicht verschwinden – die Hochwertigkeit und Effizienz der Arbeit werden zunehmen.

— Ich habe auch eine interessante Idee gehört, dass die Arbeit tatsächlich zunehmen wird.

Dmitry: Natürlich, hundert Prozent! Denn die Menge an Software, die wir schreiben, wächst ständig. Die Anzahl der Fragen, die wir mit Software lösen, steigt ebenfalls. Der Arbeitsaufwand nimmt zu. Der DevOps-Markt ist derzeit extrem überhitzt. Das zeigt sich in den Gehaltsvorstellungen. Idealerweise sollten es Junioren geben, die X wollen, Mid-Level, die 1,5X wollen, und Senioren, die 2X wollen. Aber momentan, wenn man sich den Moskauer DevOps-Gehaltsmarkt anschaut, will ein Junior zwischen X und 3X und ein Senior zwischen X und 3X.

Niemand weiß, wie viel es kostet. Das Gehaltsniveau wird durch dein Selbstbewusstsein bestimmt – es ist völliger Wahnsinn, ganz ehrlich, der Markt ist extrem überhitzt.

Natürlich wird sich diese Situation sehr bald ändern – eine gewisse Sättigung muss eintreten. Bei der Softwareentwicklung ist das nicht so – obwohl alle Entwickler gebraucht werden, und es gute Entwickler sein müssen, versteht der Markt, was jeder wert ist – die Branche hat sich stabilisiert. Bei DevOps ist das momentan nicht der Fall.

— Aus dem, was ich gehört habe, habe ich den Eindruck gewonnen, dass der aktuelle Systemadministrator sich nicht allzu viele Sorgen machen muss, aber es ist an der Zeit, die Fähigkeiten zu verbessern und sich darauf vorzubereiten, dass morgen mehr Arbeit ansteht, die jedoch auch anspruchsvoller sein wird.

Dmitry: Absolut. Im Grunde leben wir im Jahr 2019 und das Lebensmotto lautet: lebenslanges Lernen – wir lernen ein Leben lang. Ich denke, das wissen und spüren mittlerweile die meisten, aber es reicht nicht zu wissen – man muss auch handeln. Jeden Tag müssen wir uns verändern. Wenn wir das nicht tun, werden wir früher oder später zum Abstellgleis der Profession abgelegt.

Seid bereit für plötzliche Wendungen um 180 Grad. Ich schließe nicht aus, dass sich etwas grundlegend ändert, dass etwas Neues erfunden wird – das passiert. Zack! – und wir handeln jetzt anders. Es ist wichtig, darauf vorbereitet zu sein und sich nicht darüber zu stressen. Es kann sein, dass alles, was ich morgen mache, nicht mehr benötigt wird – ist in Ordnung, ich habe mein Leben lang gelernt und bin bereit, etwas anderes zu lernen. Das ist kein Problem. Man sollte sich keine Sorgen um die Arbeitsplatzsicherheit machen, aber man muss bereit sein, ständig Neues zu lernen.

Wünsche und eine kleine Werbung

— Hast du einen bestimmten Wunsch?

Dmitry: Ja, ich habe mehrere Wünsche.

Der erste und materielle – abonnieren Sie YouTube. Liebe Leser, besuchen Sie YouTube und abonnieren Sie unseren Kanal. In etwa einem Monat werden wir mit einer aktiven Expansion auf den Video-Service beginnen, und wir werden eine Menge Lehrinhalte über Kubernetes haben, von praktischen Themen bis hin zu Laborübungen und tiefgehenden theoretischen Prinzipien, sowie wie man Kubernetes auf der Ebene von Prinzipien und Mustern anwendet.

Der zweite materielle Wunsch – besuchen Sie GitHub und hinterlassen Sie Sterne, denn davon leben wir. Wenn Sie uns keine Sterne geben, haben wir nichts zum Essen. Das ist wie das Mana in einem Computerspiel. Wir tun etwas, tun unser Bestes, während manche sagen, dass es schreckliche Fahrräder sind, andere, dass alles ganz falsch ist, aber wir machen weiter und handeln absolut ehrlich. Wir sehen das Problem, lösen es und teilen unsere Erfahrungen. Deshalb geben Sie uns bitte einen Stern, es kostet Sie nichts, und es gibt uns etwas zurück, denn davon leben wir.

Drittens, ein wichtiges und nicht materielles Anliegen – hören Sie auf, an Märchen zu glauben. Sie sind Profis. DevOps ist ein sehr ernstes und verantwortungsvolles Berufsfeld. Spielen Sie nicht am Arbeitsplatz. Lassen Sie sich das klar werden! Stellen Sie sich vor, Sie kommen ins Krankenhaus, und der Arzt experimentiert an Ihnen. Ich verstehe, dass das für manche verletzend sein kann, aber wahrscheinlich betrifft das nicht Sie, sondern jemand anderen. Sagen Sie auch anderen, dass sie aufhören sollen. Das ruiniert real unser aller Leben – viele beginnen, die Operatoren, Admins und DevOps wie Leute zu behandeln, die wieder etwas kaputt gemacht haben. Dieses „Kaputtmachen“ passiert meistens, wenn wir anfangen zu spielen, anstatt mit kühlem Kopf zu schauen, wie es hier und dort steht.

Das bedeutet nicht, dass man nicht experimentieren sollte. Man sollte experimentieren, wir machen das auch. Um ehrlich zu sein, spielen wir manchmal auch – das ist natürlich nicht ideal, aber nichts Menschliches ist uns fremd. Lassen Sie uns das Jahr 2019 zum Jahr ernsthafter, durchdachter Experimente erklären, und nicht zu Spielereien im Produktivsystem. Vermutlich ist das der richtige Weg.

— Herzlichen Dank!

Dmitry: Vielen Dank, Vitaliy, sowohl für die Zeit als auch für das Interview. Liebe Leser, vielen Dank, dass Sie bis zu diesem Punkt gekommen sind. Ich hoffe, wir konnten Ihnen wenigstens ein paar Gedanken mit auf den Weg geben.

Im Interview ging Dmitry auf das Thema werf ein. Momentan ist es das universelle Schweizer Taschenmesser, das fast alle Aufgaben löst. Doch das war nicht immer so. Bei DevOpsConf  dem Festival RIT++ wird Dmitry Stolyarov detailliert über dieses Tool berichten. In dem Vortrag «werf – unser Tool für CI/CD in Kubernetes» wird alles behandelt: Probleme und versteckte Nuancen von Kubernetes, Lösungsansätze für diese Schwierigkeiten und die aktuelle Implementierung von werf im Detail. Seien Sie dabei am 27. und 28. Mai, wir werden perfekte Tools schaffen.

Quelle: habr.com