Kubernetes wird die Welt erobern. Wann und wie?

Im Vorfeld DevOpsConf Vitaly Chabarov führte ein Interview mit Dmitry Stolyarov (distol), dem technischen Direktor und Mitgründer von "Flant". Vitaly befragte Dmitry über die Aktivitäten von "Flant", über Kubernetes, die Entwicklung des Ökosystems und die Unterstützung. Sie diskutierten, warum Kubernetes benötigt wird und ob es überhaupt notwendig ist. Und auch über Mikrodienste, Amazon AWS, die „Mir wird schon alles gelingen“-Mentalität in DevOps, die Zukunft von Kubernetes, warum, wann und wie es die Welt erobern wird, die Perspektiven von DevOps und was Ingenieure in naher Zukunft mit der Vereinfachung und neuronalen Netzen erwarten können.

Das Originalinterview in Form eines Podcasts hören Sie auf DevOps Deflop, dem russischsprachigen Podcast über DevOps, und unten finden Sie die texliche Version.

Hier und im Folgenden stellt Vitaly Chabarov ein Ingenieur von Express42 die Fragen.

Über "Flant"

— Dima, hallo. Du bist der technische Direktor von "Flant" und auch Gründer. Erzähl bitte, womit sich die Firma befasst und welche Rolle du dabei spielst.

Dmitry: Von außen sieht es so aus, als wären wir Typen, die einfach jedem Kubernetes aufsetzen und irgendetwas damit machen. Aber das ist nicht der Fall. Wir haben als Firma angefangen, die sich mit Linux beschäftigt, aber schon vor sehr langer Zeit wurde unsere Haupttätigkeit die Betreuung von Produktions- und Highload-Projekten aus einer Hand. Normalerweise bauen wir die gesamte Infrastruktur von Grund auf und sind dann lange dafür verantwortlich. Daher ist die Hauptarbeit, die "Flant" leistet und wofür wir bezahlt werden, die Übernahme von Verantwortung und die Umsetzung von Produktionssystemen aus einer Hand..




Ich, als technischer Direktor und einer der Mitbegründer der Firma, beschäftige mich Tag und Nacht damit, mir zu überlegen, wie wir die Verfügbarkeit von Produktionssystemen erhöhen, deren Betrieb vereinfachen, das Leben der Administratoren erleichtern und das Leben der Entwickler angenehmer gestalten können.

Über Kubernetes

— In letzter Zeit habe ich viele Vorträge von "Flant" gesehen, Artikel die über Kubernetes handeln. Wie seid ihr zu ihm gekommen?

Dmitry: Ich habe darüber schon viele Male gesprochen, aber ich habe nichts dagegen, es zu wiederholen. Ich halte es für richtig, dieses Thema zu wiederholen, da oft Verwirrung zwischen Ursache und Wirkung entsteht.

Wir benötigten dringend ein Tool. Wir hatten mit einer Vielzahl von Problemen zu kämpfen, sie mit verschiedenen Notlösungen überwunden und benötigten ein Werkzeug. Wir haben viele verschiedene Optionen durchdacht, unsere eigenen Dinge erstellt und Erfahrungen gesammelt. Allmählich kamen wir dazu, Docker fast sofort nach seinem Erscheinen zu nutzen – etwa 2013. Zu diesem Zeitpunkt hatten wir bereits viel Erfahrung mit Containern und hatten eine Art 'Docker' selbst geschrieben – einige unserer eigenen Notlösungen in Python. Mit dem Erscheinen von Docker erhielten wir die Möglichkeit, die Notlösungen wegzuwerfen und eine zuverlässige und von der Community unterstützte Lösung zu verwenden.

Die Geschichte mit Kubernetes ist ähnlich. Zu dem Zeitpunkt, als es an Fahrt gewann – für uns Version 1.2 – hatten wir bereits viele Notlösungen auf Shell- und Chef-Basis, mit denen wir versuchten, Docker zu orchestrieren. Wir hatten ernsthaft in Richtung Rancher und andere Lösungen geschaut, aber dann tauchte Kubernetes auf, in dem alles genau so umgesetzt ist, wie wir es gemacht hätten, oder sogar besser. Da gibt es nichts zu beanstanden.

Ja, hier gibt es einige unvollendete Dinge, dort gibt es einige unvollendete Dinge – viele Mängel, und 1.2 ist überhaupt schrecklich, aber... Kubernetes ist wie ein sich im Bau befindliches Gebäude – man sieht das Projekt und versteht, dass es großartig werden wird. Wenn das Gebäude jetzt ein Fundament und zwei Stockwerke hat, weiß man, dass es besser ist, vorerst nicht einzuziehen, aber mit der Software gibt es solche Probleme nicht – man kann sie bereits nutzen.

Wir hatten nicht den Moment, in dem wir dachten, ob wir Kubernetes verwenden sollten oder nicht. Wir haben lange darauf gewartet, bevor es erschien, und haben selbst versucht, Nachahmungen zu erstellen.

Über Kubernetes

— Beteiligen Sie sich direkt an der Entwicklung von Kubernetes selbst?

Dmitry: Indirekt. Eher tragen wir zur Entwicklung des Ökosystems bei. Wir senden eine gewisse Anzahl von Pull-Requests: zu Prometheus, zu verschiedenen Operatoren, zu Helm – zum Ökosystem. Leider kann ich nicht alles verfolgen, was wir tun, und ich kann mich irren, aber von uns gibt es keinen einzigen Pool ins Kernel.

— Entwickeln Sie dabei auch viele eigene Werkzeuge um Kubernetes herum?

Dmitry: Die Strategie ist folgende: Wir gehen und pull-requesten alles, was es bereits gibt. Wenn dort keine Pull-Requests akzeptiert werden, forken wir sie einfach für uns und leben, bis sie mit unseren Builds akzeptiert werden. Dann, wenn dies die Upstream-Version erreicht, kehren wir zurück zur Upstream-Version.

Zum Beispiel haben wir den Prometheus-Operator, mit dem wir schon fünfmal zwischen unserem Upstream-Build hin und her gewechselt haben. Wir brauchen eine bestimmte Funktion, wir haben einen Pull-Request gesendet, und wir müssen sie morgen ausrollen, wollen aber nicht warten, bis sie im Upstream veröffentlicht wird. Daher bauen wir sie selbst zusammen, setzen unseren Build mit der Funktion, die wir brauchen, auf all unseren Clustern ein. Dann wird das, zum Beispiel, im Upstream mit den Worten verpackt: „Leute, lasst uns das für einen allgemeineren Fall machen“, und wir, oder jemand anderes, vervollständigen das, und irgendwann wird es dann wieder zusammengeführt.

Alles, was existiert, versuchen wir weiterzuentwickeln.. Viele Elemente, die es noch nicht gibt, oder die zwar schon entworfen, aber noch nicht umgesetzt wurden – wir machen das. Und nicht, weil uns der Prozess oder das Radfahren in dieser Branche gefällt, sondern einfach, weil wir dieses Werkzeug brauchen. Oft wird die Frage gestellt, warum wir jenes oder dieses gemacht haben? Die Antwort ist einfach – weil wir weiterkommen mussten, ein praktisches Problem lösen wollten, und wir haben es mit diesem Tool gelöst.

Der Weg ist immer der gleiche: Wir suchen sehr sorgfältig, und wenn wir keine Lösung finden, wie man aus einem Laib Brot ein Trolleybus macht, dann machen wir unser eigenes Brot und unseren eigenen Trolleybus.

