Kubernetes erweitern

    Heute werden wir über DevOps oder vor allem über Ops sprechen. Sie sagen, dass es sehr wenige Menschen gibt, die mit dem Automatisierungsgrad ihrer Abläufe zufrieden sind. Aber es scheint, dass die Situation fixierbar ist. In diesem Artikel wird Nikolai Ryzhikov über seine Erfahrungen beim Ausbau des Kubernetes berichten.



    Das Material wurde auf der Grundlage der Rede von Nikolay auf der Herbstkonferenz DevOops 2017 im Herbst vorbereitet - Video und Textprotokoll des Berichts.



    Momentan arbeitet Nikolai Ryzhikov im Bereich Health-IT an medizinischen Informationssystemen. Mitglied der St. Petersburger Gemeinschaft der Funktionsprogrammierer FPROG. Ein aktives Mitglied der Online Clojure-Community, ein Mitglied des Standards für den Austausch medizinischer Informationen HL7 FHIR. Seit 15 Jahren in der Programmierung tätig.


    Auf welcher Seite behandeln wir DevOps? Unsere DevOps-Formel für die letzten 10 Jahre ist ziemlich einfach: Entwickler sind für den Betrieb verantwortlich, Entwickler werden eingesetzt, Entwickler werden gewartet. Mit dieser Anordnung, die etwas hart aussieht, werden Sie auf jeden Fall DevOps. Wenn Sie DevOps schnell und mühsam implementieren möchten, machen Sie die Entwickler für Ihre Produktion verantwortlich. Wenn die Jungs klug sind, werden sie anfangen, alles zu verstehen.

    Unsere Geschichte: Vor langer Zeit, als es noch keinen Chefkoch und keine Automatisierung gab, haben wir die automatische Capistrano bereits eingesetzt. Dann langweilen sie sich, um sie in Mode zu bringen. Aber dann erschien der Chef. Wir haben darauf umgestellt und sind in die Cloud gegangen: Wir hatten unsere Rechenzentren satt. Dann erschien Ansible und Docker. Danach zogen wir mit einem handgeschriebenen Supervisor für Condo Dockers in Camel nach Terraform. Und jetzt ziehen wir nach Kubernetes.

    Was ist das Schlimmste an Operationen? Nur sehr wenige Menschen sind mit dem Automatisierungsgrad ihrer Abläufe zufrieden. Es ist beängstigend, ich bestätige: Wir haben viele Ressourcen und Anstrengungen aufgewendet, um all diese Stapel für uns zusammenzutragen, und das Ergebnis ist unbefriedigend.

    Es besteht das Gefühl, dass sich mit der Ankunft der Kubernetes etwas ändern kann. Ich bin ein Anhänger von Lean Manufacturing und aus seiner Sicht sind Operationen überhaupt nicht von Vorteil. Perfekte Vorgänge sind das Fehlen oder Minimum an Vorgängen in einem Projekt. Wert wird erstellt, wenn ein Entwickler ein Produkt herstellt. Wenn es fertig ist, erhöht die Lieferung nicht den Wert. Sie müssen aber die Kosten senken.

    Für mich war das Ideal immer Heroku. Wir haben es für einfache Anwendungen verwendet, bei denen der Entwickler sagen musste, dass git push und heroku konfiguriert werden muss, um seinen Dienst bereitzustellen. Es dauert eine Minute.

    Wie zu sein Sie können NoOps kaufen - auch Heroku. Und ich empfehle Ihnen zu kaufen, ansonsten besteht die Chance, mehr Geld für die Entwicklung normaler Operationen auszugeben.

    Es gibt Leute, Deis, sie versuchen auf Kubernetes so etwas wie Heroku zu machen. Es gibt eine Cloud-Gießerei, die auch eine Plattform bietet, auf der gearbeitet werden kann.

    Wenn Sie sich jedoch mit komplexeren oder größeren Dingen beschäftigen, können Sie dies selbst tun. Mit Docker und Kubernetes wird dies nun zu einer Aufgabe, die zu einem vernünftigen Preis zu einem vernünftigen Preis erledigt werden kann. Einmal war es zu schwer.

    Ein bisschen über Docker und Kubernetes


    Eines der Probleme bei Operationen ist die Wiederholbarkeit. Das Wunderbare, das das Docker eingeführt hat, besteht aus zwei Phasen. Wir haben eine Aufbauphase.

    Der zweite Punkt, der Docker gefällt, ist eine universelle Schnittstelle zum Starten beliebiger Dienste. Jemand versammelte Docker, steckte etwas hinein, und Operationen sagen, dass Docker läuft und läuft.



    Was ist Kubernetes? Also haben wir einen Docker entwickelt und müssen ihn irgendwo ausführen, zusammenführen, konfigurieren und mit anderen verknüpfen. Kubernetes ermöglicht es Ihnen, dies zu tun. Er führt eine Reihe von Abstraktionen ein, die als "Ressource" bezeichnet werden. Wir gehen sie schnell durch und versuchen sogar zu kreieren.

    Abstraktionen


    Die erste Abstraktion ist ein POD oder ein Satz von Containern. Richtig gemacht, was genau ist ein Satz von Behältern, nicht nur einer. Sets können Volumes, die sich über localhost sehen, untereinander fummeln. Auf diese Weise können Sie ein solches Muster als Beiwagen verwenden (dies ist, wenn wir den Hauptcontainer starten, und daneben befinden sich Hilfscontainer, die ihm helfen).

    Zum Beispiel der Botschafteransatz. In diesem Fall soll der Container nicht darüber nachdenken, wo sich einige Dienste befinden. Sie stellen sich in die Nähe eines Containers, der weiß, wo diese Dienste liegen. Und sie werden für den Hauptcontainer auf localhost verfügbar. Die Umgebung sieht also so aus, als würden Sie lokal arbeiten.

    Lassen Sie uns den POD anheben und sehen, wie er beschrieben wird. Sie können Minikube lokal entwickeln. Es frisst eine Reihe von CPUs, ermöglicht es Ihnen jedoch, einen kleinen Kubernetes-Cluster auf der Virtualbox zu erstellen und damit zu arbeiten.

    Lass uns den POD schließen. Ich sagte, Kubernetes bewerben sich und laden den POD hoch. Ich kann sehen, welche Art von PODs ich habe: Ich sehe, dass ein POD erfasst wurde. Dies bedeutet, dass Kubernetes diese Container gestartet hat.


    Ich kann sogar in diesen Behälter gehen.


    Aus dieser Sicht ist Kubernetes für den Menschen gemacht. In der Tat ist das, was wir ständig im Betrieb tun, beispielsweise im Kubernetes-Gurtzeug mithilfe des Dienstprogramms kubectl, problemlos möglich.

    Aber POD ist sterblich. Es läuft als Dockerlauf: Wenn jemand es stoppt, wird es niemand erhöhen. Zusätzlich zu dieser Abstraktion beginnt Kubernetes mit dem Bau der nächsten - zum Beispiel des Replikatsets. Dies ist ein solcher Supervisor, der den POD überwacht und deren Nummer überwacht. Wenn die PODs fallen, erhöht er sie erneut. Dies ist ein wichtiges Selbstheilungskonzept in Kubernetes, mit dem Sie nachts schlafen können.

    Zusätzlich zum Replikatset gibt es eine Abstraktion, und die Bereitstellung ist auch eine Ressource, die die Bereitstellung ohne Zeitaufwand zulässt. Beispielsweise funktioniert ein Replicaset. Wenn wir die Version des Containers, z. B. unsere, innerhalb der Bereitstellung bereitstellen und ändern, steigt ein weiteres Replikatset an. Wir warten auf den Start dieser Container, bestehen die Gesundheitsprüfungen und wechseln dann schnell zu einem neuen Replikatset. Auch eine klassische und gute Praxis.

    Lassen Sie uns einen einfachen Service anbieten. Zum Beispiel haben wir eine Bereitstellung. Darin beschreibt er die POD-Vorlage, die er anheben wird. Wir können diese Bereitstellung anwenden und sehen, was wir haben. Cooles Feature Kubernetes - alles ist in der Datenbank, und wir können sehen, was im System passiert.

    Hier sehen wir eine Bereitstellung. Wenn wir versuchen, die PODs zu betrachten, sehen wir, dass einige PODs gestiegen sind. Wir können diesen POD übernehmen und löschen. Was passiert mit PODs? Einer wird zerstört und der zweite steigt sofort auf. Dieser Replikatset-Controller hat den gewünschten POD nicht gefunden und einen anderen gestartet.


    Wenn es sich hierbei um eine Art Webdienst handelt oder in unseren Diensten eine Verbindung hergestellt werden muss, ist die Erkennung von Diensten erforderlich. Sie müssen dem Dienst einen Namen und einen Einstiegspunkt geben. Dafür bietet Kubernetes eine Ressource namens Service an. Er kann sich mit dem Lastausgleich beschäftigen und für die Ermittlung des Service verantwortlich sein.

    Lassen Sie uns einen einfachen Dienst sehen. Wir verbinden es mit Bereitstellung und POD über Labels: eine solche dynamische Bindung. Ein sehr wichtiges Konzept in Kubernetes: Das System ist dynamisch. Egal in welcher Reihenfolge es erstellt wird. Der Service wird versuchen, PODs mit solchen Etiketten zu finden und mit dem Lastausgleich zu beginnen.


    Appell Service, wir schauen, welche Dienstleistungen wir haben. Gehen Sie zu unserem Test-POD, der angehoben wurde, und rufen Sie nslookup auf. Kubernetes gibt uns ein DNS, über das sich Dienste gegenseitig sehen und erkennen können.


    Service ist eher eine Schnittstelle. Es gibt verschiedene Implementierungen, da die Lastverteilung und Serviceaufgaben sehr komplex sind: Auf eine Art arbeiten wir mit regulären Datenbanken, mit anderen Methoden mit geladenen und einige einfachen auf einfache Art und Weise. Dies ist auch ein wichtiges Konzept in Kubernetes: Einige Dinge können als Schnittstellen und nicht als Implementierungen bezeichnet werden. Sie sind nicht starr festgelegt, und verschiedene Anbieter, beispielsweise Cloud-Anbieter, bieten unterschiedliche Implementierungen an. Das heißt, es gibt beispielsweise eine persistente Volumenressource, die in jeder spezifischen Cloud bereits mit ihren eigenen Standardmitteln implementiert ist.

    Als nächstes möchten wir den Webservice normalerweise irgendwo nach draußen bringen. In Kubernetes gibt es eine Ingress-Abstraktion. Normalerweise wird dort SSL hinzugefügt.

    Der einfachste Eintritt sieht so aus. Dort schreiben wir die Regeln: durch welche URL, durch welche Hosts, an welchen internen Dienst die Anfrage umgeleitet wird. In gleicher Weise können wir unseren Eintritt erhöhen.


    Wenn Sie sich lokal bei den Hosts registrieren, können Sie diesen Dienst von hier aus sehen.


    Dies ist eine sehr regelmäßige Aufgabe: Wir haben einen Webdienst bereitgestellt, der ein wenig mit Kubernetes vertraut ist.


    Wir säubern das alles, entfernen den Eintritt und schauen uns alle Ressourcen an.


    Es gibt eine Reihe von Ressourcen, z. B. configmap und secret. Hierbei handelt es sich um rein informative Ressourcen, die Sie in einen Container stellen und beispielsweise das Kennwort von Postgres übertragen können. Sie können dies Umgebungsvariablen zuordnen, die während des Startvorgangs in den Container eingefügt werden. Sie können das Dateisystem einhängen. Alles ist sehr bequem: Standardaufgaben, nette Lösungen.

    Es gibt ein beständiges Volume - eine Schnittstelle, die für verschiedene Cloud-Anbieter unterschiedlich implementiert ist. Es besteht aus zwei Teilen: Es gibt einen permanenten Volumenanspruch (request), und dann wird eine Art EBS-ka erstellt, die in den Container gezogen wird. Sie können mit einem stateful Service arbeiten.



    Aber wie funktioniert es im Inneren? Das Konzept selbst ist sehr einfach und transparent. Kubernetes besteht aus zwei Teilen. Eine ist nur eine Datenbank, in der wir alle diese Ressourcen haben. Sie können die Ressourcen als Beschriftungen darstellen: Diese Instanzen sind nur Datensätze in den Beschriftungen. Ein API-Server wird auf Kubernetes konfiguriert. Das heißt, wenn Sie einen Kubernetes-Cluster haben, kommunizieren Sie normalerweise mit dem API-Server (genauer gesagt, der Client kommuniziert mit ihm).

    Dementsprechend wird das, was wir erstellt haben (PODs, Services usw.), einfach in die Datenbank geschrieben. Diese Datenbank wird von ETCD implementiert, d.h. so dass es auf dem hohen verfügbaren Niveau stabil ist.

    Was wird als nächstes getan? Unter jeder Art von Ressourcen gibt es außerdem einen bestimmten Controller. Es ist nur ein Dienst, der seinen Ressourcentyp überwacht und außerhalb der Welt etwas tut. Läuft das Docker beispielsweise? Wenn wir einen POD haben, gibt es für jeden Knoten einen Kubelet-Service, der die PODs überwacht, die zu diesem Knoten gehen. Und alles, was er macht, ist ein Docker-Lauf nach einer weiteren periodischen Überprüfung, ob dies nicht der Fall ist.

    Was sehr wichtig ist - alles geschieht in Echtzeit, daher liegt die Leistung dieses Controllers über dem Minimum. Häufig entfernt der Controller immer noch Metriken und prüft, was er gestartet hat. Ie nimmt Feedback aus der realen Welt und schreibt es in die Datenbank, damit Sie oder andere Controller es sehen können. Zum Beispiel wird derselbe POD-Status an ETCD zurückgeschrieben.

    Somit ist alles in Kubernetes implementiert. Es ist sehr cool, dass das Informationsmodell vom Operationssaal getrennt ist. In der Datenbank wird über die gewöhnliche CRUD-Schnittstelle angegeben, was sein soll. Dann versucht eine Reihe von Controllern, alles in Ordnung zu bringen. Das ist zwar nicht immer der Fall.

    Dies ist ein kybernetisches Modell. Wir haben eine bestimmte Vorgabe, es gibt eine Art Maschine, die versucht, die reale Welt oder die Maschine an den Ort zu lenken, der benötigt wird. Das funktioniert nicht immer so: Wir sollten eine Feedbackschleife haben. Manchmal kann die Maschine dies nicht und sollte die Person ansprechen.



    In realen Systemen denken wir an Abstraktionen der folgenden Ebene: Wir haben bestimmte Dienste und Datenbanken und verbinden all dies miteinander. Wir denken nicht an PODs und Ingress und wir wollen eine nächste Abstraktionsebene aufbauen.

    Damit der Entwickler so einfach wie möglich war: Er sagte einfach: "Ich möchte einen solchen Dienst starten", und alles andere geschah im Inneren.

    Es gibt so etwas wie HELM. Dies ist der falsche Weg - die Vorlage hat einen ansprechbaren Stil, bei dem wir versuchen, einen Satz konfigurierter Ressourcen zu generieren und in den Kubernetes-Cluster zu werfen.

    Das Problem ist erstens, dass es nur zum Zeitpunkt des Walzens ausgeführt wird. Das ist eine Menge Logik, die er nicht umsetzen kann. Zweitens verschwindet diese Abstraktion zur Laufzeit. Wenn ich mir meinen Cluster anschaue, sehe ich nur die PODs und Dienste. Ich sehe nicht, dass ein solcher und ein solcher Dienst betroffen ist, dass dort eine solche Basis mit Replikation aufgebaut wird. Ich sehe gerade, dass es Dutzende Hülsen gibt. Die Abstraktion verschwindet in der Matrix.

    Internes Lösungsmodell


    Andererseits bietet Kubernetes selbst bereits ein sehr interessantes und einfaches Erweiterungsmodell. Wir können neue Arten von Ressourcen ankündigen, beispielsweise die Bereitstellung. Dies ist eine Ressource, die auf einem POD oder Replicaset aufgebaut ist. Wir können einen Controller für diese Ressource schreiben, diese Ressource in die Datenbank aufnehmen und unsere kybernetische Schleife starten, damit alles funktioniert. Das hört sich interessant an, und ich denke, dies ist der richtige Weg, um Kubernetes zu erweitern.

    Ich würde gerne eine Art Manifest für meine Dienste im Heroku-Stil schreiben können. Ein sehr einfaches Beispiel: Ich möchte eine Art Anwendung in meiner realen Umgebung einschließen. Es gibt bereits Vereinbarungen, SSL, gekaufte Domains. Ich wollte nur den Entwicklern die einfachste mögliche Schnittstelle geben. Manifest sagt mir, welcher Container zu heben ist und welche Ressourcen dieser Container noch benötigt. Er wirbt diese Anzeige im Cluster und alles beginnt zu funktionieren.


    Wie wird es in Bezug auf benutzerdefinierte Ressourcen und Controller aussehen? Hier müssen wir in der Datenbank der Ressourcenanwendung sein. Und der Anwendungscontroller wird drei Ressourcen erzeugen. Das heißt, er registriert die Regeln für die Weiterleitung an diesen Dienst, startet den Dienst für den Lastausgleich und startet die Bereitstellung mit einer Konfiguration.



    Bevor wir eine benutzerdefinierte Ressource in Kubernetes erstellen, müssen wir sie deklarieren. Dafür gibt es eine Meta-Ressource namens CustomResourceDefinition.

    Um eine neue Ressource in Kubernetes anzukündigen, müssen wir hier nur eine solche Anzeige zaplapitieren. Lesen Sie diese Erstellentabelle.


    Eine Tabelle erstellt. Danach können wir durch kubectl nach den Ressourcen Dritter suchen, die wir haben. Sobald wir es angekündigt hatten, bekamen wir auch einen apish. Wir können zum Beispiel kubeclt Apps bekommen. Aber bis jetzt kein Appov.


    Lass uns eine App schreiben. Danach können wir eine benutzerdefinierte Ressourceninstanz erstellen. Lassen Sie uns es in YAML betrachten und erstellen, indem Sie es an eine bestimmte URL senden.


    Wenn wir kubectl ausführen und durchsehen, erschien eine App. Obwohl nichts passiert, liegt es nur in der Datenbank. Sie können beispielsweise alle App-Ressourcen übernehmen und anfordern.


    Wir können eine zweite solche Ressource aus derselben Vorlage erstellen, indem Sie einfach den Namen ändern. Hier kam die zweite Ressource.


    Als Nächstes sollte unser Controller das Templating durchführen, ähnlich wie HELM. Das heißt, nachdem ich eine Beschreibung unserer App erhalten habe, muss ich eine Ressourcenbereitstellung und einen Ressourcendienst generieren und auch einen Eintrag im Ingress vornehmen. Dies ist der einfachste Teil: Hier in clojure ist es erlmacro. Ich übertrage die Datenstruktur, es ruckt die Deployment-Funktion, geht an den Debug, der die Pipeline ist. Und das ist eine reine Funktion: einfaches Templating. In der naivsten Form könnte ich es also sofort erstellen, in ein Konsolendienstprogramm umwandeln und mit dem Verteilen beginnen.


    Das Gleiche machen wir für den Dienst: Die Dienstfunktion akzeptiert eine Deklaration und generiert die Kubernetes-Ressource für uns.


    Dasselbe machen wir für die Ingress-Linie.


    Wie wird das alles funktionieren? Es wird etwas in der realen Welt geben und es wird das geben, was wir wollen. Was wir wollen, ist, dass wir die Anwendungsressource nehmen und für das generieren, was sein sollte. Und jetzt müssen wir sehen, was ist. Was wir haben, wird über die REST-API angefordert. Wir können alle Dienste und Bereitstellungen abrufen.

    Wie funktioniert unser Custom Controller? Er wird bekommen, was wir wollen und was es ist, dieses Div nehmen und auf Kubernetes anwenden. Dies ist ähnlich wie bei React. Ich habe mir ein virtuelles DOM ausgedacht, als einige Funktionen einfach einen Baum von JS-Objekten generieren. Dann berechnet ein bestimmter Algorithmus den Patch und wendet ihn auf das echte DOM an.

    Das machen wir auch hier. Dies erfolgt in 50 Codezeilen. Willst du es - alles ist auf Github. Als Ergebnis sollten wir die Funktion abgleichen-Aktionen erhalten.

    Wir haben eine Funktion zum Abgleichen von Aktionen, die nichts tut und nur dieses div berechnet. Sie nimmt, was ist, und was benötigt wird. Und gibt dann an, was getan werden muss, um den ersten zum zweiten zu bringen.


    Lass uns sie wichsen. Es ist nichts falsch damit, Sie können es debuggen. Sie sagt, dass Sie einen Ingress-Service erstellen müssen, zwei Einträge darin vornehmen, Bereitstellung 1 und 2 erstellen, Service 1 und 2 erstellen.


    In diesem Fall sollte es nur einen Dienst geben. Wir sehen durch Ingress, dass nur ein Datensatz verbleibt.

    Als Nächstes müssen Sie nur noch eine Funktion schreiben, die diesen Patch auf den Kubernetes-Cluster anwendet. Dazu übergeben wir einfach die Abgleichaktionen an die Abgleichfunktion und alles wird zutreffen. Und hier sehen wir, dass der POD gestiegen ist, die Bereitstellung geworden ist und der Dienst begonnen hat.


    Fügen wir noch einen Dienst hinzu: Noch einmal führen wir die Funktion Reconcile-Actions aus. Mal sehen was passiert ist. Alles hat angefangen, alles ist gut.


    Wie gehe ich damit um? Wir alle packen es in einen Docker-Container. Danach schreiben wir eine Funktion, die periodisch aufwacht, versöhnt und einschlafen lässt. Die Geschwindigkeit ist nicht sehr wichtig, sie kann fünf Sekunden lang schlafen und seltener Abstimmungsaktionen ausführen.


    Unser Custom Controller ist nur ein Service, der einen Patch aufwacht und regelmäßig berechnet.

    Jetzt haben wir zwei Dienste, zepeploino, lassen Sie uns eine der Anwendungen entfernen. Mal sehen, wie unser Cluster reagiert hat: Alles ist in Ordnung. Entferne die Sekunde: alles wird gelöscht.


    Lassen Sie uns durch die Augen des Entwicklers sehen. Er muss nur sagen, dass Kubernetes sich bewerben und den Namen des neuen Dienstes festlegen. Wir machen das, unser Controller hat alles aufgegriffen und erstellt.


    Als Nächstes sammeln wir all dies in den Bereitstellungsdienst. Mit den standardmäßigen Kubernetes-Tools werfen wir diesen benutzerdefinierten Controller in einen Cluster. Wir haben eine Abstraktion für 200 Codezeilen erstellt.

    Es ist alles wie HELM, aber tatsächlich mächtiger. Der Controller arbeitet in einem Cluster: Er sieht die Basis, sieht die Außenwelt und kann ziemlich schlau gemacht werden.

    Eigenes CI


    Betrachten Sie die Beispiele der Kubernetes-Erweiterung. Wir haben entschieden, dass CI Teil der Infrastruktur sein sollte. Das ist gut, es ist aus Sicherheitsgründen bequem - ein privates Repository. Wir haben versucht, Jenkins zu verwenden, aber es ist ein veraltetes Werkzeug. Ich wollte ein Hacker-CI. Wir brauchen keine Schnittstellen, wir lieben ChatOps: Lassen Sie sie einfach im Chat sagen, ob das Build nicht funktioniert oder nicht. Außerdem wollte ich alles lokal debuggen.

    Wir haben uns hingesetzt und in einer Woche unser CI geschrieben. Nur als Erweiterung zu Kubernetes. Wenn Sie über CI nachdenken, ist dies nur ein Werkzeug, das einige Jobs ausführt. Als Teil dieses Jobs bauen wir etwas, führen Tests durch und setzen häufig ein.

    Wie funktioniert das alles? Es basiert auf dem gleichen Konzept von benutzerdefinierten Controllern. Zuerst lassen wir die Beschreibung, welche Repositories wir in Kubernetes beobachten, fallen. Der Controller geht einfach zum Githab und fügt einen Webhaken hinzu. Wir bleiben mit der Selbstbeobachtung zurück.

    Als nächstes kommt der Web-Hook, dessen einzige Aufgabe es ist, den eingehenden JSON zu verarbeiten und in die benutzerdefinierte Erstellungsressource zu werfen, die sich auch auf die Kubernetes-Datenbank summiert. Die Build-Ressource wird vom Build-Controller überwacht, der das Manifest innerhalb des Projekts liest und den POD startet. Dieser POD-e führt alle erforderlichen Dienste aus.

    Der POD verfügt über einen sehr einfachen Agenten, der eine Travis- oder Circleci-Deklaration und eine Reihe von Schritten in YAML liest. Er beginnt sie zu spielen. Danach, am Ende des Builds, setzt er sein Ergebnis in das Telegramm.

    Eine weitere Funktion, die wir mit Kubernetes zusammengestellt haben, ist, dass einer der Befehle bei der Ausführung Ihres CI oder der kontinuierlichen Übermittlung nur während des echten Schlafes 10 gesetzt werden kann und Ihr POD bei diesem Schritt einfrieren wird. Sie machen kubectl exec, Sie befinden sich in Ihrem Build und Sie können debuggen.

    Eine weitere Funktion - alles ist auf Dockern aufgebaut und Sie können das Skript lokal debuggen, indem Sie das Docker starten. Es dauerte zwei Wochen und 300 Zeilen Code.



    Mit Postgres arbeiten


    Unser Produkt basiert auf Postgres, wir verwenden alle interessanten Funktionen. Wir haben sogar eine Reihe von Erweiterungen geschrieben. Wir können jedoch kein RDS oder etwas anderes verwenden.

    Wir sind gerade dabei, einen Operator für nicht getötete Postgres zu entwickeln. Stimmhafte Architektur. Ich möchte sagen "Cluster, gib mir Postgres, die nicht getötet werden können." Dazu brauche ich zwei asynchrone Repliken, eine synchron, täglich Backups und bis zu einem Terabyte. Ich werfe alles hin und her, mein Cluster-Controller beginnt mit dem Orchestrieren und Entfalten meines Containers. Es erstellt Pginstance-Ressourcen, die für jeden Postgrader verantwortlich sind. Dies wird ein Cluster Postgres sein.

    Als nächstes kommt der Pginstance-Controller, einfach genug, der versucht, einen POD oder eine Bereitstellung mit diesen Postgres auszuführen. Das Herz ist ein beständiges Volumen. Diese gesamte Maschine übernimmt die volle Kontrolle über Postgres. Sie geben ihr einen Docker-Container, in dem es nur binäre Postgres gibt. Alles andere: Die Konfiguration und Erstellung der Startcluster-Postgres wird vom Controller selbst vorgenommen. Er tut dies, damit wir ihn später neu konfigurieren können und Replikation, Protokollebene usw. konfigurieren können. Zu Beginn durchläuft der temporäre POD den persistenten Datenträger und erstellt dort einen Postgres-Cluster für den Master.

    Als Nächstes beginnt die Bereitstellung mit Master. Das persistente Volume wird auf dieselbe Weise erstellt. Ein anderer POD wird ausgeführt, erstellt eine grundlegende Sicherung, strafft sie und die Bereitstellung beginnt von einem Slave, der darüber hinausgeht.

    Next Cluster Controller erstellt eine Sicherungsressource (nachdem die Sicherungen beschrieben wurden). Und der Backup-Controller nimmt es bereits und wirft es in ein S3.



    Was weiter?


    Stellen wir uns mit Ihnen die nahe Zukunft vor. Es kann vorkommen, dass wir früher oder später über solche interessanten benutzerdefinierten Ressourcen verfügen werden, so dass ich sagen kann: "Gib mir Postgres, gib mir Kafka, lass mir CI und fang damit an". Alles wird leicht sein.

    Wenn wir nicht über die nahe Zukunft sprechen, dann glaube ich als deklarativer Programmierer, dass die obige funktionale Programmierung nur logisch oder relational ist. Dort haben wir Operations-Semantik völlig getrennt von Informationssemantik. Wenn wir unsere benutzerdefinierten Controller genau betrachten, haben wir in der Datenbank beispielsweise eine Ressourcenanwendung. Und wir leiten daraus drei zusätzliche Ressourcen ab. Dies ist der Ansicht in der Datenbank sehr ähnlich. Dies ist ein Abzug von Fakten. Dies ist eine logische oder Beziehungsansicht.

    Der nächste Schritt für Kubernetes ist, anstelle der gehackten REST-API, eine Illusion von einer relationalen oder logischen Basis zu vermitteln, in der Sie einfach eine Regel schreiben können. Da früher oder später alles einschließlich der Rückmeldungen zur Datenbank fließt, können die Regeln wie folgt lauten: "Wenn die Last so gestiegen ist, erhöhen Sie die Replikation auf diese Weise." Wir haben eine kleine SQL-Regel oder eine logische Regel. Alles was Sie brauchen, ist eine generische Engine, die dies überwacht. Aber dies ist eine glänzende Zukunft.


    Weitere coole Berichte auf der DevOops 2018 Konferenz ! Alle Referenten und Programm - auf der Website .

    Wenn sich Ihr Zuhause im Regal befindet, finden Sie unter „The DevOps Handbook“ , „Learning Chef: Leitfaden für Konfigurationsmanagement und -automatisierung“ , „How to containerize Ihren Go-Code“ oder den neuen Code „Liquid Software: How To Achieve Achieve“ “ - bringen Sie sie zur Konferenz. In den Diskussionsbereichen nach den Berichten organisieren wir kleine Autogrammstunden mit den Autoren dieser Bücher.

    Stellen Sie sich vor: eine einzigartige Gelegenheit, ein Autogramm von John Willis selbst zu bekommen !

    Und ein schöner Bonus: bis zum 1. OktoberTickets für DevOops 2018 können mit einem Rabatt gebucht werden.

    Jetzt auch beliebt: