{"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":"Kubernetes wird die Welt erobern. Wann und wie?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im Vorfeld DevOpsConf<\/a><\/noindex> Vitaly Chabarov<\/b> f\u00fchrte ein Interview mit\u00a0Dmitry Stolyarov<\/b> (distol<\/a><\/noindex>), dem technischen Direktor und Mitgr\u00fcnder von \"Flant\". Vitaly befragte Dmitry \u00fcber die Aktivit\u00e4ten von \"Flant\", \u00fcber Kubernetes, die Entwicklung des \u00d6kosystems und die Unterst\u00fctzung. Sie diskutierten, warum Kubernetes ben\u00f6tigt wird und ob es \u00fcberhaupt notwendig ist. Und auch \u00fcber Mikrodienste, Amazon AWS, die \u201eMir wird schon alles gelingen\u201c-Mentalit\u00e4t 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\u00f6nnen.<\/p>\n

Das Originalinterview<\/a><\/noindex> in Form eines Podcasts h\u00f6ren Sie auf DevOps Deflop, dem russischsprachigen Podcast \u00fcber DevOps, und unten finden Sie die texliche Version. <\/p>\n

\"Kubernetes
\n
\nHier und im Folgenden stellt Vitaly Chabarov<\/a><\/noindex> ein Ingenieur von Express42 die Fragen.
\n<\/a><\/noindex><\/p>\n

\u00dcber \"Flant\"<\/h2>\n

\n\u2014 Dima, hallo. Du bist der technische Direktor von \"Flant<\/a><\/noindex>\" und auch Gr\u00fcnder. Erz\u00e4hl bitte, womit sich die Firma befasst und welche Rolle du dabei spielst.<\/b><\/p>\n

\"KubernetesDmitry<\/b>: Von au\u00dfen sieht es so aus, als w\u00e4ren 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\u00e4ftigt, aber schon vor sehr langer Zeit wurde unsere Hauptt\u00e4tigkeit die Betreuung von Produktions- und Highload-Projekten aus einer Hand. Normalerweise bauen wir die gesamte Infrastruktur von Grund auf und sind dann lange daf\u00fcr verantwortlich. Daher ist die Hauptarbeit, die \"Flant\" leistet und wof\u00fcr wir bezahlt werden, die \u00dcbernahme von Verantwortung und die Umsetzung von Produktionssystemen aus einer Hand.<\/b>.
\n

\n

\nIch, als technischer Direktor und einer der Mitbegr\u00fcnder der Firma, besch\u00e4ftige mich Tag und Nacht damit, mir zu \u00fcberlegen, wie wir die Verf\u00fcgbarkeit von Produktionssystemen erh\u00f6hen, deren Betrieb vereinfachen, das Leben der Administratoren erleichtern und das Leben der Entwickler angenehmer gestalten k\u00f6nnen.<\/p>\n

\u00dcber Kubernetes<\/h2>\n

\n\u2014 In letzter Zeit habe ich viele Vortr\u00e4ge von \"Flant\" gesehen,\u00a0Artikel<\/a><\/noindex> die \u00fcber Kubernetes handeln. Wie seid ihr zu ihm gekommen?<\/b><\/p>\n

Dmitry<\/b>: Ich habe dar\u00fcber schon viele Male gesprochen, aber ich habe nichts dagegen, es zu wiederholen. Ich halte es f\u00fcr richtig, dieses Thema zu wiederholen, da oft Verwirrung zwischen Ursache und Wirkung entsteht.<\/p>\n

Wir ben\u00f6tigten dringend ein Tool. Wir hatten mit einer Vielzahl von Problemen zu k\u00e4mpfen, sie mit verschiedenen Notl\u00f6sungen \u00fcberwunden und ben\u00f6tigten ein Werkzeug. Wir haben viele verschiedene Optionen durchdacht, unsere eigenen Dinge erstellt und Erfahrungen gesammelt. Allm\u00e4hlich kamen wir dazu, Docker fast sofort nach seinem Erscheinen zu nutzen \u2013 etwa 2013. Zu diesem Zeitpunkt hatten wir bereits viel Erfahrung mit Containern und hatten eine Art 'Docker' selbst geschrieben \u2013 einige unserer eigenen Notl\u00f6sungen in Python. Mit dem Erscheinen von Docker erhielten wir die M\u00f6glichkeit, die Notl\u00f6sungen wegzuwerfen und eine zuverl\u00e4ssige und von der Community unterst\u00fctzte L\u00f6sung zu verwenden.<\/p>\n

Die Geschichte mit Kubernetes ist \u00e4hnlich. Zu dem Zeitpunkt, als es an Fahrt gewann \u2013 f\u00fcr uns Version 1.2 \u2013 hatten wir bereits viele Notl\u00f6sungen auf Shell- und Chef-Basis, mit denen wir versuchten, Docker zu orchestrieren. Wir hatten ernsthaft in Richtung Rancher und andere L\u00f6sungen geschaut, aber dann tauchte Kubernetes auf, in dem alles genau so umgesetzt ist, wie wir es gemacht h\u00e4tten, oder sogar besser. Da gibt es nichts zu beanstanden.<\/p>\n

Ja, hier gibt es einige Unvollkommenheiten, dort gibt es einige Unvollkommenheiten \u2013 viele M\u00e4ngel, und 1.2 ist wirklich schrecklich, aber... Kubernetes ist wie ein im Bau befindliches Geb\u00e4ude \u2013 man schaut sich das Projekt an und versteht, dass es gro\u00dfartig werden wird. Wenn das Geb\u00e4ude jetzt ein Fundament und zwei Etagen hat, dann versteht man, dass man besser noch nicht einziehen sollte, aber mit der Software gibt es solche Probleme nicht \u2013 sie ist bereits nutzbar.<\/p>\n

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.<\/p><\/blockquote>\n

<\/p>\n

\u00dcber Kubernetes<\/h2>\n

\n\u2014 Beteiligen Sie sich direkt an der Entwicklung von Kubernetes selbst?<\/b><\/p>\n

Dmitry<\/b>: Indirekt. Eher tragen wir zur Entwicklung des \u00d6kosystems bei. Wir senden eine gewisse Anzahl von Pull-Requests: zu Prometheus, zu verschiedenen Operatoren, zu Helm \u2013 zum \u00d6kosystem. Leider kann ich nicht alles verfolgen, was wir tun, und ich kann mich irren, aber von uns gibt es keinen einzigen Pool ins Kernel.<\/p>\n

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

Dmitry<\/b>: 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\u00fcr uns und leben, bis sie mit unseren Builds akzeptiert werden. Dann, wenn dies die Upstream-Version erreicht, kehren wir zur\u00fcck zur Upstream-Version.<\/p>\n

Zum Beispiel haben wir den Prometheus-Operator, mit dem wir schon f\u00fcnfmal zwischen unserem Upstream-Build hin und her gewechselt haben. Wir brauchen eine bestimmte Funktion, wir haben einen Pull-Request gesendet, und wir m\u00fcssen sie morgen ausrollen, wollen aber nicht warten, bis sie im Upstream ver\u00f6ffentlicht 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: \u201eLeute, lasst uns das f\u00fcr einen allgemeineren Fall machen\u201c, und wir, oder jemand anderes, vervollst\u00e4ndigen das, und irgendwann wird es dann wieder zusammengef\u00fchrt.<\/p>\n

Alles, was existiert, versuchen wir weiterzuentwickeln.<\/b>. Viele Elemente, die es noch nicht gibt, oder die zwar schon entworfen, aber noch nicht umgesetzt wurden \u2013 wir machen das. Und nicht, weil uns der Prozess oder das Radfahren in dieser Branche gef\u00e4llt, sondern einfach, weil wir dieses Werkzeug brauchen. Oft wird die Frage gestellt, warum wir jenes oder dieses gemacht haben? Die Antwort ist einfach \u2013 weil wir weiterkommen mussten, ein praktisches Problem l\u00f6sen wollten, und wir haben es mit diesem Tool gel\u00f6st.<\/p>\n

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

<\/p>\n

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

\n\u2014 Mir ist bekannt, dass \u201eFlant\u201c jetzt Addon-Operatoren, Shell-Operatoren und die Tools dapp\/werf hat. So wie ich das verstehe, ist das dieselbe Software in verschiedenen Inkarnationen. Au\u00dferdem verstehe ich, dass es innerhalb von \u201eFlant\u201c noch viele verschiedene Werkzeuge gibt. Ist das so?<\/b><\/p>\n

Dmitry<\/b>: Wir haben auf GitHub noch viele andere Dinge. Was mir jetzt einf\u00e4llt, ist das statusmap \u2013 ein Dashboard f\u00fcr Grafana, das bei allen gut angekommen ist. Es wird wohl in fast jedem zweiten Artikel \u00fcber das Monitoring von Kubernetes auf Medium erw\u00e4hnt. Man kann nicht kurz erkl\u00e4ren, was das statusmap ist \u2013 daf\u00fcr braucht es einen eigenen Artikel, aber es ist ein sehr hilfreiches Werkzeug f\u00fcr das zeitliche Statusmonitoring, da wir in Kubernetes oft den Status \u00fcber die Zeit anzeigen m\u00fcssen. Au\u00dferdem haben wir LogHouse \u2013 das ist ein Tool auf Basis von ClickHouse und schwarzer Magie zur Protokollsammlung in Kubernetes.<\/p>\n

Viele Tools! Und es wird noch mehr geben, denn einige interne L\u00f6sungen werden in diesem Jahr ver\u00f6ffentlicht. Es gibt eine Menge Addons zu Kubernetes, die auf dem Addon-Operator basieren, wie zum Beispiel, wie man den Cert Manager installiert \u2013 ein Werkzeug zur Verwaltung von Zertifikaten \u2013 wie man Prometheus mit einer Menge Zusatztools installiert \u2013 das sind zwanzig verschiedene Bin\u00e4rdateien, die Daten exportieren und etwas sammeln, und zu diesem Prometheus gibt es gro\u00dfartige Grafiken und Alarme. All dies sind einfach viele Addons zu Kubernetes, die im Cluster installiert werden, und es verwandelt sich von einfach in ausgekl\u00fcgelt, hochentwickelt, automatisiert, in dem viele Fragen bereits gel\u00f6st sind. Ja, wir machen viel.<\/p>\n

Entwicklung des \u00d6kosystems<\/h2>\n

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

Dmitry<\/b>: In Russland gibt es niemanden von den Unternehmen, die auf unserem Markt t\u00e4tig sind \u2013 nicht einmal ann\u00e4hernd<\/b>. Nat\u00fcrlich ist das eine gewagte Aussage, denn es gibt gro\u00dfe Akteure wie Mail und Yandex \u2013 sie machen auch etwas mit Kubernetes, aber selbst sie kommen nicht ann\u00e4hernd 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\u00fcr Kubernetes 300 Ingenieure arbeiten, wenn ich mich nicht irre. Es ist schwer zu vergleichen. In unserer RnD-Abteilung sind wir 6 Personen, einschlie\u00dflich mir, die all unsere Tools entwickeln. 6 Personen gegen 300 Ingenieure von Red Hat \u2013 das ist irgendwie schwer zu vergleichen.<\/p>\n

\u2013 Dennoch k\u00f6nnen selbst diese 6 Personen wirklich n\u00fctzliche und abgrenzbare Dinge machen, wenn sie mit einer praktischen Aufgabe konfrontiert sind und L\u00f6sungen an die Gemeinschaft zur\u00fcckgeben \u2013 ein interessanter Fall. Ich verstehe, dass in gro\u00dfen Technologieunternehmen, die ihre eigene Entwicklung und ein Support-Team f\u00fcr Kubernetes haben, prinzipiell \u00e4hnliche Tools entwickelt werden k\u00f6nnen. Das ist f\u00fcr sie ein Beispiel, wie man etwas entwickeln und an die Gemeinschaft abgeben kann, um der gesamten Gemeinschaft, die Kubernetes nutzt, einen Schub zu geben.<\/b><\/p>\n

Dmitry<\/b>: Vielleicht ist das das Besondere am Integrator. Wir haben viele Projekte und sehen viele verschiedene Situationen. F\u00fcr uns ist der Hauptweg zur Schaffung von Mehrwert, diese F\u00e4lle zu analysieren, Gemeinsamkeiten zu finden und sie so kosteng\u00fcnstig wie m\u00f6glich zu machen. Damit besch\u00e4ftigen wir uns intensiv. Es f\u00e4llt mir schwer, \u00fcber 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 \u00fcberhaupt gibt.<\/p>\n

Ich verstehe alles \u00fcber den Jobtitel DevOps-Ingenieur, alle wissen Bescheid und gew\u00f6hnen sich daran, DevOps-Ingenieure DevOps-Ingenieuren zu nennen, dar\u00fcber werden wir nicht diskutieren. Alle diese 40 gro\u00dfartigen DevOps-Ingenieure stehen jeden Tag vor Herausforderungen und l\u00f6sen 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\u00e4ufen \u2013 das ist nur Zeit- und Ressourcenverschwendung. So sehen wir das ganz entspannt. Wir ver\u00f6ffentlichen alles mit gro\u00dfem Vergn\u00fcgen und wissen, dass das wichtig ist \u2013 zu ver\u00f6ffentlichen, weiterzuentwickeln, zu bewerben, damit die Leute es nutzen und ihre Erfahrungen einbringen k\u00f6nnen \u2013 dann w\u00e4chst alles und lebt. Dann wird das Tool in zwei Jahren nicht auf den M\u00fcll 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.<\/p>\n

Das ist Teil unserer gro\u00dfen Strategie mit dapp\/werf.<\/b>. Ich erinnere mich nicht, wann wir damit angefangen haben, es sind wohl drei Jahre her. Urspr\u00fcnglich war es komplett in Shell. Es war ein super Proof of Concept, wir haben einige unserer privaten Aufgaben gel\u00f6st \u2013 es hat funktioniert! Aber mit Shell gibt es Probleme, es ist unm\u00f6glich, damit weiterzuarbeiten, Programmieren in Shell ist kein Vergn\u00fcgen. Wir hatten die Gewohnheit, in Ruby zu schreiben, dementsprechend haben wir etwas in Ruby umgebaut, weiterentwickelt, weiterentwickelt, bis wir darauf gesto\u00dfen sind, dass die Community, die Masse, die nicht sagt: \u201eWir wollen oder wollen nicht\u201c, die Nase r\u00fcmpft und sich von Ruby abwendet, so lustig das auch ist. Wir haben verstanden, dass wir all diese Sachen in Go schreiben m\u00fcssen, um einfach dem ersten Punkt in unserer Checkliste zu entsprechen: Das DevOps-Tool muss ein statisches Bin\u00e4rformat sein.<\/b>Ob Go oder nicht Go ist nicht so wichtig, aber besser ist ein statisches Binary, das in Go geschrieben ist.<\/p>\n

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

Warum wurde die DApp erstellt<\/h2>\n

\n\u2014 Kannst du kurz erz\u00e4hlen, warum die DApp erstellt wurde und welche Probleme sie l\u00f6st?<\/b><\/p>\n

Dmitry<\/b>: Der erste Grund liegt im Build-Prozess. Urspr\u00fcnglich hatten wir gro\u00dfe 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\u00fcher oder sp\u00e4ter mit dem Problem konfrontiert, dass es viele gebaute Images gibt, die bereinigt werden m\u00fcssen, um das Nichtben\u00f6tigte zu entfernen und das Notwendige zu behalten.<\/p>\n

Der zweite Grund liegt im Deployment. Ja, es gibt Helm, aber er l\u00f6st nur einen Teil der Aufgaben. So komisch es klingt, es steht geschrieben: \"Helm \u2013 der Paketmanager f\u00fcr Kubernetes\". Genau, das \u201eder\u201c. Da sind noch die W\u00f6rter \u201ePaketmanager\u201c \u2013 was erwartet man normalerweise von einem Paketmanager? Wir sagen: \u201ePaketmanager \u2013 installiere das Paket!\u201c und erwarten, dass er uns sagt: \u201ePaket installiert\u201c. <\/p>\n

Es ist interessant, dass wir sagen: \u201eHelm, installiere das Paket\u201c, und wenn er antwortet, dass er es installiert hat, stellt sich heraus, dass er nur mit der Installation begonnen hat \u2013 er hat Kubernetes gesagt: \u201eStarte dieses Ding!\u201c, aber ob es gestartet ist oder nicht, ob es funktioniert oder nicht, das l\u00f6st Helm \u00fcberhaupt nicht.<\/p>\n

Es stellt sich also heraus, dass Helm einfach ein Textpreprozessor ist, der Daten in Kubernetes l\u00e4dt.<\/p><\/blockquote>\n

\nAber wir wollen im Rahmen jedes Deployments wissen \u2013 wurde die Anwendung auf den Produktionsserver ausgerollt oder nicht? Ein Rollout auf den Produktionsserver bedeutet, dass die Anwendung dort hin\u00fcbergefahren wurde, eine neue Version ausgerollt wurde und sie dort zumindest nicht abst\u00fcrzt und korrekt antwortet. Helm l\u00f6st diese Aufgabe nicht. Um sie zu l\u00f6sen, muss man viel Aufwand betreiben, denn man muss Kubernetes anweisen, das Deployment durchzuf\u00fchren und \u00fcberwachen, was dort passiert \u2013 ob es erfolgreich ausgef\u00fchrt wurde, ob es ausgerollt wurde. Und da sind noch viele Aufgaben, die mit dem Deployment, der Bereinigung und dem Build verbunden sind.<\/p>\n

Pl\u00e4ne<\/h2>\n

\nNoch in diesem Jahr werden wir in die lokale Entwicklung gehen. Wir wollen zu dem Zustand gelangen, der fr\u00fcher mit Vagrant m\u00f6glich war \u2013 wir geben \u201evagrant up\u201c ein und unsere VMs starten. Wir wollen so weit kommen, dass es ein Projekt in Git gibt, wo wir \u201ewerf up\u201c schreiben, und es eine lokale Kopie dieses Projekts in einem lokalen Mini-Kub hochf\u00e4hrt, mit allen f\u00fcr die Entwicklung praktischen Verzeichnissen verbunden. Je nach Programmiersprache wird dies unterschiedlich umgesetzt, aber dennoch soll es komfortabel m\u00f6glich sein, die lokale Entwicklung unter gemounteten Dateien zu f\u00fchren.<\/p>\n

Der n\u00e4chste Schritt f\u00fcr uns ist es, stark in den Komfort f\u00fcr Entwickler zu investieren<\/b>. 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\u00fcr uns ein sehr wichtiger Punkt. Aber das gibt es bisher noch nicht in werf \u2013 wir planen es nur.<\/p>\n

Aber der Weg zu dapp\/werf war immer derselbe wie zu Kubernetes zu Beginn. Wir sind auf Probleme gesto\u00dfen, haben sie mit Umwegen gel\u00f6st \u2013 haben f\u00fcr uns eigene L\u00f6sungen in Shell oder auf was auch immer erdacht. Sp\u00e4ter haben wir versucht, diese Umwege irgendwie zu begradigen, zu verallgemeinern und in Binaries zu konsolidieren, die wir einfach teilen.<\/p>\n

Es gibt auch eine andere Perspektive auf diese gesamte Geschichte, die analog ist. <\/p>\n

Kubernetes ist das Chassis eines Autos mit Motor. Es gibt keine T\u00fcren, Fenster, Radio, Duftbaum \u2013 \u00fcberhaupt nichts. Nur das Gestell und den Motor. Und es gibt Helm \u2013 das ist das Lenkrad. Toll \u2013 ein Lenkrad ist vorhanden, aber es fehlen noch der Steuerstift, die Lenkstange, das Getriebe und die R\u00e4der, ohne die es nicht funktioniert.<\/p><\/blockquote>\n

\nIm 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\u00fcnde, es so zu machen, warum wir helm zusammen mit tiller komplett in werf integriert haben, werde ich gleich in einem Vortrag auf RIT++ erz\u00e4hlen.<\/a><\/noindex>.<\/p>\n

Jetzt ist werf ein integrierterer Bestandteil. Wir erhalten ein fertiges Steuerger\u00e4t, einen Steuerstift \u2013 ich kenne mich nicht gut mit Autos aus, aber das ist ein gro\u00dfer Block, der bereits ein breites Spektrum an Aufgaben l\u00f6st. Wir m\u00fcssen nicht selbst im Katalog nach einzelnen Bauteilen suchen, eine Teil zu einem anderen zuordnen und \u00fcberlegen, wie wir sie zusammenbauen. Wir erhalten eine einsatzbereite L\u00f6sung, die viele Aufgaben sofort erledigt. Innen besteht es jedoch aus den gleichen Open-Source-Komponenten, nutzt Docker f\u00fcr den Aufbau, Helm f\u00fcr bestimmte Funktionen und hat noch einige andere Bibliotheken. Es ist ein integriertes Werkzeug, um schnell und einfach ein gro\u00dfartiges CI\/CD out of the box zu erhalten.<\/p>\n

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

\n\u2014 Du erz\u00e4hlst von der Erfahrung, dass ihr begonnen habt, Kubernetes zu nutzen, das ist f\u00fcr euch der Rahmen, der Motor, und man kann vieles daran anbringen: Geh\u00e4use, Lenkrad, Pedale, Sitze. Da stellt sich die Frage \u2013 wie schwierig ist es f\u00fcr euch, Kubernetes zu unterst\u00fctzen? Ihr habt viel Erfahrung, wie viel Zeit und Ressourcen investiert ihr ausschlie\u00dflich in die Unterst\u00fctzung von Kubernetes im Vergleich zu allem anderen?<\/b><\/p>\n

Dmitry<\/b>: Das ist eine sehr schwierige Frage und um sie zu beantworten, m\u00fcssen wir verstehen, was Unterst\u00fctzung bedeutet und was wir von Kubernetes wollen. Vielleicht kannst du das n\u00e4her ausf\u00fchren?<\/p>\n

\u2014 Soweit ich informiert bin und wie ich sehe, wollen viele Teams jetzt Kubernetes ausprobieren. Alle st\u00fcrzen sich darauf und installieren es auf ihren Laptops. 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 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\u00e4hen musst, ist der Prozess an sich nicht kompliziert. Es ist jedoch schwierig, bei jeder Gelegenheit zu garantieren, dass alles gelingt.<\/p>\n

Kubernetes zu installieren und zum Laufen zu bringen, ist einfach: zack! \u2013 es ist installiert, es gibt viele Methoden zur Installation. Aber was passiert, wenn Probleme auftreten?<\/p><\/blockquote>\n

\nEs stellen sich immer Fragen \u2013 was haben wir \u00fcbersehen? Was haben wir nicht gemacht? Welche Linux-Kernel-Parameter haben wir falsch angegeben? Mein Gott, haben wir sie \u00fcberhaupt angegeben?! Welche Kubernetes-Komponenten haben wir installiert und welche nicht? Tausende Fragen tauchen auf, und um sie zu beantworten, ben\u00f6tigt man 15-20 Jahre Erfahrung in dieser Branche.<\/p>\n

Ich habe ein frisches Beispiel zu diesem Thema, das den Sinn des Problems \"Ist es schwer, Kubernetes zu unterst\u00fctzen?\" verdeutlichen kann. Vor einiger Zeit haben wir ernsthaft dar\u00fcber nachgedacht, ob wir Cilium als Netzwerk in Kubernetes implementieren sollten.<\/p>\n

Ich erkl\u00e4re, was Cilium ist. In Kubernetes gibt es viele verschiedene Realisierungen des Netzwerk-Subsystems, und eine davon ist sehr cool \u2013 das ist Cilium. Worin liegt der Sinn? Vor einiger Zeit gab es im Kernel die M\u00f6glichkeit, Hooks f\u00fcr den Kernel zu schreiben, die in irgendeiner Weise in das Netzwerk-Subsystem und in verschiedene andere Subsysteme eingreifen und es erm\u00f6glichen, gro\u00dfe Teile des Kernels zu umgehen.<\/p>\n

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\u00dfartig, aber jetzt haben wir Container \u00fcber Container gestapelt, und das sieht aus wie ein Turm aus 15 Ziegeln \u00fcbereinander, w\u00e4hrend du auf einem Bein darauf stehst \u2013 ein seltsames Gef\u00fchl. Dieses System hat sich historisch mit vielen Nuancen entwickelt, wie der Blinddarm im K\u00f6rper. In einigen Situationen gibt es Leistungsprobleme, zum Beispiel.<\/p>\n

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

Was ist dabei herausgekommen? Sehr tolle Leistung, coole Funktionen \u2013 einfach klasse! Aber wir schauen darauf und sehen, dass auf jeder Maschine ein Programm l\u00e4uft, das sich mit der Kubernetes-API verbindet und anhand der Daten, die es aus dieser API erh\u00e4lt, C-Code generiert und Bin\u00e4rdateien kompiliert, die in den Kernel geladen werden, damit diese Hooks im Kernel-Space funktionieren.<\/p>\n

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 \u2013 ich habe deren Quellcode nicht gelesen, und 40 Ingenieure, die in unserem Unternehmen arbeiten, auch nicht. Vielleicht verstehen einige wenige Teile davon.<\/p>\n

Und was macht das f\u00fcr einen Unterschied? Es gibt also ip rout, den Linux-Kernel, und es gibt ein neues Werkzeug - was spielt das f\u00fcr eine Rolle, wir verstehen weder das eine noch das andere. Aber wir f\u00fcrchten uns, das Neue zu benutzen - warum? Weil, wenn das Werkzeug 30 Jahre alt ist, alle Bugs \u00fcber 30 Jahre hinweg gefunden wurden, man \u00fcber 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.<\/p>\n

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\u00e4uft, sind Sie in der Lage, in einer kritischen Situation schnell zu verstehen, was schiefgelaufen ist? <\/p>\n

Wenn wir dar\u00fcber sprechen, ob es schwierig ist, Kubernetes zu unterst\u00fctzen - nein, es ist sehr einfach, und ja, es ist unglaublich schwierig. Kubernetes funktioniert hervorragend f\u00fcr sich allein, aber mit einer Milliarde von Nuancen.<\/p><\/blockquote>\n

<\/p>\n

\u00dcber den Ansatz 'Ich habe Gl\u00fcck'<\/h2>\n

\n- Gibt es Unternehmen, bei denen diese Nuancen fast garantiert auftreten werden? Nehmen wir an, Yandex w\u00fcrde pl\u00f6tzlich alle Dienste auf Kubernetes umstellen, da wird ordentlich viel Verkehr sein.<\/b><\/p>\n

Dmitry<\/b>: 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\u00e4llt. Es gibt kein fertiges System, das Alarme sendet - man muss diese Alarme und jedes Diagramm konfigurieren. Und wir aktualisieren gerade Kubernetes.<\/p>\n

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\u00f6scht es die Pods, und irgendwie passiert es \u2013 ich erinnere mich nicht an die Details, entschuldigen Sie \u2013 dass systemd-Slices verbleiben. Das f\u00fchrt dazu, dass jede Maschine mit der Zeit stark langsamer wird. Es handelt sich hier nicht einmal um ein Highload-Thema. Wenn st\u00e4ndig Pods gestartet werden, zum Beispiel wenn es einen Cron Job gibt, der st\u00e4ndig Pods erzeugt, dann wird eine Maschine mit Ubuntu 16.04 nach einer Woche langsamer. Es wird st\u00e4ndig 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\u00fcber nutzt.<\/p>\n

Nehmen wir an, er aktualisiert irgendwie systemd oder etwas anderes, aber im Linux-Kernel bis 4.16 ist es noch lustiger \u2013 beim L\u00f6schen von C-Gruppen sickern sie im Kernel durch und werden tats\u00e4chlich nicht gel\u00f6scht. Deshalb wird es nach einem Monat Arbeit an dieser Maschine unm\u00f6glich 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\u00f6tigt, um in sich selbst \u00fcber Millionen von C-Gruppen zu rechnen, die zwar gel\u00f6scht zu sein scheinen, es aber nicht sind \u2013 sie sickern durch.<\/p>\n

Solcher Kleinigkeiten gibt es immer noch sehr viele hier und dort. Das ist nicht das Problem, mit dem Gro\u00dfkonzerne manchmal bei sehr hohen Lasten konfrontiert werden \u2013 nein, es ist eine Frage des t\u00e4glichen Lebens. Menschen k\u00f6nnen monatelang so leben \u2013 sie haben Kubernetes installiert, die Anwendung bereitgestellt \u2013 es scheint zu funktionieren. F\u00fcr viele ist das in Ordnung. Dass irgendwann diese Anwendung aus irgendeinem Grund ausf\u00e4llt, wird ihnen nicht einmal bewusst, der Alert kommt nicht, aber f\u00fcr sie ist das Normalit\u00e4t. Fr\u00fcher lebten sie auf virtuellen Maschinen ohne \u00dcberwachung, jetzt sind sie nach Kubernetes ohne \u00dcberwachung gewechselt \u2013 was ist der Unterschied?<\/p>\n

Die Frage ist, dass wir, wenn wir \u00fcber 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\u00fcher auch gelaufen sind.<\/p>\n

Aus meiner Sicht besteht der Nuance und die Komplexit\u00e4t des Betriebs eines jeden Systems darin, sicherzustellen, dass die Dicke des Eises genau ausreicht, um unsere Aufgaben zu l\u00f6sen. Darum geht es.<\/p><\/blockquote>\n

\nIm IT-Bereich gibt es meiner Meinung nach zu viele Ans\u00e4tze nach dem Motto \u201eIch habe Gl\u00fcck\u201c. Viele installieren Software, verwenden Bibliotheken in der Hoffnung, dass ihnen das Gl\u00fcck hold ist. Insgesamt haben viele Erfolg. Wahrscheinlich funktioniert es genau deshalb.<\/p>\n

\u2013 Aus meiner pessimistischen Sicht sieht das so aus: Wenn die Risiken hoch sind und die Anwendung funktionieren muss, ben\u00f6tigt man Unterst\u00fctzung von \u201eFlant\u201c, m\u00f6glicherweise von Red Hat, oder man ben\u00f6tigt ein internes Team, das speziell f\u00fcr Kubernetes bestimmt ist und bereit ist, es zu betreuen.<\/b><\/p>\n

Dmitry<\/b>: Objektiv ist das so. Sich selbst in die Geschichte mit Kubernetes einzuarbeiten, ist f\u00fcr ein kleines Team mit gewissen Risiken verbunden.<\/p>\n

Brauchen wir Container?<\/h2>\n

\n\u2013 Kannst du mir sagen, wie weit verbreitet Kubernetes in Russland \u00fcberhaupt ist?<\/b><\/p>\n

Dmitry<\/b>: Ich habe keine Daten dazu und bin mir nicht sicher, ob jemand diese Informationen hat. Wir sagen: \u201eKubernetes, Kubernetes\u201c, aber es gibt auch eine andere Perspektive auf die Frage. Wie verbreitet Container sind, wei\u00df ich auch nicht, aber ich kenne die Zahl aus Berichten im Internet, dass 70 % der Container mit Kubernetes orchestriert werden. Das war eine verl\u00e4ssliche Quelle aus einer ziemlich gro\u00dfen globalen Stichprobe.<\/p>\n

Die n\u00e4chste Frage lautet: Brauchen wir \u00fcberhaupt Container?<\/b> Ich habe das pers\u00f6nliche Gef\u00fchl und die generelle Position des Unternehmens \u201eFlant\u201c ist, dass Kubernetes der De-Facto-Standard ist.<\/p>\n

Es wird nichts anderes als Kubernetes geben.<\/p><\/blockquote>\n

\nEs ist ein absoluter Game-Changer im Bereich Infrastrukturmanagement. Einfach absolut \u2013 alles, keine Ansible, Chef, virtuellen Maschinen, Terraform mehr. Ich spreche schon gar nicht von alten, ineffizienten Methoden. Kubernetes ist der absolute Changer<\/b>, und jetzt wird es nur noch so sein.<\/p>\n

Es ist klar, dass einige Jahre daf\u00fcr ben\u00f6tigt werden, w\u00e4hrend 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<\/b>, nur nicht mit Code, sondern mit YML \u2013 deklarativ beschriebene Infrastruktur. Ich habe das Gef\u00fchl, dass es immer so sein wird.<\/p>\n

\u2013 Das hei\u00dft, die Unternehmen, die noch nicht auf Kubernetes umgestiegen sind, werden definitiv darauf umsteigen oder in Vergessenheit geraten. Habe ich dich richtig verstanden?<\/b><\/p>\n

Dmitry<\/b>: 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\u00e4chlich viele Jahre ohne Aktualisierungen, ohne \u00c4nderungen l\u00e4uft, dann gibt es dort nat\u00fcrlich kein Kubernetes. Das ist dort nicht n\u00f6tig.<\/p>\n

Alles, was CI\/CD betrifft \u2013 \u00fcberall, wo Continuous Delivery ben\u00f6tigt wird, wo Versionsaktualisierungen, aktive \u00c4nderungen erforderlich sind, wo Ausfallsicherheit aufgebaut werden muss \u2013 nur Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

\u00dcber Mikrodienste<\/h2>\n

\n\u2013 Hier entsteht ein kleiner Dissonanz bei mir. 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 Startup, haben wir noch nichts, k\u00f6nnte die Entwicklung f\u00fcr Kubernetes oder \u00fcberhaupt f\u00fcr eine mikrodienstliche Architektur schwierig sein und nicht immer wirtschaftlich gerechtfertigt. Mich interessiert deine Meinung \u2013 sollten Startups sofort von null auf Kubernetes schreiben oder kann man erst einen Monolithen schreiben und erst sp\u00e4ter zu Kubernetes \u00fcbergehen?<\/b><\/p>\n

Dmitry<\/b>: Das ist eine gute Frage. Ich habe einen Vortrag \u00fcber Mikrodienste. \u201eMikrodienste: Gr\u00f6\u00dfe ist wichtig.\u201c<\/a><\/noindex> Ich habe oft erlebt, dass Leute versuchen, mit einem Mikroskop N\u00e4gel 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 \u201emikro\u201c. 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.<\/p>\n

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\u00fccke zerbrochen werden muss \u2013 etwa in 10 Teile, an denen mindestens 30 Personen arbeiten. Das ist wichtig, notwendig und gro\u00dfartig. 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.<\/p>\n

Ich habe das Gef\u00fchl, dass dar\u00fcber schon tausendmal gesprochen wurde \u2013 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\u00fcber.<\/p>\n

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\u00f6nnte, andererseits ist klar, dass alles dahin geht und es nichts au\u00dfer Kubernetes geben wird. Die Antwort ist die Abw\u00e4gung des Nutzens, der kommt, und der Aufgaben, die Sie l\u00f6sen k\u00f6nnen.<\/b>. Das ist eine Seite der Waage. Auf der anderen Seite stehen die Risiken, die mit Ausfallzeiten oder einer erh\u00f6hten Reaktionszeit und einem niedrigeren Verf\u00fcgbarkeitsniveau verbunden sind \u2013 einer Abnahme der Leistungsindikatoren.<\/p>\n

Hier ist es so \u2013 entweder wir bewegen uns schnell und Kubernetes erm\u00f6glicht es, viele Dinge viel schneller und besser zu erledigen, oder wir nutzen zuverl\u00e4ssige, bew\u00e4hrte L\u00f6sungen, aber bewegen uns viel langsamer. Diese Entscheidung muss jede Firma treffen. Man kann es betrachten wie einen Pfad im Dschungel \u2013 wenn man zum ersten Mal geht, kann man eine Schlange, einen Tiger oder einen tollw\u00fctigen Dachs treffen, und nach 10 Mal geht man \u2013 hat man den Pfad getreten, die \u00c4ste beiseite ger\u00e4umt und man kann leichter gehen. Mit jedem Mal wird der Pfad breiter. Sp\u00e4ter ist es schon eine asphaltierte Stra\u00dfe, und sp\u00e4ter eine sch\u00f6ne Allee.<\/p>\n

Kubernetes steht nicht still. Wieder die Frage: Kubernetes ist einerseits 4-5 Binaries, andererseits ist es das gesamte \u00d6kosystem. Es ist das Betriebssystem, das auf unseren Maschinen l\u00e4uft. Was ist das? Ubuntu oder Curios? Es ist der Linux-Kernel, eine Menge zus\u00e4tzlicher Komponenten. All diese Dinge haben hier eine giftige Schlange von der Stra\u00dfe 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.<\/p>\n

Wenn ich auf die Frage antworte, was ein Startup tun sollte, w\u00fcrde ich sagen \u2013 kommen Sie zu \"Flant\", zahlen Sie 150.000 Rubel und erhalten Sie einen schl\u00fcsselfertigen 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\u00f6sen und w\u00e4hrenddessen Gehalt zu beziehen, bekommen Sie eine schl\u00fcsselfertige L\u00f6sung f\u00fcr alle Fragen. Ja, es gibt einige Nachteile. Wir als Outsourcing-Anbieter k\u00f6nnen nicht so stark involviert sein und schnell auf \u00c4nderungen reagieren. Aber daf\u00fcr haben wir eine Menge Expertise und bew\u00e4hrte Praktiken. Wir garantieren, dass wir in jeder Situation schnell reagieren k\u00f6nnen und jeden Kubernetes aus der Krise heben. <\/p>\n

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

<\/p>\n

Zu Amazon und Google<\/h2>\n

\nKann man die L\u00f6sung von Amazon oder Google als Outsourcing betrachten?<\/b><\/p>\n

Dmitry<\/b>: Ja, nat\u00fcrlich, das l\u00f6st 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\u00e4rmen oder im Voraus eine Anfrage stellen: \"Leute, wir bekommen Traffic, bitte w\u00e4rmt unseren Load Balancer auf!\" Diese Nuancen muss man kennen.<\/p>\n

Wenn Sie sich an Menschen wenden, die darauf spezialisiert sind, bekommen Sie fast alle g\u00e4ngigen Dinge im Voraus gel\u00f6st. Wir haben derzeit 40 Ingenieure, bis zum Ende des Jahres werden es wahrscheinlich 60 sein \u2013 wir haben damit bereits Erfahrung. Selbst wenn wir bei einem Projekt erneut auf dieses Problem sto\u00dfen, fragen wir uns schnell gegenseitig und wissen, wie man es l\u00f6st.<\/p>\n

Wahrscheinlich ist die Antwort so \u2013 nat\u00fcrlich erleichtert eine Hosted-L\u00f6sung 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. F\u00fcr all unsere F\u00e4lle \u2013 auf jeden Fall. Ansonsten haben wir keine positiven Erfahrungen gemacht. Alle anderen Clouds, mit denen wir versucht haben zu arbeiten, schaffen sehr viele Probleme \u2013 sowohl Ager als auch alles, was in Russland existiert, und verschiedene OpenStack-Implementierungen: Headster, Overage \u2013 alles, was Sie wollen. Sie alle verursachen Probleme, die man nicht l\u00f6sen m\u00f6chte.<\/p>\n

Darum lautet die Antwort \u2013 ja, aber tats\u00e4chlich gibt es nicht viele ausgereifte Hosted-L\u00f6sungen.<\/p>\n

Wer braucht Kubernetes?<\/h2>\n

\n\u2014 Und wer braucht eigentlich Kubernetes? Wer soll schon auf Kubernetes umsteigen, wer ist der typische Kunde von \u00abFlant\u00bb, der gerade nach Kubernetes fragt?<\/b><\/p>\n

Dmitry<\/b>: Die Frage ist interessant, denn gerade jetzt kommen viele zu uns auf der Welle von Kubernetes: \u201eLeute, wir wissen, dass ihr Kubernetes macht, macht es f\u00fcr uns!\u201c Wir antworten: \u201eMeine Herren, wir machen kein Kubernetes, wir bieten PROD und alles, was damit zusammenh\u00e4ngt, an.\u201c Denn heutzutage ist es einfach unm\u00f6glich, 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.<\/p>\n

Unsere Kunden erwarten Verschiedenes, aber alle warten auf ein gewisses gutes Wunder, dass sie die einen oder anderen Probleme haben und jetzt \u2014 hop! \u2014 Kubernetes wird sie l\u00f6sen. Die Leute glauben an Wunder. Sie verstehen mit dem Verstand, dass es kein Wunder geben wird, aber tief im Herzen hoffen sie \u2014 vielleicht wird uns Kubernetes jetzt alles l\u00f6sen, dar\u00fcber wird so viel gesprochen! Vielleicht ist es jetzt \u2014 huh! \u2014 und die silberne Kugel, huh! \u2014 und wir haben 100% Uptime, alle Entwickler k\u00f6nnen 50 Mal alles, was sie wollen, in PROD bringen, und es f\u00e4llt nicht aus. Kurz gesagt, ein Wunder!<\/p>\n

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

Um die Frage zu beantworten, wer Kubernetes braucht \u2014 Kubernetes braucht niemand.<\/p><\/blockquote>\n

\nEinige Leute haben das falsche Gef\u00fchl, dass sie Kubernetes brauchen. Die Menschen m\u00f6chten, sie haben das tiefgreifende Bed\u00fcrfnis, 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\u00fcr sie ist Kubernetes die Hoffnung, dass sie nicht mehr h\u00f6ren m\u00fcssen: \u201eWir haben uns da herumgeschlagen\u201c, oder \u201eWir k\u00f6nnen nicht ausrollen\u201c, oder etwas anderes.<\/p>\n

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 \u2014 Stabilit\u00e4t. Wir schlagen vor, dies zu \u00fcbernehmen und zu gestalten. Die silberne Kugel, besser gesagt, die versilberte, besteht darin, dass du aufh\u00f6ren wirst, \u00fcber diese Probleme nachzudenken und Zeit zu verschwenden. Du wirst spezielle Leute haben, die dieses Problem l\u00f6sen.<\/p>\n

Die Formulierung, dass wir oder jemand anderes Kubernetes brauchen, ist falsch.<\/p><\/blockquote>\n

\nKubernetes ist f\u00fcr Administratoren sehr wichtig, denn es ist ein \u00e4u\u00dferst interessantes Spielzeug, mit dem man experimentieren kann. Lassen Sie uns ehrlich sein \u2013 jeder liebt Spielzeuge. Wir alle sind irgendwo Kinder, und wenn wir etwas Neues sehen, m\u00f6chten 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.<\/p>\n

Man sollte nicht mit der Produktion spielen. Was ich kategorisch nicht empfehlen w\u00fcrde 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\u00e4ndig etwas in den Kindern, bemerke es an mir und abstrahiere es dann auf andere.<\/p>\n

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

\nMan kann Folgendes erreichen:<\/p>\n