werf – unser Tool für CI/CD in Kubernetes (Übersicht und Videobericht)

27. Mai im Hauptsaal der DevOpsConf 2019-Konferenz, die im Rahmen des Festivals stattfand RIT++ 2019Im Rahmen der Rubrik „Continuous Delivery“ wurde über „werf – unser Tool für CI/CD in Kubernetes“ berichtet. Davon wird die Rede sein Probleme und Herausforderungen, mit denen jeder bei der Bereitstellung auf Kubernetes konfrontiert istsowie über Nuancen, die vielleicht nicht sofort auffallen. Wir analysieren mögliche Lösungen und zeigen, wie dies in einem Open-Source-Tool umgesetzt wird Hof.

Seit der Präsentation hat unser Dienstprogramm (früher bekannt als Dapp) einen historischen Meilenstein erreicht 1000 Sterne auf GitHub – Wir hoffen, dass die wachsende Benutzergemeinschaft vielen DevOps-Ingenieuren das Leben erleichtern wird.

Also präsentieren wir Video des Berichts (~47 Minuten, viel informativer als der Artikel) und der Hauptauszug daraus in Textform. Gehen!

Bereitstellung von Code an Kubernetes

Dabei geht es nicht mehr um werf, sondern um CI/CD in Kubernetes, was bedeutet, dass unsere Software in Docker-Containern verpackt ist (Ich habe darüber gesprochen in Bericht 2016), und K8s werden verwendet, um es in der Produktion auszuführen (mehr dazu in 2017 Jahr).

Wie sieht die Lieferung in Kubernetes aus?

• Es gibt ein Git-Repository mit dem Code und Anweisungen zum Erstellen. Die Anwendung ist in ein Docker-Image integriert und in der Docker-Registrierung veröffentlicht.
• Das gleiche Repository enthält auch Anweisungen zum Bereitstellen und Ausführen der Anwendung. In der Bereitstellungsphase werden diese Anweisungen an Kubernetes gesendet, das das gewünschte Image von der Registrierung erhält und es startet.
• Außerdem gibt es in der Regel Tests. Einige davon können beim Veröffentlichen eines Bildes durchgeführt werden. Sie können auch (nach denselben Anweisungen) eine Kopie der Anwendung bereitstellen (in einem separaten K8s-Namespace oder einem separaten Cluster) und dort Tests ausführen.
• Schließlich benötigen Sie ein CI-System, das Ereignisse von Git (oder Schaltflächenklicks) empfängt und alle vorgesehenen Phasen aufruft: Erstellen, Veröffentlichen, Bereitstellen, Testen.

Hier ein paar wichtige Hinweise:

1. Weil wir über eine unveränderliche Infrastruktur verfügen (unveränderliche Infrastruktur), das Anwendungsbild, das in allen Phasen (Staging, Produktion usw.) verwendet wird, es muss einen geben. Ich habe ausführlicher und anhand von Beispielen darüber gesprochen. hier.
2. Weil wir den Infrastructure-as-Code-Ansatz verfolgen (IaK), der Anwendungscode, Anweisungen zum Zusammenstellen und Starten genau in einem Repository. Weitere Informationen hierzu finden Sie unter der gleiche Bericht.
3. Lieferkette (Lieferung) Normalerweise sehen wir es so: Die Anwendung wurde zusammengestellt, getestet, freigegeben (Veröffentlichungsphase) und das war’s – die Lieferung ist erfolgt. Aber in Wirklichkeit bekommt der Benutzer das, was Sie bereitgestellt haben. nicht Dann, als Sie es an die Produktion übergeben haben, und als er dorthin gehen konnte und diese Produktion funktionierte. Ich glaube also, dass die Lieferkette endet erst im operativen Stadium (Lauf), oder genauer gesagt, sogar zu dem Zeitpunkt, als der Code aus der Produktion entfernt (durch einen neuen ersetzt) ​​wurde.

Kehren wir zum obigen Bereitstellungsschema in Kubernetes zurück: Es wurde nicht nur von uns erfunden, sondern buchstäblich von jedem, der sich mit diesem Problem befasst hat. Tatsächlich heißt dieses Muster jetzt GitOps (Sie können mehr über den Begriff und die Ideen dahinter lesen hier). Schauen wir uns die Phasen des Schemas an.

Bauphase

Es scheint, dass man im Jahr 2019 über die Erstellung von Docker-Images sprechen kann, wenn jeder weiß, wie man Docker-Dateien schreibt und ausführt docker build?.. Hier sind die Nuancen, auf die ich achten möchte:

