Kubernetes wird die Welt übernehmen. Wann und wie?

Am Vorabend von DevOpsConf interviewte Vitaliy Khabarov Dmitry Stolyarov ( distol ), technischen Direktor und Mitbegründer von Flant. Vitaly fragte Dmitry, was Flant tut, was Kubernetes, Ökosystementwicklung und Unterstützung angeht. Wir haben diskutiert, warum Kubernetes benötigt wird und ob es überhaupt benötigt wird. Und auch über Microservices, Amazon AWS, den „I'm Lucky“ -Ansatz in DevOps, die Zukunft von Kubernetes selbst, warum, wann und wie es die Welt erobern wird, die Aussichten von DevOps und worauf sich Ingenieure in der hellen und nahen Zukunft mit Vereinfachung und neuronalen Netzen vorbereiten sollten.

Hören Sie sich das Originalinterview als Podcast auf DevOps Deflop, den russischsprachigen Podcast über DevOps und die folgende Textversion an.



Im Folgenden werden Vitaliy Khabarov von einem Ingenieur von Express42 Fragen gestellt.

Über Flant

- Dima, hi. Sie sind der technische Direktor von Flant und auch dessen Gründer. Sagen Sie mir bitte, was macht die Firma und sind Sie dabei?

Dmitry : Von außen scheint es so, als wären wir die Leute, die gehen, Kubernetes auf alle setzen und etwas mit ihm machen. Aber das ist nicht so. Wir haben als Unternehmen angefangen, das sich mit Linux befasst, aber unsere Haupttätigkeit bestand lange Zeit darin, Produktions- und schlüsselfertige Hochlastprojekte zu warten. Normalerweise bauen wir die gesamte Infrastruktur von Grund auf neu auf und sind dann für eine lange Zeit dafür verantwortlich. Daher besteht die Hauptaufgabe von Flant, für die er Geld erhält, darin , Verantwortung zu übernehmen und die Produktion schlüsselfertig umzusetzen .


Als technischer Direktor und einer der Gründer des Unternehmens arbeite ich rund um die Uhr daran, Wege zu finden, um die Verfügbarkeit der Produktion zu erhöhen, den Betrieb zu vereinfachen, Administratoren das Leben zu erleichtern und Entwicklern das Leben angenehmer zu gestalten.

Über Kubernetes

- Das letzte Mal von "Flanta" sehe ich viele Berichte und Artikel über Kubernetes. Wie bist du zu ihm gekommen?

Dmitry : Ich habe schon oft darüber gesprochen, aber es tut mir überhaupt nicht leid, es zu wiederholen. Ich halte es für richtig, dieses Thema zu wiederholen, da Ursache und Wirkung verwechselt werden.

Wir brauchten wirklich ein Werkzeug. Wir hatten viele Probleme, hatten Probleme, haben sie mit verschiedenen Krücken überwunden und hatten das Bedürfnis nach einem Instrument. Durch viele verschiedene Optionen gesiebt, ihre Fahrräder gebaut, Erfahrungen gesammelt. Allmählich kamen wir zu dem Punkt, dass wir Docker fast sofort nach Erscheinen verwendeten - um 2013 herum. Zum Zeitpunkt seines Erscheinens hatten wir bereits viel Erfahrung mit Containern, wir haben bereits ein Analogon von „Docker“ geschrieben - einige unserer Krücken in Python. Mit dem Aufkommen von Docker können Krücken weggeworfen und von einer zuverlässigen und von der Community unterstützten Lösung verwendet werden.

Bei Kubernetes ist die Geschichte ähnlich. Als er an Fahrt gewann - für uns ist dies Version 1.2 - hatten wir bereits eine Reihe von Krücken an Shell und Chef, die wir irgendwie versuchten, Docker zu orchestrieren. Wir haben uns ernsthaft mit Rancher und verschiedenen anderen Lösungen befasst, aber dann erschien Kubernetes, in dem alles genau so implementiert ist, wie wir es tun würden oder noch besser. Es gibt nichts zu beanstanden.

Ja, es gibt eine Art von Unvollkommenheit, es gibt eine Art von Unvollkommenheit - es gibt viele Unvollkommenheiten und 1.2 ist im Allgemeinen schrecklich, aber ... Kubernetes ist wie ein Gebäude im Bau - Sie sehen sich das Projekt an und verstehen, dass es cool sein wird. Wenn das Gebäude jetzt ein Fundament und zwei Stockwerke hat, ist es besser, es noch nicht zu bevölkern, aber es gibt keine derartigen Probleme mit Software - Sie können es bereits verwenden.

Wir hatten nicht den Moment, in dem wir dachten, Kubernetes zu verwenden oder nicht. Wir warteten lange bevor er auftauchte auf ihn und versuchten selbst Analoga zu machen.

In der Nähe von Kubernetes

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

Dmitry : Mittelmäßig. Wir sind eher an der Entwicklung des Ökosystems beteiligt. Wir senden eine bestimmte Anzahl von Pull-Anfragen: an Prometheus, an alle Arten von Betreibern, an Helm an das Ökosystem. Leider kann ich nicht alles verfolgen, was wir tun, und ich kann mich irren, aber es gibt keinen einzigen Pool aus unserem Kern.

- Entwickeln Sie viele Ihrer Tools rund um Kubernetes?