Die Werkzeuge von „Flant“

— Mir ist bekannt, dass „Flant“ jetzt Addon-Operatoren, Shell-Operatoren und die Tools dapp/werf hat. So wie ich das verstehe, ist das dieselbe Software in verschiedenen Inkarnationen. Außerdem verstehe ich, dass es innerhalb von „Flant“ noch viele verschiedene Werkzeuge gibt. Ist das so?

Dmitry: Wir haben auf GitHub noch viele andere Dinge. Was mir jetzt einfällt, ist das statusmap – ein Dashboard für Grafana, das bei allen gut angekommen ist. Es wird wohl in fast jedem zweiten Artikel über das Monitoring von Kubernetes auf Medium erwähnt. Man kann nicht kurz erklären, was das statusmap ist – dafür braucht es einen eigenen Artikel, aber es ist ein sehr hilfreiches Werkzeug für das zeitliche Statusmonitoring, da wir in Kubernetes oft den Status über die Zeit anzeigen müssen. Außerdem haben wir LogHouse – das ist ein Tool auf Basis von ClickHouse und schwarzer Magie zur Protokollsammlung in Kubernetes.

Viele Tools! Und es wird noch mehr geben, denn einige interne Lösungen werden in diesem Jahr veröffentlicht. Es gibt eine Menge Addons zu Kubernetes, die auf dem Addon-Operator basieren, wie zum Beispiel, wie man den Cert Manager installiert – ein Werkzeug zur Verwaltung von Zertifikaten – wie man Prometheus mit einer Menge Zusatztools installiert – das sind zwanzig verschiedene Binärdateien, die Daten exportieren und etwas sammeln, und zu diesem Prometheus gibt es großartige Grafiken und Alarme. All dies sind einfach viele Addons zu Kubernetes, die im Cluster installiert werden, und es verwandelt sich von einfach in ausgeklügelt, hochentwickelt, automatisiert, in dem viele Fragen bereits gelöst sind. Ja, wir machen viel.

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 ähnlich viel zur Entwicklung des Ökosystems beitragen würde?

Dmitry: In Russland gibt es niemanden von den Unternehmen, die auf unserem Markt tätig sind – nicht einmal annähernd. Natürlich ist das eine gewagte Aussage, denn es gibt große Akteure wie Mail und Yandex – sie machen auch etwas mit Kubernetes, aber selbst sie kommen nicht annähernd an den Beitrag von Unternehmen weltweit heran, die viel mehr tun als wir. Es ist schwer, "Flant" mit 80 Mitarbeitern und Red Hat zu vergleichen, wo nur für Kubernetes 300 Ingenieure arbeiten, wenn ich mich nicht irre. Es ist schwer zu vergleichen. In unserer RnD-Abteilung sind wir 6 Personen, einschließlich mir, die all unsere Tools entwickeln. 6 Personen gegen 300 Ingenieure von Red Hat – das ist irgendwie schwer zu vergleichen.

– Dennoch können selbst diese 6 Personen wirklich nützliche und abgrenzbare Dinge machen, wenn sie mit einer praktischen Aufgabe konfrontiert sind und Lösungen an die Gemeinschaft zurückgeben – ein interessanter Fall. Ich verstehe, dass in großen Technologieunternehmen, die ihre eigene Entwicklung und ein Support-Team für Kubernetes haben, prinzipiell ähnliche Tools entwickelt werden können. Das ist für sie ein Beispiel, wie man etwas entwickeln und an die Gemeinschaft abgeben kann, um der gesamten Gemeinschaft, die Kubernetes nutzt, einen Schub zu geben.

Dmitry: Vielleicht ist das das Besondere am Integrator. Wir haben viele Projekte und sehen viele verschiedene Situationen. Für uns ist der Hauptweg zur Schaffung von Mehrwert, diese Fälle zu analysieren, Gemeinsamkeiten zu finden und sie so kostengünstig wie möglich zu machen. Damit beschäftigen wir uns intensiv. Es fällt mir schwer, über Russland und die Welt zu sprechen, aber wir haben etwa 40 DevOps-Ingenieure im Unternehmen, die mit Kubernetes arbeiten. Ich glaube nicht, dass es in Russland viele Unternehmen mit einer vergleichbaren Anzahl von Spezialisten gibt, die sich mit Kubernetes auskennen, falls es sie überhaupt gibt.

Ich verstehe alles über den Jobtitel DevOps-Ingenieur, alle wissen Bescheid und gewöhnen sich daran, DevOps-Ingenieure DevOps-Ingenieuren zu nennen, darüber werden wir nicht diskutieren. Alle diese 40 großartigen DevOps-Ingenieure stehen jeden Tag vor Herausforderungen und lösen diese. Wir analysieren einfach diese Erfahrungen und versuchen, sie zu verallgemeinern. Wir verstehen, dass, wenn dieses Wissen bei uns bleibt, das Tool in ein oder zwei Jahren nutzlos ist, weil irgendwo in der Community ein fertiges Tool auftaucht. Es macht keinen Sinn, dieses Wissen intern anzuhäufen – das ist nur Zeit- und Ressourcenverschwendung. So sehen wir das ganz entspannt. Wir veröffentlichen alles mit großem Vergnügen und wissen, dass das wichtig ist – zu veröffentlichen, weiterzuentwickeln, zu bewerben, damit die Leute es nutzen und ihre Erfahrungen einbringen können – dann wächst alles und lebt. Dann wird das Tool in zwei Jahren nicht auf den Müll geworfen. Es ist nicht schade, weiterhin Ressourcen zu investieren, weil man sieht, dass jemand das eigene Tool nutzt, und in zwei Jahren nutzen es dann schon alle.

Das ist Teil unserer großen Strategie mit dapp/werf.. Ich erinnere mich nicht, wann wir damit angefangen haben, es sind wohl drei Jahre her. Ursprünglich war es komplett in Shell. Es war ein super Proof of Concept, wir haben einige unserer privaten Aufgaben gelöst – es hat funktioniert! Aber mit Shell gibt es Probleme, es ist unmöglich, damit weiterzuarbeiten, Programmieren in Shell ist kein Vergnügen. Wir hatten die Gewohnheit, in Ruby zu schreiben, dementsprechend haben wir etwas in Ruby umgebaut, weiterentwickelt, weiterentwickelt, bis wir darauf gestoßen sind, dass die Community, die Masse, die nicht sagt: „Wir wollen oder wollen nicht“, die Nase rümpft und sich von Ruby abwendet, so lustig das auch ist. Wir haben verstanden, dass wir all diese Sachen in Go schreiben müssen, um einfach dem ersten Punkt in unserer Checkliste zu entsprechen: Das DevOps-Tool muss ein statisches Binärformat sein.Ob Go oder nicht Go ist nicht so wichtig, aber besser ist ein statisches Binary, das in Go geschrieben ist.

Wir haben Ressourcen aufgewendet, die DApp in Go neu geschrieben und sie werf genannt. Die DApp wird nicht mehr unterstützt, wird nicht weiterentwickelt, funktioniert in irgendeiner letzten Version, aber es gibt einen absoluten Upgrade-Weg nach oben, den man gehen kann.

Warum wurde die DApp erstellt

— Kannst du kurz erzählen, warum die DApp erstellt wurde und welche Probleme sie löst?

