Mädchen auf einem Scooter. Illustration , Logo von Nomad von
Kubernetes ist ein 300 Kilogramm schwerer Gorilla zur Orchestrierung von Containern. Es wird in einigen der größten Container-Systeme weltweit eingesetzt, ist jedoch kostspielig.
Besonders teuer für kleine Teams, die viel Zeit mit Wartung und einer steilen Lernkurve verbringen müssen. Für unser Team von vier Personen ist das zu viel Overhead. Daher haben wir nach Alternativen gesucht und uns in .
verliebt.
Was wir brauchen Gollum
, sowie Datenbanken wie InfluxDB oder Elasticsearch. Jeder dieser Dienste läuft in einem eigenen Container. Wir benötigen ein einfaches System, um all dies in Betrieb zu halten.
- Wir begannen mit einer Liste von Anforderungen für die Container-Orchestrierung:
- Starten eines Satzes von Diensten auf mehreren Maschinen.
- Überblick über die laufenden Dienste.
- Verbindungen zwischen den Diensten.
- Automatischer Neustart, wenn ein Dienst ausfällt.
Zusätzlich wären die folgenden Punkte nützliche, aber nicht zwingende Ergänzungen:
- Kennzeichnung von Maschinen basierend auf ihren Fähigkeiten (z. B. Kennzeichnung von Maschinen mit schnellen Festplatten für rechenintensive I/O-Services).
- Die Möglichkeit, Dienste unabhängig vom Orchestrator zu starten (z. B. während der Entwicklung).
- Ein zentraler Ort für den Austausch von Konfigurationen und Geheimnissen.
- Eine Endpunkt für Metriken und Logs.
Warum Kubernetes für uns nicht geeignet ist
Bei der Prototypenerstellung mit Kubernetes haben wir festgestellt, dass wir immer komplexere Logikschichten eingeführt haben, auf die wir blind vertrauten.
Zum Beispiel unterstützt Kubernetes eingebettete Service-Konfigurationen über . Es kann schnell verwirrend werden, insbesondere beim Zusammenführen mehrerer Konfigurationsdateien oder beim Hinzufügen zusätzlicher Dienste zu einem Pod. Kubernetes (oder In diesem Fall ermöglicht es die dynamische Implementierung externer Konfigurationen zur Trennung der Interessen. Dies führt jedoch zu einer festen, verborgenen Bindung zwischen Ihrem Projekt und Kubernetes. Helm und ConfigMaps sind zusätzliche Optionen, die Sie nicht zwingend nutzen müssen. Sie können auch ganz einfach die Konfiguration in das Docker-Image kopieren. Dennoch ist es verlockend, diesen Weg zu gehen und unnötige Abstraktionen zu schaffen, über die Sie später vielleicht bereuen werden.
Darüber hinaus entwickelt sich das Kubernetes-Ökosystem schnell. Es erfordert viel Zeit und Energie, um über bewährte Praktiken und neueste Werkzeuge informiert zu bleiben. Kubectl, minikube, kubeadm, helm, tiller, kops, oc – die Liste lässt sich endlos fortsetzen. Zu Beginn benötigen Sie nicht alle diese Werkzeuge, aber es ist ungewiss, was Sie tatsächlich brauchen werden, daher sollten Sie über alles im Bilde sein. Dies führt zu einer steilen Lernkurve.
Wann sollte man Kubernetes einsetzen
In unserem Unternehmen nutzen viele Kubernetes und sind damit sehr zufrieden. Diese Instanzen werden von Google oder Amazon verwaltet, die über ausreichend Ressourcen verfügen.
Kubernetes wird mit , die das Management der containerbasierten Skalierung vereinfachen:
- Detaillierte .
- fügen Logik in den Cluster ein. Es sind einfach Programme, die mit der Kubernetes API kommunizieren.
- ! Kubernetes kann Dienste nach Bedarf skalieren, indem es Dienstmetriken verwendet, ohne dass manuelles Eingreifen erforderlich ist.
Die Frage ist, ob Sie wirklich all diese Funktionen benötigen. Sie sollten sich nicht nur auf Abstraktionen verlassen; .
Unser Team bietet die meisten Dienste remote an (aufgrund der engen Verbindung zur Hauptinfrastruktur), daher wollten wir keinen eigenen Kubernetes-Cluster aufbauen. Wir wollten einfach Dienste bereitstellen.
Batterien nicht enthalten
Nomad ist 20 % Orchestrierung, die 80 % des Erforderlichen bietet. Alles, was es tut, ist, Deployments zu verwalten. Nomad kümmert sich um Deployments, startet Container im Fehlerfall neu… und das war's.
Der ganze Zweck von Nomad besteht darin, dass es mindestenskeine detaillierte Rechteverwaltung oder gibt, so wurde es bewusst entworfen. Diese Komponenten werden von extern bereitgestellt oder gar nicht bereitgestellt.
Ich denke, dass Nomad den perfekten Kompromiss zwischen Benutzerfreundlichkeit und Funktionalität gefunden hat. Es ist ideal für kleine, unabhängige Dienste. Wenn mehr Kontrolle erforderlich ist, muss man diese selbst aufbauen oder einen anderen Ansatz wählen. Nomad ist einfach ein Orchestrator.
Das Beste an Nomad ist, dass es leicht Hook im Repository zu ersetzen.zu bedienen ist. Die Abhängigkeit von Anbietern ist nahezu nicht vorhanden, da seine Funktionen einfach in jedes andere Service-Management-System integriert werden können. Es funktioniert ganz einfach wie ein reguläres Binary auf jeder Maschine im Cluster, das ist alles!
Die Nomad-Ökosystem besteht aus locker verbundenen Komponenten.
Die echte Stärke von Nomad liegt in seinem Ökosystem. Es integriert sich sehr gut mit anderen - völlig optionalen - Produkten wie (einem Key-Value-Speicher) oder (Geheimnisverwaltung). Im Nomad-File gibt es Abschnitte zum Abrufen von Daten aus diesen Diensten:
template {
data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH
destination = "secrets/file.env"
env = true
} Hier lesen wir den Schlüssel service/geo-api/log-verbosity aus Consul und stellen ihn während der Laufzeit als Umgebungsvariable LOG_LEVELbereit. Wir stellen auch den Schlüssel secret/geo-api-key aus Vault als API_KEY. Einfach, aber leistungsstark!
Dank seiner Einfachheit lässt sich Nomad leicht mit anderen Diensten über APIs erweitern. Zum Beispiel werden Tags für Jobs unterstützt. Wir kennzeichnen alle Dienste mit Metriken durch ein Tag trv-metrics. Dadurch findet Prometheus diese Dienste problemlos über Consul und überprüft regelmäßig den Endpunkt /metrics auf neue Daten. Gleiches gilt zum Beispiel für Logs, die mit .
verwaltet werden. Es gibt viele weitere Beispiele für die Erweiterbarkeit:
- Ausführen eines Jenkins-Jobs mithilfe eines Hooks, wobei Consul die erneute Bereitstellung des Jobs in Nomad bei Änderungen an der Dienstkonfiguration überwacht.
- Ceph fügt Nomad ein verteiltes Dateisystem hinzu.
- für die Lastverteilung.
All dies ermöglicht es, ohne starke Bindung an einen Anbieter.
Ehrlicher Hinweis
Keine Lösung ist perfekt. Ich empfehle nicht, die allerneuesten Funktionen sofort in der Produktion einzusetzen. Natürlich gibt es Fehler und fehlende Funktionen, aber dasselbe gilt für Kubernetes.
Im Vergleich zu Kubernetes ist die Community von Nomad nicht so groß. Kubernetes hat bereits etwa 75.000 Commits und 2.000 Mitwirkende, während Nomad etwa 14.000 Commits und 300 Mitwirkende vorzuweisen hat. Es wird für Nomad schwer sein, mit Kubernetes in punkto Geschwindigkeit Schritt zu halten, aber vielleicht ist das auch gar nicht notwendig! Es handelt sich um ein spezialisierteres System, und eine kleinere Community bedeutet auch, dass Ihr Pull-Request im Vergleich zu Kubernetes eher wahrgenommen und angenommen wird.
Zusammenfassung
Fazit: Verwenden Sie Kubernetes nicht nur, weil es alle tun. Bewerten Sie Ihre Anforderungen sorgfältig und prüfen Sie, welches Werkzeug vorteilhafter ist.
Wenn Sie planen, eine Vielzahl homogener Dienste auf einer groß angelegten Infrastruktur bereitzustellen, ist Kubernetes eine gute Wahl. Bedenken Sie jedoch die zusätzliche Komplexität und Betriebskosten. Einige Kosten können vermieden werden, indem Sie eine verwaltete Kubernetes-Umgebung wie oder .
Wenn Sie einfach einen zuverlässigen Orchestrator suchen, der leicht zu warten und skalierbar ist, warum sollten Sie dann nicht Nomad ausprobieren? Möglicherweise werden Sie überrascht sein, wie weit Sie damit kommen.
Wenn man Kubernetes mit einem Auto vergleicht, ist Nomad wie ein Roller. Manchmal braucht man das eine, manchmal das andere. Beide haben ihren Platz.
Quelle: habr.com