Dmitry : Die Strategie lautet: Wir gehen in alles hinein, was bereits da ist. Wenn Pull-Anfragen dort nicht akzeptiert werden, geben wir sie einfach für uns selbst ab und leben, bis sie mit unseren Builds akzeptiert werden. Wenn es dann Upstream erreicht, kehren wir zur Upstream-Version zurück.

Zum Beispiel haben wir einen Prometheus-Operator, mit dem wir wahrscheinlich schon fünf Mal vor unserer Baugruppe hin und her gewechselt haben. Wir brauchen eine Funktion, wir haben eine Pull-Anfrage gesendet, wir müssen sie morgen einführen und wir wollen nicht warten, bis sie im Upstream veröffentlicht wird. Dementsprechend sammeln wir für uns selbst, rollen unsere Baugruppe mit unserer Funktion, die wir aus irgendeinem Grund benötigen, auf alle unsere Cluster. Dann wickeln sie uns zum Beispiel stromaufwärts mit den Worten ein: "Leute, lasst es uns für einen allgemeineren Fall tun", wir oder jemand anderes werden dies beenden und schließlich wieder zusammenführen.

Alles, was existiert, versuchen wir zu entwickeln . Viele Elemente, die noch nicht vorhanden sind, wurden noch nicht erfunden oder wurden erfunden, aber noch nicht implementiert - wir tun es. Und nicht, weil wir den Prozess selbst oder den Fahrradbau als Industrie mögen, sondern einfach, weil wir dieses Werkzeug brauchen. Sie stellen oft die Frage, warum wir dies oder jenes getan haben. Die Antwort ist einfach: Wir mussten noch weiter gehen, ein praktisches Problem lösen und es mit diesem Tool lösen.

Der Weg ist immer der folgende: Wir schauen sehr genau hin und wenn wir keine Lösung finden, wie man aus einem Laib Brot einen Trolleybus macht, dann machen wir unseren eigenen Laib und unseren eigenen Trolleybus.

Flant Tools

„Ich weiß, dass Flant jetzt Addon-Operatoren, Shell-Operatoren und dapp / werf-Tools hat. So wie ich es verstehe, ist dies das gleiche Werkzeug in verschiedenen Inkarnationen. Ich verstehe auch, dass es in Flant noch viele weitere verschiedene Tools gibt. Ist das so?

Dmitry : Wir haben noch viele Dinge auf GitHub. Soweit ich mich jetzt erinnere, haben wir eine Statuskarte - ein Panel für Grafana, das an alle ging. Es wird in fast jedem zweiten Artikel über die Überwachung von Kubernetes auf dem Medium erwähnt. Es ist unmöglich, kurz zu beschreiben, was Statusmap ist - Sie benötigen einen separaten Artikel, aber dies ist sehr nützlich, um den Status im Laufe der Zeit zu überwachen, da wir in Kubernetes häufig den Status im Laufe der Zeit anzeigen müssen. Wir haben auch LogHouse - dies ist ein auf ClickHouse und schwarzer Magie basierendes Stück zum Sammeln von Protokollen in Kubernetes.

Viele Dienstprogramme! Und es wird noch mehr geben, da in diesem Jahr eine Reihe interner Lösungen veröffentlicht werden. Von den sehr großen Addon-basierten Operatoren gibt es eine Reihe von Addons zu Kubernetes, aber wie man den Sert-Manager richtig installiert - ein Zertifikatverwaltungstool, wie man Prometheus mit einer Reihe von Dodges richtig installiert - das sind zwanzig verschiedene Binärdateien, die Daten exportieren und etwas dafür sammeln Prometheus ist eine großartige Grafik und Warnung. All dies ist nur eine Reihe von Addons zu Kubernetes, die in einem Cluster zusammengefasst sind, und es wechselt von einfach zu cool, hochentwickelt, automatisch, wobei viele Probleme bereits gelöst wurden. Ja, wir machen viel.

Ökosystementwicklung

- Es scheint mir, dass dies ein sehr großer Beitrag zur Entwicklung dieses Tools und seiner Verwendungsmethoden ist. Können Sie grob herausfinden, wer sonst den gleichen Beitrag zur Entwicklung des Ökosystems leisten würde?

Dmitry : In Russland ist keines der Unternehmen, die auf unserem Markt tätig sind, in der Nähe . Dies ist natürlich eine hochkarätige Aussage, denn es gibt große Player wie Mail mit Yandex - sie machen auch etwas mit Kubernetes, aber selbst sie haben nicht den Beitrag von Unternehmen auf der Welt erreicht, die viel mehr leisten als wir. Es ist schwierig, Flant mit 80 Mitarbeitern und Red Hat zu vergleichen, in denen es nur 300 Kubernetes-Ingenieure gibt, wenn ich mich nicht irre. Es ist schwer zu vergleichen. Wir haben 6 Mitarbeiter in der RnD-Abteilung, einschließlich mir, die alle unsere Werkzeuge sägen. 6 Personen gegen 300 Red Hat-Ingenieure - es ist irgendwie schwer zu vergleichen.

- Dennoch, wenn selbst diese 6 Personen etwas wirklich Nützliches und Entfremdetes tun können, wenn sie vor einer praktischen Aufgabe stehen und der Gemeinschaft eine Entscheidung geben - ein interessanter Fall. Ich verstehe, dass in großen Technologieunternehmen, in denen sie eine eigene Entwicklung haben und das Kubernetes-Support-Team, im Prinzip dieselben Tools entwickelt werden können. Dies ist ein Beispiel für sie, das entwickelt und der Community gegeben werden kann, um der gesamten Community, die Kubernetes verwendet, Impulse zu geben.