Dmitry: Der erste Grund liegt im Build-Prozess. Ursprünglich hatten wir große Probleme mit dem Build, als Docker noch kein Multi-Stage konnte, und wir haben das Multi-Stage selbst umgesetzt. Danach hatten wir noch viele Fragen zur Bereinigung von Images. Jeder, der CI/CD macht, sieht sich früher oder später mit dem Problem konfrontiert, dass es viele gebaute Images gibt, die bereinigt werden müssen, um das Nichtbenötigte zu entfernen und das Notwendige zu behalten.

Der zweite Grund liegt im Deployment. Ja, es gibt Helm, aber er löst nur einen Teil der Aufgaben. So komisch es klingt, es steht geschrieben: "Helm – der Paketmanager für Kubernetes". Genau, das „der“. Da sind noch die Wörter „Paketmanager“ – was erwartet man normalerweise von einem Paketmanager? Wir sagen: „Paketmanager – installiere das Paket!“ und erwarten, dass er uns sagt: „Paket installiert“.

Es ist interessant, dass wir sagen: „Helm, installiere das Paket“, und wenn er antwortet, dass er es installiert hat, stellt sich heraus, dass er nur mit der Installation begonnen hat – er hat Kubernetes gesagt: „Starte dieses Ding!“, aber ob es gestartet ist oder nicht, ob es funktioniert oder nicht, das löst Helm überhaupt nicht.

Es stellt sich also heraus, dass Helm einfach ein Textpreprozessor ist, der Daten in Kubernetes lädt.

Aber wir wollen im Rahmen jedes Deployments wissen – wurde die Anwendung auf den Produktionsserver ausgerollt oder nicht? Ein Rollout auf den Produktionsserver bedeutet, dass die Anwendung dort hinübergefahren wurde, eine neue Version ausgerollt wurde und sie dort zumindest nicht abstürzt und korrekt antwortet. Helm löst diese Aufgabe nicht. Um sie zu lösen, muss man viel Aufwand betreiben, denn man muss Kubernetes anweisen, das Deployment durchzuführen und überwachen, was dort passiert – ob es erfolgreich ausgeführt wurde, ob es ausgerollt wurde. Und da sind noch viele Aufgaben, die mit dem Deployment, der Bereinigung und dem Build verbunden sind.

Pläne

Noch in diesem Jahr werden wir in die lokale Entwicklung gehen. Wir wollen zu dem Zustand gelangen, der früher mit Vagrant möglich war – wir geben „vagrant up“ ein und unsere VMs starten. Wir wollen so weit kommen, dass es ein Projekt in Git gibt, wo wir „werf up“ schreiben, und es eine lokale Kopie dieses Projekts in einem lokalen Mini-Kub hochfährt, mit allen für die Entwicklung praktischen Verzeichnissen verbunden. Je nach Programmiersprache wird dies unterschiedlich umgesetzt, aber dennoch soll es komfortabel möglich sein, die lokale Entwicklung unter gemounteten Dateien zu führen.

Der nächste Schritt für uns ist es, stark in den Komfort für Entwickler zu investieren. Um mit einem Tool schnell ein Projekt lokal zu starten, weiterzuentwickeln, in Git zu pushen, sodass es genau so auf stage oder auf Tests ausgerollt wird, je nach Pipelines, und dann mit demselben Tool auf Produktion zu gehen. Dieser einheitliche, vereinheitlichende, reproduzierbare Infrastrukturansatz von der lokalen Umgebung bis zur Produktion ist für uns ein sehr wichtiger Punkt. Aber das gibt es bisher noch nicht in werf – wir planen es nur.

Aber der Weg zu dapp/werf war immer derselbe wie zu Kubernetes zu Beginn. Wir sind auf Probleme gestoßen, haben sie mit Umwegen gelöst – haben für uns eigene Lösungen in Shell oder auf was auch immer erdacht. Später haben wir versucht, diese Umwege irgendwie zu begradigen, zu verallgemeinern und in Binaries zu konsolidieren, die wir einfach teilen.

Es gibt auch eine andere Perspektive auf diese gesamte Geschichte, die analog ist.

Kubernetes ist das Chassis eines Autos mit Motor. Es gibt keine Türen, Fenster, Radio, Duftbaum – überhaupt nichts. Nur das Gestell und den Motor. Und es gibt Helm – das ist das Lenkrad. Toll – ein Lenkrad ist vorhanden, aber es fehlen noch der Steuerstift, die Lenkstange, das Getriebe und die Räder, ohne die es nicht funktioniert.

Im Fall von werf ist dies eine weitere Komponente zu Kubernetes. Nur jetzt haben wir in der Alpha-Version von werf beispielsweise Helm komplett in werf integriert, weil es uns langweilig wurde, das selbst zu tun. Es gibt viele Gründe, es so zu machen, warum wir helm zusammen mit tiller komplett in werf integriert haben, werde ich gleich in einem Vortrag auf RIT++ erzählen..

Jetzt ist werf ein integrierterer Bestandteil. Wir erhalten ein fertiges Steuergerät, einen Steuerstift – ich kenne mich nicht gut mit Autos aus, aber das ist ein großer Block, der bereits ein breites Spektrum an Aufgaben löst. Wir müssen nicht selbst im Katalog nach einzelnen Bauteilen suchen, eine Teil zu einem anderen zuordnen und überlegen, wie wir sie zusammenbauen. Wir erhalten eine einsatzbereite Lösung, die viele Aufgaben sofort erledigt. Innen besteht es jedoch aus den gleichen Open-Source-Komponenten, nutzt Docker für den Aufbau, Helm für bestimmte Funktionen und hat noch einige andere Bibliotheken. Es ist ein integriertes Werkzeug, um schnell und einfach ein großartiges CI/CD out of the box zu erhalten.

Ist es schwierig, Kubernetes zu betreiben?

— Du erzählst von der Erfahrung, dass ihr begonnen habt, Kubernetes zu nutzen, das ist für euch der Rahmen, der Motor, und man kann vieles daran anbringen: Gehäuse, Lenkrad, Pedale, Sitze. Da stellt sich die Frage – wie schwierig ist es für euch, Kubernetes zu unterstützen? Ihr habt viel Erfahrung, wie viel Zeit und Ressourcen investiert ihr ausschließlich in die Unterstützung von Kubernetes im Vergleich zu allem anderen?

Dmitry: Das ist eine sehr schwierige Frage und um sie zu beantworten, müssen wir verstehen, was Unterstützung bedeutet und was wir von Kubernetes wollen. Vielleicht kannst du das näher ausführen?

— Soweit ich informiert bin und wie ich sehe, wollen viele Teams jetzt Kubernetes ausprobieren. Alle stürzen sich darauf und installieren es auf ihren Laptops. 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 denkst du, wie schwierig ist es, ein Herz zu transplantieren? Ich verstehe, die Frage ist heikel. Mit einem Skalpell herumzufahren und keinen Fehler zu machen, ist nicht so schwierig. Wenn dir gesagt wird, wo du schneiden und wo du nähen musst, ist der Prozess an sich nicht kompliziert. Es ist jedoch schwierig, bei jeder Gelegenheit zu garantieren, dass alles gelingt.

Kubernetes zu installieren und zum Laufen zu bringen, ist einfach: zack! – es ist installiert, es gibt viele Methoden zur Installation. Aber was passiert, wenn Probleme auftreten?

Es stellen sich immer Fragen – was haben wir übersehen? Was haben wir nicht gemacht? Welche Linux-Kernel-Parameter haben wir falsch angegeben? Mein Gott, haben wir sie überhaupt angegeben?! Welche Kubernetes-Komponenten haben wir installiert und welche nicht? Tausende Fragen tauchen auf, und um sie zu beantworten, benötigt man 15-20 Jahre Erfahrung in dieser Branche.

