Docker-Alternative Rocket
Im Steigflug
Von Anfang an brachte CoreOS seine Container-Implementierung rkt gegen Docker in Stellung. Sie bietet technische Vorteile und soll gerade in Verbindung mit Kubernetes ihre Stärken zeigen, weil sie gezielt dafür entworfen wurde. Dort dominiert allerdings nach wie vor Docker – mit Neuerungen, die von rkt entlehnt sind.
Auf der DockerCon 2014 in Amsterdam stellte CoreOS mit rkt eine eigene Container-Implementierung vor. Dies wurde schnell als Angriff auf die populärste Alternative Docker gewertet. Vergleicht man die beiden Systeme, scheint es das Ziel von rkt zu sein, Docker als Standard-Container-Umgebung in Kubernetes-Clustern abzulösen.
Das Unternehmen CoreOS hatte selbst früh begonnen, eine Cluster-Umgebung für den Container-Betrieb, speziell mit Docker, zu bauen. Diese Umgebung bestand im Kern aus dem Betriebssystem CoreOS (das inzwischen Container Linux heißt), dem verteilten Key-Value-Store etcd, der Netzwerkabstraktion flannel und der Container-Verwaltung fleet.
Container Linux, ein ChromeOS-Fork, ist ein minimales OS mit aktuellem Kernel und systemd. An die Stelle einer eigenen Paketverwaltung treten dabei Container. flannel spannt ein flaches Netzwerk über mehrere Hosts auf, in dem die Container direkt miteinander kommunizieren können. Zum Verteilen der Container im Cluster übergeben Anwender systemd-Unit-Files an fleet – gespeichert werden diese hochverfügbar im Key-Value-Store etcd. flannel koordiniert die Subnetze und nimmt die Daten hierfür ebenfalls aus etcd.
Inzwischen hat sich CoreOS Kubernetes zugewandt (siehe Artikel auf Seite 98). Auch wenn das Unternehmen keine eigene Cluster-Umgebung mehr entwickelt, leben Teile weiter: etcd hat sich zum zentralen Storage-System für Kubernetes gemausert, flannel stellt dessen Standard-Netzwerk. Die Arbeit an fleet hat CoreOS eingestellt. Mit Tectonic bietet CoreOS außerdem eine kommerzielle Implementierung von Kubernetes.
Sowohl für die Cluster-Umgebung von CoreOS als auch für den Einsatz mit Kubernetes reduziert man Docker auf einen Teil seiner Fähigkeiten. So steht das flache Netzwerk von flannel im Gegensatz zum Docker’schen Netzwerk via NAT, bei dem aller Traffic via Portmapping über das Interface des Hosts läuft (siehe Abbildung 1). Warum also nicht eine Container-Technik verwenden, die lediglich das Nötige mitbringt? rkt besitzt tatsächlich nur diese Grundfunktionen. Es könnte letztendlich Docker als Container-Technik in Kubernetes ersetzen. rkt ist bewusst ohne Overhead konzipiert, um als reiner Anwendungscontainer in einem Cluster zu funktionieren.
Während CoreOS 2014 als vielversprechende Cluster-Implementierung für Docker-Container galt, schickte sich Docker an, mit Docker Swarm, einem Proxy für Docker-Multi-Host-Setups, ebenfalls in diesen Markt zu expandieren – und gab das auf der DockerCon 2014 bekannt.
Docker hat dann 2016 Docker Swarm zugunsten des Swarm Mode aufgegeben und bietet damit eine integrierte Cluster-Technik, die jede Docker-Installation von Haus aus mitbringt. Sie deckt unter anderem die Funktionen von etcd und flannel ab.
rkt stellt einen Weg dar, Anwendungscontainer zu implementieren. Vor dem genannten Hintergrund geht die Zielsetzung allerdings darüber hinaus und es ist durchaus als strategisch und politisch gewollte Alternative zu Docker zu verstehen. Allein technisch lassen sich bereits Erweiterungen erkennen.
Mehrstufig, dann gelingt der Start
Zu einer Zeit, in der Docker-Images nur über ihre Namen und Tags adressierbar waren, gab es keine Gewissheit, was sich dahinter versteckte oder von wem sie wirklich stammten. Die damalige technische Begründung für die Entwicklung des App Container Image Formats (ACI/AppC) von rkt ist dessen Fähigkeit, Images zu signieren. Etwas, das Docker mittlerweile auch beherrscht – allerdings nicht so schön gelöst: Es muss dafür der Dienst Notary laufen und manuell gewartet werden. Dieser übernimmt das Verifizieren.
rkt-Images bestehen zudem nur aus einem Layer und brauchen keine Registry, die die passenden Layer zusammensucht und dem Client (wie beim docker pull) schickt.
Ein Kritikpunkt an Docker war dessen eigener Daemon, der beim Ableben alle Container mit in den Tod reißt. rkt verzichtet darauf und verweist stattdessen auf systemd oder Kubelet (in einem Kubernetes-Cluster), um Container zu starten und zu überwachen.
Das Starten eines rkt-Containers erfolgt in drei Phasen:
– Der Aufruf des Kommandozeilen-Tools rkt bildet Stage 0. Dies kann direkt aus der Shell, über systemd oder vom Kubelet erfolgen. rkt kümmert sich um die Image-Verwaltung.
– Anschließend erzeugt systemd in Stage 1 eine isolierte Umgebung für die Applikation.
– Hat systemd die Umgebung erzeugt, kann in Stage 2 die Applikation im Image starten.
systemd im Kern
rkt baut auf systemd und verwendet dessen Container-Implementierung systemd -nspawn. Das startet nicht wie bei Docker direkt die Applikation, sondern erst systemd. Dieser wiederum lädt (in einer eigenen chroot-Umgebung) journald, bevor die eigentliche Anwendung startet.