Dmitry : Dies ist wahrscheinlich ein Integrator-Chip, dessen Merkmal. Wir haben viele Projekte und sehen viele verschiedene Situationen. Für uns besteht der Hauptweg zur Schaffung von Mehrwert darin, diese Fälle zu analysieren, die häufigsten zu finden und sie für uns so billig wie möglich zu gestalten. Wir machen das aktiv. Es fällt mir schwer, über Russland und die Welt zu sprechen, aber wir haben ungefähr 40 DevOps-Ingenieure bei Kubernetes. Ich glaube nicht, dass es in Russland viele Unternehmen mit einer vergleichbaren Anzahl von Spezialisten gibt, die Kubernetes verstehen, wenn überhaupt.

Ich verstehe alles über die Berufsbezeichnung DevOps-Ingenieur, jeder versteht alles und ist es gewohnt, DevOps-Ingenieure als DevOps-Ingenieure zu bezeichnen. Wir werden dies nicht diskutieren. Alle diese 40 wunderbaren DevOps-Ingenieure stehen jeden Tag vor Problemen und lösen sie. Wir analysieren nur diese Erfahrung und versuchen, sie zusammenzufassen. Wir verstehen, dass das Tool in ein oder zwei Jahren unbrauchbar ist, wenn es bei uns bleibt, da irgendwo in der Community ein fertiges Tool angezeigt wird. Es macht keinen Sinn, diese Erfahrung im Inneren zu sammeln - es ist nur ein Zeit- und Energieverlust in dev / null. Und so tut es uns überhaupt nicht leid. Es ist uns eine große Freude, alles zu veröffentlichen und zu verstehen, dass wir es veröffentlichen, entwickeln, fördern, fördern müssen, damit die Menschen ihre eigenen Erfahrungen nutzen und hinzufügen können - dann wächst und lebt alles. Nach zwei Jahren geht das Werkzeug dann nicht in den Papierkorb. Es ist nicht schade, weiterhin Energie zu schütten, da klar ist, dass jemand Ihr Werkzeug verwendet und nach zwei Jahren jeder es verwendet.

Dies ist Teil unserer großen Strategie mit dapp / werf . Ich kann mich nicht erinnern, wann wir vor ungefähr 3 Jahren damit angefangen haben. Anfangs war es im Allgemeinen auf der Schale. Es war ein super Proof of Concept, wir haben einige unserer privaten Aufgaben gelöst - es stellte sich heraus! Es gibt jedoch Probleme mit der Shell. Es ist unmöglich, sie weiter zu entwickeln. Die Programmierung auf der Shell ist etwas anderes. Wir hatten die Angewohnheit, in Ruby zu schreiben. In Ruby haben wir etwas überarbeitet, entwickelt, entwickelt, entwickelt und uns darauf gestützt, dass die Community, eine Menge, die nicht sagt, dass wir wollen oder nicht wollen, Rubys Nase aufdreht. es ist nicht lustig Wir haben erkannt, dass wir all diese Dinge auf Go schreiben sollten, nur um dem ersten Absatz in der Checkliste zu entsprechen: Das DevOps-Tool sollte eine statische Binärdatei sein . On Go oder nicht Go ist nicht so wichtig, aber eine in Go geschriebene statische Binärdatei ist besser.

Wir haben uns Mühe gegeben, dapp on Go umgeschrieben und es werf genannt. Dapp wird nicht mehr unterstützt, entwickelt sich nicht, funktioniert in einigen neuesten Versionen, aber es gibt einen absoluten Upgrade-Pfad nach oben, und Sie können ihm folgen.

Warum wurde dapp erstellt?

- Können Sie uns kurz sagen, warum dapp erstellt wurde und welche Probleme es löst?

Dmitry : Der erste Grund in der Versammlung. Anfänglich hatten wir starke Build-Probleme, als Docker nicht wusste, wie man mehrstufig arbeitet, und wir machten selbst mehrstufig. Dann hatten wir ein paar Fragen zum Reinigen des Bildes. Jeder, der CI / CD eher früher als später erstellt, hat das Problem, dass es eine Menge gesammelter Bilder gibt. Sie müssen irgendwie bereinigen, was nicht benötigt wird, und das lassen, was benötigt wird.

Der zweite Grund liegt in der Bereitstellung. Ja, es gibt Helm, aber er löst nur einen Teil der Probleme. Ironischerweise steht geschrieben, dass "Helm - der Paketmanager für Kubernetes". Nämlich das "das". Es gibt auch die Worte "Paketmanager" - was ist die übliche Erwartung vom Paketmanager? Wir sagen: "Paketmanager - liefern Sie das Paket!" und erwarten Sie, dass er uns sagt: "Das Paket wurde geliefert."

Es ist interessant, dass wir sagen: "Helm, setzen Sie das Paket", und wenn er antwortet, dass er es installiert hat, stellt sich heraus, dass er gerade mit der Installation begonnen hat - Kubernetes wies darauf hin: "Führen Sie dieses Ding aus!", Aber es wurde gestartet oder nicht, es funktioniert oder nicht Helm löst dieses Problem überhaupt nicht.