Ich habe ein frisches Beispiel zu diesem Thema, das den Sinn des Problems "Ist es schwer, Kubernetes zu unterstützen?" verdeutlichen kann. Vor einiger Zeit haben wir ernsthaft darüber nachgedacht, ob wir Cilium als Netzwerk in Kubernetes implementieren sollten.

Ich erkläre, was Cilium ist. In Kubernetes gibt es viele verschiedene Realisierungen des Netzwerk-Subsystems, und eine davon ist sehr cool – das ist Cilium. Worin liegt der Sinn? Vor einiger Zeit gab es im Kernel die Möglichkeit, Hooks für den Kernel zu schreiben, die in irgendeiner Weise in das Netzwerk-Subsystem und in verschiedene andere Subsysteme eingreifen und es ermöglichen, große Teile des Kernels zu umgehen.

Im Linux-Kernel gibt es historisch gesehen ip rout, netfilter, Bridges und viele verschiedene alte Komponenten, die 15, 20 oder sogar 30 Jahre alt sind. Insgesamt funktionieren sie, alles ist großartig, aber jetzt haben wir Container über Container gestapelt, und das sieht aus wie ein Turm aus 15 Ziegeln übereinander, während du auf einem Bein darauf stehst – ein seltsames Gefühl. Dieses System hat sich historisch mit vielen Nuancen entwickelt, wie der Blinddarm im Körper. In einigen Situationen gibt es Leistungsprobleme, zum Beispiel.

Es gibt ein wunderbares 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 das Linux-Kernel, sie ziehen es direkt am Eingang heraus, verarbeiten es nach Bedarf ohne Bridges, ohne TCP, ohne IP-Stack – kurz, sie umgehen alles, was im Linux-Kernel geschrieben ist, und spucken es gleich in den Container aus.

Was ist dabei herausgekommen? Sehr tolle Leistung, coole Funktionen – einfach klasse! Aber wir schauen darauf und sehen, dass auf jeder Maschine ein Programm läuft, das sich mit der Kubernetes-API verbindet und anhand der Daten, die es aus dieser API erhält, C-Code generiert und Binärdateien kompiliert, die in den Kernel geladen werden, damit diese Hooks im Kernel-Space funktionieren.

Was passiert, wenn etwas schiefgeht? Wir wissen es nicht. Um das zu verstehen, muss man den ganzen Code lesen, die gesamte Logik verstehen, und das ist unglaublich schwierig. Aber auf der anderen Seite gibt es diese Bridges, netfilter, ip rout – ich habe deren Quellcode nicht gelesen, und 40 Ingenieure, die in unserem Unternehmen arbeiten, auch nicht. Vielleicht verstehen einige wenige Teile davon.

Und was macht das für einen Unterschied? Es gibt also ip rout, den Linux-Kernel, und es gibt ein neues Werkzeug - was spielt das für eine Rolle, wir verstehen weder das eine noch das andere. Aber wir fürchten uns, das Neue zu benutzen - warum? Weil, wenn das Werkzeug 30 Jahre alt ist, alle Bugs über 30 Jahre hinweg gefunden wurden, man über alle Stolpersteine gestolpert ist, und man nicht alles wissen muss - es funktioniert wie eine Blackbox und funktioniert immer. Alle wissen, welchen Diagnoseschraubendreher man wo ansetzen muss, welchen tcpdump man wann starten muss. Alle kennen die Diagnosetools gut und verstehen, wie diese Komponentensammlung im Linux-Kernel funktioniert - nicht wie sie aufgebaut ist, sondern wie man sie nutzt.

Und das fantastisch coole Cilium ist nicht 30 Jahre alt, es ist noch nicht ausgereift. Mit Kubernetes ist es dasselbe, eine Kopie. Sowohl Cilium als auch Kubernetes lassen sich hervorragend installieren, aber wenn es in der Produktion mal nicht gut läuft, sind Sie in der Lage, in einer kritischen Situation schnell zu verstehen, was schiefgelaufen ist?

Wenn wir darüber sprechen, ob es schwierig ist, Kubernetes zu unterstützen - nein, es ist sehr einfach, und ja, es ist unglaublich schwierig. Kubernetes funktioniert hervorragend für sich allein, aber mit einer Milliarde von Nuancen.

Über den Ansatz 'Ich habe Glück'

- Gibt es Unternehmen, bei denen diese Nuancen fast garantiert auftreten werden? Nehmen wir an, Yandex würde plötzlich alle Dienste auf Kubernetes umstellen, da wird ordentlich viel Verkehr sein.

Dmitry: Nein, es geht hier nicht um die Last, sondern um die einfachsten Dinge. Zum Beispiel haben wir Kubernetes, wir haben dort eine Anwendung deployed. Wie erkennt man, dass sie funktioniert? Es gibt kein fertiges Werkzeug, um zu erkennen, dass die Anwendung nicht ausfällt. Es gibt kein fertiges System, das Alarme sendet - man muss diese Alarme und jedes Diagramm konfigurieren. Und wir aktualisieren gerade Kubernetes.

Es gibt Ubuntu 16.04. Man kann sagen, dass dies eine alte Version ist, aber wir sind immer noch darauf, weil es LTS gibt. Es hat systemd, dessen Nuance darin besteht, dass es die C-Gruppen nicht bereinigt. Kubernetes startet Pods, erstellt C-Gruppen, dann löscht es die Pods, und irgendwie passiert es – ich erinnere mich nicht an die Details, entschuldigen Sie – dass systemd-Slices verbleiben. Das führt dazu, dass jede Maschine mit der Zeit stark langsamer wird. Es handelt sich hier nicht einmal um ein Highload-Thema. Wenn ständig Pods gestartet werden, zum Beispiel wenn es einen Cron Job gibt, der ständig Pods erzeugt, dann wird eine Maschine mit Ubuntu 16.04 nach einer Woche langsamer. Es wird ständig eine hohe Last durchschnittlich geben, weil eine Menge C-Gruppen erstellt wurde. Dies ist ein Problem, mit dem jeder konfrontiert wird, der einfach Ubuntu 16 installiert und Kubernetes darüber nutzt.

Nehmen wir an, er aktualisiert irgendwie systemd oder etwas anderes, aber im Linux-Kernel bis 4.16 ist es noch lustiger – beim Löschen von C-Gruppen sickern sie im Kernel durch und werden tatsächlich nicht gelöscht. Deshalb wird es nach einem Monat Arbeit an dieser Maschine unmöglich sein, die Speicherstatistik zu den Pods zu betrachten. Wir holen uns eine Datei, testen sie in der Anwendung, und eine Datei braucht 15 Sekunden, weil der Kernel sehr lange benötigt, um in sich selbst über Millionen von C-Gruppen zu rechnen, die zwar gelöscht zu sein scheinen, es aber nicht sind – sie sickern durch.

Solcher Kleinigkeiten gibt es immer noch sehr viele hier und dort. Das ist nicht das Problem, mit dem Großkonzerne manchmal bei sehr hohen Lasten konfrontiert werden – nein, es ist eine Frage des täglichen Lebens. Menschen können monatelang so leben – sie haben Kubernetes installiert, die Anwendung bereitgestellt – es scheint zu funktionieren. Für viele ist das in Ordnung. Dass irgendwann diese Anwendung aus irgendeinem Grund ausfällt, wird ihnen nicht einmal bewusst, der Alert kommt nicht, aber für sie ist das Normalität. Früher lebten sie auf virtuellen Maschinen ohne Überwachung, jetzt sind sie nach Kubernetes ohne Überwachung gewechselt – was ist der Unterschied?