1. Bildgewicht wichtig, also verwenden mehrstufigeum im Bild nur die Anwendung zu belassen, die für den Vorgang wirklich notwendig ist.
2. Anzahl der Schichten müssen durch die Kombination von Ketten minimiert werden RUN-Befehle nach Bedeutung.
3. Dies bringt jedoch zusätzliche Probleme mit sich Debuggen, denn wenn die Assembly abstürzt, müssen Sie den richtigen Befehl aus der Kette finden, der das Problem verursacht hat.
4. Montagegeschwindigkeit wichtig, weil wir Änderungen schnell umsetzen und die Ergebnisse sehen wollen. Sie möchten beispielsweise nicht jedes Mal, wenn Sie eine Anwendung erstellen, Abhängigkeiten in Sprachbibliotheken neu erstellen.
5. Oftmals benötigen Sie ein Git-Repository viele Bilder, was durch eine Reihe von Docker-Dateien (oder benannten Stufen in einer Datei) und ein Bash-Skript mit ihrer sequentiellen Zusammenstellung gelöst werden kann.

Dies war nur die Spitze des Eisbergs, mit der jeder konfrontiert ist. Aber es gibt noch andere Probleme, insbesondere:

1. Oft brauchen wir in der Montagephase etwas montieren (z. B. das Ergebnis eines Befehls wie apt in einem Verzeichnis eines Drittanbieters zwischenspeichern).
2. Wir wollen Ansible anstatt in der Shell zu schreiben.
3. Wir wollen ohne Docker bauen (Warum brauchen wir eine zusätzliche virtuelle Maschine, in der wir dafür alles konfigurieren müssen, wenn wir bereits einen Kubernetes-Cluster haben, in dem wir Container ausführen können?).
4. Parallele Montage, was auf unterschiedliche Weise verstanden werden kann: verschiedene Befehle aus der Docker-Datei (wenn mehrstufig verwendet wird), mehrere Commits desselben Repositorys, mehrere Docker-Dateien.
5. Verteilte Montage: Wir wollen Dinge in Pods sammeln, die „vergänglich“ sind, weil Ihr Cache verschwindet, was bedeutet, dass er irgendwo separat gespeichert werden muss.
6. Schließlich habe ich den Gipfel der Wünsche benannt automatisch: Ideal wäre es, zum Repository zu gehen, einen Befehl einzugeben und ein fertiges Bild zu erhalten, das mit einem Verständnis dafür zusammengestellt wurde, wie und was richtig zu tun ist. Allerdings bin ich mir persönlich nicht sicher, ob auf diese Weise alle Nuancen vorhersehbar sind.

Und hier sind die Projekte:

• moby/buildkit — ein Builder von Docker Inc (bereits in aktuelle Docker-Versionen integriert), der versucht, all diese Probleme zu lösen;
• Kaniko – ein Builder von Google, mit dem Sie ohne Docker bauen können;
• Buildpacks.io — CNCFs Versuch, automatische Magie zu erzeugen, und insbesondere eine interessante Lösung mit Rebase für Ebenen;
• und eine Reihe anderer Dienstprogramme, wie z Buildah, Genuinetools/img...

...und schauen Sie, wie viele Sterne sie auf GitHub haben. Das heißt einerseits docker build existiert und kann etwas tun, aber in Wirklichkeit Das Problem ist nicht vollständig gelöst - Ein Beweis dafür ist die parallele Entwicklung alternativer Kollektoren, die jeweils einen Teil der Probleme lösen.

Montage in werf

Also haben wir es geschafft Hof (früher berühmt wie dapp) — Ein Open-Source-Dienstprogramm der Firma Flant, das wir seit vielen Jahren entwickeln. Alles begann vor 5 Jahren mit Bash-Skripten, die die Zusammenstellung von Dockerfiles optimierten, und in den letzten 3 Jahren erfolgte die vollständige Entwicklung im Rahmen eines Projekts mit eigenem Git-Repository (zuerst in Ruby und dann umgeschrieben to Go, und gleichzeitig umbenannt). Welche Montageprobleme werden in werf gelöst?

Die blau schattierten Probleme wurden bereits implementiert, der parallele Build wurde innerhalb desselben Hosts durchgeführt und die gelb hervorgehobenen Probleme sollen bis zum Ende des Sommers abgeschlossen sein.

