Docker Swarm, Kubernetes und Mesos sind die beliebtesten Container-Orchestrierungs-Frameworks. In seinem Vortrag vergleicht Arun Gupta die folgenden Aspekte von Docker, Swarm und Kubernetes:
- Lokale Entwicklung.
- Bereitstellungsfunktionen.
- Multi-Container-Anwendungen.
- Diensterkennung.
- Skalierung des Dienstes.
- Einmalige Aufgaben ausführen.
- Integration mit Maven.
- „Rollendes“ Update.
- Erstellen eines Couchbase-Datenbankclusters.
Dadurch erhalten Sie ein klares Verständnis dafür, was die einzelnen Orchestrierungstools zu bieten haben, und lernen, wie Sie diese Plattformen effektiv nutzen können.
Arun Gupta ist der Cheftechnologe für Open-Source-Produkte bei Amazon Web Services, der seit über 10 Jahren die Entwicklergemeinschaften Sun, Oracle, Red Hat und Couchbase aufbaut. Verfügt über umfangreiche Erfahrung in der Leitung funktionsübergreifender Teams bei der Entwicklung und Umsetzung von Strategien für Marketingkampagnen und -programme. Er leitete Teams von Sun-Ingenieuren, ist einer der Gründer des Java EE-Teams und Gründer der US-Niederlassung von Devoxx4Kids. Arun Gupta ist Autor von mehr als 2 Beiträgen in IT-Blogs und hat Vorträge in mehr als 40 Ländern gehalten.
Zeile 55 enthält einen COUCHBASE_URI, der auf diesen Datenbankdienst verweist, der ebenfalls mithilfe der Kubernetes-Konfigurationsdatei erstellt wurde. Wenn Sie sich Zeile 2 ansehen, können Sie Folgendes sehen: Service ist der Dienst, den ich erstelle, der Couchbase-Service heißt, und derselbe Name ist in Zeile 4 aufgeführt. Nachfolgend sind einige Ports aufgeführt.
Die Schlüsselzeilen sind 6 und 7. Im Service sage ich: „Hey, das sind die Labels, nach denen ich suche!“, und diese Labels sind nichts anderes als Variablenpaarnamen, und Zeile 7 zeigt auf meinen Couchbase-RS-Pod Anwendung. Im Folgenden sind die Ports aufgeführt, die den Zugriff auf dieselben Labels ermöglichen.
In Zeile 19 erstelle ich einen neuen Typ ReplicaSet, Zeile 31 enthält den Namen des Bildes und die Zeilen 24–27 verweisen auf die mit meinem Pod verknüpften Metadaten. Das ist genau das, wonach der Dienst sucht und wozu die Verbindung hergestellt werden soll. Am Ende der Datei gibt es eine Art Verbindung zwischen den Zeilen 55-56 und 4, die besagt: „Nutze diesen Dienst!“
Ich starte meinen Dienst also, wenn ein Replikatsatz vorhanden ist, und da jeder Replikatsatz über einen eigenen Port mit der entsprechenden Bezeichnung verfügt, ist er im Dienst enthalten. Aus Entwicklersicht rufen Sie einfach den Dienst auf, der dann die von Ihnen benötigten Replikate verwendet.
Dadurch habe ich einen WildFly-Pod, der über den Couchbase-Service mit dem Datenbank-Backend kommuniziert. Ich kann das Frontend mit mehreren WildFly-Pods nutzen, das über den Couchbase-Dienst auch mit dem Couchbase-Backend kommuniziert.
Später werden wir uns ansehen, wie ein Dienst außerhalb des Clusters über seine IP-Adresse mit Elementen kommuniziert, die sich innerhalb des Clusters befinden und über eine interne IP-Adresse verfügen.
Zustandslose Container sind also großartig, aber wie gut ist es, zustandsbehaftete Container zu verwenden? Schauen wir uns die Systemeinstellungen für zustandsbehaftete oder persistente Container an. In Docker gibt es vier verschiedene Ansätze für das Datenspeicherlayout, auf die Sie achten sollten. Der erste ist Implicit Per-Container, was bedeutet, dass bei Verwendung von Couchbase-, MySQL- oder MyDB-Satateful-Containern alle mit der Standard-Sandbox beginnen. Das heißt, alles, was in der Datenbank gespeichert ist, wird im Container selbst gespeichert. Wenn der Container verschwindet, verschwinden auch die Daten.
Die zweite Option ist „Explicit Per-Container“, wenn Sie mit dem Docker-Volume-Create-Befehl einen bestimmten Speicher erstellen und Daten darin speichern. Der dritte Pro-Host-Ansatz ist mit der Speicherzuordnung verbunden, bei der alles, was im Container gespeichert ist, gleichzeitig auf dem Host dupliziert wird. Fällt der Container aus, bleiben die Daten auf dem Host. Bei Letzterem handelt es sich um den Einsatz mehrerer Multi-Host-Hosts, der bereits im Produktionsstadium verschiedener Lösungen sinnvoll ist. Nehmen wir an, Ihre Container mit Ihren Anwendungen laufen auf dem Host, Sie möchten Ihre Daten aber irgendwo im Internet speichern und nutzen dafür die automatische Zuordnung für verteilte Systeme.
Jede dieser Methoden verwendet einen bestimmten Speicherort. Implizite und explizite Container pro Container speichern Daten auf dem Host unter /var/lib/docker/volumes. Bei Verwendung der Per-Host-Methode wird der Speicher im Container bereitgestellt und der Container selbst wird auf dem Host bereitgestellt. Für Multihosts können Lösungen wie Ceph, ClusterFS, NFS usw. verwendet werden.
Wenn ein persistenter Container ausfällt, ist in den ersten beiden Fällen der Zugriff auf das Speicherverzeichnis nicht mehr möglich, in den letzten beiden Fällen bleibt der Zugriff jedoch bestehen. Im ersten Fall können Sie jedoch über einen Docker-Host, der auf einer virtuellen Maschine läuft, auf das Repository zugreifen. Im zweiten Fall gehen die Daten auch nicht verloren, da Sie einen expliziten Speicher erstellt haben.
Fällt der Host aus, ist das Speicherverzeichnis in den ersten drei Fällen nicht verfügbar, im letzten Fall wird die Verbindung zum Speicher nicht unterbrochen. Schließlich ist die gemeinsame Funktion im ersten Fall für die Speicherung völlig ausgeschlossen und im übrigen möglich. Im zweiten Fall können Sie Speicher gemeinsam nutzen, je nachdem, ob Ihre Datenbank verteilten Speicher unterstützt oder nicht. Im Fall von Per-Host ist die Datenverteilung nur auf einem bestimmten Host möglich, und bei einem Multihost erfolgt sie durch Clustererweiterung.
Dies sollte bei der Erstellung von Stateful-Containern berücksichtigt werden. Ein weiteres nützliches Docker-Tool ist das Volume-Plugin, das nach dem Prinzip „Batterien vorhanden, müssen aber ausgetauscht werden“ funktioniert. Wenn Sie einen Docker-Container starten, heißt es: „Hey, sobald Sie einen Container mit einer Datenbank starten, können Sie Ihre Daten in diesem Container speichern!“ Dies ist die Standardfunktion, Sie können sie jedoch ändern. Dieses Plugin ermöglicht es Ihnen, anstelle einer Container-Datenbank ein Netzlaufwerk oder ähnliches zu verwenden. Es enthält einen Standardtreiber für hostbasierten Speicher und ermöglicht die Containerintegration mit externen Speichersystemen wie Amazon EBS, Azure Storage und GCE Persistent Disks.
Die nächste Folie zeigt die Architektur des Docker Volume-Plugins.
Die blaue Farbe stellt den Docker-Client dar, der dem blauen Docker-Host zugeordnet ist, der über eine lokale Speicher-Engine verfügt, die Ihnen Container zum Speichern von Daten bereitstellt. Grün zeigt den Plugin-Client und den Plugin-Daemon an, die ebenfalls mit dem Host verbunden sind. Sie bieten die Möglichkeit, Daten im Netzwerkspeicher des von Ihnen benötigten Storage-Backend-Typs zu speichern.
Das Docker Volume-Plugin kann mit Portworx-Speicher verwendet werden. Das PX-Dev-Modul ist eigentlich ein von Ihnen ausgeführter Container, der eine Verbindung zu Ihrem Docker-Host herstellt und Ihnen die einfache Speicherung von Daten auf Amazon EBS ermöglicht.
Mit dem Portworx-Client können Sie den Status verschiedener Speichercontainer überwachen, die mit Ihrem Host verbunden sind. Wenn Sie meinen Blog besuchen, können Sie lesen, wie Sie Portworx mit Docker optimal nutzen.
Das Speicherkonzept in Kubernetes ähnelt dem von Docker und wird durch Verzeichnisse dargestellt, auf die Ihr Container in einem Pod zugreifen kann. Sie sind unabhängig von der Lebensdauer eines Containers. Die am häufigsten verfügbaren Speichertypen sind hostPath, nfs, awsElasticBlockStore und gsePersistentDisk. Werfen wir einen Blick darauf, wie diese Stores in Kubernetes funktionieren. Normalerweise besteht der Verbindungsprozess aus drei Schritten.
Der erste besteht darin, dass Ihnen jemand auf der Netzwerkseite, normalerweise ein Administrator, dauerhaften Speicher zur Verfügung stellt. Hierfür gibt es eine entsprechende PersistentVolume-Konfigurationsdatei. Als nächstes schreibt der Anwendungsentwickler eine Konfigurationsdatei namens PersistentVolumeClaim oder eine PVC-Speicheranforderung, die besagt: „Ich habe 50 GB verteilten Speicher bereitgestellt, aber damit auch andere Leute seine Kapazität nutzen können, teile ich diesem PVC mit, dass ich es derzeit verwende.“ benötige nur 10 GB". Der dritte Schritt schließlich besteht darin, dass Ihre Anfrage als Speicher bereitgestellt wird und die Anwendung, die über den Pod, den Replikatsatz oder etwas Ähnliches verfügt, damit beginnt, ihn zu verwenden. Es ist wichtig zu bedenken, dass dieser Prozess aus den genannten 3 Schritten besteht und skalierbar ist.
Die nächste Folie zeigt den Kubernetes Persistence Container der AWS-Architektur.
Innerhalb des braunen Rechtecks, das den Kubernetes-Cluster darstellt, befinden sich ein Masterknoten und zwei Workerknoten, die gelb markiert sind. Einer der Worker-Knoten enthält einen orangefarbenen Pod, Speicher, einen Replikat-Controller und einen grünen Docker Couchbase-Container. Innerhalb des Clusters, über den Knoten, zeigt ein violettes Rechteck den von außen zugänglichen Dienst an. Diese Architektur wird für die Speicherung von Daten auf dem Gerät selbst empfohlen. Bei Bedarf kann ich meine Daten in EBS außerhalb des Clusters speichern, wie in der nächsten Folie gezeigt. Dies ist ein typisches Skalierungsmodell, bei der Verwendung ist jedoch ein finanzieller Aspekt zu berücksichtigen: Das Speichern von Daten irgendwo im Netzwerk kann teurer sein als auf einem Host. Bei der Auswahl von Containerisierungslösungen ist dies eines der gewichtigen Argumente.
Genau wie bei Docker können Sie mit Portworx persistente Kubernetes-Container verwenden.
Dies wird in der aktuellen Kubernetes 1.6-Terminologie als „StatefulSet“ bezeichnet – eine Art der Arbeit mit Stateful-Anwendungen, die Ereignisse über das Stoppen des Pods und das Durchführen eines Graceful Shutdown verarbeitet. In unserem Fall handelt es sich bei solchen Anwendungen um Datenbanken. In meinem Blog können Sie lesen, wie Sie mit Portworx ein StatefulSet in Kubernetes erstellen.
Lassen Sie uns über den Entwicklungsaspekt sprechen. Wie gesagt, Docker hat zwei Versionen – CE und EE. Im ersten Fall sprechen wir von einer stabilen Version der Community Edition, die im Gegensatz zur monatlich aktualisierten Version von EE alle 2 Monate aktualisiert wird. Sie können Docker für Mac, Linux oder Windows herunterladen. Nach der Installation wird Docker automatisch aktualisiert und der Einstieg ist sehr einfach.
Für Kubernetes bevorzuge ich die Minikube-Version – sie ist eine gute Möglichkeit, mit der Plattform zu beginnen, indem man einen Cluster auf einem einzelnen Knoten erstellt. Um Cluster aus mehreren Knoten zu erstellen, ist die Auswahl an Versionen größer: Dies sind Kops, Kube-Aws (CoreOS+AWS), Kube-Up (veraltet). Wenn Sie AWS-basiertes Kubernetes nutzen möchten, empfehle ich Ihnen, der AWS SIG beizutreten, die sich jeden Freitag online trifft und eine Vielzahl interessanter Materialien zur Arbeit mit AWS Kubernetes veröffentlicht.
Schauen wir uns an, wie Rolling Update auf diesen Plattformen durchgeführt wird. Wenn ein Cluster aus mehreren Knoten vorhanden ist, wird eine bestimmte Version des Bildes verwendet, beispielsweise WildFly:1. Ein rollierendes Update bedeutet, dass die Image-Version nacheinander auf jedem Knoten durch eine neue ersetzt wird.
Dazu verwende ich den Befehl docker service update (service name), in dem ich die neue Version des WildFly:2-Images und die Update-Methode update-parallelism 2 spezifiziere. Die Zahl 2 bedeutet, dass das System 2 Anwendungsimages aktualisiert Gleichzeitig erfolgt dann eine 10-sekündige Aktualisierungsverzögerung von 10 Sekunden, danach werden die nächsten 2 Bilder auf 2 weiteren Knoten usw. aktualisiert. Dieser einfache Rolling-Update-Mechanismus wird Ihnen als Teil von Docker zur Verfügung gestellt.
In Kubernetes funktioniert ein Rolling Update so. Der Replikationscontroller rc erstellt eine Reihe von Replikaten derselben Version, und jeder Pod in diesem webapp-rc wird mit einem Label versehen, das sich in etcd befindet. Wenn ich einen Pod benötige, greife ich über den Anwendungsdienst auf das etcd-Repository zu, das mir den Pod mit der angegebenen Bezeichnung bereitstellt.
In diesem Fall haben wir 3 Pods im Replikationscontroller, auf denen die Anwendung WildFly Version 1 ausgeführt wird. Bei der Aktualisierung im Hintergrund wird am Ende ein weiterer Replikationscontroller mit demselben Namen und Index erstellt – xxxxx, wobei x Zufallszahlen sind, und mit den gleichen Etiketten. Jetzt verfügt Application Service über drei Pods mit der alten Version der Anwendung und drei Pods mit der neuen Version im neuen Replikationscontroller. Anschließend werden die alten Pods gelöscht, der Replikationscontroller mit den neuen Pods umbenannt und in Betrieb genommen.
Kommen wir zur Überwachung. Docker verfügt über viele integrierte Überwachungsbefehle. Mit der Befehlszeilenschnittstelle „Docker Container Stats“ können Sie beispielsweise jede Sekunde Informationen über den Status von Containern auf der Konsole anzeigen – Prozessorauslastung, Festplattennutzung, Netzwerklast. Das Docker Remote API-Tool stellt Daten darüber bereit, wie der Client mit dem Server kommuniziert. Es nutzt einfache Befehle, basiert aber auf der Docker REST API. In diesem Fall bedeuten die Wörter REST, Flash, Remote dasselbe. Wenn Sie mit dem Host kommunizieren, handelt es sich um eine REST-API. Mit der Docker Remote API können Sie weitere Informationen zum Ausführen von Containern erhalten. In meinem Blog werden die Details zur Verwendung dieser Überwachung mit Windows Server beschrieben.
Durch die Überwachung von Docker-Systemereignissen beim Ausführen eines Multi-Host-Clusters ist es möglich, Daten über einen Host-Absturz oder einen Container-Absturz auf einem bestimmten Host, Skalierungsdienste und Ähnliches zu erhalten. Ab Docker 1.20 ist Prometheus enthalten, das Endpunkte in bestehende Anwendungen einbettet. Dadurch können Sie Metriken über HTTP empfangen und auf Dashboards anzeigen.
Eine weitere Überwachungsfunktion ist cAdvisor (kurz für Container Advisor). Es analysiert und stellt Ressourcennutzungs- und Leistungsdaten von laufenden Containern bereit und stellt Prometheus-Metriken direkt nach dem Auspacken bereit. Das Besondere an diesem Tool ist, dass es nur Daten für die letzten 60 Sekunden liefert. Daher müssen Sie in der Lage sein, diese Daten zu sammeln und in einer Datenbank abzulegen, damit Sie einen langfristigen Prozess überwachen können. Es kann auch verwendet werden, um Dashboard-Metriken mithilfe von Grafana oder Kibana grafisch anzuzeigen. In meinem Blog finden Sie eine detaillierte Beschreibung, wie Sie mit cAdvisor Container mithilfe des Kibana-Dashboards überwachen.
Die nächste Folie zeigt, wie die Ausgabe des Prometheus-Endpunkts aussieht und welche Metriken zur Anzeige verfügbar sind.
Unten links sehen Sie Metriken für HTTP-Anfragen, -Antworten etc., rechts deren grafische Darstellung.
Kubernetes enthält außerdem integrierte Überwachungstools. Diese Folie zeigt einen typischen Cluster mit einem Master- und drei Worker-Knoten.
Jeder der Arbeitsknoten enthält einen automatisch gestarteten cAdvisor. Darüber hinaus gibt es Heapster, ein Leistungsüberwachungs- und Metrikerfassungssystem, das mit Kubernetes Version 1.0.6 und höher kompatibel ist. Mit Heapster können Sie nicht nur Leistungsmetriken von Workloads, Pods und Containern erfassen, sondern auch Ereignisse und andere vom gesamten Cluster generierte Signale. Um Daten zu sammeln, kommuniziert es mit dem Kubelet jedes Pods, speichert die Informationen automatisch in der InfluxDB-Datenbank und gibt sie als Metriken an das Grafana-Dashboard aus. Beachten Sie jedoch, dass diese Funktion bei Verwendung von miniKube nicht standardmäßig verfügbar ist und Sie daher Add-ons zur Überwachung verwenden müssen. Es hängt also alles davon ab, wo Sie die Container ausführen und welche Überwachungstools Sie standardmäßig verwenden können und welche Sie als separate Add-Ons installieren müssen.
Die nächste Folie zeigt Grafana-Dashboards, die den Betriebsstatus meiner Container anzeigen. Hier gibt es viele interessante Daten. Natürlich gibt es viele kommerzielle Docker- und Kubernetes-Prozessüberwachungstools wie SysDig, DataDog, NewRelic. Einige von ihnen verfügen über eine 30-jährige kostenlose Testphase, sodass Sie ausprobieren können, welches Programm am besten zu Ihnen passt. Persönlich bevorzuge ich die Verwendung von SysDig und NewRelic, die sich gut in Kubernetes integrieren lassen. Es gibt Tools, die sich gleichermaßen gut in Docker- und Kubernetes-Plattformen integrieren lassen.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com