Die Frage ist, dass wir, wenn wir über Eis laufen, niemals wissen, wie dick es ist, wenn wir es nicht vorher gemessen haben. Viele laufen einfach und machen sich keine Gedanken, weil sie früher auch gelaufen sind.

Aus meiner Sicht besteht der Nuance und die Komplexität des Betriebs eines jeden Systems darin, sicherzustellen, dass die Dicke des Eises genau ausreicht, um unsere Aufgaben zu lösen. Darum geht es.

Im IT-Bereich gibt es meiner Meinung nach zu viele Ansätze nach dem Motto „Ich habe Glück“. Viele installieren Software, verwenden Bibliotheken in der Hoffnung, dass ihnen das Glück hold ist. Insgesamt haben viele Erfolg. Wahrscheinlich funktioniert es genau deshalb.

– Aus meiner pessimistischen Sicht sieht das so aus: Wenn die Risiken hoch sind und die Anwendung funktionieren muss, benötigt man Unterstützung von „Flant“, möglicherweise von Red Hat, oder man benötigt ein internes Team, das speziell für Kubernetes bestimmt ist und bereit ist, es zu betreuen.

Dmitry: Objektiv ist das so. Sich selbst in die Geschichte mit Kubernetes einzuarbeiten, ist für ein kleines Team mit gewissen Risiken verbunden.

Brauchen wir Container?

– Kannst du mir sagen, wie weit verbreitet Kubernetes in Russland überhaupt ist?

Dmitry: Ich habe keine Daten dazu und bin mir nicht sicher, ob jemand diese Informationen hat. Wir sagen: „Kubernetes, Kubernetes“, aber es gibt auch eine andere Perspektive auf die Frage. Wie verbreitet Container sind, weiß ich auch nicht, aber ich kenne die Zahl aus Berichten im Internet, dass 70 % der Container mit Kubernetes orchestriert werden. Das war eine verlässliche Quelle aus einer ziemlich großen globalen Stichprobe.

Die nächste Frage lautet: Brauchen wir überhaupt Container? Ich habe das persönliche Gefühl und die generelle Position des Unternehmens „Flant“ ist, dass Kubernetes der De-Facto-Standard ist.

Es wird nichts anderes als Kubernetes geben.

Es ist ein absoluter Game-Changer im Bereich Infrastrukturmanagement. Einfach absolut – alles, keine Ansible, Chef, virtuellen Maschinen, Terraform mehr. Ich spreche schon gar nicht von alten, ineffizienten Methoden. Kubernetes ist der absolute Changer, und jetzt wird es nur noch so sein.

Es ist klar, dass einige Jahre dafür benötigt werden, während andere Jahrzehnte brauchen, um das zu begreifen. Ich habe keinen Zweifel daran, dass es nichts anderes als Kubernetes und diesen neuen Ansatz geben wird: Wir verletzen das Betriebssystem nicht mehr, sondern nutzen Infrastructure as Code, nur nicht mit Code, sondern mit YML – deklarativ beschriebene Infrastruktur. Ich habe das Gefühl, dass es immer so sein wird.

– Das heißt, die Unternehmen, die noch nicht auf Kubernetes umgestiegen sind, werden definitiv darauf umsteigen oder in Vergessenheit geraten. Habe ich dich richtig verstanden?

Dmitry: Das ist auch nicht ganz richtig. Wenn wir zum Beispiel die Aufgabe haben, einen DNS-Server zu starten, kann man ihn auf FreeBSD 4.10 starten und er kann 20 Jahre lang problemlos funktionieren. Einfach funktionieren und das war's. Vielleicht muss man in 20 Jahren einmal etwas aktualisieren. Wenn wir von Software im Format sprechen, dass wir sie gestartet haben und sie tatsächlich viele Jahre ohne Aktualisierungen, ohne Änderungen läuft, dann gibt es dort natürlich kein Kubernetes. Das ist dort nicht nötig.

Alles, was CI/CD betrifft – überall, wo Continuous Delivery benötigt wird, wo Versionsaktualisierungen, aktive Änderungen erforderlich sind, wo Ausfallsicherheit aufgebaut werden muss – nur Kubernetes.

Über Mikrodienste

– Hier entsteht ein kleiner Dissonanz bei mir. 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 Startup, haben wir noch nichts, könnte die Entwicklung für Kubernetes oder überhaupt für eine mikrodienstliche Architektur schwierig sein und nicht immer wirtschaftlich gerechtfertigt. Mich interessiert deine Meinung – sollten Startups sofort von null auf Kubernetes schreiben oder kann man erst einen Monolithen schreiben und erst später zu Kubernetes übergehen?

Dmitry: Das ist eine gute Frage. Ich habe einen Vortrag über Mikrodienste. „Mikrodienste: Größe ist wichtig.“ Ich habe oft erlebt, dass Leute versuchen, mit einem Mikroskop Nägel einzuschlagen. An sich ist der Ansatz richtig, wir selbst entwerfen interne Software genau so. Aber wenn man das macht, muss man genau verstehen, was man tut. Am meisten hasse ich an Mikrodiensten das Wort „mikro“. Es hat sich historisch dort so entwickelt, und aus irgendeinem Grund denken die Leute, dass mikro etwas sehr Kleines ist, kleiner als ein Millimeter, wie ein Mikrometer. Das ist nicht so.

Zum Beispiel gibt es einen Monolithen, an dem 300 Personen arbeiten, und alle, die an der Entwicklung beteiligt waren, wissen, dass es dort Probleme gibt und er in kleine Stücke zerbrochen werden muss – etwa in 10 Teile, an denen mindestens 30 Personen arbeiten. Das ist wichtig, notwendig und großartig. Aber wenn ein Startup zu uns kommt, wo 3 sehr coole und talentierte Typen in Eigenregie 60 Mikrodienste zusammen geschrieben haben, suche ich jedes Mal nach Corvalol.

Ich habe das Gefühl, dass darüber schon tausendmal gesprochen wurde – wir haben ein verteiltes Monolith in einer oder anderen Form erhalten. Das ist wirtschaftlich nicht gerechtfertigt und sehr komplex. Ich habe es so oft gesehen, dass es mir fast wehtut, deshalb spreche ich weiterhin darüber.

Die Ausgangsfrage ist, dass es einen Konflikt gibt zwischen der Tatsache, dass es einerseits furchtbar ist, Kubernetes zu nutzen, weil unklar ist, was kaputtgehen oder nicht funktionieren könnte, andererseits ist klar, dass alles dahin geht und es nichts außer Kubernetes geben wird. Die Antwort ist die Abwägung des Nutzens, der kommt, und der Aufgaben, die Sie lösen können.. Das ist eine Seite der Waage. Auf der anderen Seite stehen die Risiken, die mit Ausfallzeiten oder einer erhöhten Reaktionszeit und einem niedrigeren Verfügbarkeitsniveau verbunden sind – einer Abnahme der Leistungsindikatoren.

Hier ist es so – entweder wir bewegen uns schnell und Kubernetes ermöglicht es, viele Dinge viel schneller und besser zu erledigen, oder wir nutzen zuverlässige, bewährte Lösungen, aber bewegen uns viel langsamer. Diese Entscheidung muss jede Firma treffen. Man kann es betrachten wie einen Pfad im Dschungel – wenn man zum ersten Mal geht, kann man eine Schlange, einen Tiger oder einen tollwütigen Dachs treffen, und nach 10 Mal geht man – hat man den Pfad getreten, die Äste beiseite geräumt und man kann leichter gehen. Mit jedem Mal wird der Pfad breiter. Später ist es schon eine asphaltierte Straße, und später eine schöne Allee.