Stadium der Veröffentlichung im Register (veröffentlichen)

Wir haben gewählt docker push... - Was könnte beim Hochladen eines Bildes in die Registrierung schwierig sein? Und dann stellt sich die Frage: „Welches Tag soll ich dem Bild hinzufügen?“ Es entsteht aus dem Grund, den wir haben Gitflow (oder eine andere Git-Strategie) und Kubernetes, und die Branche versucht sicherzustellen, dass das, was in Kubernetes passiert, dem folgt, was in Git passiert. Schließlich ist Git unsere einzige Quelle der Wahrheit.

Was ist daran so schwer? Stellen Sie die Reproduzierbarkeit sicher: aus einem Commit in Git, der von Natur aus unveränderlich ist (unveränderlich), zu einem Docker-Image, das gleich bleiben sollte.

Es ist uns auch wichtig Herkunft bestimmen, weil wir verstehen wollen, aus welchem ​​Commit die in Kubernetes laufende Anwendung erstellt wurde (dann können wir Diffs und ähnliche Dinge machen).

Tagging-Strategien

Der erste ist einfach git-Tag. Wir haben eine Registrierung mit einem Bild, das als markiert ist 1.0. Kubernetes verfügt über eine Bühne und Produktion, wo dieses Bild hochgeladen wird. In Git machen wir Commits und irgendwann taggen wir 2.0. Wir sammeln es gemäß den Anweisungen aus dem Repository und platzieren es mit dem Tag in der Registrierung 2.0. Wir bringen es auf die Bühne und, wenn alles in Ordnung ist, dann in die Produktion.

Das Problem bei diesem Ansatz besteht darin, dass wir zuerst das Tag setzen und es dann erst testen und ausrollen. Warum? Erstens ist es einfach unlogisch: Wir geben eine Softwareversion heraus, die wir noch nicht einmal getestet haben (wir können nicht anders, denn um dies zu überprüfen, müssen wir ein Tag setzen). Zweitens ist dieser Pfad nicht mit Gitflow kompatibel.

Die zweite Option - Git-Commit + Tag. Der Hauptzweig hat ein Tag 1.0; dafür in der Registrierung - ein für die Produktion bereitgestelltes Image. Darüber hinaus verfügt der Kubernetes-Cluster über Vorschau- und Staging-Konturen. Als nächstes folgen wir Gitflow: im Hauptzweig für die Entwicklung (develop) erstellen wir neue Funktionen, was zu einem Commit mit der Kennung führt #c1. Wir sammeln es und veröffentlichen es im Register unter Verwendung dieser Kennung (#c1). Mit derselben Kennung führen wir den Rollout zur Vorschau durch. Das Gleiche machen wir mit Commits #c2 и #c3.