Es stellt sich heraus, dass Helm nur ein Textvorprozessor ist, der Daten in Kubernetes lädt.

Aber wir möchten im Rahmen jeder Bereitstellung wissen, ob die Anwendung auf Prod umgestellt wurde oder nicht. Die Einführung auf das Produkt bedeutet, dass die Anwendung dorthin gegangen ist, eine neue Version bereitgestellt wurde und zumindest nicht abgestürzt ist und korrekt reagiert. Helm löst dieses Problem nicht. Um es zu lösen, müssen Sie viel Energie aufwenden, da Sie Kubernetes den Befehl geben müssen, auszurollen und zu überwachen, was dort passiert - ob es sich umgedreht hat, ob es ausgerollt ist. Darüber hinaus gibt es eine Reihe von Aufgaben im Zusammenhang mit Bereitstellung, Reinigung und Montage.

Pläne

In diesem Jahr werden wir zur lokalen Entwicklung gehen. Wir wollen zu dem kommen, was früher in Vagrant war - wir haben "vagrant up" eingegeben und virtuelle Maschinen bereitgestellt. Wir möchten zu einem solchen Zustand kommen, dass es in Git ein Projekt gibt, wir schreiben dort „werf“ und es wird eine lokale Kopie dieses Projekts erstellt, die in einem lokalen Mini-Kub bereitgestellt wird und mit der alle für die Entwicklung geeigneten Verzeichnisse verbunden sind. Abhängig von der Entwicklungssprache erfolgt dies auf unterschiedliche Weise, jedoch ist es bequem, die lokale Entwicklung unter den bereitgestellten Dateien durchzuführen.

Der nächste Schritt für uns besteht darin , stark in den Komfort für Entwickler zu investieren . Um ein Projekt schnell lokal mit einem Tool bereitzustellen, müssen Sie es an Git senden. Je nach Pipeline wird es auch für die Phase oder Tests bereitgestellt und dann mit demselben Tool zum Produkt weitergeleitet. Diese Einheit, Vereinheitlichung und Reproduzierbarkeit der Infrastruktur von der lokalen Umgebung bis zum Verkauf ist für uns ein sehr wichtiger Moment. Aber das ist noch nicht in werf - ich habe nur vor, es zu tun.

Aber der Weg zu dapp / werf war immer der gleiche wie bei Kubernetes am Anfang. Wir sind auf Probleme gestoßen, haben sie durch Problemumgehungen gelöst - wir haben uns auf der Shell eine Lösung für alles ausgedacht. Dann haben diese Problemumgehungen versucht, in diesem Fall die Binärdateien zu begradigen, zu verallgemeinern und zu konsolidieren, die wir einfach teilen.

Es gibt eine andere Sicht auf diese ganze Geschichte mit Analogien.

Kubernetes ist ein Fahrzeugrahmen mit Motor. Es gibt keine Türen, Fenster, ein Radio, Weihnachtsbäume - überhaupt nichts. Nur der Rahmen und der Motor. Und da ist Helm - das ist das Lenkrad. Cool - es gibt ein Lenkrad, braucht aber noch einen Lenkstift, eine Zahnstange, ein Getriebe und Räder, aber ohne sie nichts.

Im Fall von werf ist dies eine weitere Komponente von Kubernetes. Erst jetzt in unserer Alpha-Version von werf zum Beispiel kompiliert Helm insgesamt zu werf, weil wir es satt haben, dies selbst zu tun. Es gibt viele Gründe dafür, im Detail darüber, warum wir das Ruder als Ganzes zusammen mit der Pinne in werf zusammengestellt haben, werde ich nur im Bericht über RIT ++ erzählen.

Jetzt ist werf eine stärker integrierte Komponente. Wir bekommen ein fertiges Lenkrad, einen Lenkbolzen - ich bin nicht sehr gut in Autos, aber dies ist ein großer Block, der bereits eine ganze Reihe von Aufgaben löst. Wir müssen den Katalog nicht selbst erklimmen, ein Teil zum anderen aufnehmen und darüber nachdenken, wie wir sie aneinander befestigen können. Wir erhalten einen vorgefertigten Mähdrescher, der sofort ein großes Bündel von Aufgaben löst. Es besteht jedoch aus denselben Open-Source-Komponenten, verwendet Docker für die Montage, Helm für einen Teil der Funktionalität und mehrere andere Bibliotheken. Dies ist ein integriertes Tool, mit dem Sie CI / CD schnell und bequem sofort abkühlen können.

Ist Kubernetes schwer zu warten?

- Sie sprechen über die Erfahrung, dass Sie mit Kubernetes angefangen haben, dies ist ein Rahmen, ein Motor für Sie, und dass Sie viele verschiedene Dinge daran hängen können: Karosserie, Lenkrad, Pedale befestigen, Sitze. Die Frage ist: Wie schwierig ist die Unterstützung von Kubernetes für Sie? Sie haben umfangreiche Erfahrungen. Wie viel Zeit und Ressourcen benötigen Sie, um Kubernetes getrennt von allem anderen zu unterstützen?

Dmitry : Dies ist eine sehr schwierige Frage. Um sie zu beantworten, müssen Sie verstehen, was Unterstützung ist und was wir von Kubernetes erwarten. Vielleicht wirst du es verraten?

- Soweit ich weiß und wie ich es sehe, wollen jetzt viele Teams Kubernetes ausprobieren. Jeder spannte sich an und legte sein Knie auf. Ich habe das Gefühl, dass die Leute die Komplexität dieses Systems nicht immer verstehen.