Kubernetes steht nicht still. Wieder die Frage: Kubernetes ist einerseits 4-5 Binaries, andererseits ist es das gesamte Ökosystem. Es ist das Betriebssystem, das auf unseren Maschinen läuft. Was ist das? Ubuntu oder Curios? Es ist der Linux-Kernel, eine Menge zusätzlicher Komponenten. All diese Dinge haben hier eine giftige Schlange von der Straße entfernt, dort einen Zaun aufgestellt. Kubernetes entwickelt sich sehr schnell und dynamisch weiter, und das Risiko, die Unbekannten sinkt jeden Monat, und damit werden diese Waagen neu gewichtet.

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 Easy Service. Wenn Sie ein kleines Team von Entwicklern sind, funktioniert das. Anstatt einen eigenen DevOps einzustellen, der lernen muss, Ihre Probleme zu lösen und währenddessen Gehalt zu beziehen, bekommen Sie eine schlüsselfertige Lösung für alle Fragen. Ja, es gibt einige Nachteile. Wir als Outsourcing-Anbieter können nicht so stark involviert sein und schnell auf Änderungen reagieren. Aber dafür haben wir eine Menge Expertise und bewährte Praktiken. Wir garantieren, dass wir in jeder Situation schnell reagieren können und jeden Kubernetes aus der Krise heben.

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

Zu Amazon und Google

Kann man die Lösung von Amazon oder Google als Outsourcing betrachten?

Dmitry: Ja, natürlich, das löst einige Fragen. Aber es gibt wieder Nuancen. Man muss trotzdem verstehen, wie man es nutzt. Zum Beispiel gibt es tausend Kleinigkeiten bei der Arbeit mit Amazon AWS: den Load Balancer muss man vorwärmen oder im Voraus eine Anfrage stellen: "Leute, wir bekommen Traffic, bitte wärmt unseren Load Balancer auf!" Diese Nuancen muss man kennen.

Wenn Sie sich an Menschen wenden, die darauf spezialisiert sind, bekommen Sie fast alle gängigen Dinge im Voraus gelöst. Wir haben derzeit 40 Ingenieure, bis zum Ende des Jahres werden es wahrscheinlich 60 sein – wir haben damit bereits Erfahrung. Selbst wenn wir bei einem Projekt erneut auf dieses Problem stoßen, fragen wir uns schnell gegenseitig und wissen, wie man es löst.

Wahrscheinlich ist die Antwort so – natürlich erleichtert eine Hosted-Lösung 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. Für all unsere Fälle – auf jeden Fall. Ansonsten haben wir keine positiven Erfahrungen gemacht. Alle anderen Clouds, mit denen wir versucht haben zu arbeiten, schaffen sehr viele Probleme – sowohl Ager als auch alles, was in Russland existiert, und verschiedene OpenStack-Implementierungen: Headster, Overage – alles, was Sie wollen. Sie alle verursachen Probleme, die man nicht lösen möchte.

Darum lautet die Antwort – ja, aber tatsächlich gibt es nicht viele ausgereifte Hosted-Lösungen.

Wer braucht Kubernetes?

— Und wer braucht eigentlich Kubernetes? Wer soll schon auf Kubernetes umsteigen, wer ist der typische Kunde von «Flant», der gerade nach Kubernetes fragt?

Dmitry: Die Frage ist interessant, denn gerade jetzt kommen viele zu uns auf der Welle von Kubernetes: „Leute, wir wissen, dass ihr Kubernetes macht, macht es für uns!“ Wir antworten: „Meine Herren, wir machen kein Kubernetes, wir bieten PROD und alles, was damit zusammenhängt, an.“ Denn heutzutage ist es einfach unmöglich, PROD zu erstellen, ohne das gesamte CI/CD und all diese Geschichten zu machen. Alle haben sich von der Trennung entfernt, dass wir Entwicklung als Entwicklung und dann Betrieb als Betrieb haben.

Unsere Kunden erwarten Verschiedenes, aber alle warten auf ein gewisses gutes Wunder, dass sie die einen oder anderen Probleme haben und jetzt — hop! — Kubernetes wird sie lösen. Die Leute glauben an Wunder. Sie verstehen mit dem Verstand, dass es kein Wunder geben wird, aber tief im Herzen hoffen sie — vielleicht wird uns Kubernetes jetzt alles lösen, darüber wird so viel gesprochen! Vielleicht ist es jetzt — huh! — und die silberne Kugel, huh! — und wir haben 100% Uptime, alle Entwickler können 50 Mal alles, was sie wollen, in PROD bringen, und es fällt nicht aus. Kurz gesagt, ein Wunder!

Wenn solche Leute 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 ein zuverlässiges PROD zu haben, muss man es zuverlässig erstellen. Um ein praktisches CI/CD zu haben, muss man es so gestalten. Das ist viel Arbeit, die erledigt werden muss.

Um die Frage zu beantworten, wer Kubernetes braucht — Kubernetes braucht niemand.

Einige Leute haben das falsche Gefühl, dass sie Kubernetes brauchen. Die Menschen möchten, sie haben das tiefgreifende Bedürfnis, sich nicht mehr mit den ganzen Infrastrukturproblemen und den Problemen beim Start ihrer Anwendungen auseinanderzusetzen. Sie wollen, dass die Anwendungen einfach laufen und einfach bereitgestellt werden. Für sie ist Kubernetes die Hoffnung, dass sie nicht mehr hören müssen: „Wir haben uns da herumgeschlagen“, oder „Wir können nicht ausrollen“, oder etwas anderes.

In der Regel kommt ein technischer Direktor zu uns. Man fragt ihn zwei Dinge: auf der einen Seite, gib uns Funktionen, auf der anderen Seite — Stabilität. Wir schlagen vor, dies zu übernehmen und zu gestalten. Die silberne Kugel, besser gesagt, die versilberte, besteht darin, dass du aufhören wirst, über diese Probleme nachzudenken und Zeit zu verschwenden. Du wirst spezielle Leute haben, die dieses Problem lösen.

Die Formulierung, dass wir oder jemand anderes Kubernetes brauchen, ist falsch.

Kubernetes ist für Administratoren sehr wichtig, denn es ist ein äußerst interessantes Spielzeug, mit dem man experimentieren kann. Lassen Sie uns ehrlich sein – jeder liebt Spielzeuge. Wir alle sind irgendwo Kinder, und wenn wir etwas Neues sehen, möchten wir damit spielen. Bei manchen ist das vielleicht abgestellt, zum Beispiel im Admin-Bereich, weil sie bereits genug gespielt haben und es einfach langweilig geworden ist. Aber das ist bei niemandem vollkommen abgestellt. Wenn mir Spielzeuge im Bereich Systemadministration und DevOps schon lange langweilig sind, kaufe ich trotzdem immer noch neue Spielzeuge. Alle Menschen wollen auf die eine oder andere Weise immer noch einige Spielzeuge.

Man sollte nicht mit der Produktion spielen. Was ich kategorisch nicht empfehlen würde und was ich derzeit oft sehe: "Oh, ein neues Spielzeug!" - ran an das Kaufen, gekauft und: "Lass uns das jetzt in die Schule bringen, um es allen Freunden zu zeigen." Machen Sie das nicht. Entschuldigung, ich habe einfach Kinder, die heranwachsen, und ich sehe ständig etwas in den Kindern, bemerke es an mir und abstrahiere es dann auf andere.

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