Als uns klar wurde, dass es genügend Funktionen gibt, beginnen wir, alles zu stabilisieren. Erstellen Sie einen Zweig in Git release_1.1 (in der Basis #c3 von develop). Es besteht keine Notwendigkeit, diese Veröffentlichung einzusammeln, weil... Dies wurde im vorherigen Schritt durchgeführt. Deshalb können wir es einfach ins Staging ausrollen. Wir beheben Fehler #c4 und auf ähnliche Weise ins Staging überführen. Gleichzeitig ist die Entwicklung in vollem Gange develop, aus dem regelmäßig Änderungen übernommen werden release_1.1. Irgendwann bekommen wir einen Commit kompiliert und ins Staging hochgeladen, womit wir zufrieden sind (#c25).

Dann führen wir (mit schnellem Vorlauf) den Release-Zweig zusammen (release_1.1) im Master. Wir haben diesem Commit ein Tag mit der neuen Version hinzugefügt (1.1). Dieses Bild ist jedoch bereits in der Registrierung erfasst. Um es nicht noch einmal zu erfassen, fügen wir einfach ein zweites Tag zum vorhandenen Bild hinzu (jetzt verfügt es über Tags in der Registrierung). #c25 и 1.1). Danach führen wir es in die Produktion ein.

Es gibt einen Nachteil, dass nur ein Bild zum Staging hochgeladen wird (#c25), und in der Produktion ist es etwas anders (1.1), aber wir wissen, dass es sich „physisch“ um dasselbe Bild aus der Registrierung handelt.

Der eigentliche Nachteil besteht darin, dass Merge-Commits nicht unterstützt werden und Sie einen schnellen Vorlauf durchführen müssen.

Wir können noch einen Schritt weitergehen und einen Trick anwenden ... Schauen wir uns ein Beispiel einer einfachen Docker-Datei an:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Erstellen wir daraus eine Datei nach folgendem Prinzip:

• SHA256 aus den Identifikatoren der verwendeten Bilder (ruby:2.3 и nginx:alpine), die Prüfsummen ihres Inhalts sind;
• alle Mannschaften (RUN, CMD usw.);
• SHA256 aus hinzugefügten Dateien.

... und nimm die Prüfsumme (wieder SHA256) aus einer solchen Datei. Das Unterschrift alles, was den Inhalt des Docker-Images definiert.

Kehren wir zum Diagramm zurück und Anstelle von Commits werden wir solche Signaturen verwenden, d.h. Markieren Sie Bilder mit Signaturen.

Wenn es nun beispielsweise notwendig ist, Änderungen von einem Release zum Master zusammenzuführen, können wir einen echten Merge-Commit durchführen: Es wird einen anderen Bezeichner, aber dieselbe Signatur haben. Mit derselben Kennung werden wir das Image in die Produktion einführen.

Der Nachteil besteht darin, dass es jetzt nicht möglich ist, festzustellen, welche Art von Commit in die Produktion übertragen wurde – Prüfsummen funktionieren nur in eine Richtung. Dieses Problem wird durch eine zusätzliche Ebene mit Metadaten gelöst – mehr dazu erzähle ich dir später.

Markieren in werf

In werf sind wir sogar noch weiter gegangen und bereiten einen verteilten Build mit einem Cache vor, der nicht auf einer Maschine gespeichert ist ... Wir erstellen also zwei Arten von Docker-Images, wie wir sie nennen Stufe и Image.

Das werf-Git-Repository speichert buildspezifische Anweisungen, die die verschiedenen Phasen des Builds beschreiben (vor der Installation, installieren, beforeSetup, Setup). Wir sammeln das Bild der ersten Stufe mit einer Signatur, die als Prüfsumme der ersten Schritte definiert ist. Dann fügen wir den Quellcode hinzu, für das neue Bühnenbild berechnen wir dessen Prüfsumme... Diese Vorgänge werden für alle Bühnen wiederholt, wodurch wir eine Reihe von Bühnenbildern erhalten. Dann erstellen wir das endgültige Bild, das auch Metadaten über seine Herkunft enthält. Und wir kennzeichnen dieses Bild auf unterschiedliche Weise (Details später).

Angenommen, danach erscheint ein neues Commit, bei dem nur der Anwendungscode geändert wurde. Was wird passieren? Bei Codeänderungen wird ein Patch erstellt und ein neues Stage-Image vorbereitet. Seine Signatur wird als Prüfsumme des alten Stage-Images und des neuen Patches ermittelt. Aus diesem Bild wird ein neues Endbild erstellt. Ein ähnliches Verhalten tritt bei Änderungen in anderen Phasen auf.

Somit handelt es sich bei Stage-Images um einen Cache, der verteilt gespeichert werden kann und die daraus bereits erstellten Images in die Docker-Registrierung hochgeladen werden.

Bereinigen der Registry

Wir sprechen hier nicht über das Löschen von Ebenen, die nach gelöschten Tags hängen geblieben sind – dies ist eine Standardfunktion der Docker-Registrierung selbst. Wir sprechen von einer Situation, in der sich viele Docker-Tags ansammeln und wir verstehen, dass wir einige davon nicht mehr benötigen, sie aber Platz beanspruchen (und/oder wir dafür bezahlen).

Welche Reinigungsstrategien gibt es?

1. Du kannst einfach nichts tun nicht reinigen. Manchmal ist es wirklich einfacher, ein wenig für zusätzlichen Platz zu bezahlen, als ein riesiges Wirrwarr von Tags zu entwirren. Das funktioniert aber nur bis zu einem gewissen Punkt.
2. Vollständiger Reset. Wenn Sie alle Bilder löschen und nur die aktuellen im CI-System neu erstellen, kann ein Problem auftreten. Wenn der Container in der Produktion neu gestartet wird, wird ein neues Image dafür geladen – eines, das noch von niemandem getestet wurde. Dies macht die Idee einer unveränderlichen Infrastruktur zunichte.
3. Blau Grün. Eine Registrierung begann überzulaufen – wir laden Bilder in eine andere hoch. Das gleiche Problem wie bei der vorherigen Methode: Ab wann können Sie die überlaufende Registrierung löschen?
4. Mit der Zeit. Alle Bilder löschen, die älter als 1 Monat sind? Aber es wird auf jeden Fall einen Dienst geben, der einen Monat lang nicht aktualisiert wurde ...
5. manuell Bestimmen Sie, was bereits gelöscht werden kann.

Es gibt zwei wirklich praktikable Optionen: keine Reinigung oder eine Kombination aus Blau-Grün + manuell. Im letzteren Fall sprechen wir von Folgendem: Wenn Sie verstehen, dass es an der Zeit ist, die Registrierung zu bereinigen, erstellen Sie eine neue und fügen ihr beispielsweise im Laufe eines Monats alle neuen Bilder hinzu. Und sehen Sie nach einem Monat, welche Pods in Kubernetes noch die alte Registry verwenden, und übertragen Sie sie ebenfalls in die neue Registry.

Wozu sind wir gekommen? Hof? Wir sammeln:

1. Git-Kopf: alle Tags, alle Zweige – vorausgesetzt, wir benötigen alles, was in Git in den Bildern getaggt ist (und wenn nicht, müssen wir es in Git selbst löschen);
2. alle Pods, die derzeit an Kubernetes gepumpt werden;
3. alte ReplicaSets (was kürzlich veröffentlicht wurde) und wir planen auch, Helm-Releases zu scannen und dort die neuesten Images auszuwählen.

... und erstellen Sie aus diesem Satz eine Whitelist – eine Liste von Bildern, die wir nicht löschen werden. Wir bereinigen alles andere, finden dann verwaiste Bühnenbilder und löschen sie ebenfalls.

Bereitstellungsphase

Zuverlässige Aussagekraft

Der erste Punkt, auf den ich bei der Bereitstellung aufmerksam machen möchte, ist der Rollout der aktualisierten Ressourcenkonfiguration, deklarativ deklariert. Das ursprüngliche YAML-Dokument, das Kubernetes-Ressourcen beschreibt, unterscheidet sich immer stark von dem Ergebnis, das tatsächlich im Cluster ausgeführt wird. Weil Kubernetes der Konfiguration Folgendes hinzufügt:

1. Identifikatoren;
2. Service Information;
3. viele Standardwerte;
4. Abschnitt mit aktuellem Status;
5. Änderungen, die im Rahmen des Zulassungs-Webhooks vorgenommen wurden;
6. das Ergebnis der Arbeit verschiedener Controller (und des Schedulers).

Wenn daher eine neue Ressourcenkonfiguration erscheint (neu), können wir nicht einfach die aktuelle „Live“-Konfiguration übernehmen und damit überschreiben (leben). Dazu müssen wir vergleichen neu mit der zuletzt angewendeten Konfiguration (zuletzt angewendet) und aufrollen leben Patch erhalten.

Dieser Ansatz heißt 2-Wege-Zusammenführung. Es wird beispielsweise in Helm verwendet.

Es gibt auch 3-Wege-Zusammenführung, was sich darin unterscheidet:

• vergleichen zuletzt angewendet и neu, wir schauen uns an, was gelöscht wurde;
• vergleichen neu и leben, wir schauen uns an, was hinzugefügt oder geändert wurde;
• der summierte Patch wird angewendet leben.

Wir stellen über 1000 Anwendungen mit Helm bereit, sodass wir tatsächlich mit der 2-Wege-Zusammenführung leben. Es gibt jedoch eine Reihe von Problemen, die wir mit unseren Patches gelöst haben, die dazu beitragen, dass Helm normal funktioniert.

Echter Rollout-Status

Nachdem unser CI-System basierend auf dem nächsten Ereignis eine neue Konfiguration für Kubernetes generiert hat, übermittelt es diese zur Verwendung (anwenden) zu einem Cluster - mit Helm oder kubectl apply. Als nächstes erfolgt der bereits beschriebene N-Way-Merge, auf den die Kubernetes-API dem CI-System und dessen Benutzer zustimmend reagiert.

Allerdings gibt es ein großes Problem: schließlich Eine erfolgreiche Anwendung bedeutet nicht unbedingt einen erfolgreichen Rollout. Wenn Kubernetes versteht, welche Änderungen vorgenommen werden müssen, und diese anwendet, wissen wir immer noch nicht, wie das Ergebnis aussehen wird. Beispielsweise kann das Aktualisieren und Neustarten von Pods im Frontend erfolgreich sein, im Backend jedoch nicht, und wir erhalten unterschiedliche Versionen der laufenden Anwendungsimages.

Um alles richtig zu machen, erfordert dieses Schema einen zusätzlichen Link – einen speziellen Tracker, der Statusinformationen von der Kubernetes-API empfängt und zur weiteren Analyse des tatsächlichen Stands der Dinge übermittelt. Wir haben eine Open-Source-Bibliothek in Go erstellt - Cubedog (siehe seine Ankündigung hier), das dieses Problem löst und in werf integriert ist.

Das Verhalten dieses Trackers auf werf-Ebene wird mithilfe von Anmerkungen konfiguriert, die auf Bereitstellungen oder StatefulSets platziert werden. Hauptanmerkung - fail-mode - versteht die folgenden Bedeutungen:

• IgnoreAndContinueDeployProcess — Wir ignorieren die Probleme bei der Einführung dieser Komponente und setzen die Bereitstellung fort;
• FailWholeDeployProcessImmediately — Ein Fehler in dieser Komponente stoppt den Bereitstellungsprozess;
• HopeUntilEndOfDeployProcess — Wir hoffen, dass diese Komponente bis zum Ende der Bereitstellung funktioniert.

Beispielsweise diese Kombination aus Ressourcen und Anmerkungswerten fail-mode:

Wenn wir zum ersten Mal bereitstellen, ist die Datenbank (MongoDB) möglicherweise noch nicht bereit – Bereitstellungen schlagen fehl. Aber Sie können den Moment abwarten, bis es losgeht, und die Bereitstellung wird trotzdem stattfinden.

Es gibt zwei weitere Anmerkungen für kubedog in werf:

• failures-allowed-per-replica — die Anzahl der zulässigen Stürze für jede Replik;
• show-logs-until – regelt den Zeitpunkt, bis zu dem werf (in stdout) Protokolle von allen ausgerollten Pods anzeigt. Die Standardeinstellung ist PodIsReady (um Nachrichten zu ignorieren, die wir wahrscheinlich nicht möchten, wenn der Verkehr zum Pod kommt), aber auch Werte sind gültig: ControllerIsReady и EndOfDeploy.

Was wollen wir sonst noch von der Bereitstellung?

Zusätzlich zu den beiden bereits beschriebenen Punkten wünschen wir uns:

• siehe Protokolle - und nur das Notwendige und nicht alles hintereinander;
• Spur Fortschritt, denn wenn der Job mehrere Minuten lang „still“ hängt, ist es wichtig zu verstehen, was dort passiert;
• иметь automatisches Rollback für den Fall, dass etwas schief gelaufen ist (und daher ist es wichtig, den tatsächlichen Status der Bereitstellung zu kennen). Der Rollout muss atomar sein: Entweder geht er bis zum Ende durch, oder alles kehrt in seinen vorherigen Zustand zurück.

Ergebnisse

Für uns als Unternehmen reichen ein CI-System und ein Dienstprogramm aus, um alle beschriebenen Nuancen in den verschiedenen Phasen der Bereitstellung (Build, Publishing, Deployment) umzusetzen Hof.

Statt Fazit:

Mit Hilfe von werf haben wir gute Fortschritte bei der Lösung einer großen Anzahl von Problemen für DevOps-Ingenieure gemacht und würden uns freuen, wenn die breitere Community dieses Dienstprogramm zumindest in Aktion ausprobieren würde. Gemeinsam wird es einfacher, ein gutes Ergebnis zu erzielen.

Videos und Folien

Video vom Auftritt (~47 Minuten):

Präsentation des Berichts:

PS

Weitere Berichte zu Kubernetes auf unserem Blog:

• «Autoskalierung und Ressourcenverwaltung in Kubernetes» (Dmitry Stolyarov; 27. April 2019 über „Strike“);
• «Kubernetes erweitern und ergänzen» (Andrey Polovov; 8. April 2019 auf Saint HighLoad++);
• «Datenbanken und Kubernetes» (Dmitry Stolyarov; 8. November 2018 auf HighLoad++);
• «Überwachung und Kubernetes» (Dmitry Stolyarov; 28. Mai 2018 auf der RootConf);
• «Best Practices für CI/CD mit Kubernetes und GitLab» (Dmitry Stolyarov; 7. November 2017 auf HighLoad++);
• «Unsere Erfahrung mit Kubernetes in kleinen Projekten» (Dmitry Stolyarov; 6. Juni 2017 bei RootConf).

Source: habr.com