Vor kurzem sprach Alexander Chistyakov, DevOps mit 7 Jahren Erfahrung und Mitbegründer der DevOps-Ingenieurgemeinschaft in St. Petersburg, in unseren sozialen Netzwerken.
Sasha ist einer der Top-Sprecher in diesem Bereich. Er trat auf den Hauptbühnen bei Highload ++, RIT ++, PiterPy und Strike auf und machte insgesamt mindestens 100 Berichte. Letzten Montag beantwortete er Fragen von Zuschauern und sprach über seine Erfahrungen.
Wir teilen die Aufzeichnung und das Transkript der Sendung.
Mein Name ist Alexander Chistyakov, ich arbeite seit vielen Jahren als DevOps-Ingenieur. Ich habe verschiedene Unternehmen lange Zeit bei der Implementierung von DevOps-Praktiken, der Verwendung moderner DevOps-Tools und der Organisation von Infrastrukturen beraten, damit wir alle nachts gut schlafen können und die Menschen weiterhin Geld für ihre Waren und Dienstleistungen erhalten.
Grundsätzlich habe ich ausländische Unternehmen konsultiert.
Wir werden darüber sprechen, wie Menschen Kubernetes in der täglichen Praxis verwenden, warum Sie es brauchen, warum Sie keine Angst davor haben sollten, worauf Sie achten sollten und was als nächstes passieren wird.
Ich denke, Systemadministratoren, DevOps-Ingenieure, CIOs und andere Infrastrukturmanager (und Unterstützer) werden es nützlich finden.
Wie hat sich diese Landschaft entwickelt? Ich erinnere mich an Computer mit installiertem ROM Basic und es war möglich, Programme ohne installiertes Betriebssystem zu schreiben. Seitdem ist viel Wasser unter die Brücke geflossen. Anfangs gab es kein Betriebssystem als solches (genauer gesagt, sie wurden in Assembler geschrieben). Dann erschien die C-Sprache und die Situation verbesserte sich dramatisch. Natürlich kennen wir jetzt alle das Konzept eines Betriebssystems: Es ist eine Plattform, mit der wir benutzerdefinierte Anwendungen ausführen und die auf diesem Computer vorhandenen Ressourcen verwalten können. Oder andere, wenn es verteilt wird. Schon damals war es möglich, einen Hochleistungs-Computercluster aus Ihrem Laptop und Desktop zusammenzustellen - so machten es die Studenten 1997 im Hostel der Polytechnischen Universität St. Petersburg.
Dann stellte sich heraus - ich habe diesen Artikel wahrscheinlich vor 10 Jahren gelesen -, dass Google, das Webmail erfunden hat, ein Betriebssystem um genau diese Webmail herum erstellt, damit Benutzer es von Tablets und Handys aus verwenden können. Dies war unerwartet. Normalerweise führt das Betriebssystem die Binärdateien aus. Wenn Sie die Anwendung über den Browser betrachten, wissen Sie nicht einmal, ob die Binärdatei vorhanden ist. Sie können E-Mails lesen, in einem Online-Messenger chatten, Folien zeichnen und Dokumente gemeinsam bearbeiten. Es stellte sich heraus, dass dies vielen passt.
Google war zwar nicht sehr konsistent und stellte viele solcher Produkte her, die nicht benötigt wurden und nicht über den Prototyp hinausgingen - zum Beispiel Google Wave. Nun, dies ist die Politik eines großen Unternehmens - schnell zu handeln, häufig zusammenzubrechen, bis das Unternehmen aufhört zu existieren.
Im Massenbewusstsein hat sich jedoch die Idee des Betriebssystems als Plattform verschoben, die nicht die Dienste bereitstellt, die einst von einem Standardisierungsausschuss genehmigt und ihm zugewiesen wurden, sondern lediglich die Bedürfnisse der Benutzer erfüllt. Was sind diese Bedürfnisse?
Früher war es üblich, den Entwickler zu fragen, worüber er schreibt. Es gab Spezialisten für C ++ (wahrscheinlich und jetzt gibt es irgendwo), jetzt gibt es viele Spezialisten für PHP (sie lachen manchmal über sich selbst) und viele JavaScript-Entwickler. Typescript, die GoLang-Sprache, zu der Menschen mit PHP-Kenntnissen gewechselt sind, gewinnt jetzt an Popularität. Es gab die Perl-Sprache (wahrscheinlich bleibt sie immer noch, hat aber viel an Popularität verloren), die Ruby-Sprache. Im Allgemeinen kann eine Bewerbung in alles geschrieben werden. Wenn Sie in der realen Welt leben, sind Sie wahrscheinlich auf die Tatsache gestoßen, dass sie in irgendetwas geschrieben sind: Javascript, Rust, C; finde einen Namen - etwas wurde darauf geschrieben.
Und das alles muss ausgenutzt werden. Es stellte sich heraus, dass in einem solch heterogenen System zum einen Spezialisten erforderlich sind, um sich in verschiedenen Sprachen zu entwickeln, und zum anderen eine Plattform benötigt wird, mit der Sie einen Dienst in einer angenehmen Umgebung starten und seinen Lebenszyklus überwachen können. Es gibt einen bestimmten Vertrag mit dieser Plattform, der in der modernen Welt so aussieht: Sie haben ein Container-Image (das Container-Management-System ist jetzt überall - Docker, obwohl ich nichts Gutes dazu sagen kann; wir werden später über Probleme sprechen).
Trotz der Tatsache, dass sich die Menschheit in einem bestimmten Evolutionsprozess bewegt, hat dieser Prozess Konvergenz. In unserer Branche stellt sich heraus, dass noch jemand Code in Perl (unter mod_perl Apache) schreibt und bereits eine Microservice-Architektur in GoLang schreibt. Es stellte sich heraus, dass der Vertrag mit der Plattform sehr wichtig ist, der Inhalt der Plattform sehr wichtig ist und es sehr wichtig ist, dass die Plattform einer Person hilft. Es wird sehr teuer, manuelle Vorgänge durchzuführen, um den Dienst abzuschließen und zu starten. Ich bin auf Projekte gestoßen, bei denen es 20 Dienstleistungen gab - und es war kein sehr großes Projekt; Ich habe von Leuten gehört, die tausend verschiedene Dienste haben. 20 ist eine normale Menge; und jeder Satz von Diensten wird von seinem eigenen Team in seiner eigenen Sprache entwickelt, sie sind nur durch das Austauschprotokoll verbunden.
In Bezug auf die Funktionsweise des Vertrags für die Anwendung. Es gibt ein "12-Faktor-Anwendungsmanifest" - 12 Regeln für die Anordnung einer Anwendung, damit sie bequem verwendet werden kann. Ich mag ihn nicht. Insbesondere heißt es, dass Sie Konfigurationen über Umgebungsvariablen bereitstellen müssen. und ich bin wiederholt auf die Tatsache gestoßen, dass bei Amazon beispielsweise die Anzahl der Umgebungsvariablen, die an Elastic Beanstalk übergeben werden können, eine Seite des Linux-Kernels ist - 4 Kilobyte. Und sie laufen sehr schnell über; Wenn Sie 80 verschiedene Variablen haben, ist es schwierig, 81 zu verwenden. Darüber hinaus handelt es sich um einen flachen Konfigurationsbereich. Wenn Variablen vorhanden sind, müssen diese in Großbuchstaben mit einem Unterstrich benannt werden, und es gibt keine Hierarchie zwischen ihnen. Es ist schwer zu verstehen, was los ist. Ich habe noch nicht herausgefunden, wie ich damit umgehen soll, und ich habe niemanden, mit dem ich darüber diskutieren kann - es gibt keine Gruppe von Enthusiasten,Wer wäre gegen einen solchen Ansatz. Wenn dies plötzlich auch nicht mehr zu jemandem passt - schreiben Sie mir (Demeliorator in Telegram), ich werde wissen, dass ich nicht allein bin. Ich mag es absolut nicht. Es ist schwierig zu verwalten und hierarchische Daten zu übertragen. Es stellt sich heraus, dass es die Aufgabe eines modernen Ingenieurs ist, zu wissen, wo sich die Variablen befinden, was sie bedeuten, ob sie richtig eingestellt sind und wie einfach es ist, sie zu ändern. Es scheint mir, dass die guten alten Konfigurationsregeln besser waren.ob sie richtig eingerichtet sind, wie einfach es ist, sie zu ändern. Ich denke, die guten alten Konfigurationsregeln waren besser.ob sie richtig eingerichtet sind, wie einfach es ist, sie zu ändern. Es scheint mir, dass die guten alten Konfigurationsregeln besser waren.
Rückkehr zum Vertrag. Es stellt sich heraus, dass Sie ein Docker-Image benötigen: Sie benötigen Docker selbst (trotz der Tatsache, dass es selbst schlecht ist - ich hoffe, dass einige Microsoft sie kaufen und es entweder begraben oder normal entwickeln). Wenn Sie mit Docker nicht zufrieden sind, können Sie Red Hat's Stack ausprobieren. Ich kann nichts dazu sagen, obwohl es mir scheint, dass es besser sein sollte als nur Vanille Kubernetes. Die Mitarbeiter von Red Hat widmen Sicherheitsproblemen viel mehr Aufmerksamkeit. Sie wissen sogar, wie man Installationen mit mehreren Drehungen, mehreren Benutzern und mehreren Clients mit normaler Rechtstrennung durchführt. Im Allgemeinen stellen sie sicher, dass die Rechteverwaltung vorhanden ist.
Lassen Sie uns auf Sicherheitsfragen eingehen. Es ist schlecht mit ihr überall, nicht nur auf Kubernetes. Wenn wir über Sicherheits- und Container-Orchestrierungsprobleme sprechen, habe ich große Hoffnungen auf die Webassemblierung, die von der Serverseite durchgeführt wird, und für Webassemblierungsanwendungen wird es möglich sein, den Ressourcenverbrauch zu begrenzen. Systemaufrufe können in speziellen Containern in Rust gebunden werden. Dies wäre eine gute Antwort auf die Sicherheitsfrage. Und Kubernetes hat keine Sicherheit.
Nehmen wir an, wir haben eine Bewerbung. Es ist ein Docker-Image, es ist ein 12-Faktor - das heißt, es kann Ihre Konfiguration aus Umgebungsvariablen oder aus einer Datei übernehmen, die Sie im Container bereitstellen. Es kann gestartet werden - im Inneren ist es autark, Sie können versuchen, es durch Konfigurationen automatisch mit anderen Anwendungen zu verknüpfen. Und es sollte Protokolle in die Standardausgabe schreiben - was wahrscheinlich das am wenigsten Übel ist; Wenn der Container Protokolle in Dateien schreibt, ist das Sammeln von dort nicht sehr einfach. Sogar Nginx wurde gepatcht, damit Sie Protokolle von der Standardausgabe des Containers sammeln können. Dies ist akzeptabel (im Gegensatz zum Übergeben der Konfiguration über einen Parameter). Tatsächlich hatten wir mehrere Orchestratoren: Rancher, Marathon Mesos, Nomad; aber, wie das Prinzip von Anna Karenina in Bezug auf technische Systeme sagt,komplexe technische Systeme sind auf die gleiche Weise angeordnet.
Mit Kubernetes haben wir die gleiche Situation wie mit Fluggesellschaften mit der Boeing 737 MAX - sie fliegt nicht, weil ein Fehler vorliegt, aber es gibt nichts anderes, weil das Design sehr komplex ist. Ich kann nicht sagen, dass es mir gefällt - wie die GoLang-Sprache und die Steuerung über das YAML-Format, wenn Sie eine Syntax haben und nichts darüber liegt - keine Überprüfung Ihrer Texte, keine Datentypen. Alle Überprüfungen, die Sie vor dem Anwenden von Konfigurationen in Kubernetes durchführen, sind Grundlagen. Sie können versuchen, die falsche Konfiguration anzuwenden, und sie wird ohne Frage angewendet, und Sie wissen nicht, was. Es ist sehr einfach, die falsche Konfigurationsdatei zu schreiben. Dies ist ein großes Problem, und die Leute haben bereits begonnen, es langsam mit DSL und Kubernetes in Kotlin-Sprachen, sogar Typescript, zu lösen. Es gibt ein Pulumi-Projekt,Es gibt ein Amazon-Projekt EKS - obwohl es sich mehr auf Amazon konzentriert. Pulumi ist eine Terraform, nur in Typoskript. Ich wünschte, ich hätte Pulumi schon ausprobiert, weil ich glaube, dass es die Zukunft ist. Die Konfiguration muss in einer Programmiersprache mit starker statischer Typisierung beschrieben werden, damit Sie vor der Anwendung, die möglicherweise den Cluster zerstören kann, zumindest beim Kompilieren darüber informiert werden, dass dies nicht möglich ist.
Somit gibt es im Moment nur einen Orchestrator. Ich weiß, dass noch einige MATA-Benutzer übrig sind. Ich schüttle ihnen die Hand. Ich hoffe, niemand anderes benutzt Docker Swarm - meine Erfahrung damit war ziemlich negativ. Ich glaube, es könnte anders sein, aber ich weiß nicht warum; Ich sehe keine weitere Entwicklung von Docker Swarm voraus und ich glaube nicht, dass die Leute, die es veröffentlichen, jetzt etwas damit anfangen werden. Kapitalismus; Wenn Sie kein Geld verdienen, gibt es nichts, was Sie für die Entwicklung ausgeben können - und das Unternehmen befindet sich seit zwei Jahren im "Tal des Todes" für Start-ups: Niemand möchte ihnen Geld geben. Sie können Gebote abgeben, wer sie kaufen wird. Microsoft war nicht interessiert. Vielleicht schafft es ein Mikrofokus, wenn Docker überlebt.
Da es nur noch ein Kubernetes gibt, lassen Sie uns darüber sprechen. Es gibt ein schönes Bild mit einem Pentagramm von fünf seiner Binärdateien; Es steht geschrieben, dass Kubernetes sehr einfach ist, nur fünf Binärdateien. Ich bin jedoch weit davon entfernt, die Komplexität eines Systems an der Anzahl der Binärdateien zu messen, in die es kompiliert wird, und an der Anzahl der Dienste, die den Kern des Systems ausmachen. Es spielt keine Rolle, wie viele Binärdateien es gibt - was zählt, ist, was Kubernetes kann und wie es intern funktioniert.
Was kann er tun? Stellen Sie sich vor, Sie müssen einem fünfjährigen Kind erklären, was Sie bei der Arbeit getan haben. Und so sagt Papa, der versucht hat, Playbooks und Rollen auf Ansible zu schreiben, die es ihm ermöglichen würden, eine blaugrüne Bereitstellung basierend auf Nginx auf einem Host und einer Reihe von Containern durchzuführen, die nicht für etwas anderes als tv-ansible registriert sind: „Weißt du, mein Sohn, ich habe alles versucht Es ist Zeit, deine eigenen Kubernetes zu machen. Es funktioniert nicht gut, es ist schlecht getestet, ich verstehe es nicht gut, ich kenne nicht alle Randbedingungen, es funktioniert innerhalb derselben Maschine, aber es gehört mir! " Ich habe das ungerechtfertigt oft gesehen - ich habe es nur 2 oder 3 Mal gesehen und 2 Mal habe ich daran teilgenommen, so etwas zu schreiben. Früher oder später erkennt eine Person, die daran teilnimmt, dass es kein viertes Mal geben sollte. Es ist wie bei meinen AutofreundenWer einst die VAZ-2101 restaurierte - installierte elektrische Fensterheber, reparierte den Innenraum mit Herde, lackierte ihn in Metallic. Das Erstellen eines eigenen Orchestrators ist ungefähr so. Sie können es einmal versuchen, um sicherzustellen, dass Sie es können, aber ich bin nicht bereit, es jedem zu empfehlen - nicht nur Enthusiasten. Daher ist das Lifecycle Management und das Container State Management die Aufgabe von Kubernetes.
Er kann sicherstellen, dass der Container auf dem Knoten ausgeführt wird, auf dem sich Ressourcen befinden. Er kann einen toten Container neu starten. Er kann sicherstellen, dass der Datenverkehr nicht gestartet wird, wenn der Container nicht gestartet wird, wenn eine neue Bereitstellung erfolgt. Wir haben auch damit begonnen, dass Kubernetes das Betriebssystem ist. Wo sich das Betriebssystem befindet, sollte ein Paketmanager vorhanden sein. Als Kubernetes begann, waren Objektbeschreibungen unerlässlich; Stateful Set und Codebeschreibung sind Beschreibungen, die direkt funktionieren, und Sie müssen etwas hinzufügen, um den Status Ihres [??? 18:52 - Aufnahmefehler]. Der radikale Unterschied zu Ansible und anderen ähnlichen Konfigurationsmanagementsystemen besteht darin, dass Sie in Kubernetes beschreiben, was sich herausstellen soll, nicht wie es sich herausstellen soll. Sie beschreiben natürlichWelche Objekte haben Sie und welche Eigenschaften haben sie. Objekte sind Service, Deployment, Daemonset, Statefulset. Es ist interessant, dass es neben den Objekten, die standardmäßig erstellt werden können, auch benutzerdefinierte Objekte gibt, die in Kubernetes beschrieben und erstellt werden können. Es ist sehr nützlich; Es wird auch die Reihen der Sysadmins und Entwickler erheblich verringern.
Wann wird Kubernetes sterben?
Gute Frage. Kommt darauf an, was mit dem Wort "sterben" gemeint ist. Hier ist Docker - vor einem Jahr haben wir uns auf einer Konferenz in St. Petersburg getroffen, es gab einen runden Tisch, und wir haben gemeinsam entschieden (da wir eine Branche sind, glaube ich, dass es dort eine qualifizierte Mehrheit gibt und wir es uns leisten können, für alle zu sprechen), dass Docker bereits gestorben. Warum? Denn auf der Konferenz gab es keine Gespräche über Docker, obwohl es nicht so viele Jahre alt ist. Niemand hat etwas über ihn erzählt. Wir sprachen über Kubernetes, über die nächsten Schritte - Kube Flow, zum Beispiel über die Verwendung von Operatoren, über das Platzieren von Kubernetes-Basen. Alles andere als Docker. Dies ist der Tod - wenn Sie so schlecht sind, dass Sie am Leben zu sein scheinen, aber niemand zu Ihnen kommt.
Docker ist bereits tot. Wenn Kubernetes stirbt - warten wir 5 Jahre. Er wird nicht sterben, jeder wird es haben - es wird in Tesla sein, in Ihrem Telefon, überall, und niemand wird daran interessiert sein, darüber zu sprechen. Ich denke das ist der Tod. Vielleicht nicht einmal in 5 Jahren, sondern in 3. Eine andere Frage ist, was es ersetzen wird: eine laute neue Technologie, über die alle sprechen werden, vielleicht überhaupt nicht aus der DevOps-Welt. Jetzt reden sie über Kubernetes, nur um das Gespräch am Laufen zu halten, und das ist okay - es ist in Mode.
Was ist los mit Docker?
Alle. Dies ist eine einzelne Binärdatei für die Verwaltung von allem. Dies ist ein Dienst, der im System gestartet werden muss. Dies ist ein Teil, der ebenfalls über einen Socket gesteuert wird. Dies ist ein Produkt mit viel Code, der, wie ich denke, von niemandem überprüft wurde. Dies ist ein Produkt, für das es im Großen und Ganzen kein Unternehmensgeld gibt. Red Hat hat sehr kluge Leute, ich habe großen Respekt vor ihnen, und wenn Sie ein durchschnittlicher Ingenieur sind, sollten Sie sich ansehen, was sie tun, da dies die Landschaft für die nächsten 5 Jahre bestimmen könnte. Nun, Red Hat hat Docker völlig über Bord geworfen. Sie bewegen sich darauf zu, ihn nicht zu haben. Bisher können sie dies nicht bis zum Ende tun, aber sie sind nah dran und werden früher oder später Docker beenden. Er hat zusätzlich zu allem, was ich aufgelistet habe, einen riesigen Angriffsbereich. Es gibt dort keine Sicherheit. Es wurden nicht viele CVEs darauf angesprochen, aber wenn man sie sich ansieht, ist es klar, dassWie bei jedem anderen Projekt, bei dem die Sicherheit nicht im Vordergrund steht, wird sie auf der Basis von Resten behandelt. Das ist das Gesetz. Sicherheit ist lang, teuer, trostlos, schränkt den Entwickler ein und verkompliziert das Leben erheblich. Sicherheit richtig zu machen ist harte Arbeit und man muss dafür bezahlen. Wenn Sie mit einem Sicherheitsexperten sprechen, egal welche Qualifikationen Sie haben, werden Sie viele Horrorgeschichten über Docker und Geschichten darüber hören, wie schlimm die Dinge sind. Sie sind teilweise mit Docker selbst verwandt, teilweise mit den Personen, die es bedienen, aber Docker selbst könnte Personen helfen und einige Sicherheitskontrollen in sich selbst durchführen. Starten Sie beispielsweise keinen Prozess in einem Container von root aus, es sei denn, Sie werden ausdrücklich dazu aufgefordert.schränkt den Entwickler ein, macht das Leben sehr schwer. Sicherheit richtig zu machen ist harte Arbeit und man muss dafür bezahlen. Wenn Sie mit einem Sicherheitsexperten sprechen, egal welche Qualifikationen Sie haben, werden Sie viele Horrorgeschichten über Docker und Geschichten darüber hören, wie schlimm die Dinge sind. Sie sind teilweise mit Docker selbst verwandt, teilweise mit den Personen, die es bedienen, aber Docker selbst könnte Menschen helfen und einige Sicherheitskontrollen in sich selbst durchführen. Starten Sie beispielsweise keinen Prozess in einem Container von root aus, es sei denn, Sie werden ausdrücklich dazu aufgefordert.schränkt den Entwickler ein, macht das Leben sehr schwer. Sicherheit richtig zu machen ist harte Arbeit und man muss dafür bezahlen. Wenn Sie mit einem Sicherheitsexperten sprechen, egal welche Qualifikationen Sie haben, werden Sie viele Horrorgeschichten über Docker und Geschichten darüber hören, wie schlimm die Dinge sind. Sie sind teilweise mit Docker selbst verbunden, teilweise mit den Personen, die es bedienen, aber Docker selbst könnte Personen helfen und einige Sicherheitskontrollen in sich selbst durchführen. Starten Sie beispielsweise keinen Prozess in einem Container von root aus, es sei denn, Sie werden ausdrücklich dazu aufgefordert.teilweise - mit den Leuten, die es ausnutzen, aber Docker selbst könnte den Leuten helfen und einige Sicherheitskontrollen in sich selbst durchführen; Starten Sie beispielsweise keinen Prozess in einem Container von root aus, es sei denn, Sie werden ausdrücklich dazu aufgefordert.teilweise - mit den Leuten, die es ausnutzen, aber Docker selbst könnte den Leuten helfen und einige Sicherheitskontrollen in sich selbst durchführen; Starten Sie beispielsweise keinen Prozess in einem Container von root aus, es sei denn, Sie werden ausdrücklich dazu aufgefordert.
Wie speichere ich Zustände? Kann ich die Datenbank auf Kubernetes hosten?
Wenn Sie den DBA oder die Person fragen, die für die Infrastruktur dieser Datenbank verantwortlich war, bevor Sie sich entschieden haben, sie auf Kubernetes zu stellen, sagt diese Person Nein. Ich denke, an vielen runden Tischen werden die Leute sagen, dass es in Kubernetes keine Datenbanken geben sollte: Es ist schwierig, unzuverlässig, es ist nicht klar, wie man es verwaltet.
Ich glaube, dass DBs in Kubernetes vertreten sein können. Wie zuverlässig ist es? Schauen Sie: Wir haben es mit einem verteilten System zu tun. Wenn Sie eine Datenbank in einen Cluster einfügen, müssen Sie verstehen, dass eine Fehlertoleranz erforderlich ist. Wenn Sie eine solche Anforderung haben, ist es höchstwahrscheinlich ein Datenbankcluster, den Sie in Ihre Kubernetes einfügen. Wie viele Menschen in der modernen Welt wissen, wie man einen normalen Datenbankcluster erstellt? Bieten viele Datenbanken Clustering-Funktionen? Hier beginnt die Aufteilung der Datenbanken in traditionelle - relationale und nicht relationale. Ihr Unterschied besteht nicht darin, dass letztere SQL in der einen oder anderen Form nicht unterstützen. Der Unterschied besteht darin, dass nicht relationale Datenbanken viel besser für die Arbeit in Clustern geeignet sind, da sie ursprünglich so geschrieben wurden, dass die Datenbank verteilt wurde. Deshalb,Wenn Sie für eine MongoDB oder Cassandra Hosting in Kubernetes durchführen möchten, kann ich Sie nicht davon abhalten, aber Sie sollten eine sehr gute Vorstellung davon haben, was als nächstes passieren wird. Sie sollten sehr gut verstehen, wo sich Ihre Daten befinden, was im Falle eines Fehlers und einer Wiederherstellung passieren wird, wie die Sicherungen ablaufen, wo sich der Wiederherstellungspunkt befindet und wie lange die Wiederherstellung dauern wird. Diese Fragen sind für Kubernetes nicht relevant. Sie haben damit zu tun, wie Sie im Grunde eine Clusterlösung betreiben, die auf herkömmlichen Datenbanken basiert. Mit NoSQL-Lösungen ist es einfacher, sie sind sofort Cloud-fähig.Wo befindet sich der Wiederherstellungspunkt und wie lange dauert die Wiederherstellung? Diese Fragen sind für Kubernetes nicht relevant. Sie haben damit zu tun, wie Sie im Grunde eine Clusterlösung betreiben, die auf herkömmlichen Datenbanken basiert. Mit NoSQL-Lösungen ist es einfacher, sie sind sofort Cloud-fähig.Wo befindet sich der Wiederherstellungspunkt und wie lange dauert die Wiederherstellung? Diese Fragen sind für Kubernetes nicht relevant. Sie haben damit zu tun, wie Sie im Grunde eine Clusterlösung betreiben, die auf herkömmlichen Datenbanken basiert. Mit NoSQL-Lösungen ist es einfacher, sie sind sofort Cloud-fähig.
Trotzdem stellt sich die Frage, warum die Datenbank in Kubernetes abgelegt wird. Sie können einen von Ihrem Anbieter bereitgestellten Dienst in Anspruch nehmen, eine verwaltete Lösung. Sie können RDS bei Amazon und verwaltete Datenbanken bei Google verwenden. Und selbst ein geografisch verteilter Cluster dieser Datenbank, im Fall von Amazon, Aurora, können Sie installieren und verwenden. Wenn Sie jedoch einen geografisch verteilten Cluster der Basis installieren möchten, lesen Sie die Dokumentation sorgfältig durch. Ich bin auf Aurora-Cluster mit einem einzelnen Knoten gestoßen - sie wurden nicht einmal in zwei Regionen aufgeteilt. Darüber hinaus wurde die zweite Region überhaupt nicht benötigt. Im Allgemeinen haben Menschen sehr seltsame Dinge im Kopf: Sie glauben, dass die Hauptsache darin besteht, ein Produkt auszuwählen, und dann wird es sich selbst versorgen und so funktionieren, wie es sollte. Nein. Relationale Datenbanken waren selbst in einem regulären Cluster überhaupt nicht betriebsbereit.Ganz zu schweigen von der geografischen Verteilung. Wenn Sie daher etwas Komplexes basierend darauf ausführen, lesen Sie die Dokumentation.
Grundsätzlich habe ich Erfahrung im Betrieb einer Datenbank in Kubernetes. Es gab nichts Schreckliches. Es gab mehrere Abstürze im Zusammenhang mit dem Herunterfallen des Knotens. Der Umzug funktionierte normal zu einem anderen Knoten. Alles unter Kontrolle. Das einzige, was ich Ihnen nicht gefallen kann und sagen kann, dass es eine große Anzahl von Tausenden von Anfragen pro Sekunde gab.
Wenn Sie eine mittlere oder kleine Lösung haben - eine durchschnittliche Lösung für Russland entspricht in etwa einer großen Nachrichtenagentur wie Lenta -, sollte die Datenbank keine große Anzahl komplexer Abfragen enthalten. Wenn die Basis ausfällt, machen Sie wahrscheinlich etwas falsch und müssen darüber nachdenken. Skaliere nicht gedankenlos. Das Verschieben einer nicht geclusterten Lösung in einen Cluster hat seine Vorteile, aber auch eine Vielzahl von Nachteilen - insbesondere, wenn Sie einen Postgres-Cluster verwenden, der auf Patroni oder Stallone basiert. Es gibt viele Randbedingungen; Ich bin ihnen nicht begegnet, aber Kollegen von Data Egret erzählen Ihnen gerne, wie es passiert. Es gibt einen wunderbaren Bericht von Alexei Lesovsky darüber, was passieren wird, wenn Sie versuchen, Ihre Basis ohne nachzudenken auf einen Cluster zu übertragen.
Über Tausende von Anfragen pro Sekunde. Wenn Sie über eine einzelne DB-Instanz verfügen, wird die Optimierung mit Tausenden von Anforderungen pro Sekunde immer noch vergrößert. Früher oder später werden Sie in Schwierigkeiten geraten. Es scheint mir, dass es besser ist, horizontale Skalierungsoptionen in Betracht zu ziehen, wenn eine schwere Last geplant ist. Suchen Sie die größte Tabelle in Ihrer Datenbank, sehen Sie, was dort vorhanden ist, und überlegen Sie, ob sie in einen nicht relationalen Speicher verschoben werden kann. Überlegen Sie, wie Sie nicht in einer relationalen Datenbank speichern, was Sie normalerweise darin speichern - zum Beispiel Systemzugriffsprotokolle, von denen es viele Drops gibt, und Sie greifen normalerweise nach demselben Muster zu, nach dem Sie auf den Schlüsselwertspeicher zugreifen ... Warum also nicht Protokolle in Cassandra schreiben? Dies ist eine Frage für einen Architekten. Es ist genau das Richtige, eine kleine und nicht sehr ausgelastete Basisinstanz in Kubernetes zu behaltenweil die Magie des Bedieners beginnt, dafür verantwortlich zu sein.
Wenn Sie sich ansehen, was Kubernetes als Betriebssystem und Plattform ist, dann ist dies im Grunde ein Do-it-yourself-Konstruktor. Sie haben alles, um eine Microservice-Architektur zu erstellen, einschließlich der Möglichkeit, Status auf Datenträgern zu speichern, Telemetrie, Überwachung und Alarmierung zu organisieren. Dies erledigt Helm, der Kubernetes-Paketmanager. Es gibt eine große Anzahl von öffentlich zugänglichen Open Source-Helmkarten im Internet. Der einfachste Weg, die Infrastruktur eines Projekts zu verbessern, besteht darin, das Helmdiagramm zu verwenden, in dem Ihre Anwendung und Ihr Dienst aufgeführt sind, wenn es sich bei diesem Dienst um eine Redis-Datenbank, PostgreSQL oder Patroni handelt. Starten Sie die Konfiguration und wenden Sie diese Konfiguration an. Es ist völlig deklarativ; Was auch immer vorhergesehen werden kann, die Autoren der Helm-Charts stellen normalerweise zur Verfügung. Ihre Anwendung wird am besten auch mit Helm veröffentlicht.Der dritte Helm enthält keine cluster-seitigen Dienste. Der zweite enthielt, er hatte einen Dienst, der ständig vom Cluster-Administrator arbeitete, der notwendig war, um Releases nach Namespace zu verteilen, aber der dritte Helm schloss diese Sicherheitslücke.
Helm ist eine solche Vorlagen-Engine, die auf der GoLang-Vorlagensyntax basiert. Es braucht eine Liste von Variablen, die eine nicht planare Struktur sind (Gott sei Dank, hierarchisch - geschrieben in YAML); Mit Helm werden diese Variablen an den richtigen Stellen in Helmvorlagen platziert. Anschließend wenden Sie alles in einem Namespace an. Dort werden Ihre Codes und Dienste gestartet und Ihre Rollen erstellt. Es gibt einen Gerüstgenerator, mit dem Helmkarten geschrieben werden können, ohne das Bewusstsein wiederzugewinnen. Das einzige, was mir nicht gefällt, ist die Notwendigkeit, die Syntax von GoLang-Vorlagen und bedingten Verzweigungen in Helm selbst zu kennen. Sie werden nach dem Lisp-Prinzip mit Präfixnotation hergestellt. Es ist gut, dass es jemand anderem gefällt, aber es lässt den Kopf jedes Mal wechseln. Nun, wir werden darüber hinwegkommen.
Nun ein wenig darüber, was als nächstes passieren wird. Ich ähnelte bereits Betreibern; Dies sind die Dienste, die im Kubernetes-Cluster leben und den Lebenszyklus einer anderen, größeren Anwendung verwalten. Hart genug. Sie können sich einen Betreiber als Ihren Silizium-Home-Site-Zuverlässigkeitsingenieur vorstellen. Sicherlich werden die Leute in Zukunft immer mehr Operatoren schreiben, weil niemand einen Wechsel der Leute auf der ersten Support-Ebene beibehalten möchte, die dem Nagios-Zeitplan folgen, Ausfälle bemerken und manuelle Maßnahmen ergreifen würden. Der Bediener versteht, welche Systemzustände möglich sind; es ist eine Zustandsmaschine. Jetzt wird die Konzentration menschlichen Wissens, geschrieben in der GoLang-Sprache oder dergleichen, kompiliert, in einem Cluster zusammengefasst und erledigt eine Menge Arbeit für Sie: Hinzufügen oder Entfernen von Knoten, Neukonfigurieren, Sicherstellen, dass der Gefallene aufsteigt,so dass die Daten an den gewünschten Codes andocken, von wo sie sind. Im Allgemeinen verwaltet es den Lebenszyklus dessen, was darunter installiert ist. Betreiber sind jetzt buchstäblich für alles. Ich hatte Spaß mit der Tatsache, dass ich mit dem Rook-Operator sev direkt in den Kubernetes-Cluster eingefügt habe. Ich habe mir angesehen, wie dies geschieht, und ich bin sehr glücklich, und ich denke, dass mehr Bediener benötigt werden, und wir sollten alle daran teilnehmen, sie zu testen. Die Zeit, die Sie damit verbringen, den Operator eines anderen zu korrigieren, ist ein Geschenk an die Menschheit. Sie müssen nicht mehr immer und immer wieder den gleichen Job machen. Sie können diese Arbeit in einer entfremdeten Form in das Repository stellen, und dann erledigt ein intelligentes Programm dies für Sie - ist es nicht Glück?Betreiber sind jetzt buchstäblich für alles. Ich hatte Spaß daran, dass ich mit dem Rook-Operator sev direkt in den Kubernetes-Cluster eingefügt habe. Ich habe mir angesehen, wie dies geschieht, und ich bin sehr glücklich, und ich denke, dass mehr Bediener benötigt werden, und wir sollten alle an ihren Tests teilnehmen. Die Zeit, die Sie damit verbringen, den Operator eines anderen zu korrigieren, ist ein Geschenk an die Menschheit. Sie müssen nicht mehr immer und immer wieder den gleichen Job machen. Sie können diese Arbeit in einer entfremdeten Form in das Repository stellen, und dann erledigt ein intelligentes Programm dies für Sie - ist es nicht Glück?Betreiber sind jetzt buchstäblich für alles. Ich hatte Spaß daran, mit dem Rook-Operator sev direkt in den Kubernetes-Cluster zu stellen. Ich habe mir angesehen, wie dies geschieht, und ich bin sehr glücklich, und ich denke, dass mehr Bediener benötigt werden, und wir sollten alle daran teilnehmen, sie zu testen. Die Zeit, die Sie damit verbringen, den Operator eines anderen zu korrigieren, ist ein Geschenk an die Menschheit. Sie müssen nicht mehr immer und immer wieder den gleichen Job machen. Sie können diese Arbeit in einer entfremdeten Form in das Repository stellen, und dann erledigt ein intelligentes Programm dies für Sie - ist es nicht Glück?Dass Sie für die Korrektur des Operators eines anderen ausgeben, ist ein Geschenk an die Menschheit. Sie müssen nicht mehr immer und immer wieder den gleichen Job machen. Sie können diese Arbeit in einer entfremdeten Form in das Repository stellen, und dann erledigt ein intelligentes Programm dies für Sie - ist es nicht Glück?Dass Sie für die Korrektur des Operators eines anderen ausgeben, ist ein Geschenk an die Menschheit. Sie müssen nicht mehr immer und immer wieder den gleichen Job machen. Sie können diese Arbeit in einer entfremdeten Form in das Repository stellen, und dann erledigt ein intelligentes Programm dies für Sie - ist es nicht Glück?
Ich habe das Red Hat-Buch heruntergeladen - sie geben es kostenlos heraus -, wie Kubernetes-Betreiber funktionieren und wie Sie Ihr eigenes schreiben. Ich empfehle Ihnen, auf deren Website zu gehen und es auch herunterzuladen. Das Buch ist sehr interessant. Wenn ich es vollständig gelesen habe, können wir vielleicht gemeinsam einen Operator analysieren.
Wer unterstützt Swarm? Neben Docker Inc?
Niemand. Und Docker Inc. bereits in zwei Hälften zerrissen und eine Hälfte irgendwo verkauft. Ich verfolge nicht, was mit ihnen passiert; Zu einer Zeit nannten sie das Produkt Mobi, aber es war eine Open-Source-Version, das heißt, es war keine Open-Version. Und etwas wurde mit Rechten verkauft, aber etwas wurde nicht verkauft. Für mich sieht es aus wie ein „kranker Mensch, der vor seinem Tod schwitzt“ - die Leute versuchen irgendwie, das Geld, das sie investiert haben, herauszuholen. Im Allgemeinen unterstützt es niemand.
Master / Slave
Es klappt. Wenn Master / Slave nicht mehr in einer relationalen Datenbank arbeitet, endet die Welt dort. Kubernetes stört den Betrieb der Datenbank in keiner Weise. Das einzige, was es bringt, sind verschiedene Gesundheitschecks, die auf Wunsch deaktiviert werden können, und im Prinzip die staatliche Verwaltung. Es ist ratsam, sie nicht zu deaktivieren. Ihr Bediener, der die Datenbank verwaltet, sollte ihren Status sehen.
Wie heißt das Red Hat-Buch?
Kubernetes Operators heißt so. Die Ente wird dort gezeichnet. O'Reillys Buch, das jetzt die Umschläge neu gestaltete; In Zusammenarbeit mit Red Hat wurden einige Bücher veröffentlicht. Red Hat hat 3 oder 4 weitere Kubernetes-Bücher, die Sie kostenlos herunterladen können: zum Beispiel Kubernetes Patterns, gRPC. Das gRPC-Protokoll ist zwar nicht direkt mit Kubernetes verbunden, wird jedoch von vielen zum Datenaustausch zwischen Mikrodiensten verwendet. Darüber hinaus wird es in Load Balancern der nächsten Generation verwendet, z. B. in Envoy.
Was ist eine SRA?
Dies ist die Art von Person, die den Zeitrahmen von Änderungen in einem verteilten System versteht. Grob gesagt versteht er, wie lange Sie diesen Monat gelegen haben, wie viel mehr Sie können, ob Sie die Erlaubnis für die Veröffentlichung geben können. Verwaltet Schlüssel aus Backups, Wiederherstellungsplänen, Disaster Recovery-Problemen und Infrastrukturwartungsproblemen für eine industrielle Anwendung, die rund um die Uhr funktionieren sollte. Es enthält Metriken für den Status und den Geschäftsstatus der Anwendung in den Anwendungsmetriken - wie viel Latenz, wo und wie viele Anforderungen; die gleichen 4 Goldsignale. Darüber hinaus kann die SRA auf der Grundlage dieser Metriken Schritte unternehmen, um das System wieder in Kampfbereitschaft zu bringen. Er hat einen Plan, wie dies zu tun ist. Aus irgendeinem Grund ist dies für klassische DevOps nicht erforderlich. Es hilft dem Entwickler lediglich, die Anwendung zur Veröffentlichung zu bringen und sie im Allgemeinen irgendwo einzuführen.Und SRA widersetzt sich auch dem Fluss von Anfragen von verschiedenen Seiten.
Ich habe versprochen, über Sicherheit zu sprechen. Sie wissen, das ist ein ziemlich junges Thema in Kubernetes. Ich kenne nur die Grundlagen: Zum Beispiel, dass Sie eine Anwendung in einem Dienst nicht von root aus ausführen sollten, da sie in diesem Fall Zugriff auf alles im Namespace und auf die Superuser-Rechte hat und Sie versuchen können, den Kern des Host-Systems zu beschädigen. wahrscheinlich wird es funktionieren (und alle anderen Operationen von der Wurzel ausführen). Geben Sie Hackern keinen solchen Hinweis. Wenn möglich, geben Sie den Benutzern so wenig Rechte wie möglich und verarbeiten Sie Benutzereingaben gut. Es scheint mir, dass wenn wir über die Sicherheit von Kubernetes sprechen, diese irgendwo in den geschlossenen Kreisläufen entfernt werden muss, die wir derzeit haben. Wenn Sie sich wirklich mit Sicherheitsproblemen befassen möchten, sollten Sie sich das Cilium-Projekt ansehen. Er weiß, wie man Überspannungsschutz benutzt,BPF-basierte Differenzierung des Netzwerkverkehrs - dies funktioniert besser als iptables. Das ist die Zukunft. Es scheint mir, dass außerhalb Kaliforniens niemand es wirklich benutzt, aber Sie können bereits anfangen. Vielleicht gibt es ein anderes Projekt, aber ich bezweifle es. Im Allgemeinen hat die Menschheit nur wenige arbeitende Hände.
Daher habe ich nichts Besonderes zur Sicherheit zu sagen. In Kubernetes gibt es verschiedene Optionen für das gemietete Mietverhältnis. Dort müssen Sie jedoch mit einem Bleistift sitzen und herausfinden, was die Leute getan haben, welche Sicherheitslücke sie geschlossen haben, ob es sinnvoll ist, ob es für Ihr Bedrohungsmodell gilt. Übrigens empfehle ich, zunächst nach einer Beschreibung zu suchen, wie das Bedrohungsmodell erstellt wird, und es selbst zu erstellen. Es gibt mehr oder weniger formale Methoden. Zeichnen Sie, schauen Sie es sich an, und vielleicht wird ein Einblick entstehen, und Sie werden verstehen, was Sie brauchen und was in der aktuellen Situation nicht benötigt wird. Vielleicht reicht es aus, alle Kubernetes in einen geschlossenen Kreislauf zu bringen. Dies ist übrigens die richtige Entscheidung; Ich bin darauf gestoßen und es ist undurchdringlich. Wenn Sie nur durch Vorlage eines Passes auf der Uhr Zugriff auf das System erhalten können und kein Internet vorhanden ist und der Austausch über ein spezielles Gateway erfolgt,befindet sich in der DMZ und ist schwer zu brechen, weil es ungewöhnlich geschrieben ist - dann ist es ein gut geschütztes System. Wie es mit technischen Mitteln geht - nun, Sie müssen den aktuellen Markt für Lösungen überwachen. Es ändert sich sehr, Sicherheit ist ein heißes Thema. Es gibt viele Spieler, die versuchen zu sein, aber welcher von ihnen lügt und wer nicht - ich nehme nicht an zu sagen. Während Red Hat wahrscheinlich nicht lügt, ist es nicht jedem voraus. Sie müssen nur recherchieren (und ich auch), weil es noch nicht klar ist.Sie müssen nur recherchieren (und ich auch), weil es noch nicht klar ist.Sie müssen nur recherchieren (und ich auch), weil es noch nicht klar ist.
Lassen Sie uns darüber sprechen, was der Kubernetes-Cluster sonst noch haben sollte. Da wir dort die Möglichkeit haben, Anwendungen kostenlos zu installieren, haben wir keine Angst, die Datenbank dort zu speichern. Wenn Sie über verwaltete Kubernetes verfügen, gibt es übrigens keine Fragen zum Speichern der Datenbank: Sie verfügen über fehlertoleranten Speicher in der einen oder anderen Form (häufig in Form von Blockgeräten), der aus der Cloud bereitgestellt wird, in der sich verwaltete Kubernetes befinden. Sie können Festplatten aus diesem Speicher sicher in Ihrem Cluster ablegen und Snapshots verwenden, um konsistente Sicherungen zu erstellen. Vergessen Sie nur nicht, dass der Snapshot kein Backup ist. Sie müssen den Snapshot auch irgendwo kopieren. Dies ist offensichtlich, aber die offensichtlichen Dinge lassen sich gut wiederholen, damit sie nicht vergessen werden.
Wenn Sie über eine Microservice-Architekturplattform verfügen, ist es sehr wichtig, diese nachvollziehbar und beobachtbar zu machen, damit Sie verstehen, wo sich Anforderungen befinden und wo sie Zeit verschwenden usw. Der Aufbau einer solchen Plattform ist viel Arbeit. Du wirst Prometheus brauchen. Es wird benötigt, da es sich um ein Projekt der Cloud Native Computing Foundation handelt. Es wurde speziell zur Überwachung von Kubernetes entwickelt. Enthält eine große Anzahl von Exporteuren, Metriksammlern; Einige Anwendungen enthalten nativ alle Dashboards. Wenn Ihre Anwendung diese nicht enthält, dauert das Anhängen an die langlebige Prometheus-Dashboard-Anwendung 20 Minuten. Obwohl aus irgendeinem Grund niemand es anbringt. Nach meiner Erfahrung geschieht dies, weil Menschen ihre Produkte in den Wolken halten. Es gibt Amazon CloudWatch, Google StackDriver,und Sie können Metriken auf die gleiche Weise dorthin senden - obwohl dies Geld kostet. Das heißt, wenn die Leute immer noch für die Infrastruktur bezahlen, bezahlen sie für die damit verbundenen Überwachungstools. Trotzdem kann Prometheus sehr praktisch sein, wenn Sie mehrere verschiedene Orte haben, an denen Sie Metriken abrufen, wenn sich die Cloud nicht an einem Ort befindet, wenn sie hybride ist, wenn Sie über lokale Maschinen verfügen und eine zentralisierte Infrastruktur benötigen. Dann ist Prometheus Ihre Wahl.Wenn Sie über lokale Maschinen verfügen und eine zentralisierte Infrastruktur benötigen. Dann ist Prometheus Ihre Wahl.Wenn Sie über lokale Maschinen verfügen und eine zentralisierte Infrastruktur benötigen. Dann ist Prometheus Ihre Wahl.
Was brauchst du noch? Es ist klar, dass bei Prometheus auch ein Alert Manager erforderlich ist. Außerdem benötigen Sie eine verteilte Verfolgung Ihrer Anforderungen. Wie das in Kubernetes geht - nimm ein Produkt wie Jaeger oder Zipkin oder was auch immer gerade oben ist; auch Cassandra, um deine Spuren zu speichern, auch Grafana, um sie zu rendern. Soweit ich weiß, wurde diese Funktion kürzlich in Grafana veröffentlicht, aber dies ist kein Grund, sie nicht zu implementieren. Das heißt, Sie können manuell eine Umgebung zusammenstellen, in der Anwendungen [Pannen 49:14] (haben?) Zu dieser Laufzeit sowohl Zähler als auch andere Metriken, die zum Erstellen und Visualisieren Ihrer verteilten Traces geeignet sind: Wo verbringt die Anwendung wie lange?
Es ist weniger bequem, darüber zu sprechen als es zu zeigen, aber es gibt nichts, was ich jetzt zeigen könnte; Ich habe jetzt nichts davon in meinem Labor. Eines Tages werde ich mich wahrscheinlich fertig machen.
Ich glaube, ich habe alles erzählt, was ich erzählen wollte. Ich werde die wichtigsten Bestimmungen noch einmal wiederholen.
Erstens: Kubernetes befreit Sie von der Notwendigkeit, einen Mechanismus zum ausfallsicheren Ersetzen eines Containers durch einen anderen selbst auf Ansible Engine X zu schreiben.
Zweitens: Kubernetes wird nirgendwo verschwinden. Es kann "sterben", aber es ist nicht mehr möglich, es nicht mehr zu benutzen, es hat den größten Teil des Marktes erobert. Auf die Frage "Wann wird Kubernetes sterben:" Ich möchte fragen "Wann wird WordPress sterben?" Und er muss noch leben und leben Lassen Sie uns die Reihenfolge festlegen: zuerst WP, dann Kubernetes.
Kubernetes ist also bei uns. Es ist eher nicht er, der interessant ist, aber die Dienste, die oben aufgewickelt werden, sind interessant - dies sind Operatoren und benutzerdefinierte Ressourcendefinitionen. Die Möglichkeit, Ihre eigene Ressource, die als "PostgreSQL-Cluster" bezeichnet wird, zu übernehmen und zu schreiben, beschreibt sie mit einem YAML-Fußtuch und wirft sie in den Cluster.
Was wird sonst noch passieren? Es wird auch die Möglichkeit geben, all diese statisch typisierten Programmiersprachen wie GoLang und TypeScript zu verwalten. Und ich glaube wirklich an Kotlin - viele coole DSLs sind bereits darauf geschrieben. Und es wird noch mehr geschrieben.
Es gibt auch kostenpflichtige Helm-Charts, kostenpflichtige Anwendungen, die vor Ort gestartet werden können, einige lizenzierte, per Abonnement. Es wird eine Integration verschiedener Dienste geben - tatsächlich gibt es diese bereits, zum Beispiel integriert DataDog bereits in Kubernetes. Und neue Leute, die auf dem Markt für Überwachungsalarme erscheinen werden, werden sich aus offensichtlichen Gründen auch in Kubernetes integrieren. Ein Cloud-Produkt wird auf die eine oder andere Weise nicht an Kubernetes vorbeikommen. Dies ist die Plattform, auf die jeder abzielen wird.
Aber das alles bedeutet nicht, dass Kubernetes gut ist und nichts könnte besser sein. Ich vergleiche es mit dem, was es vorher war - mit Amazon-Lösungen: ECS, Elastic Beanstalk. Diejenigen, die auf sie gestoßen sind, wissen, dass in meiner alten Analogie das eine, das andere nicht nur 737 MAX, sondern 737 MAX aus Klebeband und Plastilin wäre. Daher sind die Hauptakteure - Amazon, Microsoft Azure, Google - bereits in Kubernetes. Wahrscheinlich sind es auch Yandex und Mail.ru, aber ich folge ihnen nicht. Dies ist eine so gemeinsame Zukunft. Eine so schlechte, aber "gut genug" gemeinsame Zukunft, über die sich bisher alle einig sind. Was ist das alles Mutation weiter, müssen Sie Red Hat fragen - sie sind schlauer als ich.
Wie steht Java zu Kubernetes?
Fein.
Welches Betriebssystem verwenden Sie auf Ihrem PC?
Beide sind unter macOS.
Werden DevOps-Spezialisten jetzt aktiv eingestellt?
Ja, sie wurden immer aktiv an einem entfernten Ort aufgenommen, und jetzt werden sie auf die gleiche Weise aktiv aufgenommen. Die Situation wird sich nicht grundlegend ändern, denke ich. Generell betrachte ich nicht ungelöste Arbeit: Nicht jedes gute Unternehmen hat ein Büro in St. Petersburg. Natürlich wird es eine Distanz geben, und aktuelle Ereignisse haben den Menschen gezeigt, dass dies möglich ist. Die Zahl der Menschen, die sich damit besser auskennen, wird nur noch zunehmen. Uns wird gesagt, dass „viele Leute es versucht haben und zurück ins Büro gegangen sind“ - nun, zurück ins Büro zu gehen kostet Geld. Kein Geld - keine Wahl, und viele Unternehmen sparen jetzt.
Was ist vorher passiert?
- Ilona Papava, Senior Software Engineer bei Facebook - wie man ein Praktikum bekommt, ein Angebot bekommt und alles über die Arbeit in einem Unternehmen
- Boris Yangel, Yandex ML-Ingenieur - wie man sich als Data Scientist nicht den dummen Spezialisten anschließt
- Alexander Kaloshin, LastEO LastBackend - wie man ein Startup startet, in den chinesischen Markt eintritt und 15 Millionen Investitionen erhält.
- , Vue.js core team member, GoogleDevExpret — GitLab, Vue Staff-engineer.
- , DeviceLock — .
- , RUVDS — . 1. 2.
- , - . — .
- , Senior Digital Analyst McKinsey Digital Labs — Google, .
- «» , Duke Nukem 3D, SiN, Blood — , .
- , - 12- — ,
- , GameAcademy — .
- , PHP- Badoo — Highload PHP Badoo.
- , CTO Delivery Club — 50 43 ,
- , Doom, Quake Wolfenstein 3D — , DOOM
- , Flipper Zero —
- , - Google — Google-
- .
- Data Science ? Unity
- c Revolut
- : ,
- IT-
