Mädchen auf einem Roller. Illustration , Nomad-Logo von
Kubernetes ist der 300-Pfund-Gorilla der Container-Orchestrierung. Es funktioniert in einigen der größten Containersysteme der Welt, ist aber teuer.
Besonders teuer für kleinere Teams, die viel Supportzeit und eine steile Lernkurve erfordern. Das ist zu viel Aufwand für unser vierköpfiges Team. Also machten wir uns auf die Suche nach Alternativen – und verliebten uns in sie .
Was willst du
Unser Team unterstützt eine Reihe gängiger Leistungsüberwachungs- und Analysedienste: API-Endpunkte für in Go geschriebene Metriken, Prometheus-Exporte, Protokollparser wie Logstash und sowie Datenbanken wie InfluxDB oder Elasticsearch. Jeder dieser Dienste läuft in einem eigenen Container. Wir brauchen ein einfaches System, um alles am Laufen zu halten.
Wir begannen mit einer Liste von Anforderungen für die Container-Orchestrierung:
- Ausführen einer Reihe von Diensten auf vielen Maschinen.
- Übersicht über laufende Dienste.
- Verbindungen zwischen Diensten.
- Automatischer Neustart, wenn der Dienst ausfällt.
- Wartung der Infrastruktur durch ein kleines Team.
Darüber hinaus sind die folgenden Dinge nette, aber nicht erforderliche Ergänzungen:
- Markieren Sie Maschinen basierend auf ihren Fähigkeiten (z. B. Markieren von Maschinen mit schnellen Festplatten für umfangreiche I/O-Dienste).
- Möglichkeit, Dienste unabhängig vom Orchestrator auszuführen (z. B. während der Entwicklung).
- Ein gemeinsamer Ort zum Teilen von Konfigurationen und Geheimnissen.
- Endpunkt für Metriken und Protokolle.
Warum Kubernetes nicht das Richtige für uns ist
Als wir mit Kubernetes Prototypen erstellten, stellten wir fest, dass wir immer komplexere Logikebenen hinzufügten, auf die wir uns stark verließen.
Beispielsweise unterstützt Kubernetes integrierte Dienstkonfigurationen über . Insbesondere beim Zusammenführen mehrerer Konfigurationsdateien oder beim Hinzufügen zusätzlicher Dienste zu einem Pod kann es schnell zu Verwirrung kommen. Kubernetes (oder (in diesem Fall) ermöglicht es Ihnen, externe Konfigurationen dynamisch zu implementieren, um Belange zu trennen. Dies führt jedoch zu einer engen, versteckten Kopplung zwischen Ihrem Projekt und Kubernetes. Helm und ConfigMaps sind jedoch zusätzliche Optionen, sodass Sie sie nicht verwenden müssen. Sie können die Konfiguration einfach in das Docker-Image kopieren. Es ist jedoch verlockend, diesen Weg zu gehen und unnötige Abstraktionen zu erstellen, die Sie später möglicherweise bereuen.
Darüber hinaus entwickelt sich das Kubernetes-Ökosystem rasant weiter. Es erfordert viel Zeit und Energie, mit Best Practices und den neuesten Tools auf dem Laufenden zu bleiben. Kubectl, Minikube, Kubeadm, Helm, Pinne, Kops, OC – die Liste geht weiter und weiter. Am Anfang werden nicht alle dieser Tools benötigt, aber Sie wissen nicht, was Sie brauchen, also müssen Sie über alles Bescheid wissen. Aus diesem Grund ist die Lernkurve recht steil.
Wann sollte Kubernetes verwendet werden?
In unserem Unternehmen nutzen viele Leute Kubernetes und sind sehr zufrieden damit. Diese Instanzen werden von Google oder Amazon verwaltet, die über die Ressourcen verfügen, sie zu unterstützen.
Kubernetes ist im Lieferumfang enthalten , wodurch die Container-Orchestrierung im großen Maßstab einfacher zu verwalten ist:
- Ausführlich .
- Fügen Sie dem Cluster Logik hinzu. Dabei handelt es sich einfach um Programme, die mit der Kubernetes-API kommunizieren.
- ! Kubernetes kann Dienste nach Bedarf mithilfe von Dienstmetriken skalieren, ohne dass manuelle Eingriffe erforderlich sind.
Die Frage ist, ob Sie all diese Funktionen wirklich benötigen. Man kann sich nicht nur auf Abstraktionen verlassen; .
Unser Team stellt die meisten Dienste aus der Ferne bereit (aufgrund der engen Verbindung zur Hauptinfrastruktur), daher wollten wir keinen eigenen Kubernetes-Cluster aufbauen. Wir wollten lediglich Dienstleistungen erbringen.
Batterien nicht enthalten
Nomad macht 20 % der Orchestrierung aus, die 80 % des Bedarfs bereitstellt. Es verwaltet lediglich Bereitstellungen. Nomad kümmert sich um Bereitstellungen, startet Container bei Fehlern neu ... und das war’s.
Der springende Punkt bei Nomad ist, was es tut Minimum: keine granulare Rechteverwaltung bzw , das ist speziell konzipiert. Diese Komponenten werden extern oder gar nicht bereitgestellt.
Ich denke, Nomad hat den perfekten Kompromiss zwischen Benutzerfreundlichkeit und Nutzen gefunden. Es ist gut für kleine, unabhängige Dienste. Wenn Sie mehr Kontrolle benötigen, müssen Sie diese selbst erhöhen oder einen anderen Ansatz wählen. Nomad ist nur Orchestrator.
Das Beste an Nomad ist, dass es einfach ist ersetzen. Es besteht praktisch keine Verbindung zum Anbieter, da seine Funktionen problemlos in jedes andere System zur Verwaltung von Diensten integriert werden können. Es läuft einfach wie eine normale Binärdatei auf jeder Maschine im Cluster, das ist alles!
Nomadisches Ökosystem aus lose gekoppelten Komponenten
Die wahre Stärke von Nomad ist sein Ökosystem. Es lässt sich sehr gut mit anderen – völlig optionalen – Produkten integrieren, wie z (Schlüsselwertspeicher) oder (Verarbeitungsgeheimnisse). In der Nomad-Datei gibt es Abschnitte zum Extrahieren 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 von Consul und während der Arbeit machen wir es einer Umgebungsvariablen zugänglich LOG_LEVEL. Wir präsentieren auch den Schlüssel secret/geo-api-key aus Vault as API_KEY. Einfach, aber kraftvoll!
Aufgrund seiner Einfachheit ist Nomad über die API problemlos mit anderen Diensten erweiterbar. Beispielsweise werden Tags für Aufgaben unterstützt. Wir kennzeichnen alle Dienste mit Metriken trv-metrics. Auf diese Weise kann Prometheus diese Dienste einfach über Consul finden und den Endpunkt regelmäßig überprüfen /metrics für neue Daten. Dasselbe kann beispielsweise für Protokolle erfolgen, indem .
Es gibt viele weitere Beispiele für Erweiterbarkeit:
- Führen Sie einen Jenkins-Job mit einem Hook aus, und Consul überwacht die erneute Bereitstellung des Nomad-Jobs, wenn sich die Dienstkonfiguration ändert.
- Ceph fügt Nomad ein verteiltes Dateisystem hinzu.
- zum Lastausgleich.
All dies ermöglicht ohne besondere Verbindung zum Anbieter.
Faire Warnung
Kein System ist perfekt. Ich empfehle nicht, die neuesten Funktionen sofort in die Produktion einzuführen. Natürlich gibt es Fehler und fehlende Funktionen, aber das Gleiche gilt auch für Kubernetes.
Im Vergleich zu Kubernetes ist die Nomad-Community nicht so groß. Kubernetes hat bereits etwa 75 Commits und 000 Mitwirkende, während Nomad etwa 2000 Commits und 14 Mitwirkende hat. Nomad wird es schwer haben, mit der Geschwindigkeit von Kubernetes mitzuhalten, aber vielleicht muss es das auch nicht! Es handelt sich um ein spezialisierteres System, und die kleinere Community bedeutet auch, dass Ihre Pull-Anfrage im Vergleich zu Kubernetes eher wahrgenommen und akzeptiert wird.
Zusammenfassung
Fazit: Verwenden Sie Kubernetes nicht, nur weil es alle anderen tun. Bewerten Sie Ihre Anforderungen sorgfältig und prüfen Sie, welches Tool vorteilhafter ist.
Wenn Sie vorhaben, eine Menge homogener Dienste in einer großen Infrastruktur bereitzustellen, ist Kubernetes eine gute Option. Beachten Sie jedoch die zusätzliche Komplexität und die Betriebskosten. Einige Kosten können durch die Verwendung einer verwalteten Kubernetes-Umgebung vermieden werden, z oder .
Wenn Sie einfach nur auf der Suche nach einem zuverlässigen Orchestrator sind, der einfach zu warten und erweiterbar ist, warum probieren Sie nicht Nomad aus? Sie werden überrascht sein, wie weit Sie damit kommen werden.
Vergleicht man Kubernetes mit einem Auto, wäre Nomad ein Roller. Manchmal braucht man eine Sache und manchmal braucht man eine andere. Beide haben eine Daseinsberechtigung.
Source: habr.com