Ein Mädchen auf einem Scooter. Illustration , Logo von Nomad von
Kubernetes ist ein 300-Kilogramm-Gorilla zur Orchestrierung von Containern. Es wird in einigen der größten Containersysteme der Welt eingesetzt, ist aber teuer.
Insbesondere für kleine Teams, die viel Zeit mit Wartung und einer steilen Lernkurve verbringen müssen. Für unser Team von vier Personen sind die Kosten zu hoch. Daher haben wir nach Alternativen gesucht – und uns in .
Was wir wollen
Unser Team unterstützt eine Reihe typischer Dienste zur Überwachung und Analyse der Leistung: API-Endpunkte für Metriken, die in Go geschrieben sind, Prometheus-Exporte, Log-Parser wie Logstash und , sowie Datenbanken wie InfluxDB oder Elasticsearch. Jeder dieser Dienste läuft in einem eigenen Container. Wir brauchen ein einfaches System, um das alles am Laufen zu halten.
Wir begannen mit einer Liste von Anforderungen für die Orchestrierung von Containern:
- Starten eines Sets von Diensten auf vielen Maschinen.
- Übersicht über die laufenden Dienste.
- Verbindungen zwischen Diensten.
- Automatischer Neustart, wenn ein Dienst ausfällt.
- Wartung der Infrastruktur durch ein kleines Team.
Darüber hinaus wären folgende Punkte angenehm, aber keine Pflicht:
- Kennzeichnung von Maschinen nach ihren Möglichkeiten (z. B. Kennzeichnung von Maschinen mit schnellen Festplatten für rechenintensive Dienste).
- Die Möglichkeit, Dienste unabhängig vom Orchestrator zu starten (z. B. während der Entwicklung).
- Ein gemeinsamer Ort zum Austausch von Konfigurationen und Geheimnissen.
- Ein Endpunkt für Metriken und Logs.
Warum Kubernetes für uns nicht geeignet ist
Beim Erstellen eines Prototyps mit Kubernetes haben wir festgestellt, dass wir immer komplexere Logikschichten hinzufügen, auf die wir ohne Vorbehalt angewiesen waren.
Zum Beispiel unterstützt Kubernetes eingebettete Dienstkonfigurationen über . Man kann schnell den Überblick verlieren, 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 Integration externer Konfigurationen zur Trennung von Interessen. Dies führt jedoch zu einer strikten, verborgenen Verbindung zwischen Ihrem Projekt und Kubernetes. Helm und ConfigMaps sind zusätzliche Optionen, die Sie nicht unbedingt nutzen müssen. Sie können die Konfiguration einfach in das Docker-Image kopieren. Dennoch kann es verlockend sein, diesen Weg zu gehen und unnötige Abstraktionen zu schaffen, über die Sie später vielleicht bereuen werden.
Zudem entwickelt sich das Kubernetes-Ökosystem schnell weiter. Es erfordert viel Zeit und Energie, um über bewährte Verfahren und die neuesten Tools informiert zu bleiben. Kubectl, minikube, kubeadm, helm, tiller, kops, oc – die Liste geht weiter und weiter. Zu Beginn benötigt man nicht all diese Tools, aber man weiß nicht, was man brauchen wird, also muss man über alles informiert sein. Dadurch ist die Lernkurve ziemlich steil.
Wann man Kubernetes verwenden sollte
In unserem Unternehmen nutzen viele Kubernetes und sind damit recht zufrieden. Diese Instanzen werden von Google oder Amazon verwaltet, die genügend Ressourcen zur Unterstützung haben.
Kubernetes kommt mit , die das Management von großen Container-Orchestrierungen erleichtern:
- Detaillierte .
- fügen dem Cluster Logik hinzu. Das sind einfach Programme, die mit der Kubernetes-API kommunizieren.
- ! Kubernetes kann Dienste bedarfsgerecht skalieren, unter Verwendung von Dienstmetriken, ohne manuelles Eingreifen.
Die Frage ist, ob Sie wirklich all diese Funktionen benötigen. Man kann sich nicht nur auf Abstraktionen verlassen; .
Unser Team stellt die meisten Dienste remote bereit (aufgrund enger Verknüpfungen mit der grundlegenden Infrastruktur), daher wollten wir keinen eigenen Kubernetes-Cluster aufbauen. Wir wollten einfach nur Dienstleistungen bereitstellen.
Batterien nicht enthalten
Nomad ist die 20 % Orchestrierung, die 80 % des Notwendigen bietet. Alles, was es tut, ist die Verwaltung von Deployments. Nomad kümmert sich um Deployments, startet Container im Fehlerfall neu… und das war's.
Der gesamte Sinn von Nomad liegt darin, dass es Mindestsatz: keine detaillierte Rechteverwaltung oder , so ist es gezielt konzipiert. Diese Komponenten werden extern bereitgestellt oder überhaupt nicht bereitgestellt.
Ich denke, dass Nomad den perfekten Kompromiss zwischen Benutzerfreundlichkeit und Nützlichkeit gefunden hat. Er ist gut für kleine, unabhängige Dienste. Wenn mehr Kontrolle erforderlich ist, müssen sie selbstständig hochgefahren oder ein anderer Ansatz verwendet werden. Nomad ist einfach ein Orchestrator.
Das Beste an Nomad ist, dass er einfach ersetzt werden kann. Die Bindung an Anbieter ist praktisch nicht vorhanden, da seine Funktionen leicht in jedes andere System integriert werden können, das Dienste verwaltet. Er funktioniert einfach wie ein gewöhnliches Binärprogramm auf jedem Rechner im Cluster, das ist alles!
Das Ökosystem von Nomad besteht aus schwach verknüpften Komponenten
Die wahre Stärke von Nomad liegt in seinem Ökosystem. Er integriert sich sehr gut mit anderen - völlig optionalen - Produkten, wie (Key-Value-Speicher) oder (Geheimnisverarbeitung). In der Nomad-Datei 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 präsentieren ihn zur Laufzeit als Umgebungsvariable LOG_LEVEL. Wir präsentieren auch den Schlüssel secret/geo-api-key aus Vault als API_KEY. Einfach, aber mächtig!
Dank seiner Einfachheit lässt sich Nomad leicht durch andere Dienste über die API erweitern. Zum Beispiel werden Tags für Aufgaben unterstützt. Wir kennzeichnen alle Dienste mit Metriken mit dem Tag trv-metrics. So findet Prometheus diese Dienste leicht über Consul und überprüft regelmäßig den Endpunkt /metrics auf neue Daten. Das Gleiche kann zum Beispiel für Logs gemacht werden, unter Verwendung von .
Es gibt viele andere Beispiele für Erweiterbarkeit:
- Start eines Jenkins-Jobs mit einem Hook, während Consul das erneute Bereitstellen des Nomad-Jobs bei Änderungen an der Dienstkonfiguration verfolgt.
- Ceph bringt ein verteiltes Dateisystem in Nomad ein.
- für Lastverteilung.
All dies ermöglicht es, ohne große Anbieterbindung.
Eine ehrliche Warnung
Keine System ist perfekt. Ich empfehle nicht, die neuesten Funktionen sofort in der Produktion einzuführen. Natürlich gibt es Fehler und fehlende Funktionen, aber das gilt auch 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 hat. Es wird für Nomad schwierig sein, Schritt mit Kubernetes zu halten, aber vielleicht muss es das auch gar nicht! Es ist ein spezialisierteres System, und eine kleinere Community bedeutet auch, dass dein Pull-Request eher bemerkt und angenommen wird als bei Kubernetes.
Zusammenfassung
Fazit: Verwende Kubernetes nicht nur, weil es alle tun. Beurteile deine Anforderungen sorgfältig und prüfe, welches Werkzeug vorteilhafter ist.
Wenn du planst, eine Vielzahl homogener Dienste auf großer Infrastruktur bereitzustellen, ist Kubernetes eine gute Wahl. Denk einfach an die zusätzliche Komplexität und die Betriebskosten. Einige Kosten können vermieden werden, indem du eine verwaltete Kubernetes-Umgebung wie oder .
Wenn du einfach einen zuverlässigen Orchestrator suchst, der leicht zu warten und skalierbar ist, warum nicht Nomad ausprobieren? Vielleicht wirst du überrascht sein, wohin es dich führen kann.
Wenn man Kubernetes mit einem Auto vergleicht, wäre Nomad ein Motorroller. Manchmal braucht man das eine und manchmal das andere. Beide haben ihre Berechtigung.
Quelle: habr.com
