Hardwarevirtualisatie biedt een lijst van voordelen zoals schaalbaarheid, beveiliging, isolatie, enz. door hypervisors te gebruiken om fysieke hardware te delen met virtuele machines (VM’s). Op dit moment zijn virtuele machines niet de enige vorm van virtualisatie, aangezien containers ook behoorlijk populair zijn geworden. Terwijl VM’s de fysieke hardware van onderliggende machines delen, delen containers de kernel van het onderliggende besturingssysteem. Containers zijn geen lichtgewicht virtuele machines, maar gestandaardiseerde uitvoerbare pakketten die worden gebruikt om toepassingen te leveren, inclusief toepassingen die zijn ontwikkeld met behulp van de op microservices gebaseerde softwarearchitectuur, en alle componenten bevatten die nodig zijn om toepassingen uit te voeren.
Het Docker-engine is het meest populaire platform voor het uitvoeren van containers. Kubernetes is een term die je steeds vaker hoort in de sfeer van containerisatie en cloud computing. Maar wat is beter – Docker of Kubernetes? Het is een populair onderwerp van debat, maar het op deze manier formuleren is technisch niet correct. Je kunt bijvoorbeeld niet vragen: “Wat is beter – warm of blauw?”
Wat is Docker?
Docker is een open source standalone applicatie die werkt als een engine om gecontaineriseerde toepassingen uit te voeren. Het is geïnstalleerd op uw besturingssysteem (OS), bij voorkeur op Linux, maar kan ook worden geïnstalleerd op Windows en macOS, dat op zijn beurt draait op een fysieke of virtuele machine.
Een toepassing die in een container draait, is geïsoleerd van de rest van het systeem en van andere containers, maar geeft de illusie dat deze draait in zijn eigen OS-instantie. Meerdere Docker-containers kunnen tegelijkertijd op hetzelfde besturingssysteem worden uitgevoerd; je kunt die containers beheren met Docker, en Docker kan zonder Kubernetes draaien. Als je meerdere hosts hebt voor het uitvoeren van containers, kan het handmatig beheren ervan moeilijk zijn, en het is over het algemeen beter om een gecentraliseerd beheerinstrument of een orchestratie-oplossing te selecteren.
Docker Compose is een eenvoudig containerorchestratiehulpmiddel dat wordt gebruikt voor het uitvoeren van multi-container Docker-toepassingen. Je kunt één YAML (yml) Docker Compose-configuratiebestand configureren om multi-container toepassingen te definiëren in plaats van handmatig afzonderlijke Docker-bestanden te configureren voor elke container. Na het configureren van het enkele YAML-bestand, kun je alle benodigde containers uitvoeren met één opdracht in je Linux-console. Het gebruik van Docker Compose is één manier om je Docker-containers te orchestreren, maar er is een krachtig alternatief voor Docker Compose beschikbaar dat Kubernetes wordt genoemd.
Wat is Kubernetes?
Kubernetes is een open source containerorchestratieoplossing die wordt gebruikt voor het beheren van containergebaseerde software en services met een hoge mate van automatisering.
Kubernetes is een project van Google bedoeld om de implementatie, schaalbaarheid en beschikbaarheid van toepassingen die in containers draaien te automatiseren. Je kunt het aantal hosts dat containers uitvoert verhogen tot wel 11 of meer hosts. Bovendien kun je met Kubernetes een cluster van Docker-containers maken om hoge beschikbaarheid en load balancing te garanderen.
Hosts die worden gebruikt in een cluster worden nodes genoemd. Het architectuurtype van Kubernetes is meester-slaaf – het cluster bestaat uit meester nodes en werkende nodes. Het minimum aanbevolen aantal nodes dat door Kubernetes vereist is, is vier. Hoewel je een cluster kunt bouwen met één machine, heb je voor het uitvoeren van alle voorbeelden en tests minstens vier nodes nodig. Een Kubernetes-cluster dat de productietraffic afhandelt, moet minimaal drie werkende nodes hebben. Het gebruik van twee meester nodes beschermt je cluster tegen het uitvallen van één meester node. Je kunt meer dan twee meester nodes gebruiken indien nodig.
- Meester nodes worden gebruikt om de status van een cluster te beheren, wat het accepteren van clientverzoeken, het plannen van bewerkingen met containers, het uitvoeren van regelkringen, enz. omvat. Een kopie van de etcd database die alle gegevens van het cluster opslaat, moet worden uitgevoerd op elke meester node. De meester node voert een reeks van de drie processen uit: kube-apiserver, kube-controller-manager en kube-scheduler.
- Werkende nodes worden gebruikt om toepassingsworkloads uit te voeren door containers uit te voeren. De twee Kubernetes-processen worden uitgevoerd op de niet-meester node: kubelet (om te communiceren met de meester nodes) en kube-proxy (om Kubernetes-netwerkservices op elke node te reflecteren).
- Replicatiecontroller is een component die ervoor zorgt dat Pod-replica’s waarvan het aantal is gespecificeerd, altijd draaien op elk gegeven moment. Zo kunt u ervoor zorgen dat Pods altijd beschikbaar zijn wanneer u ze nodig heeft.
Verschillende CLI’s en API’s worden gebruikt om services met elkaar te laten communiceren als Kubernetes wordt gebruikt. Er zijn ook specifieke termen die worden gebruikt voor het benoemen van objecten en resources van de RESTful API, die componenten zijn van de cluster gebouwd met Kubernetes. - Pod is een basisplanningseenheid in Kubernetes. Dit is een groep resources waarin meerdere containers kunnen werken. Containers die tot één Pod behoren, kunnen op dezelfde host draaien en dezelfde resources en hetzelfde lokale netwerk gebruiken. Containers in de Pod zijn geïsoleerd maar kunnen vrij gemakkelijk met elkaar communiceren. Daarom worden Pods over het algemeen gebruikt in Kubernetes, maar als u een zelfstandige Docker-toepassing gebruikt, zijn alleen containerpools beschikbaar.
- Service is een set containers die samenwerken om bijvoorbeeld de werking van een multi-tier applicatie te bieden. Kubernetes ondersteunt het dynamisch benoemen en load balancen van Pods door abstracties te gebruiken. Deze aanpak zorgt voor een transparante verbinding tussen services op basis van de naam en stelt u in staat hun huidige status bij te houden.
- Labels zijn sleutel/waarde-paren die zijn gebonden aan Pods en andere objecten of services, naast het mogelijk maken om ze gemakkelijk te groeperen en taken toe te wijzen.
- Namespaces is een methode die het mogelijk maakt om logisch het verenigde Kubernetes-cluster te verdelen in meerdere virtuele clusters. Elke virtuele cluster kan bestaan binnen een virtuele omgeving die beperkt is door quota’s zonder invloed te hebben op andere virtuele clusters.
Kubernetes kan worden gebruikt met Docker, hoewel Docker niet het enige containerplatform is waarmee Kubernetes kan worden gebruikt. Kubernetes kan ook samenwerken met Windows-containers, Linux-containers, rkt, enz. K8s is de naam van Kubernetes die soms te vinden is in technische documentatie.
Kubernetes vs Docker: Netwerkvergelijking
Laten we de netwerkmogelijkheden voor elke oplossing bekijken.
Docker biedt drie netwerkmodi voor netwerkcommunicatie tussen containers.
Bridge. Deze modus wordt standaard gebruikt en creëert een virtuele laag-3 bridge. De netwerknaam op uw host is docker0 voor dit netwerk. Docker maakt automatisch een laag-3 netwerkbrug aan en configureert masquerading-regels voor de externe netwerkinterface, met behulp van het principe van network address translation (NAT), waardoor containers met elkaar kunnen communiceren en verbinding kunnen maken met externe netwerken. U kunt poortdoorsturing configureren voor de netwerkinterface van de hostmachine als u verbinding wilt maken met een container vanaf andere hosts en externe netwerken. Zo wordt u door verbinding te maken met de juiste poort van de hostmachine doorgestuurd naar de benodigde poort van de Docker-container. U kunt indien nodig meer dan één netwerkinterface voor een Docker-container maken.
Host. In deze modus zorgt een host netwerkdriver ervoor dat een container niet geïsoleerd is van de Docker-host. De container deelt de netwerkstack van de host en de hostnaam van de container is hetzelfde als de hostnaam van het hostbesturingssysteem. Als u een container uitvoert waarop een TCP-poort 8080 wordt beluisterd, is de toepassing van de container beschikbaar op de TCP-poort 8080 van het IP-adres van de hostmachine. De host-netwerkdriver is alleen beschikbaar voor Linux-machines.
None. Er zijn geen IP-adressen geconfigureerd voor de netwerkinterface van een gegeven container, behalve het adres 127.0.0.1 voor de loopback-interface. Er is geen toegang tot externe netwerken als de netwerkmodus None is ingesteld.
Multi-host networking voor Docker-containers. Als containers op verschillende hosts worden uitgevoerd, kunnen ze met elkaar communiceren nadat u het overlay-netwerk hebt geconfigureerd. Een geldige key-value store-service (Consul, Etcd of ZooKeeper) moet worden geconfigureerd voor het maken van dergelijke netwerken.
Kubernetes. Als u zelfstandige Docker-containers gebruikt, kan elke container worden beschouwd als een basisunit die communiceert via het netwerk door gebruik te maken van de juiste netwerkinterface. Als u Kubernetes gebruikt, zijn Pods de basisunits van de containercluster. Elke pod heeft zijn eigen IP-adres en bestaat uit minstens één container. Een Pod kan bestaan uit meerdere containers die worden gebruikt voor gerelateerde taken. Containers van dezelfde Pod kunnen niet tegelijkertijd dezelfde poort openen. Dit type beperking wordt gebruikt omdat een Pod die bestaat uit meerdere containers nog steeds slechts één IP-adres heeft.
Bovendien maakt Kubernetes voor elke Pod een speciale pause-container aan. Deze speciale container is bedoeld om een netwerkinterface te bieden (voor interne en externe communicatie) voor andere containers en staat meestal in de pauzestand (in een slaapmodus). Deze pauzecontainers worden wakker wanneer Kubernetes een “SIGTERM”-signaal verzendt.
Flannel wordt doorgaans gebruikt als een netwerkstof voor het verbinden van containers in Kubernetes door gebruik te maken van principes van netwerkoverlay. De overlay-netwerking maakt het mogelijk om containers te laten draaien door te communiceren via het logische netwerk van verschillende fysieke hosts van het cluster (die worden aangeduid als nodes). De open source etcd key/value-store wordt gebruikt om de koppelingen tussen de werkelijke IP-adressen die aan containers zijn toegewezen door de hosts waarop de containers draaien, en de IP-adressen in het overlay-netwerk op te slaan.
Kubernetes-netwerken kunnen geïntegreerd worden met VMware NSX-T door gebruik te maken van de NSX Container Plugin. Deze integratie maakt het mogelijk om een multi-tenant netwerktopologie te gebruiken die niet “out of the box” beschikbaar is in Kubernetes.
Het netwerkmodel van Kubernetes biedt de volgende functies:
- Alle containers kunnen communiceren met alle andere containers binnen een cluster zonder NAT.
- Alle cluster nodes kunnen communiceren met alle containers binnen een cluster zonder NAT. Omgekeerd kunnen alle containers communiceren met alle cluster nodes.
- Containers zien hun eigen IP-adressen en die IP-adressen worden gezien door andere componenten van Kubernetes.
Ingress is een API-object van Kubernetes dat wordt gebruikt voor het beheren van toegang tot services in de cluster van buitenaf (voornamelijk HTTP en HTTPS). U kunt Ingress configureren om externe toegang tot de gecontaineriseerde services uit te voeren, voor load balancing, SSL-terminatie en op naam gebaseerd virtueel hosten. Een Ingress-controller moet worden ingezet op de master-node om de Ingress-regels te laten werken.
Gebruiksscenario’s
Het gebruik van Docker als op zichzelf staande software is goed voor de ontwikkeling van applicaties, omdat ontwikkelaars hun applicaties in geïsoleerde omgevingen kunnen uitvoeren. Bovendien kunnen testers ook Docker gebruiken om applicaties in sandbox-omgevingen uit te voeren. Als u Docker wilt gebruiken om een groot aantal containers in de productieomgeving uit te voeren, kunt u onderweg enkele complicaties tegenkomen. Bijvoorbeeld, sommige containers kunnen gemakkelijk worden overbelast of falen. U kunt de container handmatig op de juiste machine opnieuw starten, maar handmatig beheer kan veel van uw waardevolle tijd en energie in beslag nemen.
Kubernetes stelt u in staat deze problemen op te lossen door belangrijke functies te bieden zoals hoge beschikbaarheid, load balancing, container orchestratietools, enz. Als gevolg hiervan is Kubernetes het meest geschikt voor zeer belaste productieomgevingen met een groot aantal Docker-containers. Het implementeren van Kubernetes is moeilijker dan het installeren van een op zichzelf staande Docker-applicatie, daarom wordt Kubernetes mogelijk niet altijd gebruikt voor ontwikkeling en testen.
Kubernetes vs Docker Swarm
Docker Swarm is een native clusterhulpmiddel voor Docker dat een pool van Docker-hosts kan omzetten in één virtuele host. Docker Swarm is volledig geïntegreerd met de Docker Engine en stelt u in staat om standaard API’s en netwerkprocessen te gebruiken; het is bedoeld om Docker-containers te implementeren, te beheren en te schalen.
Swarm is een cluster van Docker-hosts die nodes worden genoemd. Laten we de volgende belangrijkste componenten van een cluster overwegen wanneer u Docker Swarm gebruikt voordat u de cluster-implementatie vergelijkt met Kubernetes en Docker Swarm:
Manager nodes worden gebruikt om controle-orkestratie, clusterbeheer en taakverdeling uit te voeren.
Worker nodes worden gebruikt voor het uitvoeren van containers waarvan de taken worden toegewezen door Manager nodes. Elke node kan geconfigureerd worden als een Manager node, Worker node, of als beide om zowel Manager als Worker node functies uit te voeren. Let op dat worker nodes swarm services uitvoeren.
Services. Een service van Docker Swarm definieert de vereiste optimale staat voor elke gecontaineriseerde service. Een service controleert parameters zoals het aantal replica’s, de beschikbare netwerkresources ervoor, de poorten die toegankelijk moeten zijn vanuit externe netwerken, etc. Serviceconfiguratie, zoals netwerkconfiguratie, kan worden gewijzigd en toegepast op een container zonder dat u de service handmatig met de container hoeft te herstarten.
Tasks. Een taak is een slot waarin een enkele container wordt uitgevoerd. Taken zijn de onderdelen van een Swarm-service.
Docker Swarm en Kubernetes zijn twee verschillende platforms die voor soortgelijke doeleinden worden gebruikt. Nu is het tijd om ze te vergelijken in een passende reeks categorieën.
Clusterimplementatie
Docker Swarm. Een standaard Docker API maakt het mogelijk om een cluster te implementeren met Swarm door gebruik te maken van een standaard Docker CLI (command line interface) die de implementatie vergemakkelijkt, vooral wanneer deze voor de eerste keer wordt gebruikt. De eenvoud van implementatie voor Swarm in vergelijking met Kubernetes wordt ook bereikt door het vermogen van een enkele Docker-master om te beslissen hoe services worden verdeeld. Er worden geen Pods gebruikt in Docker Swarm.
Kubernetes vereist dat je specifieke commando’s gebruikt die verschillen van standaard Docker-commando’s. Specifieke API’s worden gebruikt in Kubernetes, wat betekent dat zelfs als je commando’s kent voor Docker-beheer, je ook moet leren om een aanvullende set tools te gebruiken voor Kubernetes-implementatie. De nodes moeten handmatig worden gedefinieerd in het Kubernetes-cluster – je moet de master-node selecteren, de controller, scheduler, enz. definiëren.
Schaalbaarheid
Docker Swarm. Dankzij de eenvoudige API die Docker biedt, kunnen containers en service-updates in grote en kleine clusters sneller worden geïmplementeerd. Een command line interface (CLI) is vrij eenvoudig en gemakkelijk te begrijpen. Als gevolg hiervan kan Swarm worden beschouwd als een meer schaalbare oplossing in vergelijking met Kubernetes.
Hoge beschikbaarheid
De twee oplossingsopties hebben elk vergelijkbare replicatie- en redundantiemechanismen voor services, en in beide gevallen is het systeem zelfregulerend en vereist het geen handmatige herconfiguratie nadat een mislukte node weer in een cluster is ingeschakeld.
Docker Swarm. Manager nodes beheren de resources van worker nodes en het gehele cluster. De Swarm cluster nodes helpen bij de replicatie van services.
Kubernetes. Ongezonde nodes worden gedetecteerd door load balancing services van Kubernetes, en worden geëlimineerd uit de cluster. Alle Pods worden verdeeld over nodes, waardoor een hoge beschikbaarheid wordt gegarandeerd, mocht een node waarop een gecontaineriseerde toepassing draait, uitvallen.
Load balancing
Docker Swarm. Load balancing is een ingebouwde functie en kan automatisch worden uitgevoerd door het interne Swarm-netwerk te gebruiken. Alle verzoeken aan de cluster worden verdeeld en doorgestuurd naar de cluster nodes; elke node kan verbinding maken met elke container. Docker Swarm gebruikt een DNS-element om inkomende verzoeken naar servicenamen te distribueren.
Kubernetes. Beleidsregels gedefinieerd in Pods worden gebruikt voor load balancing in Kubernetes. In dit geval moeten container Pods worden gedefinieerd als services. Load balancing-instellingen moeten handmatig worden geconfigureerd, terwijl Ingress kan worden gebruikt voor load balancing.
Het maken en uitvoeren van containers
Docker Swarm. Het overgrote deel van de commando’s die beschikbaar zijn voor Docker CLI kunnen worden gebruikt wanneer Docker Swarm wordt gebruikt, dankzij de gestandaardiseerde API van Docker Swarm. Docker Compose definieert het werken met volumes en gebruikte netwerken, naast het definiëren van welke containers moeten worden gegroepeerd. Het precieze aantal replicaties kan worden ingesteld met Docker Compose voor Docker Swarm.
Kubernetes. Kubernetes heeft zijn eigen API, client, en heeft YAML-bestanden nodig om te worden geconfigureerd. Dit is een van de belangrijkste verschillen, aangezien Docker Compose en Docker CLI niet kunnen worden gebruikt om containers in dit geval te implementeren. In Kubernetes volgt het systeem voor het definiëren van services een vergelijkbaar werkprincipe als voor Docker Compose, maar is het complexer. De functionaliteit van Docker Compose wordt uitgevoerd door Pods, Deployments en Services te gebruiken in Kubernetes, waarbij elke laag wordt gebruikt voor zijn eigen gespecificeerde doel. Pods zijn verantwoordelijk voor containerinteractie, terwijl deployments verantwoordelijk zijn voor hoge beschikbaarheid en netwerken voor een enkele node in de cluster (net als de Docker Compose voor een op zichzelf staande Docker-toepassing zonder Swarm), en Kubernetes-services zijn verantwoordelijk voor configuratie van servicebewerking binnen de cluster, fouttolerantie, enzovoort.
Netwerken
Docker Swarm. Er is één standaard intern netwerk voor communicatie tussen containers binnen een cluster, waar meer netwerken aan toegevoegd kunnen worden indien nodig. Netwerken zijn beschermd met gegenereerde TLS-certificaten. Handmatige certificaatgeneratie wordt ondersteund voor de versleuteling van containergegevensverkeer.
Kubernetes. Het netwerkmodel van Kubernetes is behoorlijk verschillend en wordt geïmplementeerd door middel van plugins, waarvan Flannel de meest populaire optie is. Pods interacteren met elkaar, en deze interactie kan beperkt worden door beleidsregels. Er is een intern netwerk beheerd door de etcd-service. TLS-versleuteling is ook beschikbaar, maar moet handmatig geconfigureerd worden. Het netwerkmodel van Kubernetes veronderstelt het configureren van twee CIDRs, Classless Inter-Domain Routing, wat ook bekend staat als supernetting.
Monitoring
Docker Swarm. Er zijn geen ingebouwde tools voor monitoring en logging, hoewel je handmatig externe monitoringtools kunt opzetten. ELK of Reimann kunnen hiervoor gebruikt worden.
Kubernetes. Ingebouwde tools worden door Kubernetes geleverd voor logging en monitoring. Elasticsearch en Kibana (ELK) kunnen gebruikt worden om de volledige clusterstatus te monitoren, terwijl Heapster, Grafana en Influx ondersteund worden voor het monitoren van containerdiensten.
Graphical User Interface (GUI)
Docker Swarm. De GUI kan ingeschakeld worden met externe tools zoals Portainer.io die een gebruiksvriendelijke webinterface bieden. Als alternatief kun je de Enterprise Edition van Docker gebruiken die een grafische interface biedt voor het beheer van clusters.
Kubernetes. De GUI die door Kubernetes wordt geleverd, is een betrouwbaar dashboard dat kan worden geopend via een webinterface waarmee u eenvoudig uw cluster kunt beheren. De GUI kan een zeer waardevol hulpmiddel zijn voor gebruikers met minimale ervaring in het beheren van Kubernetes met de CLI.
Conclusie
Docker Swarm is een inheemse Docker-oplossing die voornamelijk gebruikmaakt van Docker API en CLI. Kubernetes daarentegen is een project van Google dat wordt gebruikt voor het implementeren van een cluster waarop containers worden uitgevoerd.
Zowel Docker Swarm als Kubernetes bieden hoge beschikbaarheid, load balancing, overlay-netwerken en schaalbaarheidsfuncties. Docker Swarm is eenvoudiger te implementeren dan de twee, omdat de configuratie van de meeste van zijn functies geautomatiseerd is en het weinig hardwarebronnen verbruikt. Functionaliteit wordt echter beperkt door Docker API, en native bewakingstools ontbreken.
Kubernetes daarentegen is een modulaire oplossing met een hoog niveau van flexibiliteit die door de meerderheid van grote bedrijven al een aantal jaren wordt ondersteund. Ingebouwde tools voor het monitoren van services en het gehele cluster zijn beschikbaar voor Kubernetes, hoewel implementatie en configuratie moeilijker zijn, waardoor deze bron een veeleisender oplossing is. Kubernetes is niet compatibel met Docker CLI en Docker Compose. Het gebruik van Kubernetes wordt aanbevolen in grote omgevingen waar sterk belaste multi-container applicaties worden uitgevoerd.