Dieses Posting ist aus dem April 2021
Es ist ja schon länger klar, dass es potentielle Kunden gibt, die nicht die Zeit haben, den Aufwand scheuen oder einfach nicht die Chance haben, auf der "grünen Wiese" in eine Containerwelt mit Kubernetes einzutauchen. Eine Option für solche Unternehmen ist Docker Swarm - unter anderem, weil Mirantis die Lösung weiter unterstützt. Kleine Umgebungen lassen sich damit sehr schnell aufbauen und einfach betreiben. Die Handhabung kann aber durchaus etwas hakelig sein.
Eine andere Option, der Unternehmen wie CloudFlare, Trivago, CircleCI, SAP und eBay vertrauen, ist Nomad aus dem Hause Hashicorp.
Nomad arbeitet als Orchestrator - allerdings nicht nur für Docker Container sondern auch für KVM-VMs, Java Dienste, Prozesse, die direkt oder in einer Change-Root Umgebung ausgeführt werden und für weitere Dienste, die per Treiber angebunden werden können. Bei Trivago werden mit Nomad z. B. Dienste in FreeBSD-Jails gestartet und verwaltet. Es gibt aber auch Treiber für Podman. Nomad registriert spätestens beim Start, welche Treiber sich in seinem Plugin-Verzeichnis befinden und macht sie benutzbar.
Nomad integriert sich sehr einfach mit den anderen Projekten aus dem Hashicorp-Universum (z. B. mit Consul und Vault). Es ist kein Problem Cluster aufzubauen, die aus VMs, Containern, Bare Metal Servern bestehen und auf verschiedenen Betriebssystemen basieren.
Nomad ist vielleicht auch deshalb für Kunden so interessant, weil sie ihre seine bewährten und bekannten Storagesysteme weiterverwenden können (Host Volume Support) - inzwischen ist aber auch Storage über CSI ansprechbar. Für die Bereitstellung von Diensten nach außen bieten sich Software Loadbalancer wie Traefik und Fabio an, die ihre Konfiguration aus Consul beziehen und dynamisch anpassen können. Es gibt offenbar aber auch eine Integration von Consul und F5.
Eine Produktionsumgebung nach der Nomad Reference Architecture sieht wie folgt aus:
Ein Consul Cluster (bestehend aus mindestens drei Consul-Instanzen) wird mit einem Nomad-Cluster (bestehend aus mindestens drei Nomad-Server Instanzen) verbunden. Dieses Setup kann dann von einer Vielzahl von Nomad-Clients (auf denen gleichzeitig auch immer ein Consul-Client für das Service-Discovery laufen sollte) konsumiert werden.
Nun sind vielen Kunden ja diese "Meta-Nodes", die für ihre Anwendungen nicht nutzbar sind - aber trotzdem bezahlt werden müssen, ein Dorn im Auge. Deswegen habe ich für die Consul- und Nomad-Cluster in der Triton-Umgebung LX-branded Zones genommen. Das Consul-Cluster kann per docker-compose ausgerollt werden und baut sich dank Containerpilot automatisch selbst auf. Für den Nomad-Cluster habe ich drei Void-Linux Zonen gewählt, für die ich vorher mit Packer ein Image erzeugt hatte. Vermutlich ließe sich aber auch hier ein Setup mit Docker und Containerpilot herstellen. So belegt eine Void-Linux Zone mit laufendem Consul-Client und Nomad-Server ungefähr 140 MB Arbeitsspeicher - ein Consul-Container kommt mit etwa 75 MB Memory daher. Trotzdem können sie die volle Leistung des darunterliegenden Compute Nodes abfordern, wenn keine anderen Instanzen diese benötigen. Zusätzlich lassen sich die Zonen online rekonfigurieren - falls z. B. doch mehr Arbeitsspeicher benötigt werden sollte. Void-Linux läßt sich für diese Aufgabe mit minimaler Diensteausstattung konfigurieren:
[root@7aa0927f-8ded-40ae-bd57-f577b44c6dff ~]# vsv
SERVICE STATE ENABLED PID COMMAND TIME
✔ consul run true 24463 consul 5 days
X nanoklogd down true --- --- 0 seconds
✔ nomad run true 41107 nomad 23 hours
✔ socklog-unix run true 37770 socklog 5 days
✔ sshd run true 67524 sshd -D [listener 5 days
Das Consul Server Cluster ist nach dem Autopilot Pattern aufgebaut und verwendet Containerpilot und das entsprechende Consul Repository aus dem Autopilot Pattern Repo auf Github, um per docker-compose ein leicht skalierbares Cluster aus lx-branded Zones aufzubauen.
Nomad und Consul kennen das Konzept des "Datacenters". Nomad kennt zusätzlich noch das Konzept der "Region", welche wiederum aus mehreren "Datacentern" besteht. Innerhalb einer Region sollte die Kommunikation zwischen den Nomad-Servern mit geringer Latenz möglich sein. Bei der Kommunikation zwischen Regionen werden auch höhere Latenzen toleriert. In der Dokumentation wird dabei dieses Bild verwendet:
Dazu ist es sinnvoll, das Konzept vom Consul Connect zu kennen. Consul Connect ist das Service Mesh auf Basis von Consul, welches sowohl in Kubernetes aber auch überall, wo ein Consul-Client läuft, verwendet werden kann. Consul baut mit Hilfe des Envoy Proxy, der ja auch bei Istio zum Einsatz kommt, ein Service Mesh auf:
Natürlich integriert sich hier auch wieder Nomad, wenn gewünscht. Im Multi-Cloud Kontext existieren in Consul Connect auch Gateways, die eine Kommunikation zwischen Diensten über Datacenter-Grenzen hinweg möglich machen.
Die Funktioen zum Loadbalancing, Traffic-Routing sowie Geo-Failover sind im Multi-Cloud Betrieb unerläßlich. Für das Service Mesh sind IP-Adressen übrigens uninteressant, weil die Dienste mit Namen registriert werden. Deshalb ist auch keine NAT-Konfiugration erforderlich. Die Kommunikation wird verschlüsselt abgewickelt.
Der Aufbau einer echten Multi-Cloud Infrastruktur ist damit relativ einfach möglich. Auch das Ausbringen von Workloads, die sich über mehrere Datacenter oder Clouds verteilen sollen, ist damit umsetzbar.
Im Vergleich zu Kubernetes-Systemen wie Gardener, Kubermatic und Giantswarm, verwendet Nomad kein "Cluster of Clusters" Konzept sondern Cluster und Regionen sind unabhängig voneinander und es gibt kein zentrales Cluster. Nomad unterstützt Multi-Region Deployments von Applikationen (s. unten). Damit stellt Nomad eine Möglichkeit für Kunden dar z. B. eine Applikation in verschiedenen Cloud-Regionen auszurollen. Dafür sind keine besonderen Voraussetzungen durch die zu Grunde liegende Infrastruktur zu erfüllen. Consul und Nomad sind für Multi-Datacenter und Multi-Region Konstrukte ausgelegt.
Links:
Nomad CI/CD Developer Workflows and Integrations
Von dev nach Nomad mit Gitlab CI
Multi-Cluster Deployments with Nomad (Transcript, Blogeintrag, Usecase Bowery Farming)
Nomad: Kubernetes without the complexity
Mixing Containerized and non containerized Workloads with Services and Batch Jobs in Nomad
Machine Learning Workflows with Hashicorp Nomad and Apache Spark
Going global with Nomad and Google Cloud Platform
Going Multi-Cloud with Terraform and Nomad
GitLab + Nomad: a GitOps Dream Come True (Slides, Repo, Video)
Mixing Containerized and Non-Containerized Workloads with Services and Batch Jobs in Nomad
Loadbalancing with F5 and Consul