Dmitry : Das war's.

- Wie schwierig ist es, Kubernetes zu nehmen und zu liefern, ohne dass es produktionsbereit ist?

Dmitry : Denken Sie, wie schwierig es ist, ein Herz zu transplantieren? Ich verstehe, die Frage ist kompromittierend. Mit einem Skalpell zu tragen und keinen Fehler zu machen ist nicht so schwierig. Wenn Sie wissen, wo Sie schneiden und wo Sie nähen müssen, ist das Verfahren selbst einfach. Es ist schwierig, von Zeit zu Zeit zu garantieren, dass alles klappt.

Setzen Sie Kubernetes und machen Sie es einfach: Küken! - geliefert, gibt es eine Reihe von Installationsmethoden. Aber was passiert, wenn Probleme auftreten?

Es stellen sich immer Fragen - was haben wir noch nicht berücksichtigt? Was haben wir noch nicht getan? Welche Parameter des Linux-Kernels haben Sie falsch angegeben? Herr, haben wir sie überhaupt darauf hingewiesen ?! Welche Kubernetes-Komponenten haben wir geliefert und welche nicht? Tausende von Fragen stellen sich, und um sie zu beantworten, müssen Sie 15 bis 20 Jahre in dieser Branche kochen.

Ich habe ein neues Beispiel zu diesem Thema, das möglicherweise die Bedeutung des Problems „Ist es schwierig, Kubernetes zu warten?“ Aufzeigt. Vor einiger Zeit haben wir ernsthaft darüber nachgedacht, ob wir versuchen sollten, Cilium als Netzwerk in Kubernetes zu implementieren.

Lassen Sie mich erklären, was Cilium ist. Kubernetes hat viele verschiedene Implementierungen des Netzwerksubsystems, und eine davon ist sehr cool - es ist Cilium. Was bedeutet es? Im Kernel wurde es vor einiger Zeit möglich, Hooks für den Kernel zu schreiben, die irgendwie in das Netzwerksubsystem und verschiedene andere Subsysteme eindringen und es Ihnen ermöglichen, große Blöcke im Kernel zu umgehen.

Der Linux-Kernel verfügt historisch gesehen über einen IP-Router, einen Superfilter, Bridges und viele verschiedene alte Komponenten, die 15, 20, 30 Jahre alt sind. Im Allgemeinen funktionieren sie, alles ist cool, aber jetzt haben sie einen Behälter mit Behältern hergestellt, und es sieht aus wie ein Turm aus 15 Steinen übereinander, und Sie stehen auf einem Bein darauf - ein seltsames Gefühl. Dieses System hat sich historisch mit vielen Nuancen entwickelt, wie ein Anhang im Körper. In einigen Situationen treten beispielsweise Leistungsprobleme auf.

Es gibt eine wunderbare BPF und die Möglichkeit, Hooks für den Kernel zu schreiben - die Jungs haben ihre Hooks für den Kernel geschrieben. Das Paket kommt zum Linux-Kernel, sie nehmen es direkt an der Eingabe heraus, verarbeiten es selbst ohne Bridges, ohne TCP, ohne IP-Stack - kurz gesagt, umgehen alles, was im Linux-Kernel geschrieben ist, und spucken es sofort in den Container aus.

Was ist passiert? Sehr coole Leistung, coole Features - einfach toll! Wir sehen uns dies jedoch an und stellen fest, dass auf jedem Computer ein Programm vorhanden ist, das eine Verbindung zur Kubernetes-API herstellt und basierend auf den von dieser API empfangenen Daten C-Code generiert und die in den Kernel geladenen Binärdateien kompiliert, sodass diese Hooks im Kernelraum funktionieren .

Was passiert, wenn etwas schief geht? Wir wissen es nicht. Um dies zu verstehen, müssen Sie den gesamten Code lesen, die gesamte Logik verstehen, und das ist verblüfft, wie schwierig. Auf der anderen Seite gibt es diese Brücken, Netzfilter, IP-Router - ich habe ihre Quellen nicht gelesen - und 40 Ingenieure, die auch in unserem Unternehmen arbeiten. Vielleicht verstehen einige Stücke Einheiten.

Und was ist der Unterschied? Es stellt sich heraus, dass es einen IP-Router, den Linux-Kernel und ein neues Tool gibt - was der Unterschied ist, wir verstehen weder das eine noch das andere. Aber wir haben Angst, das Neue zu benutzen - warum? Denn wenn das Tool 30 Jahre alt ist, wurden über 30 Jahre alle Fehler gefunden, alle Rechen sind gekommen und Sie müssen nicht alles wissen - es funktioniert wie eine Black Box und es funktioniert immer. Jeder weiß, welcher diagnostische Schraubendreher an welcher Stelle angebracht werden soll, welcher TCP-Dump an welchem ​​Punkt zu starten ist. Jeder kennt die Diagnose-Dienstprogramme gut und versteht, wie diese Komponenten im Linux-Kernel funktionieren - nicht wie sie funktionieren, sondern wie man sie verwendet.

Und unglaublich cool Cilium ist nicht 30 Jahre alt, es ist noch nicht ausgereift. Mit Kubernetes das gleiche Problem kopieren. Dass Cilium perfekt eingestellt ist, dass Kubernetes perfekt eingestellt ist, aber wenn im Produkt etwas schief geht, können Sie dann schnell verstehen, was in einer kritischen Situation schief gelaufen ist?