Man kann Folgendes erreichen:

• Die Produktion fällt nicht aus;
• Selbst wenn sie versucht auszufallen, wissen wir im Voraus davon und können etwas dagegen unternehmen;
• Wir können sie mit der Geschwindigkeit ändern, die wir für unser Geschäft benötigen, und das auf eine bequeme Weise, ohne dass es Probleme verursacht.

Es gibt zwei reale Bedürfnisse: Zuverlässigkeit und Dynamik/Flexibilität bei der Bereitstellung. Allen, die derzeit IT-Projekte durchführen, egal in welcher Branche – Software zur Erleichterung der Welt, und die das verstehen, müssen diese Bedürfnisse lösen. Kubernetes ermöglicht es mit der richtigen Herangehensweise, dem richtigen Verständnis und ausreichender Erfahrung, diese zu erfüllen.

Über serverless

Wenn man einen Blick in die Zukunft wagt, dann entstehen bei dem Versuch, das Problem der Kopfschmerzen mit der Infrastruktur, der Geschwindigkeit der Bereitstellung und der Änderungsrate von Anwendungen zu lösen, neue Lösungen, zum Beispiel serverless. Siehst du in dieser Richtung ein gewisses Potenzial und, sagen wir mal, eine Gefahr für Kubernetes und ähnliche Lösungen?

Dmitry: Hier muss ich erneut darauf hinweisen, dass ich kein Wahrsager bin, der in die Zukunft schaut und sagt – das wird so sein! Obwohl ich gerade das Gleiche gemacht habe. Ich schaue nach unten und sehe dort eine Menge Probleme, zum Beispiel, wie Transistoren im Computer funktionieren. Lustig, oder? Wir sind mit einigen Bugs in der CPU konfrontiert.

Serverless so zu gestalten, dass es ausreichend zuverlässig, kostengünstig, effektiv und bequem ist, indem alle ökosystematischen Fragen gelöst werden. Hier stimme ich Elon Musk zu, dass eine zweite Planet nötig ist, um eine Fehlertoleranz für die Menschheit zu schaffen. Auch wenn ich nicht weiß, was er sagt, verstehe ich, dass ich nicht bereit bin, selbst nach Mars zu fliegen, und das wird nicht morgen geschehen.

Bei serverless ist es klar, dass es ideologisch eine richtige Lösung ist, wie die Fehlertoleranz für die Menschheit – zwei Planeten zu haben ist besser als einer. Aber wie soll das jetzt umgesetzt werden? Eine Expedition zu senden – kein Problem, wenn man sich darauf konzentriert. Mehrere Expeditionen zu schicken und dort ein paar tausend Menschen anzusiedeln, halte ich auch für realistisch. Aber eine vollständige Fehlertoleranz zu schaffen, sodass die Hälfte der Menschheit dort lebt, erscheint mir derzeit unmöglich, nicht machbar.

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

Wie wird sich Kubernetes entwickeln

– Während wir auf diese potenziell wunderbare ferne Zukunft zusteuern, wie siehst du die Entwicklung von Kubernetes und dem Ökosystem darumherum?

Dmitry: Ich habe viel darüber nachgedacht und habe eine klare Antwort. Erstens, statefull — es ist tatsächlich leichter, stateless zu machen. Kubernetes hat von Anfang an mehr in dieses Konzept investiert, es hat alles damit begonnen. Stateless funktioniert praktisch perfekt in Kubernetes, da gibt es einfach nichts zu beanstanden. Bei statefull gibt es noch viele Probleme, besser gesagt, Nuancen. Bei uns funktioniert es dort bereits hervorragend, aber das sind wir. Damit es bei allen funktioniert, braucht es mindestens noch ein paar Jahre. Dies ist kein gemessener Wert, sondern mein persönliches Gefühl.

Kurz gesagt, statefull muss sich stark weiterentwickeln — und wird es auch — denn alle unsere Anwendungen speichern Status, es gibt keine stateless Anwendungen. Das ist eine Illusion, immer wird irgendwie eine Datenbank und noch etwas anderes benötigt. Statefull bedeutet, alles zu straffen, alle Bugs zu beheben, alle Probleme, mit denen wir momentan konfrontiert sind, zu verbessern — nennen wir es Adoption.

Das Niveau des Unbekannten, das Niveau der ungelösten Probleme, das Niveau der Wahrscheinlichkeit, auf etwas zu stoßen, wird stark sinken. Das ist eine wichtige Sache. Und Operatoren — alles, was mit der Kodifizierung der Administrationslogik, der Managementlogik zu tun hat, um einen einfachen Service zu erhalten: MySQL einfacher Service, RabbitMQ einfacher Service, Memcache einfacher Service, — wirklich alle diese Komponenten, die wir benötigen, um aus der Box heraus garantiert funktionsfähig zu sein. Das löst genau die Probleme, dass wir eine Datenbank wollen, sie aber nicht verwalten möchten, oder wir Kubernetes möchten, aber es nicht administrieren wollen.

Diese Entwicklungsgeschichte von Operatoren in irgendeiner Form wird in den nächsten Jahren wichtig sein.

Ich denke, dass die Einfachheit des Betriebs stark zunehmen sollte — die Box wird immer mehr und mehr schwarz werden, immer zuverlässiger, mit immer einfacheren Steuerungen.

Ich habe einmal ein altes Interview mit Isaac Asimov aus den 80er Jahren auf YouTube in der Show Saturday Night Live gehört — eine Art Urgant-Show, nur interessanter. Dort wurde er nach der Zukunft der Computer gefragt. Er sagte, dass die Zukunft in der Einfachheit liegt, wie es beim Radioempfänger der Fall war. Der Radioempfänger war ursprünglich eine komplizierte Angelegenheit. Um eine Welle einzufangen, musste man 15 Minuten lang Knöpfe drehen, Regler bewegen und überhaupt wissen, wie alles funktioniert, die Physik der Übertragung von Radiowellen verstehen. Am Ende blieb im Radio nur ein Regler übrig.

Was ist jetzt im Jahr 2019 das Radio? Im Auto findet der Radioreceiver alle Wellen, die Namen der Sender. Die Physik des Prozesses hat sich in 100 Jahren nicht geändert, aber die Benutzerfreundlichkeit hat sich verändert. Jetzt und nicht nur jetzt, schon 1980, als das Interview mit Asimov stattfand, benutzten alle das Radio und niemand dachte darüber nach, wie es funktioniert. Es hat immer funktioniert – das ist eine Gegebenheit.

Asimov sagte damals, dass es bei Computern ähnlich sein wird – die Benutzerfreundlichkeit wird zunehmen. Wenn man 1980 eine spezielle Ausbildung benötigte, um auf einem Computer Tasten zu drücken, wird das in Zukunft nicht so sein.

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

Was ist mit den Ingenieuren?

– Und was wird dann aus den Ingenieuren, Systemadministratoren, die Kubernetes unterstützen?

Dmitry: Was geschah mit dem Buchhalter nach dem Erscheinen von 1C? Etwa das Gleiche. Davor rechnete man auf Papier – jetzt in der Software. Die Arbeitsproduktivität hat sich um ein Vielfaches erhöht, und die Arbeit ist dadurch nicht verschwunden. Wenn früher für das Einschrauben einer Glühbirne 10 Ingenieure gebraucht wurden, wird jetzt einer ausreichen.

