Er zijn inmiddels 32 gecertificeerde orkestratieplatformen gebaseerd op Kubernetes beschikbaar (https://landscape.cncf.io/landscape=certified-kubernetes-distribution). Over het algemeen maken ze allemaal gebruik van Docker als container engine. Maar er zijn alternatieven: van bekende (Rkt) tot misschien minder bekende (Cri-o) – maar ook hele oude: afhankelijk van hoe het begrip wordt gedefinieerd dateert de eerste implementatie al uit minstens de jaren ’80, in de vorm van het Unix-eigen chroot.
In dit artikel een overzicht van deze container engines. Om het overzichtelijk te houden beperk ik me tot vijf: Cri-o, Docker, Garden, LXC en Rkt.
Open Container Initiative
In 2015 richten 21 belangrijke spelers in de container-industrie – waaronder CoreOS, Docker, Pivotal, Amazon en Google – het Open Container Initiative (https://www.opencontainers.org/) op, met als doel te komen tot open standaarden rondom containers. De Docker standaard wordt hierbij als uitgangspunt genomen (specifiek RunC), hetgeen aan de ene kant tot enige kritiek leidde (zoals het gezegde luidt, “a choice of one”), maar ook de constatering dat er geen betere oplossing is.
Het OCI beheert op dit moment twee specificaties, van de container-runtime en de container-image. Een derde, over de distributie van containers, is in de maak.
Cri-o (http://cri-o.io/)
Cri-o is een OCI-compliant, lichtgewicht container runtime voor Kubernetes. Expliciet niet in scope voor de engine zijn command line tools, maar vooral de processen rondom bouw en distributie van images naar repositories.
Cri-o maakt gebruikt van een standaard koppeling tussen Kubernetes en een onderliggende, OCI-compliante containerruntime zoals RunC of Clear Containers van Intel (nu Kata Containers), de Container Runtime Interface (CRI) van Kubernetes. Er zijn meer runtimes zoals Cri-o in ontwikkeling (bijvoorbeeld rktlet – https://github.com/kubernetes-incubator/rktlet en frakti – https://github.com/kubernetes/frakti), maar Cri-o is het verst gevorderd. En Waar Cri-o compliant is aan OCI is er ook een interessante afwijking: het oorspronkelijke doel van OCI was het bieden van een generiek formaat waarmee het mogelijk is RunC aan te spreken. Met Cri-o wordt het aantal runtimes dus uitgebreid.
Github: https://github.com/kubernetes-incubator/cri-o
Docker (https://www.docker.com/)
Docker heeft – voor een bedrijf dat in 2013 is opgericht – een roemruchte geschiedenis met een misschien wel even grote schare volgelingen als criticasters. Wie op Google zoekt komt zeer harde kritiek tegen zoals in “Docker in production: a history of failure” (https://thehftguy.com/2017/02/23/docker-in-production-an-update/), maar ook het meer neutrale rapport van Datadog over Docker adoption (https://www.datadoghq.com/docker-adoption/). Waarschijnlijk heeft dit te maken met de zeer snelle opkomst van Docker, die door een samenloop van verschillende factoren te verklaren is: dat het open source is en goed beschreven, open API’s heeft en dat de timing precies goed was om als enabler te dienen voor de DevOps revolutie, die aanliep tegen de grenzen van mogelijkheden virtuele machines. De cijfers zijn in ieder geval indrukwekkend (14 Miljoen Docker Hosts, 900.000 Docker apps, adoptie in grote bedrijven 35%) en Docker is met afstand de grootste containerengine. (Cijfers uit het eerder genoemde Datadog rapport en de Rightscale State of Cloud 2017 – https://www.rightscale.com/press-releases/rightscale-2017-state-of-the-cloud-report-uncovers-cloud-adoption-trends)
Github: https://github.com/docker
Warden en Garden (https://www.cloudfoundry.org/containers/)
Cloud Foundry, een applicatie runtime en container management platform, heeft een eigen manier van aansturen (orkestreren en draaien) van containers, maar ondersteunt inmiddels ook Docker en Kubernetes (https://www.cloudfoundry.org/container-runtime/). In de traditionele implementatie van Cloud Foundry is Warden de containerimplementatie, die over een eigen backend beschikt. Garden is de opvolger daarvan, die met een recente architectuurwijziging (Diego) werd geïntroduceerd. Garden maakt gebruik van RunC in plaats van een eigen implementatie en is daarmee OCI-compliant. Ook ondersteuning van Docker images is mogelijk met Garden.
Het grootste verschil tussen Warden en Docker is de manier waarop de containers technisch opgebouwd zijn: bij Warden bestaat een containerimage uit maximaal twee lagen (een read-only OS laag en een read/write applicatielaag), terwijl er bij Docker meerdere lagen zijn – een laag voor ieder RUN-commando in de Dockerfile.
Een wat ouder overzicht van hoe Garden en Warden precies werken is terug te vinden in een blog op de website van Cloudfoundry: https://www.cloudfoundry.org/blog/cloud-foundry-containers-difference-warden-docker-garden/.
Github: https://github.com/cloudfoundry/garden
LXC (https://linuxcontainers.org/)
In 2008 ontstond LXC, onderdeel van Linuxcontainers.org (met daarin bijvoorbeeld ook containermanager LXD en filesystem LXCFS). Het is een manier om meerdere geïsoleerde Linux besturingssystemen op een enkele host te draaien, door gebruik te maken van zogenaamde namespaces (het aanbieden van systeemresources aan een proces alsof ze uniek voor dat proces zijn) en cgroups (het isoleren van rekenkracht en geheugen voor specifieke processen). Ook bij Docker spelen cgroups en namespaces een belangrijke rol, maar het doel van Docker is de isolatie van het niveau van het besturingssysteem terug te brengen tot het niveau van applicaties en processen. In een Docker container draait maximaal één proces. Een ander belangrijk verschil is dat Docker veel weg-abstraheert (zoals het al genoemde besturingssysteem, maar ook netwerk en opslag), waardoor containers meer portabel zijn.
LXC wordt standaard ondersteund in moderne versies van Linux. Daarnaast is er ondersteuning in virtualisatiesoftware Proxmox en PaaS/containerplatform Salesforce Heroku en Apache Mesos.
Github: https://github.com/lxc/lxc
Rkt (https://coreos.com/rkt/)
Rkt, een afkorting voor Rocket, is een containerengine van CoreOS uit 2014 die oorspronkelijk geen gebruik maakte van de OCI-compliant RunC runtime, maar van een alternatieve standaard: AppC (https://github.com/appc/spec). Sinds eind 2016 is Rkt overgestapt naar OCI-compliancy.
De CEO van CoreOS beschrijft in een uitvoerig blog (uit 2014) de redenen voor het ontwerpen en bouwen van Rkt (https://coreos.com/blog/rocket.html). Een van de belangrijkste redenen is security. Rkt heeft geen daemon (zoals Docker, die destijds nog als root werd gedraaid). De bezwaren uit 2014 zijn inmiddels vrijwel allemaal verdwenen en beide producten ontlopen elkaar niet veel meer voor wat betreft features en security.
Github: https://github.com/rkt/rkt