Wenn wir sagen, dass es schwierig ist, Kubernetes zu warten, nein, es ist sehr einfach und ja, es ist unglaublich schwierig. Kubernetes , .

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . Es ist nicht so.

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . Was ist das? Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

Über serverlos

- Wenn Sie ein wenig weiter in die Zukunft schauen und versuchen, das Problem des Mangels an Kopfschmerzen mit der Infrastruktur zu lösen, mit Rollout-Geschwindigkeit und Geschwindigkeit für Anwendungsänderungen, erscheinen neue Lösungen, beispielsweise ohne Server. Spüren Sie ein Potenzial in diese Richtung und beispielsweise eine Gefahr für Kubernetes und ähnliche Lösungen?

Dmitry : Hier müssen wir noch einmal eine Bemerkung machen, dass ich kein Visionär bin, der nach vorne schaut und sagt - es wird so sein! Obwohl ich genau das Gleiche getan habe. Ich schaue auf meine Füße und sehe dort eine Reihe von Problemen, zum Beispiel, wie Transistoren in einem Computer funktionieren. Komisch, oder? Wir haben einige Fehler in der CPU.

Serverlos zuverlässig genug, billig, effizient und bequem machen und alle Ökosystemprobleme lösen. Dann stimme ich Elon Mask zu, dass wir einen zweiten Planeten brauchen, um Fehlertoleranz für die Menschheit zu schaffen. Obwohl ich nicht weiß, was er sagt, verstehe ich, dass ich nicht bereit bin, selbst zum Mars zu fliegen, und es wird nicht morgen sein.

Mit serverless ist klar, dass dies die ideologisch korrekte Sache ist, da Fehlertoleranz für die Menschheit - zwei Planeten sind besser als einer. Aber wie geht das jetzt? Eine Expedition zu schicken ist kein Problem, wenn wir uns auf diese Bemühungen konzentrieren. Es ist auch realistisch, mehrere Expeditionen zu schicken und mehrere tausend Menschen dort zu bevölkern. Aber es ist völlig um Fehlertoleranz zu machen, dass die Hälfte der Menschheit dort lebt, es scheint mir jetzt unmöglich, nicht berücksichtigt.

Mit Serverless eins zu eins: Das Ding ist cool, aber es ist weit entfernt von den Problemen von 2019. Näher an 2030 - lass es uns erleben. Ich habe keinen Zweifel, dass wir überleben werden, wir werden sicherlich überleben (vor dem Schlafengehen wiederholen), aber jetzt müssen wir andere Probleme lösen. Es ist, als würde man an ein fabelhaftes Pony Rainbow glauben. Ja, ein paar Prozent der Fälle sind gelöst und perfekt gelöst, aber subjektiv ohne Server ist ein Regenbogen ... Für mich ist dieses Thema zu weit und zu unverständlich. Ich bin nicht bereit zu reden. Im Jahr 2019 werden Sie mit serverless keine einzige Anwendung schreiben.

Wie sich Kubernetes entwickeln wird

"Was wird Ihrer Meinung nach Kubernetes und das Ökosystem um es herum entwickeln, wenn wir uns dieser potenziell schönen, fernen Zukunft nähern?"

Dmitry : Ich habe viel darüber nachgedacht und ich habe eine klare Antwort. Der erste ist zustandsbehaftet - noch staatenlos ist einfacher zu tun. Kubernetes hat zunächst mehr investiert, alles begann damit. Staatenlos funktioniert in Kubernetes fast perfekt, es gibt nichts zu beanstanden. Durch Statefull gibt es immer noch viele Probleme oder vielmehr Nuancen. Dort funktioniert bei uns schon alles gut, aber wir sind es. Damit dies für alle funktioniert, benötigen Sie noch mindestens ein paar Jahre. Dies ist kein kalkulierter Indikator, sondern mein Gefühl vom Kopf.

Kurz gesagt, statefull muss und wird sich sehr weiterentwickeln, da alle unsere Anwendungen den Status haben und es keine zustandslosen Anwendungen gibt. Dies ist eine Illusion, Sie brauchen immer eine Art Datenbank und etwas anderes. Statefull ist die Korrektur von allem, was möglich ist, die Korrektur aller Fehler, die Verbesserung aller Probleme, mit denen wir derzeit konfrontiert sind - nennen wir es Adoption.

Das Niveau des Unbekannten, das Niveau der ungelösten Probleme, die Wahrscheinlichkeit, auf etwas zu stoßen, wird stark sinken. Dies ist eine wichtige Geschichte. Und die Bediener - alles, was mit der Kodifizierung der Administrationslogik und der Steuerlogik zu tun hat, um einen einfachen Service zu erhalten: MySQL-Easy-Service, RabbitMQ-Easy-Service, Memcache-Easy-Service - im Allgemeinen sind all diese Komponenten, die wir benötigen, garantiert sofort einsatzbereit. Dies löst nur den Schmerz, dass wir eine Datenbank wollen, sie aber nicht verwalten wollen oder Kubernetes wollen, aber sie nicht verwalten wollen.

Diese Geschichte mit der Entwicklung der Betreiber in der einen oder anderen Form wird in den nächsten Jahren wichtig sein.

