Containers en virtuele machines

Een virtuele machine en een container, die zijn niet met elkaar te vergelijken. Een container emuleert een besturingssysteem, is lichtgewicht en geschikt om (zo klein mogelijke) geïsoleerde applicatiefunctionaliteit in te hosten. Een microservice bijvoorbeeld. Een virtuele machine emuleert hardware en is meer geschikt voor (grote) applicatiestacks.

 

Een vorm van virtualisatie

Eigenlijk is containerisatie een vorm van virtualisatie. Maar wat als de twee varianten (virtuele machines en containers dus) naast elkaar moeten bestaan? Bijvoorbeeld omdat bepaalde workloads niet of moeilijk naar containers zijn te migreren en daarom naast vernieuwing draaien?

In de omvangrijke tool ecosphere van Kubernetes zijn hier inmiddels meerdere oplossingen voor, die in dit artikel aan bod komen.

 

KubeVirt (http://kubevirt.io/)

Het tool KubeVirt (een upstream Red Hat project) is bedacht om de overgang van virtuele machines naar containers zo makkelijk mogelijk te maken door één omgeving te maken waar het beheer van beiden bij elkaar komt. Het is een uitbreiding op Kubernetes (geïnstalleerd via Custom Resource Definitions, waarmee de functionaliteit van de Kubernetes API is uit te breiden) waardoor een gebruiker een virtuele machine kan aanmaken, starten en stoppen via de command line en tool kubectl (en eigen tool virtctl om verbinding te maken met een VM). Op het Kubernetes cluster draait een controller, op de node(s) een specifieke handler. Om de VM’s aan te sturen wordt Libvirtd gebruikt. Een aangemaakte VM draait vervolgens in een pod. KubeVirt is behoorlijk in ontwikkeling (developer-speak voor niet productie-gereed) en relatief zwaar (er wordt nogal wat gedownload en geïnstalleerd om het beheer van virtuele machines mogelijk te maken). In de KubeVirt-manier van werken blijven virtuele machines los te beheren en is er eigenlijk sprake van een losstaande toevoeging aan Kubernetes.

Github: https://github.com/kubevirt

 

Kata Containers (https://katacontainers.io/)

Kata Containers is een samensmelting van de RunV technologie van Hyper.sh en de door Intel in 2015 ontwikkelde Clear Containers (https://clearlinux.org/containers). Intel had als doel om beveiligingsproblemen zoals Dirty Cow (https://dirtycow.ninja/) binnen containers op te lossen, onder andere door gebruik te maken van de eigen hardware virtualization laag VT-x. Een Clear Container (of is het een mini-VM?) heeft – volgens Intel – onder andere een betere beveiliging doordat er een eigen OS met dedicated kernel in opgenomen is. Sinds eind 2017 is het project overgedragen aan de OpenStack foundation.

De Kata Containers runtime ondersteunt de Container Runtime Interface van Kubernetes. Het is daardoor mogelijk eenvoudig te wisselen tussen bijvoorbeeld Docker of CRI-O en de Kata-runtime. Hoe dit werkt is goed uitgelegd in een artikel van Eric Ernst van Intel, via https://medium.com/cri-o/intel-clear-containers-and-cri-o-70824fb51811.

Github: https://github.com/kata-containers en https://github.com/hyperhq/runv

 

Virtlet

Het tool Virtlet van Mirantis is specifiek bedoeld voor Kubernetes, met net als Kata Containers ondersteuning voor de Container Runtime Interface. Met Virtlet is het mogelijk om QCOW2 VM’s te draaien binnen Kubernetes (Qemu en KVM). Er is een eigen tool (virtletctl) dat los of als plugin via kubectl is aan te roepen. Dat moet nu nog met de syntax kubectl plugin, maar zal in de nabije toekomst rechtstreeks mogelijk zijn.

In de Virtlet manier-van werken is er diepe integratie tussen virtuele machines en Kubernetes. De intentie is om de gebruikerservaring volledig op werken met pods te laten aansluiten en de standaard commando’s van kubectl te ondersteunen.

Github: https://github.com/Mirantis/virtlet

 

RancherVM

Dit tool van Rancher werd in 2015 ontwikkeld en in 2018 beschikbaar gemaakt voor Kubernetes. Een virtuele machine (Qemu/KVM) wordt verpakt als een Docker image en draait in een VM pod. De integratie verloopt via Custom Resource Definitions, vergelijkbaar met KubeVirt. RancherVM biedt als enige van de in dit artikel vermelde tools een grafische interface voor het beheer van de virtuele machines.

Github: https://github.com/rancher/vm

 

Wat betekent dit voor OpenStack?

Betekent dit dat Kubernetes langzamerhand OpenStack gaat overschaduwen? Er is zeker een gedeelte van de community die dit ziet gebeuren. Maar voorlopig is het nog niet zo ver en kunnen we nog gewoon kiezen uit Kubernetes op OpenStack (https://wiki.openstack.org/wiki/Magnum) of OpenStack op Kubernetes (https://wiki.openstack.org/wiki/Kolla). Gewoon, omdat het kan.

About the author

Niels Goossens

Niels is een pragmatische Enterprise Architect met een gevoel voor techniek en een achtergrond in de overheid.
Volledig profiel


>