{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Wird Kubernetes die Welt erobern? Wann und wie?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im Vorfeld DevOpsConf<\/a><\/noindex> Vitaliy Chabarov<\/b> f\u00fchrte ein Interview mit\u00a0Dmitry Stolyarov<\/b> (distol<\/a><\/noindex>), dem technischen Direktor und Mitbegr\u00fcnder des Unternehmens \u201eFlant\u201c. Vitaliy fragte Dmitry, womit sich \u201eFlant\u201c besch\u00e4ftigt, \u00fcber Kubernetes, die Entwicklung des \u00d6kosystems und den Support. Sie besprachen, warum Kubernetes n\u00f6tig ist und ob es \u00fcberhaupt ben\u00f6tigt wird. Au\u00dferdem ging es um Mikrodienste, Amazon AWS, den Ansatz \u201eEs wird schon klappen\u201c in DevOps, die Zukunft von Kubernetes, wann, wie und warum es die Welt erobern wird, die Perspektiven f\u00fcr DevOps und worauf sich Ingenieure in naher Zukunft mit Vereinfachungen und neuronalen Netzen vorbereiten sollten.<\/p>\n

Das Originalinterview<\/a><\/noindex> im Podcastformat k\u00f6nnen Sie auf DevOps Defloop - einem russischsprachigen Podcast \u00fcber DevOps - h\u00f6ren, und weiter unten finden Sie die Textversion. <\/p>\n

\"Wird
\n
\nHier und im Folgenden stellt Vitaliy Chabarov<\/a><\/noindex> ein Ingenieur von Express42.
\n<\/a><\/noindex><\/p>\n

\u00dcber \u201eFlant\u201c<\/h2>\n

\n\u2014 Dima, hallo. Du bist der technische Direktor von \u201eFlant<\/a><\/noindex>\u201c und auch dessen Gr\u00fcnder. Bitte erz\u00e4hl uns, womit besch\u00e4ftigt sich das Unternehmen und was ist deine Rolle darin?<\/b><\/p>\n

\"WirdDmitry<\/b>: Von au\u00dfen sieht es so aus, als w\u00e4ren wir die Art von Typen, die \u00fcberall Kubernetes implementieren und damit experimentieren. Aber das stimmt nicht. Wir haben als Linux-Company begonnen, aber seit langem konzentrieren wir uns haupts\u00e4chlich auf die Betreuung von Produktions- und Highload-Projekten aus einer Hand. Normalerweise bauen wir die gesamte Infrastruktur von Grund auf neu und sind dann lange daf\u00fcr verantwortlich. Daher ist die Hauptarbeit von \u00abFlant\u00bb, f\u00fcr die wir auch bezahlt werden, die \u00dcbernahme von Verantwortung und die Implementierung von Produktionsl\u00f6sungen aus einer Hand.<\/b>.
\n

\n

\nIch, als technischer Direktor und einer der Gr\u00fcnder des Unternehmens, besch\u00e4ftige mich rund um die Uhr damit, mir zu \u00fcberlegen, wie die Verf\u00fcgbarkeit der Produktion erh\u00f6ht, die Nutzung vereinfacht und das Leben der Admins erleichtert werden kann, um das Leben der Entwickler angenehmer zu gestalten.<\/p>\n

\u00dcber Kubernetes<\/h2>\n

\n\u2014 In letzter Zeit sehe ich viele Vortr\u00e4ge von \u00abFlant\u00bb\u00a0Artikel<\/a><\/noindex> \u00fcber Kubernetes. Wie sind Sie dazu gekommen?<\/b><\/p>\n

Dmitry<\/b>: Ich habe schon oft dar\u00fcber gesprochen, aber ich habe nichts dagegen, das zu wiederholen. Ich halte es f\u00fcr wichtig, dieses Thema erneut anzusprechen, denn es herrscht h\u00e4ufig Verwirrung zwischen Ursache und Wirkung.<\/p>\n

Wir ben\u00f6tigten dringend ein Werkzeug. Wir hatten mit vielen Problemen zu k\u00e4mpfen, suchten nach L\u00f6sungen und erlebten den Bedarf an einem passenden Tool. Wir durchforsteten zahlreiche Optionen, bauten unsere eigenen L\u00f6sungen und sammelten Erfahrung. Allm\u00e4hlich kamen wir dazu, Docker fast sofort nach seiner Ver\u00f6ffentlichung 2013 zu nutzen. Zu diesem Zeitpunkt hatten wir bereits viel Erfahrung mit Containern gesammelt und selbst eine Art \"Docker\" mit eigenen Notl\u00f6sungen in Python entwickelt. Mit der Einf\u00fchrung von Docker konnten wir unsere provisorischen L\u00f6sungen endlich beiseitelegen und ein zuverl\u00e4ssiges, von der Community unterst\u00fctztes Produkt nutzen.<\/p>\n

Die Geschichte mit Kubernetes ist \u00e4hnlich. Als es anfing, popul\u00e4r zu werden \u2013 f\u00fcr uns war das die Version 1.2 \u2013 hatten wir bereits viele provisorische L\u00f6sungen, sowohl in Shell als auch in Chef, mit denen wir versuchten, Docker zu orchestrieren. Wir schauten uns ernsthaft Rancher und verschiedene andere L\u00f6sungen an, aber dann kam Kubernetes, das genau so umgesetzt wurde, wie wir es auch gemacht h\u00e4tten \u2013 oder sogar besser. Da gab es nichts zu beanstanden.<\/p>\n

Ja, hier gibt es einige M\u00e4ngel, dort noch einen Mangel \u2013 viele Baustellen, und 1.2 ist wirklich beunruhigend, aber\u2026 Kubernetes ist wie ein im Bau befindliches Geb\u00e4ude \u2013 man sieht das Projekt und versteht, dass es gro\u00dfartig werden wird. Wenn das Geb\u00e4ude jetzt ein Fundament und zwei Stockwerke hat, dann sollte man besser noch nicht einziehen, aber bei der Software gibt es solche Probleme nicht \u2013 man kann sie bereits nutzen.<\/p>\n

Wir hatten keinen Moment, in dem wir dar\u00fcber nachgedacht haben, ob wir Kubernetes verwenden sollten oder nicht. Wir haben darauf gewartet, lange bevor es erschien, und haben versucht, eigene Analogien zu entwickeln.<\/p><\/blockquote>\n

<\/p>\n

\u00dcber Kubernetes<\/h2>\n

\n\u2014 Nehmen Sie direkt an der Entwicklung von Kubernetes teil?<\/b><\/p>\n

Dmitry<\/b>: Indirekt. Wir tragen eher zur Entwicklung des \u00d6kosystems bei. Wir senden eine bestimmte Anzahl von Pull-Requests: in Prometheus, an verschiedene Operatoren, in Helm \u2013 ins \u00d6kosystem. Leider bin ich nicht in der Lage, alles, was wir tun, zu verfolgen und k\u00f6nnte irren, aber von uns gibt es noch keinen einzigen Pull-Request zum Kern.<\/p>\n

\u2014 Entwickeln Sie dabei auch viele eigene Tools rund um Kubernetes?<\/b><\/p>\n

Dmitry<\/b>: Die Strategie ist folgenderma\u00dfen: Wir gehen und erstellen Pull-Requests f\u00fcr alles, was bereits existiert. Wenn Pull-Requests dort nicht angenommen werden, forken wir sie einfach f\u00fcr uns und leben damit, bis sie mit unseren Builds akzeptiert werden. Dann, wenn das bei Upstream ankommt, kehren wir zur Upstream-Version zur\u00fcck.<\/p>\n

Zum Beispiel haben wir den Prometheus-Operator, mit dem wir bereits f\u00fcnfmal hin und her gewechselt sind zwischen unserem Upstream-Build. Wir brauchen ein bestimmtes Feature, wir haben einen Pull-Request geschickt, wir m\u00fcssen es morgen ausrollen, und wir wollen nicht warten, bis es im Upstream ver\u00f6ffentlicht wird. Daher bauen wir uns das selbst und rollen unseren Build mit unserem ben\u00f6tigten Feature auf all unseren Clustern aus. Dann wird das zum Beispiel im Upstream mit den Worten zur\u00fcckgebracht: 'Leute, lasst uns das f\u00fcr einen allgemeineren Fall machen', wir oder jemand anderer machen das fertig, und im Laufe der Zeit wird es wieder zusammengef\u00fchrt.<\/p>\n

Alles, was existiert, streben wir an, weiterzuentwickeln.<\/b>. Viele Elemente, die noch nicht existieren, wurden entweder noch nicht erfunden oder zwar erdacht, aber noch nicht umgesetzt \u2013 und genau das tun wir. Nicht, weil uns der Prozess oder das Fahrradbauen als Branche gef\u00e4llt, sondern einfach, weil wir dieses Werkzeug brauchen. Oft wird die Frage gestellt, warum wir das eine oder andere gemacht haben. Die Antwort ist einfach \u2013 weil wir vorankommen und ein praktisches Problem l\u00f6sen mussten, und wir haben es mit diesem Tool gel\u00f6st.<\/p>\n

Der Weg ist immer der gleiche: Wir suchen sehr gr\u00fcndlich und, wenn wir keine L\u00f6sung finden, wie man aus einem Laib Brot einen Oberleitungsbus macht, dann machen wir unser eigenes Brot und unseren eigenen Oberleitungsbus.<\/p><\/blockquote>\n

<\/p>\n

Die \u201eFlant\u201c-Werkzeuge<\/h2>\n

\n\u2013 Mir ist bekannt, dass es bei \u201eFlant\u201c jetzt Addon-Operatoren, Shell-Operatoren und dapp\/werf-Werkzeuge gibt. Soweit ich verstehe, handelt es sich um dasselbe Werkzeug in verschiedenen Inkarnationen. Auch verstehe ich, dass es innerhalb von \u201eFlant\u201c noch viele verschiedene Werkzeuge gibt. Ist das so?<\/b><\/p>\n

Dmitry<\/b>: Auf unserem GitHub gibt es noch viele weitere Dinge. Unter anderem haben wir statusmap \u2013 ein Dashboard f\u00fcr Grafana, das bei allen gut angekommen ist. Es wird in fast jedem zweiten Artikel \u00fcber das Monitoring von Kubernetes auf Medium erw\u00e4hnt. Es ist schwierig, statusmap kurz zu erkl\u00e4ren \u2013 daf\u00fcr br\u00e4uchte man einen eigenen Artikel, aber es ist ein sehr n\u00fctzliches Tool f\u00fcr die zeitliche Status\u00fcberwachung, da wir in Kubernetes h\u00e4ufig den Status in Echtzeit anzeigen m\u00fcssen. Au\u00dferdem haben wir LogHouse \u2013 ein Tool auf Basis von ClickHouse und ein bisschen Magie zur Log-Erfassung in Kubernetes.<\/p>\n

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

Entwicklung des \u00d6kosystems<\/h2>\n

\n\u2014 Ich denke, das ist ein sehr gro\u00dfer Beitrag zur Entwicklung dieses Werkzeugs und seiner Anwendungsmethoden. Kannst du ungef\u00e4hr absch\u00e4tzen, wer ebenfalls einen solchen Beitrag zur Entwicklung des \u00d6kosystems leisten w\u00fcrde?<\/b><\/p>\n

Dmitry<\/b>: In Russland, von den Unternehmen, die auf unserem Markt t\u00e4tig sind \u2013 niemand kommt auch nur ann\u00e4hernd daran.<\/b>. Nat\u00fcrlich ist das eine gewagte Aussage, denn es gibt gro\u00dfe Akteure wie Mail und Yandex \u2013 sie arbeiten ebenfalls mit Kubernetes, aber selbst sie sind nicht ansatzweise mit dem Beitrag der Unternehmen weltweit vergleichbar, die viel mehr leisten als wir. Es ist schwierig, Flant mit einem Team von 80 Personen mit Red Hat zu vergleichen, bei dem, wenn ich mich nicht irre, allein f\u00fcr Kubernetes 300 Ingenieure arbeiten. Ein Vergleich ist nicht wirklich fair. In unserer R&D-Abteilung haben wir 6 Personen, einschlie\u00dflich mir, die alle unsere Tools entwickeln. 6 Personen im Vergleich zu 300 Ingenieuren bei Red Hat \u2013 das l\u00e4sst sich nur schwer vergleichen.<\/p>\n

\u2013 Dennoch ist es bemerkenswert, dass selbst diese 6 Personen etwas wirklich N\u00fctzliches und \u00dcbertragbares schaffen k\u00f6nnen, wenn sie mit einer praktischen Herausforderung konfrontiert werden und eine L\u00f6sung in die Community einbringen \u2013 das ist ein interessanter Fall. Ich verstehe, dass in gro\u00dfen Technologieunternehmen, in denen es eigene Entwicklungen und Unterst\u00fctzungsteams f\u00fcr Kubernetes gibt, \u00e4hnliche Tools entwickelt werden k\u00f6nnen. Das ist ein Beispiel daf\u00fcr, dass man etwas entwickeln und der Community zur Verf\u00fcgung stellen kann, um der gesamten Kubernetes-Community einen Impuls zu geben.<\/b><\/p>\n

Dmitry<\/b>: Das k\u00f6nnte eine spezielle F\u00e4higkeit des Integrators sein, seine Besonderheit. Wir haben viele Projekte und begegnen unterschiedlichen Situationen. F\u00fcr uns besteht der Hauptweg zur Schaffung von Mehrwert darin, diese F\u00e4lle zu analysieren, das Gemeinsame zu finden und sie f\u00fcr uns m\u00f6glichst kosteng\u00fcnstig zu gestalten. Damit besch\u00e4ftigen wir uns aktiv. Es ist schwierig, \u00fcber Russland und die Welt zu sprechen, aber wir haben etwa 40 DevOps-Ingenieure in unserem Unternehmen, die sich mit Kubernetes besch\u00e4ftigen. Ich glaube nicht, dass es in Russland viele Unternehmen gibt, die mit einer vergleichbaren Anzahl von Fachleuten aufwarten k\u00f6nnen, die sich mit Kubernetes auskennen, falls es sie \u00fcberhaupt gibt.<\/p>\n

Ich verstehe alles \u00fcber den Jobtitel DevOps-Ingenieur, jeder kennt ihn und wir haben uns daran gew\u00f6hnt, DevOps-Ingenieure DevOps-Ingenieuren zu nennen, dar\u00fcber wollen wir nicht diskutieren. Diese 40 gro\u00dfartigen DevOps-Ingenieure stehen t\u00e4glich vor Herausforderungen und l\u00f6sen sie; wir analysieren einfach diese Erfahrungen und versuchen, sie zusammenzufassen. Wir wissen, dass, wenn dieses Wissen bei uns bleibt, das Tool in ein oder zwei Jahren nutzlos wird, weil irgendwo in der Community bereits ein passendes Tool verf\u00fcgbar sein wird. Es macht keinen Sinn, diese Erfahrungen anzusammeln \u2013 es ist einfach eine Verschwendung von Ressourcen und Zeit. Wir nehmen das Risiko jedoch gerne in Kauf. Wir ver\u00f6ffentlichen alles mit gro\u00dfer Freude und verstehen, dass wir es ver\u00f6ffentlichen, weiterentwickeln, bekannt machen und f\u00f6rdern m\u00fcssen, damit die Menschen es nutzen und ihre Erfahrungen einbringen \u2013 dann w\u00e4chst und lebt alles weiter. In zwei Jahren landet das Tool nicht im M\u00fcll. Es ist keine Schande, weiter Ressourcen zu investieren, da man sieht, dass jemand dein Tool nutzt, und in zwei Jahren nutzen es schon alle.<\/p>\n

Das ist Teil unserer gro\u00dfen Strategie mit dapp\/werf<\/b>. Ich kann mich nicht erinnern, wann wir damit angefangen haben, ich glaube, vor etwa 3 Jahren. Urspr\u00fcnglich wurde es \u00fcberhaupt in Shell geschrieben. Es war ein super Prototyp, wir haben einige unserer eigenen Probleme gel\u00f6st \u2013 es hat funktioniert! Aber mit Shell gibt es Probleme, es ist unm\u00f6glich, weiter auszubauen, in Shell zu programmieren ist eine echte Herausforderung. Wir hatten die Gewohnheit, in Ruby zu schreiben, also haben wir etwas umgeschrieben und weiterentwickelt, aber wir sind auf das Problem gesto\u00dfen, dass die Community, die Leute, die nicht sagen \u201ewir wollen oder wollen nicht\u201c, die Nase r\u00fcmpfen, wenn es um Ruby geht, so komisch das auch ist. Wir haben verstanden, dass wir das Ganze in Go schreiben m\u00fcssen, um einfach den ersten Punkt auf der Liste zu erf\u00fcllen: Das DevOps-Tool sollte ein statisches Binary sein<\/b>. Ob in Go oder nicht, das ist nicht so wichtig, aber ein besseres statisches Binary, das in Go geschrieben ist.<\/p>\n

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

Warum wurde dapp erstellt<\/h2>\n

\n\u2014 Kannst du in K\u00fcrze erz\u00e4hlen, warum dapp erstellt wurde, welche Probleme es l\u00f6st?<\/b><\/p>\n

Dmitry<\/b>: Der erste Grund betrifft das Bauen. Zun\u00e4chst hatten wir erhebliche Probleme mit dem Bauen, als Docker das Multi-Stage-Deployment nicht unterst\u00fctzte, und wir mussten es selbst umsetzen. Danach hatten wir eine ganze Reihe von Fragen zur Bereinigung von Images. Jeder, der CI\/CD einrichtet, muss fr\u00fcher oder sp\u00e4ter das Problem l\u00f6sen, dass viele gebaute Images existieren, aus denen wir diejenigen entfernen m\u00fcssen, die nicht ben\u00f6tigt werden, und die benotigen behalten m\u00fcssen.<\/p>\n

Der zweite Grund betrifft das Deployen. Ja, es gibt Helm, aber er l\u00f6st nur einen Teil der Probleme. Komisch, aber wahr, es steht geschrieben, dass \u201eHelm der Paketmanager f\u00fcr Kubernetes\u201c ist. Genau, \u201eder\u201c. Zudem erwarten wir als Nutzer eines \u201ePaketmanagers\u201c in der Regel, dass, wenn wir sagen: \u201ePaket installieren!\u201c, er uns auch mitteilt: \u201ePaket installiert.\u201c <\/p>\n

Interessanterweise sagen wir: \u201eHelm, installiere das Paket\u201c, und wenn er antwortet, dass es installiert wurde, stellt sich heraus, dass er nur den Installationsprozess gestartet hat \u2013 er hat Kubernetes gesagt: \u201eStarte dieses Ding!\u201c, aber ob es tats\u00e4chlich gestartet wurde oder funktioniert, das kl\u00e4rt Helm \u00fcberhaupt nicht.<\/p>\n

Es stellt sich heraus, dass Helm einfach ein textbasierter Preprocessor ist, der Daten in Kubernetes hochl\u00e4dt.<\/p><\/blockquote>\n

\nDoch bei jedem Deployment wollen wir wissen \u2013 ist die Anwendung in Produktion gegangen oder nicht? In Produktion bedeutet, dass die Anwendung dort angekommen ist, eine neue Version bereitgestellt wurde, und sie zumindest nicht ausf\u00e4llt und korrekt reagiert. Helm l\u00f6st dieses Problem nicht. Um es zu l\u00f6sen, m\u00fcssen wir viel Aufwand betreiben, denn wir m\u00fcssen Kubernetes anweisen, die Anwendung bereitzustellen und beobachten, was passiert \u2013 ob es bereitgestellt wurde, ob es ausgerollt wurde. Und es gibt viele Aufgaben im Zusammenhang mit dem Deployment, der Bereinigung und dem Zusammenbau.<\/p>\n

Pl\u00e4ne<\/h2>\n

\nNoch in diesem Jahr werden wir in die lokale Entwicklung gehen. Wir m\u00f6chten zu dem zur\u00fcckkehren, was fr\u00fcher mit Vagrant m\u00f6glich war \u2013 man gab \"vagrant up\" ein und die virtuellen Maschinen wurden gestartet. Wir wollen zu einem Zustand kommen, in dem es ein Projekt in Git gibt, wir dort \"werf up\" eingeben und es eine lokale Kopie dieses Projekts in einem lokalen Mini-Kub hochf\u00e4hrt, mit allen Verzeichnissen, die f\u00fcr die Entwicklung praktisch sind. Je nach Programmiersprache wird dies unterschiedlich umgesetzt, aber dennoch soll es bequem sein, die lokale Entwicklung mit eingebundenen Dateien fortzuf\u00fchren.<\/p>\n

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

Der Weg zu dapp\/werf war schon immer der gleiche wie der Anfang mit Kubernetes. Wir sind auf Probleme gesto\u00dfen und haben sie mit Umgehungsl\u00f6sungen gel\u00f6st \u2013 wir haben uns irgendwelche L\u00f6sungen auf Shell \u00fcberlegt, auf was auch immer. Dann haben wir versucht, diese Umgehungsl\u00f6sungen zu straffen, zu verallgemeinern und in Bin\u00e4rdateien zu konsolidieren, die wir dann einfach teilen.<\/p>\n

Es gibt auch eine andere Sichtweise auf diese ganze Geschichte, mit Analogien. <\/p>\n

Kubernetes ist das Chassis eines Autos mit Motor. Es gibt keine T\u00fcren, keine Fenster, kein Radio, keinen Duftbaum \u2013 \u00fcberhaupt nichts. Nur das Gestell und der Motor. Und da ist Helm \u2013 das ist das Lenkrad. Cool \u2013 es gibt ein Lenkrad, aber wir brauchen auch eine Lenks\u00e4ule, eine Lenkung, ein Getriebe und R\u00e4der, und ohne die geht es nicht.<\/p><\/blockquote>\n

\nIm Fall von werf handelt es sich um einen weiteren Bestandteil von Kubernetes. Aktuell haben wir eine Alpha-Version von werf, in der Helm beispielsweise vollst\u00e4ndig in werf integriert ist, weil wir keine Lust mehr haben, dies selbst zu tun. Es gibt viele Gr\u00fcnde daf\u00fcr, weshalb wir Helm zusammen mit Tiller in werf integriert haben, und ich werde das ausf\u00fchrlich erl\u00e4utern. bei dem Vortrag auf RIT++<\/a><\/noindex>.<\/p>\n

Jetzt ist werf ein deutlich integrierteres Modul. Wir haben ein fertiges Steuerrad, einen Steuerstift \u2013 ich bin kein gro\u00dfer Autoexperte, aber das ist ein gro\u00dfes Modul, das bereits ein breites Spektrum an Aufgaben l\u00f6st. Wir m\u00fcssen nicht selbst durch den Katalog bl\u00e4ttern, um ein Teil zum anderen zu finden und dar\u00fcber nachdenken, wie man sie verbindet. Wir erhalten einen kompletten Kombi, der auf einmal eine Vielzahl von Aufgaben bew\u00e4ltigt. Intern besteht es aus denselben Open-Source-Komponenten, nutzt Docker f\u00fcr den Build, Helm f\u00fcr einen Teil der Funktionalit\u00e4t und hat auch noch einige andere Bibliotheken. Es ist ein integriertes Tool, um schnell und einfach eine gro\u00dfartige CI\/CD-L\u00f6sung direkt aus der Box zu erhalten.<\/p>\n

Ist es schwierig, Kubernetes zu unterst\u00fctzen?<\/h2>\n

\n\u2014 Sie sprechen \u00fcber Ihre Erfahrungen mit Kubernetes, das f\u00fcr Sie wie ein Chassis oder Motor ist, an dem man viele verschiedene Komponenten anbringen kann: Karosserie, Lenkrad, Pedale, Sitze. Die Frage ist: Wie schwierig ist es f\u00fcr Sie, Kubernetes zu verwalten? Sie haben umfangreiche Erfahrungen, wie viel Zeit und Ressourcen verwenden Sie spezifisch f\u00fcr die Verwaltung von Kubernetes im Vergleich zu anderen Aufgaben?<\/b><\/p>\n

Dmitry<\/b>: Das ist eine sehr komplexe Frage, und um sie zu beantworten, m\u00fcssen wir verstehen, was wir unter Verwaltung verstehen und was wir von Kubernetes erwarten. K\u00f6nnten Sie das n\u00e4her erl\u00e4utern?<\/p>\n

\u2014 Soweit ich wei\u00df und das, was ich beobachte, wollen viele Teams Kubernetes ausprobieren. Alle setzen es hastig auf, einfach mal schnell. Ich habe das Gef\u00fchl, dass die Leute nicht immer die Komplexit\u00e4t dieses Systems verstehen.<\/b><\/p>\n

Dmitry<\/b>: Das stimmt.<\/p>\n

\u2014 Wie schwierig ist es, Kubernetes von Grund auf zu installieren, sodass es produktionsbereit ist?<\/b><\/p>\n

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

Kubernetes zu installieren und zum Laufen zu bringen ist einfach: Klick! \u2014 schon installiert, es gibt viele Installationsmethoden. Aber was passiert, wenn Probleme auftreten?<\/p><\/blockquote>\n

\nEs tauchen immer Fragen auf \u2014 was haben wir noch nicht ber\u00fccksichtigt? Was haben wir noch nicht getan? Welche Parameter des Linux-Kernels haben wir falsch angegeben? Oh Gott, haben wir sie \u00fcberhaupt angegeben?! Welche Komponenten von Kubernetes haben wir installiert und welche nicht? Tausende von Fragen entstehen, und um sie zu beantworten, braucht man 15-20 Jahre Erfahrung in dieser Branche.<\/p>\n

Ich habe ein aktuelles Beispiel zu diesem Thema, das die Essenz der Frage \u201aIst es schwierig, Kubernetes zu warten?\u2018 beleuchten kann. Vor einiger Zeit haben wir ernsthaft in Betracht gezogen, Cilium als Netzwerk f\u00fcr Kubernetes einzuf\u00fchren.<\/p>\n

Ich erkl\u00e4re, was Cilium ist. In Kubernetes gibt es viele verschiedene Implementierungen des Netzwerk-Subsystems, und eine davon ist wirklich gro\u00dfartig \u2014 das ist Cilium. Worauf basiert es? Vor einiger Zeit wurden im Kernel Hooks eingef\u00fchrt, die in das Netzwerk-Subsystem und andere Subsysteme eingreifen k\u00f6nnen und es erm\u00f6glichen, gro\u00dfe Teile des Kernels zu umgehen.<\/p>\n

Im Linux-Kernel gibt es historisch gesehen ip rout, Netfilter, Br\u00fccken und viele verschiedene alte Komponenten, die 15, 20 oder sogar 30 Jahre alt sind. Im Gro\u00dfen und Ganzen funktionieren sie gut, alles ist klasse, aber jetzt gibt es viele Container, und das sieht aus wie ein Turm aus 15 Ziegeln, auf dem du auf einem Bein stehst \u2013 ein seltsames Gef\u00fchl. Dieses System hat sich historisch mit vielen Nuancen entwickelt, \u00e4hnlich einem Appendix im K\u00f6rper. In einigen Situationen gibt es Performance-Probleme, zum Beispiel.<\/p>\n

Es gibt ein beeindruckendes BPF und die M\u00f6glichkeit, Hooks f\u00fcr den Kernel zu schreiben \u2013 die Leute haben ihre eigenen Hooks f\u00fcr den Kernel geschrieben. Ein Paket kommt in den Linux-Kernel, sie ziehen es direkt am Eingang heraus, verarbeiten es nach ihren Bed\u00fcrfnissen, ohne Br\u00fccken, ohne TCP, ohne IP-Stack \u2013 kurz gesagt, komplett um alles herum, was im Linux-Kernel geschrieben ist, und spucken es sofort in den Container aus.<\/p>\n

Was ist daraus geworden? Eine sehr gute Performance, tolle Features \u2013 einfach gro\u00dfartig! Aber wir sehen, dass auf jeder Maschine ein Programm l\u00e4uft, das sich mit dem Kubernetes-API verbindet und basierend auf den Daten, die es von dieser API erh\u00e4lt, C-Code generiert und Bin\u00e4rdateien kompiliert, die im Kernel geladen werden, damit diese Hooks im Kernel-Space funktionieren.<\/p>\n

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

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

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

Wenn wir dar\u00fcber sprechen, ob es schwierig ist, Kubernetes zu unterst\u00fctzen \u2013 die Antwort ist: Nein, es ist sehr einfach, und ja, es ist unglaublich kompliziert. Kubernetes funktioniert f\u00fcr sich allein hervorragend, aber es gibt eine Billion Nuancen.<\/p><\/blockquote>\n

<\/p>\n

Zur Philosophie \"Mir wird schon alles gelingen\"<\/h2>\n

\nGibt es Unternehmen, in denen diese Nuancen fast garantiert auftreten? Stellen wir uns vor, Yandex w\u00fcrde pl\u00f6tzlich alle Dienste auf Kubernetes umstellen \u2013 das w\u00e4re eine gewaltige Belastung.<\/b><\/p>\n

Dmitry<\/b>Das ist nicht das Thema der Belastung, sondern der grundlegendsten Dinge. Zum Beispiel haben wir Kubernetes und haben eine Anwendung dort bereitgestellt. Wie k\u00f6nnen wir sicherstellen, dass sie funktioniert? Es gibt kein fertiges Tool, um herauszufinden, ob die Anwendung stabil l\u00e4uft. Ein fertiges System, das Alarme sendet, gibt es nicht \u2013 Sie m\u00fcssen diese Alarme und jeden einzelnen Graphen einrichten. Und wir sind dabei, Kubernetes zu aktualisieren.<\/p>\n

Wir verwenden Ubuntu 16.04. Man k\u00f6nnte sagen, dass das eine \u00e4ltere Version ist, aber wir nutzen sie weiterhin, weil es sich um eine LTS-Version handelt. Sie enth\u00e4lt systemd, dessen Besonderheit darin besteht, dass es die C-Gruppen nicht bereinigt. Kubernetes startet Pods, erstellt C-Gruppen, und wenn die Pods gel\u00f6scht werden, bleibt irgendwie etwas von systemd \u00fcbrig \u2013 ich erinnere mich nicht an die Einzelheiten, entschuldigen Sie bitte \u2013, was dazu f\u00fchrt, dass im Laufe der Zeit jede Maschine stark langsamer wird. Das ist nicht einmal eine Frage des Hochlastbetriebs. Wenn st\u00e4ndig Pods gestartet werden, zum Beispiel wenn es einen Cron-Job gibt, der kontinuierlich Pods generiert, wird eine Maschine mit Ubuntu 16.04 nach einer Woche langsam werden. Es wird st\u00e4ndig eine hohe mittlere Last geben, weil eine Menge C-Gruppen erstellt wurden. Das ist ein Problem, mit dem jeder konfrontiert ist, der einfach Ubuntu 16 installiert und Kubernetes dar\u00fcber setzt.<\/p>\n

Angenommen, er aktualisiert irgendwie systemd oder etwas anderes, aber im Linux-Kernel bis zur Version 4.16 ist es noch absurder \u2013 beim L\u00f6schen von C-Gruppen treten sie im Kernel wieder auf und werden tats\u00e4chlich nicht entfernt. Nach einem Monat Betrieb mit dieser Maschine ist es unm\u00f6glich, Statistiken zu RAM bei den Pods zu sehen. Wir holen eine Datei heraus, testen sie im Programm, und eine Datei ben\u00f6tigt 15 Sekunden, weil das Kernel sehr lange braucht, um intern mit Millionen von C-Gruppen zu rechnen, die angeblich gel\u00f6scht sind, aber nicht \u2013 sie bleiben bestehen.<\/p>\n

Es gibt immer noch viele solcher Kleinigkeiten da und dort. Das ist kein Problem, mit dem gro\u00dfe Unternehmen manchmal bei sehr hohen Belastungen konfrontiert werden k\u00f6nnen \u2013 nein, es ist eine Frage des t\u00e4glichen Lebens. Menschen k\u00f6nnen monatelang so leben \u2013 sie haben Kubernetes installiert, eine Anwendung bereitgestellt \u2013 es scheint zu funktionieren. F\u00fcr viele ist das in Ordnung. Sie erfahren nicht einmal, dass diese Anwendung irgendwann aus irgendeinem Grund ausf\u00e4llt; ein Alarm kommt nicht, aber f\u00fcr sie ist das normal. Fr\u00fcher lebten sie auf virtuellen Maschinen ohne \u00dcberwachung, jetzt sind sie auch ohne \u00dcberwachung in Kubernetes umgezogen \u2013 wo ist der Unterschied?<\/p>\n

Die Frage ist, dass wir, wenn wir \u00fcber das Eis gehen, nie wissen, wie dick es ist, wenn wir es nicht im Voraus gemessen haben. Viele gehen einfach und machen sich keinen Kopf dar\u00fcber, weil sie es schon fr\u00fcher gemacht haben.<\/p>\n

Aus meiner Sicht besteht die Nuance und Komplexit\u00e4t im Betrieb eines Systems darin, sicherzustellen, dass die Dicke des Eises genau ausreicht, um unsere Anforderungen zu erf\u00fcllen. Darum geht es.<\/p><\/blockquote>\n

\nIm IT-Bereich gibt es, meiner Meinung nach, zu viele Ans\u00e4tze mit dem Motto \u201eMir wird schon Gl\u00fcck zuteil\u201c. Viele installieren Software und nutzen Programmierbibliotheken in der Hoffnung, dass sie Erfolg haben. Insgesamt haben viele tats\u00e4chlich Gl\u00fcck. Wahrscheinlich funktioniert es deshalb.<\/p>\n

\u2014 Aus meiner pessimistischen Perspektive sieht es so aus: Wenn die Risiken hoch sind und die Anwendung laufen muss, dann ist Unterst\u00fctzung von \u201aFlant\u2018 notwendig, wom\u00f6glich von Red Hat, oder es wird ein eigenes internes Team ben\u00f6tigt, das speziell f\u00fcr Kubernetes zust\u00e4ndig ist und bereit ist, es zu betreuen.<\/b><\/p>\n

Dmitry<\/b>: Objektiv betrachtet ist das so. Sich als kleines Team selbst in die Kubernetes-Thematik einzuarbeiten, birgt einige Risiken.<\/p>\n

Brauchen wir Container?<\/h2>\n

\n\u2014 Kannst du mir erz\u00e4hlen, wie verbreitet Kubernetes \u00fcberhaupt in Russland ist?<\/b><\/p>\n

Dmitry<\/b>: Ich habe diese Daten nicht und bin mir nicht sicher, ob sie \u00fcberhaupt jemand hat. Wir reden \u00fcber: \u201eKubernetes, Kubernetes\u201c, aber es gibt ja auch eine andere Sichtweise zu diesem Thema. Wie verbreitet Container sind, wei\u00df ich ebenfalls nicht, aber ich kenne die Zahl aus Berichten im Internet, dass 70 % der Container von Kubernetes orchestriert werden. Das war eine verl\u00e4ssliche Quelle auf einer ausreichend gro\u00dfen Stichprobe weltweit.<\/p>\n

Eine weitere Frage ist - brauchen wir Container?<\/b> Mein pers\u00f6nliches Empfinden und insgesamt die Position des Unternehmens \u201aFlant\u2018 ist, dass Kubernetes der De-facto-Standard ist.<\/p>\n

Nichts au\u00dfer Kubernetes wird es geben.<\/p><\/blockquote>\n

\nDas ist ein absoluter Game-Changer im Bereich Infrastrukturmanagement. Einfach absolut - Schluss mit Ansible, Chef, virtuellen Maschinen, Terraform. Ich spreche schon gar nicht mehr \u00fcber die alten, veralteten Methoden. Kubernetes ist der absolute Changer<\/b>, und jetzt wird es nur noch so sein.<\/p>\n

Es ist klar, dass einige Jahre n\u00f6tig sind, um das zu erkennen, w\u00e4hrend andere Jahrzehnte brauchen. Ich habe keine Zweifel, dass es nichts geben wird au\u00dfer Kubernetes und dieser neuen Sichtweise: Wir greifen nicht mehr auf das Betriebssystem zu, sondern nutzen infrastructure as code<\/b>, allerdings nicht mit Code, sondern mit YML - einer deklarativ beschriebenen Infrastruktur. Ich habe das Gef\u00fchl, dass es immer so sein wird.<\/p>\n

Das bedeutet, dass die Unternehmen, die noch nicht auf Kubernetes umgestiegen sind, entweder auf Kubernetes wechseln oder in Vergessenheit geraten werden. Habe ich dich richtig verstanden?<\/b><\/p>\n

Dmitry<\/b>Das ist auch nicht ganz korrekt. Wenn wir zum Beispiel einen DNS-Server betreiben m\u00f6chten, k\u00f6nnen wir ihn auf FreeBSD 4.10 installieren und er kann 20 Jahre lang hervorragend funktionieren. Einfach nur funktionieren, und das war's. Vielleicht muss nach 20 Jahren einmal etwas aktualisiert werden. Wenn wir \u00fcber Software sprechen, die wir in einem Zustand gestartet haben und die viele Jahre ohne irgendwelche Updates oder \u00c4nderungen funktioniert, dann wird Kubernetes dort sicherlich nicht ben\u00f6tigt. Es ist einfach nicht notwendig.<\/p>\n

Alles, was CI\/CD betrifft \u2013 \u00fcberall dort, wo Continuous Delivery erforderlich ist, wo Versionsupdates notwendig sind, wo aktive \u00c4nderungen vorgenommen werden m\u00fcssen, wo Ausfallsicherheit aufgebaut werden muss \u2013 ist Kubernetes unerl\u00e4sslich.<\/p><\/blockquote>\n

<\/p>\n

\u00dcber Mikrodienste<\/h2>\n

\n\u2014 Hier habe ich ein kleines Dissonanzgef\u00fchl. Um mit Kubernetes zu arbeiten, braucht man externe oder interne Unterst\u00fctzung \u2013 das ist der erste Punkt. Der zweite \u2013 wenn wir gerade erst mit der Entwicklung beginnen, sind wir ein kleines Start-up, wir haben noch nichts, und die Entwicklung f\u00fcr Kubernetes oder \u00fcberhaupt f\u00fcr eine Microservices-Architektur kann herausfordernd und nicht immer wirtschaftlich sinnvoll sein. Ich bin gespannt auf deine Meinung \u2013 sollten Start-ups von Anfang an direkt f\u00fcr Kubernetes entwickeln, oder ist es besser, zuerst ein Monolith zu erstellen und sp\u00e4ter zu Kubernetes zu wechseln?<\/b><\/p>\n

Dmitry<\/b>: Gute Frage. Ich habe einen Vortrag \u00fcber Microservices. \u201eMicroservices: Die Gr\u00f6\u00dfe macht den Unterschied\u201c.<\/a><\/noindex> Ich habe oft erlebt, dass Leute versuchen, mit einem Mikroskop N\u00e4gel einzuschlagen. Der Ansatz an sich ist richtig, wir gestalten unsere interne Software tats\u00e4chlich auf diese Weise. Aber wenn man das macht, muss man genau wissen, was man tut. Was ich an Microservices am meisten hasse, ist das Wort \u201emicro\u201c. Historisch hat sich dieses Wort entwickelt, und aus irgendeinem Grund denken die Leute, dass mikro sehr klein ist, kleiner als ein Millimeter, wie ein Mikrometer. Das ist nicht richtig.<\/p>\n

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

Es scheint, als w\u00e4re dar\u00fcber schon tausend Mal gesprochen worden - wir haben einen verteilten Monolithen in der einen oder anderen Form. Das ist wirtschaftlich nicht tragbar und \u00e4u\u00dferst kompliziert. Ich habe es einfach so oft gesehen, dass es mir schmerzt, weshalb ich weiter dar\u00fcber spreche.<\/p>\n

Zur eingangs gestellten Frage: Es gibt einen Konflikt zwischen der Tatsache, dass Kubernetes furchtbar schwer zu nutzen ist, weil unklar bleibt, was dort kaputtgehen oder nicht funktionieren k\u00f6nnte, und der Erkenntnis, dass der gesamte Trend dorthin geht und nichts anderes als Kubernetes sein wird. Die Antwort ist - den Nutzen, der entsteht, und das Volumen der Aufgaben, die Sie l\u00f6sen k\u00f6nnen, abzuw\u00e4gen.<\/b>. Dies ist die eine Seite der Waagschale. Auf der anderen Seite stehen die Risiken, die mit Ausfallzeiten oder l\u00e4ngeren Reaktionszeiten und Verf\u00fcgbarkeitsproblemen verbunden sind \u2013 ein R\u00fcckgang der Leistungskennzahlen.<\/p>\n

Hier ist es so \u2013 entweder wir bewegen uns schnell, und Kubernetes erm\u00f6glicht viele Dinge viel schneller und besser, oder wir ziehen zuverl\u00e4ssige, bew\u00e4hrte L\u00f6sungen vor, bewegen uns aber deutlich langsamer. Diese Entscheidung muss jedes Unternehmen treffen. Man kann das als einen Pfad im Dschungel betrachten \u2013 wenn man das erste Mal geht, kann man einer Schlange, einem Tiger oder einem wilden Dachs begegnen, und nach dem zehnten Mal ist der Weg klarer \u2013 man hat den Pfad geebnet, \u00c4ste entfernt und es wird einfacher. Mit jedem Mal wird der Pfad breiter. Schlie\u00dflich wird es zu einer asphaltierten Stra\u00dfe und sp\u00e4ter zu einem sch\u00f6nen Boulevard.<\/p>\n

Kubernetes entwickelt sich st\u00e4ndig weiter. Die Frage bleibt: Ist Kubernetes, auf der einen Seite, nur eine Ansammlung von 4-5 Bin\u00e4rdateien, oder ist es auf der anderen Seite eine umfassende Ecosystem? Es ist ein Betriebssystem, das auf unseren Maschinen l\u00e4uft. Was ist es genau? Ubuntu oder Curios? Es basiert auf dem Linux-Kernel, erg\u00e4nzt durch zahlreiche Komponenten. W\u00e4hrend hier eine giftige Schlange von der Stra\u00dfe verbannt wurde und ein Zaun errichtet wurde, entwickelt sich Kubernetes sehr schnell und dynamisch. Mit jedem Monat verringert sich das Risiko und das Unbekannte, wodurch die Balance sich allm\u00e4hlich verschiebt.<\/p>\n

Wenn ich auf die Frage antworte, was ein Startup tun sollte, w\u00fcrde ich sagen: Kommen Sie zu \"Flant\", zahlen Sie 150.000 Rubel und erhalten Sie einen schl\u00fcsselfertigen DevOps-Service. Wenn Sie ein kleines Team von Entwicklern sind, funktioniert das. Anstatt einen eigenen DevOps-Mitarbeiter einzustellen, der lernen muss, Ihre Probleme zu l\u00f6sen, und w\u00e4hrend dieser Zeit Gehalt zu kosten, erhalten Sie eine schl\u00fcsselfertige L\u00f6sung f\u00fcr alle Ihre Anliegen. Ja, es gibt einige Nachteile. Als Outsourcing-Anbieter k\u00f6nnen wir nicht so engagiert sein und schnell auf \u00c4nderungen reagieren. Aber wir haben daf\u00fcr jede Menge Expertise und bew\u00e4hrte Praktiken. Wir garantieren, dass wir in jeder Situation schnell reagieren und jedes Kubernetes Problem l\u00f6sen k\u00f6nnen. <\/p>\n

Ich empfehle Outsourcing f\u00fcr Startups und etablierte Unternehmen kategorisch bis zu dem Punkt, an dem Sie ein Team von 10 Personen f\u00fcr den Betrieb bereitstellen k\u00f6nnen, denn anders macht es keinen Sinn. Es ist absolut sinnvoll, auszulagern.<\/p><\/blockquote>\n

<\/p>\n

\u00dcber Amazon und Google<\/h2>\n

\nKann man Hosting-L\u00f6sungen von Amazon oder Google als Outsourcing betrachten?<\/b><\/p>\n

Dmitry<\/b>: Ja, das l\u00f6st selbstverst\u00e4ndlich einige Fragen. Aber es gibt wieder Nuancen. Man muss dennoch verstehen, wie man das anwendet. Zum Beispiel gibt es eine Vielzahl von Details bei der Arbeit mit Amazon AWS: Den Load Balancer muss man aufw\u00e4rmen oder im Voraus eine Anfrage stellen: \u201eLeute, wir erwarten Traffic, bitte w\u00e4rmt unseren Load Balancer auf!\u201c Diese Nuancen sollte man kennen.<\/p>\n

Wenn Sie sich an Fachleute wenden, die in diesem Bereich spezialisiert sind, erhalten Sie fast alle typischen Dinge fixiert. Wir haben derzeit 40 Ingenieure, und bis zum Ende des Jahres werden es wahrscheinlich 60 sein \u2013 wir sind bereits mit all diesen Themen konfrontiert gewesen. Selbst wenn wir in einem bestimmten Projekt erneut auf dieses Problem sto\u00dfen, fragen wir uns schnell untereinander und wissen bereits, wie wir es l\u00f6sen k\u00f6nnen.<\/p>\n

Wahrscheinlich lautet die Antwort: Ja, die Hosted-L\u00f6sung erleichtert einen Teil davon. Die Frage ist, ob Sie diesen Hostern vertrauen k\u00f6nnen und ob sie Ihre Probleme l\u00f6sen werden. Amazon und Google haben sich gut bew\u00e4hrt. In all unseren F\u00e4llen \u2013 definitiv. Weitere positive Erfahrungen haben wir nicht gemacht. Alle anderen Clouds, mit denen wir versucht haben zu arbeiten, verursachen viele Probleme \u2013 sowohl Ager als auch alles, was es in Russland gibt, und diverse OpenStack-Implementierungen: Headster, Overage \u2013 alles, was Sie wollen. Sie alle erzeugen Schwierigkeiten, die man nicht l\u00f6sen m\u00f6chte.<\/p>\n

Deshalb ist die Antwort: Ja, aber tats\u00e4chlich gibt es nicht viele ausgereifte Hosted-L\u00f6sungen.<\/p>\n

Wer braucht Kubernetes?<\/h2>\n

\nAber wer braucht Kubernetes wirklich? Wer sollte bereits auf Kubernetes umsteigen, wer ist der typische Kunde von \"Flanta\", der genau f\u00fcr Kubernetes kommt?<\/b><\/p>\n

Dmitry<\/b>: Eine interessante Frage, denn gerade jetzt, im Zuge des Kubernetes-Trends, kommen viele zu uns: \u201eLeute, wir wissen, dass ihr Kubernetes macht \u2013 macht es f\u00fcr uns!\u201c Unsere Antwort darauf: \u201eMeine Damen und Herren, wir bieten kein Kubernetes an, wir bieten Produktionsl\u00f6sungen und alles, was damit zusammenh\u00e4ngt.\u201c Denn ein Produktionssystem einzurichten, ohne dabei die gesamte CI\/CD-Pipeline und all diese Dinge zu ber\u00fccksichtigen, ist heutzutage einfach unm\u00f6glich. Jeder hat Abstand davon genommen, Entwicklung und Betrieb strikt zu trennen.<\/p>\n

Unsere Kunden haben unterschiedliche Erwartungen, aber alle hoffen auf ein gewisses Wunder, dass sie Probleme haben und dass jetzt \u2013 schwupp! \u2013 Kubernetes sie l\u00f6sen wird. Die Leute glauben an Wunder. Sie verstehen mit dem Verstand, dass es kein Wunder geben wird, haben aber tief im Herzen die Hoffnung, dass Kubernetes jetzt alles f\u00fcr uns l\u00f6st, \u00fcber das so viel gesprochen wird! Vielleicht ist es jetzt \u2013 huch! \u2013 die silberne Kugel, huch! \u2013 und wir haben 100% Uptime, alle Entwickler k\u00f6nnen 50 Mal willk\u00fcrlich etwas in die Produktion bringen, und es f\u00e4llt nicht aus. Kurz gesagt, ein Wunder!<\/p>\n

Wenn solche Menschen zu uns kommen, sagen wir: \u201eEntschuldigung, aber Wunder gibt es nicht.\u201c Um gesund zu sein, muss man sich gut ern\u00e4hren und Sport treiben. Um eine zuverl\u00e4ssige Produktionsumgebung zu haben, muss man sie zuverl\u00e4ssig aufbauen. Um eine komfortable CI\/CD-Pipeline zu haben, muss man sie entsprechend gestalten. Das erfordert viel Arbeit.<\/p>\n

Bez\u00fcglich der Frage, wer Kubernetes ben\u00f6tigt \u2013 niemand ben\u00f6tigt Kubernetes.<\/p><\/blockquote>\n

\nEinige Menschen haben das falsche Gef\u00fchl, dass sie Kubernetes brauchen. Was sie wirklich brauchen, ist der tiefgreifende Wunsch, sich nicht mehr mit allen Infrastrukturproblemen und dem Start ihrer Anwendungen auseinandersetzen zu m\u00fcssen. Sie wollen, dass ihre Anwendungen einfach funktionieren und ohne Probleme bereitgestellt werden. F\u00fcr sie ist Kubernetes die Hoffnung, dass sie nicht mehr h\u00f6ren m\u00fcssen, dass \u201ewir irgendwo stecken geblieben sind\u201c oder \u201enicht ausrollen k\u00f6nnen\u201c oder etwas \u00c4hnliches.<\/p>\n

In der Regel kommt der technische Direktor zu uns. Von ihm werden zwei Dinge erwartet: Einerseits die neuen Funktionen, andererseits die Stabilit\u00e4t. Wir bieten an, das f\u00fcr Sie zu \u00fcbernehmen. Der Schl\u00fcssel liegt darin, dass Sie nicht mehr \u00fcber diese Probleme nachdenken und Zeit verschwenden m\u00fcssen. Sie haben spezielle Personen, die sich um diese Fragen k\u00fcmmern.<\/p>\n

Die Aussage, dass wir oder jemand anderes Kubernetes ben\u00f6tigen, ist falsch.<\/p><\/blockquote>\n

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

Spielen Sie nicht mit dem Produktionssystem. Was ich kategorisch nicht empfehlen w\u00fcrde und was ich gerade massenhaft sehe: \u201eOh, ein neues Spielzeug!\u201c \u2013 dann laufen alle los, um es zu kaufen, kaufen es und: \u201eLass uns das jetzt in die Schule mitnehmen, um es allen Freunden zu zeigen.\u201c Machen Sie das nicht. Entschuldigung, ich habe einfach Kinder, die aufwachsen, und ich sehe st\u00e4ndig etwas bei den Kindern, nehme es bei mir wahr und verallgemeinere das dann auf andere.<\/p>\n

Die endg\u00fcltige Antwort: Kubernetes ist nicht erforderlich. Sie m\u00fcssen Ihre Probleme l\u00f6sen.<\/p><\/blockquote>\n

\nErreichen kann man Folgendes:<\/p>\n