Ich denke, die Benutzerfreundlichkeit sollte stark zunehmen - die Box wird immer schwarzer, immer zuverlässiger und mit immer einfacheren Drehungen.

Ich habe mir einmal Isaac Asimovs altes 80er-Jahre-Interview auf YouTube bei Saturday Night Live angehört, einer Urgant-ähnlichen Show, die einfach nur interessant ist. Dort wurde er nach der Zukunft der Computer gefragt. Er sagte, die Zukunft sei einfach, wie es beim Radio der Fall war. Das Radio war ursprünglich eine komplizierte Sache. Um die Welle zu fangen, dauerte es 15 Minuten, um die Wirbel zu drehen, die Spieße zu drehen und allgemein zu wissen, wie alles funktioniert, um die Physik der Funkwellenübertragung zu verstehen. Infolgedessen blieb eine Drehung im Radio.

Welches Radio jetzt im Jahr 2019? Im Auto findet das Radio alle Wellen, den Namen der Sender. Die Physik des Prozesses hat sich in 100 Jahren nicht geändert, die Benutzerfreundlichkeit hat sich geändert. Jetzt und nicht nur jetzt, bereits 1980, als es ein Interview mit Azimov gab, benutzten alle das Radio und niemand dachte darüber nach, wie es arrangiert war. Es hat immer funktioniert - es ist eine Selbstverständlichkeit.

Azimov sagte dann, dass es mit Computern ähnlich sein würde - die Benutzerfreundlichkeit würde zunehmen . Wenn Sie 1980 eine spezielle Ausbildung benötigen, um Tasten auf einem Computer zu drücken, wird dies in Zukunft nicht mehr der Fall sein.

Ich habe das Gefühl, dass mit Kubernetes und der Infrastruktur auch die Benutzerfreundlichkeit dramatisch zunehmen wird. Dies ist meiner Meinung nach offensichtlich - es liegt an der Oberfläche.

Was tun mit den Ingenieuren?

- Und was passiert dann mit den Ingenieuren, Systemadministratoren, die Kubernetes unterstützen?

Dmitry : Und was ist mit dem Buchhalter nach dem Erscheinen von 1C passiert? Ungefähr das Gleiche. Vorher dachten sie auf ein Stück Papier - jetzt im Programm. Die Arbeitsproduktivität hat um Größenordnungen zugenommen, und die Arbeit selbst ist davon nicht verschwunden. Früher mussten 10 Ingenieure die Glühbirne einschrauben, jetzt reicht einer aus.

Die Anzahl der Software und die Anzahl der Aufgaben, so scheint es mir, wachsen jetzt schneller als bei neuen DevOps, und die Effizienz steigt. Es gibt einen spezifischen Mangel auf dem Markt, der lange anhalten wird. Später wird alles in eine bestimmte Norm gehen, bei der die Effizienz der Arbeit zunimmt, sie serverloser wird, ein Neuron an Kubernetes bindet, das alle Ressourcen richtig auswählt, wie es sollte, und im Allgemeinen alles so macht, wie es sollte - die Person entkommt und sich nicht darum kümmert.

Aber trotzdem muss jemand Entscheidungen treffen. Es ist klar, dass das Qualifikations- und Spezialisierungsniveau dieser Person höher ist. In der Buchhaltung brauchen Sie keine 10 Mitarbeiter, die Bücher führen, damit ihre Hand nicht müde wird. Es ist einfach nicht notwendig. Viele Dokumente werden vom elektronischen Dokumentenverwaltungssystem automatisch gescannt und erkannt. Ein kluger Hauptbuchhalter reicht aus, bereits mit viel größeren Fähigkeiten, mit einem guten Verständnis.

Im Allgemeinen ist ein solcher Weg in allen Sektoren. Ähnlich verhält es sich mit Autos: Früher waren ein Automechaniker und drei Fahrer am Auto befestigt. Jetzt ist Autofahren der einfachste Prozess, an dem wir alle jeden Tag teilnehmen. Niemand hält ein Auto für etwas Kompliziertes.

DevOps oder Systems Engineering werden nirgendwo hingehen - die Effizienz auf hohem Niveau und im Betrieb wird steigen.

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

Dmitry : Natürlich hundertprozentig! Weil die Menge an Software, die wir schreiben, ständig wächst. Die Anzahl der Probleme, die wir mit Software lösen, wächst ständig. Der Arbeitsaufwand wächst. Jetzt ist der DevOps-Markt schrecklich überhitzt. Dies geht aus den Gehaltserwartungen hervor. Auf eine gute Art und Weise, ohne auf Details einzugehen, sollte es Junioren geben, die X wollen, Mitten, die 1,5X wollen, und Senioren, die 2X wollen. Und jetzt, wenn Sie sich den Moskauer DevOps-Gehaltsmarkt ansehen, will der Junior von X bis 3X und der Senior von X bis 3X.

Niemand weiß, wie viel es kostet. Ihr Gehaltsniveau wird an Ihrem Selbstvertrauen gemessen - ein komplettes Irrenhaus, um ehrlich zu sein, ein schrecklich überhitzter Markt.

Natürlich wird sich diese Situation sehr bald ändern - eine gewisse Sättigung sollte kommen. Bei der Softwareentwicklung ist dies nicht der Fall - trotz der Tatsache, dass jeder Entwickler braucht und jeder gute Entwickler braucht, versteht der Markt, wie viel es kostet - die Branche hat sich beruhigt. Dies ist bei DevOps nicht der Fall.