Die Anzahl der Software und die Menge der Aufgaben scheinen mir derzeit schneller zu wachsen, als neue DevOps erscheinen und die Effizienz steigt. Der Markt hat derzeit einen akuten Mangel, und dieser wird lange anhalten. Später wird sich alles in eine gewisse Norm einpendeln, bei der die Effizienz der Arbeit steigen wird, es wird immer mehr Serverless geben, und an Kubernetes wird eine neuronale Netzwerktechnologie angekoppelt, die alle Ressourcen genau so auswählen wird, wie es nötig ist, und alles selbst macht – Mensch, geh weg und stör nicht.

Aber die Entscheidungen müssen trotzdem von jemandem getroffen werden. Es ist klar, dass das Qualifikationsniveau und die Spezialisierung dieser Person höher sind. Jetzt benötigen Sie in der Buchhaltungsabteilung keine 10 Mitarbeiter mehr, die Buchhaltungsunterlagen führen, damit deren Hände nicht ermüden. Das ist einfach nicht notwendig. Viele Dokumente werden automatisch gescannt und vom System der elektronischen Dokumentenverwaltung erkannt. Ein intelligenter Hauptbuchhalter mit viel größeren Fähigkeiten und einem guten Verständnis reicht aus.

Insgesamt ist dieser Weg in allen Branchen so. Mit Autos ist es nicht anders: Früher gehörte zum Auto ein Mechaniker und drei Fahrer. Heute ist das Fahren eines Autos ein einfacher Prozess, an dem wir täglich alle teilnehmen. Niemand denkt darüber nach, dass ein Auto etwas Komplexes ist.

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

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

Dmitry: Natürlich, hundert Prozent! 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. Die Menge an Arbeit wächst. Der DevOps-Markt ist jetzt extrem überhitzt. Das zeigt sich an den Gehaltsvorstellungen. Im Grunde, ohne ins Detail zu gehen, sollte es Juniors geben, die X wollen, Middler, die 1,5X wollen, und Seniors, die 2X wollen. Doch heutzutage, wenn man sich den Moskauer Gehaltsmarkt für DevOps ansieht, will ein Junior zwischen X und 3X und ein Senior zwischen X und 3X.

Niemand weiß, was es wert ist. Das Gehaltsniveau wird durch dein Selbstbewusstsein gemessen – völliger Wahnsinn, ganz ehrlich, der Markt ist extrem überhitzt.

Natürlich wird sich diese Situation sehr bald ändern – es sollte eine gewisse Sättigung eintreten. Bei der Softwareentwicklung ist es nicht so – obwohl Entwickler überall gebraucht werden und gute Entwickler gefragt sind, versteht der Markt, wer wie viel wert ist – die Branche hat sich stabilisiert. Bei DevOps ist das derzeit nicht der Fall.

– Aus dem, was ich gehört habe, habe ich den Schluss gezogen, dass sich der aktuelle Systemadministrator nicht allzu viele Sorgen machen sollte, aber es ist an der Zeit, die Fähigkeiten auszubauen und sich darauf vorzubereiten, dass morgen die Arbeit zunehmen wird, aber sie wird qualifizierter sein.

Dmitry: Absolut. Im Allgemeinen leben wir im Jahr 2019 und die Regel für das Leben ist: lebenslanges Lernen – wir lernen ein Leben lang. Ich glaube, das wissen und spüren heutzutage schon viele, aber es reicht nicht aus, nur zu wissen – man muss handeln. Jeden Tag müssen wir uns verändern. Wenn wir das nicht tun, werden wir früher oder später an den Rand des Berufs gedrängt.

Sei bereit für plötzliche Wendungen um 180 Grad. Ich schließe nicht aus, dass sich etwas grundlegend ändert, etwas Neues erfunden wird – das kommt vor. Hopp! – und wir handeln jetzt anders. Es ist wichtig, darauf vorbereitet zu sein und sich nicht zu stressen. Es könnte passieren, dass morgen alles, was ich tue, überflüssig ist – kein Problem, ich habe mein ganzes Leben lang gelernt und bin bereit, etwas Neues zu lernen. Das ist kein Problem. Man sollte keine Angst vor der Jobsicherheit haben, aber man muss bereit sein, ständig etwas Neues zu lernen.

Wünsche und eine Minute Werbung

– Hast du einen Wunsch?

Dmitry: Ja, ich habe einige Wünsche.

Der erste und materielle – abonniere YouTube. Liebe Leser, geht auf YouTube und abonniert unseren Kanal. In etwa einem Monat werden wir mit einer aktiven Expansion auf dem Video-Service beginnen und wir werden jede Menge Lerninhalte über Kubernetes haben, offen und vielfältig: von praktischen Dingen, einschließlich Laboren, bis hin zu tiefgreifenden theoretischen Prinzipien und wie man Kubernetes auf der Ebene von Prinzipien und Mustern anwendet.

Der zweite materielle Wunsch – geht auf GitHub und gebt uns Sterne, denn davon leben wir. Wenn ihr uns keine Sterne gebt, werden wir nichts zu essen haben. Das ist wie Mana in einem Computerspiel. Wir tun irgendetwas, bemühen uns, jemand sagt, dass es schreckliche Fahrräder sind, jemand anders, dass alles überhaupt falsch ist, und wir machen weiter und handeln absolut ehrlich. Wir sehen ein Problem, lösen es und teilen unsere Erfahrungen. Also gebt uns einen Stern; euch kostet es nichts, uns kommt es zugute, denn wir leben davon.

Der dritte, wichtige und nicht materielle Wunsch – hört auf, an Märchen zu glauben. Ihr seid Profis. DevOps ist ein sehr ernsthafter und verantwortungsvoller Beruf. Hört auf, am Arbeitsplatz zu spielen. Lasst euch einen Schock versetzen, und ihr werdet es verstehen. Stellt euch vor, ihr kommt ins Krankenhaus, und dort experimentiert ein Arzt mit euch. Ich verstehe, dass das einige verletzen könnte, aber wahrscheinlich gilt das nicht für euch, sondern für jemand anderen. Sagt anderen, dass sie auch aufhören sollen. Das macht unser aller Leben wirklich schwerer – viele beginnen, die Betriebstechnik, die Admins und die DevOps-Leute als Typen zu betrachten, die wieder etwas kaputt gemacht haben. Dieses „kaputt gemacht“ passiert meist, weil wir gespielt haben, anstatt mit einem klaren Kopf zu schauen, was hier so ist und was dort so.

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

— Vielen Dank!

Dmitry: Danke dir, Vitaliy, und für die Zeit, und für das Interview. Liebe Leser, vielen Dank, wenn ihr bis zu diesem Punkt gekommen seid. Ich hoffe, dass wir euch wenigstens ein paar Gedanken mitgebracht haben.

Im Interview sprach Dmitry über das Werkzeug werf. Momentan ist es ein universelles Schweizer Taschenmesser, das fast alle Aufgaben löst. Aber das war nicht immer so. Auf DevOpsConf  dem Festival RIT++ wird Dmitry Stolyarov ausführlich über dieses Werkzeug sprechen. In seinem Vortrag „werf – unser Werkzeug für CI/CD in Kubernetes“ wird es alles geben: Probleme und verborgene Nuancen von Kubernetes, Lösungsmöglichkeiten für diese Herausforderungen und die aktuelle Umsetzung von werf im Detail. Kommt am 27. und 28. Mai dazu, wir werden perfekte Werkzeuge schaffen.

Quelle: habr.com