- Nach allem, was ich gehört habe, bin ich zu dem Schluss gekommen, dass der derzeitige Systemadministrator nicht sehr besorgt sein sollte, aber es ist Zeit, Fähigkeiten herunterzuladen und sich darauf vorzubereiten, dass morgen mehr Arbeit, aber mehr Qualifikation vorhanden sein wird.

Dmitry : Auf jeden Fall. Im Allgemeinen leben wir im Jahr 2019 und die Lebensregel lautet: Lebenslanges Lernen - wir lernen unser ganzes Leben lang . Es scheint mir, dass jetzt jeder es weiß und fühlt, aber ein wenig zu wissen ist notwendig. Jeden Tag müssen wir uns ändern. Wenn wir dies nicht tun, werden wir früher oder später am Rande des Berufs abgesetzt.

Machen Sie sich bereit für scharfe 180-Grad-Kurven. Ich schließe eine Situation nicht aus, in der sich etwas dramatisch ändert, sie sich etwas Neues einfallen lassen - es passiert. Hop! - und jetzt handeln wir anders. Es ist wichtig, darauf vorbereitet zu sein und nicht zu dämpfen. Es kann vorkommen, dass morgen alles, was ich tue, unnötig ist - nichts, ich habe mein ganzes Leben lang studiert und bin bereit, etwas anderes zu lernen. Das ist kein Problem. Sie sollten keine Angst vor der Arbeitsplatzsicherheit haben, aber Sie müssen bereit sein, ständig etwas Neues zu lernen.

Wünsche und eine Minute Werbung

- Hast du einen Wunsch?

Dmitry : Ja, ich habe ein paar Wünsche.

Der erste und kaufmännische - abonnieren Sie YouTube . Liebe Leser, gehen Sie zu YouTube und abonnieren Sie unseren Kanal. In ungefähr einem Monat werden wir mit einer aktiven Erweiterung des Videodienstes beginnen. Wir werden eine Reihe offener und unterschiedlicher Bildungsinhalte über Kubernetes haben: von praktischen Dingen über Labors bis hin zu tiefgreifenden theoretischen Dingen und der Anwendung von Kubernetes auf der Ebene von Prinzipien und Mustern.

Der zweite kaufmännische Wunsch - gehe zu GitHub und setze Sterne, weil wir sie essen. Wenn Sie uns keine Sterne geben, haben wir nichts zu essen. Es ist wie Mana in einem Computerspiel. Wir tun etwas, tun, versuchen, jemand sagt, dass dies schreckliche Fahrräder sind, jemand, dass im Allgemeinen alles falsch ist, und wir machen weiter und handeln absolut ehrlich. Wir sehen das Problem, lösen es und teilen unsere Erfahrungen. Deshalb gib uns ein Sternchen, es wird nicht von dir abnehmen, aber es wird zu uns kommen, weil wir sie essen.

Das dritte, wichtige und nicht mehr kaufmännische Verlangen - hör auf, an Märchen zu glauben . Sie sind Profis. DevOps ist ein sehr seriöser und verantwortungsbewusster Beruf. Hör auf am Arbeitsplatz zu spielen. Lass dich klicken und du wirst es verstehen. Stellen Sie sich vor, Sie kommen ins Krankenhaus und dort experimentiert der Arzt mit Ihnen. Ich verstehe, dass dies für jemanden beleidigend sein kann, aber höchstwahrscheinlich geht es nicht um Sie, sondern um jemanden anderen. Sagen Sie anderen, sie sollen auch aufhören. Es verdirbt wirklich das Leben für uns alle - viele beginnen sich auf Ausbeutung, Admins und DevOps zu beziehen, ebenso wie auf Typen, die wieder etwas kaputt gemacht haben. Dies war meistens „kaputt“, weil wir zum Spielen gingen und nicht mit kaltem Bewusstsein sahen, dass es so war, sondern so.

Dies bedeutet nicht, dass Sie nicht experimentieren müssen. Wir müssen experimentieren, wir machen es selbst. Um ehrlich zu sein, spielen wir selbst manchmal auch - das ist natürlich sehr schlecht, aber nichts Menschliches ist uns fremd. Lassen Sie uns 2019 zum Jahr ernsthafter nachdenklicher Experimente erklären, nicht zu Spielen auf Prod. Wahrscheinlich so.

- Vielen Dank!

Dmitry : Danke, Vitaly, sowohl für die Zeit als auch für das Interview. Liebe Leserinnen und Leser, vielen Dank, wenn Sie plötzlich an diesem Punkt angelangt sind. Ich hoffe, dass wir Ihnen zumindest ein paar Gedanken gebracht haben.

In einem Interview berührte Dmitry werf. Jetzt ist es ein universelles Schweizer Messer, das fast alle Aufgaben löst. Das war aber nicht immer der Fall. Auf der DevOpsConf beim RIT ++ Festival wird Dmitry Stolyarov ausführlich über dieses Tool sprechen. Der Bericht „werf ist unser Werkzeug für CI / CD in Kubernetes“ wird alles enthalten: Probleme und versteckte Nuancen von Kubernetes, Lösungen für diese Schwierigkeiten und die aktuelle Implementierung von werf im Detail. Machen Sie am 27. und 28. Mai mit, wir werden ideale Werkzeuge erstellen.