Mesos tegen Kubernetes

1. Overzicht

In deze zelfstudie begrijpen we de basisbehoefte van een containerorkestratiesysteem.

We zullen het gewenste kenmerk van een dergelijk systeem evalueren. Van daaruit zullen we proberen om twee van de meest populaire containerorkestratiesystemen die momenteel in gebruik zijn, Apache Mesos en Kubernetes, te vergelijken.

2. Containerorkestratie

Voordat we Mesos en Kubernetes gaan vergelijken, moeten we wat tijd besteden aan het begrijpen van wat containers zijn en waarom we toch containerorkestratie nodig hebben.

2.1. Containers

EENcontainer is een gestandaardiseerde software-eenheid die code en al zijn vereiste afhankelijkheden verpakt.

Daarom biedt het platformonafhankelijkheid en operationele eenvoud. Docker is een van de meest populaire containerplatforms die in gebruik zijn.

Docker maakt gebruik van de Linux-kernel functies zoals CGroups en naamruimten om isolatie te bieden van verschillende processen. Hierdoor kunnen meerdere containers onafhankelijk en veilig draaien.

Het is vrij triviaal om docker-images te maken, alles wat we nodig hebben is een Dockerfile:

VAN openjdk: 8-jdk-alpine VOLUME / tmp COPY target / hello-world-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java", "- jar", "/ app.jar"] EXPOSE 9001

Deze paar regels zijn dus goed genoeg om een Docker-image van een Spring Boot-applicatie te maken met behulp van de Docker CLI:

docker build -t hello_world.

2.2. Container Orchestration

We hebben dus gezien hoe containers de implementatie van applicaties betrouwbaar en herhaalbaar kunnen maken. Maar waarom hebben we containerorkestratie nodig?

Hoewel we een paar containers te beheren hebben, gaat het goed met Docker CLI. We kunnen ook enkele van de eenvoudige klusjes automatiseren. Maar wat gebeurt er als we honderden containers moeten beheren?

Denk bijvoorbeeld aan architectuur met verschillende microservices, allemaal met verschillende eisen op het gebied van schaalbaarheid en beschikbaarheid.

Daardoor kunnen dingen snel uit de hand lopen, en dat is waar de voordelen van een containerorkestratiesysteem zich realiseren. EENcontainer orchestration-systeem behandelt een cluster van machines met een multi-container-applicatie als een enkele implementatie-entiteit. Het biedt automatisering vanaf de eerste implementatie, planning, updates tot andere functies zoals bewaking, schaalvergroting en failover.

3. Kort overzicht van Mesos

Apache Mesos is een open-source clustermanager die oorspronkelijk is ontwikkeld aan UC Berkeley. Het biedt applicaties API's voor resourcebeheer en planning in het hele cluster. Mesos geeft ons de flexibiliteit om zowel gecontaineriseerde als niet-gecontaineriseerde workloads op een gedistribueerde manier uit te voeren.

3.1. Architectuur

Mesos-architectuur bestaat uit Mesos Master, Mesos Agent en Application Frameworks:

Laten we de componenten van architectuur hier begrijpen:

Kaders: Dit zijn de daadwerkelijke applicaties die gedistribueerde uitvoering vereisen van taken of werklast. Typische voorbeelden zijn Hadoop of Storm. Frameworks in Mesos bestaan uit twee hoofdcomponenten:
- Planner: Dit is verantwoordelijk voor het registreren bij de Master Node zodat de meester kan beginnen met het aanbieden van middelen
- Uitvoerder: Dit is het proces dat wordt gestart op de agentknooppunten om de taken van het raamwerk uit te voeren
Mesos-agenten: Dit zijn verantwoordelijk voor het daadwerkelijk uitvoeren van de taken. Elke agent publiceert zijn beschikbare bronnen, zoals CPU en geheugen, naar de master. Bij het ontvangen van taken van de meester, wijzen ze de vereiste middelen toe aan de uitvoerder van het raamwerk.
Mesos-meester: Dit is verantwoordelijk voor het plannen van taken die zijn ontvangen van de Frameworks op een van de beschikbare agentknooppunten. Master doet resource-aanbiedingen aan Frameworks. De planner van Framework kan ervoor kiezen om taken uit te voeren op deze beschikbare bronnen.

3.2. Marathon

Zoals we net hebben gezien, is Mesos vrij flexibel en stelt het frameworks in staat om taken te plannen en uit te voeren via goed gedefinieerde API's. Het is echter niet handig om deze primitieven rechtstreeks te implementeren, vooral als we aangepaste applicaties willen plannen. Bijvoorbeeld het orkestreren van applicaties die zijn verpakt als containers.

Dit is waar een raamwerk als Marathon ons kan helpen. Marathon is een raamwerk voor containerorkestratie dat op Mesos draait. Marathon fungeert daarbij als raamwerk voor het Mesos-cluster. Marathon biedt verschillende voordelen die we doorgaans verwachten van een orkestratieplatform, zoals service-detectie, taakverdeling, metrische gegevens en API's voor containerbeheer.

Marathon behandelt een langlopende service als een applicatie en een applicatie-instantie als een taak. Een typisch scenario kan meerdere applicaties hebben met afhankelijkheden die zogenaamde applicatiegroepen vormen.

3.3. Voorbeeld

Laten we dus eens kijken hoe we Marathon kunnen gebruiken om onze eenvoudige Docker-image die we eerder hebben gemaakt, te implementeren. Merk op dat het installeren van een Mesos-cluster weinig omslachtig kan zijn en daarom kunnen we een eenvoudiger oplossing zoals Mesos Mini gebruiken. Mesos Mini stelt ons in staat om een lokaal Mesos-cluster op te starten in een Docker-omgeving. Het bevat een Mesos-meester, een enkele Mesos-agent en een marathon.

Zodra we het Mesos-cluster met Marathon in gebruik hebben genomen, kunnen we onze container inzetten als een langlopende applicatieservice. Alles wat we nodig hebben een kleine JSON-toepassingsdefinitie:

# hello-marathon.json {"id": "marathon-demo-application", "cpus": 1, "mem": 128, "disk": 0, "instances": 1, "container": {"type ":" DOCKER "," docker ": {" image ":" hello_world: latest "," portMappings ": [{" containerPort ": 9001," hostPort ": 0}]}}," networks ": [{" mode ":" host "}]}

Laten we begrijpen wat hier precies gebeurt:

We hebben een id opgegeven voor onze applicatie
Vervolgens hebben we de resourcevereisten voor onze applicatie gedefinieerd
We hebben ook gedefinieerd hoeveel instanties we zouden willen uitvoeren
Vervolgens hebben we de containergegevens verstrekt om een app van te starten
Ten slotte hebben we de netwerkmodus gedefinieerd zodat we toegang hebben tot de applicatie

We kunnen deze applicatie starten met behulp van de REST API's van Marathon:

curl -X POST \ // localhost: 8080 / v2 / apps \ -d @ hello-marathon.json \ -H "Content-type: application / json"

4. Kort overzicht van Kubernetes

Kubernetes is een open-source containerorkestratiesysteem dat oorspronkelijk door Google is ontwikkeld. Het maakt nu deel uit van Cloud Native Computing Foundation (CNCF). Het biedt een platform voor het automatiseren van implementatie, schaalvergroting en bewerkingen van applicatiecontainers over een cluster van hosts.

4.1. Architectuur

Kubernetes-architectuur bestaat uit een Kubernetes-master en Kubernetes-knooppunten:

Laten we de belangrijkste delen van deze architectuur op hoog niveau doornemen:

Kubernetes Master: De master is verantwoordelijk voor het handhaven van de gewenste status van het cluster. Het beheert alle knooppunten in het cluster. Zoals we kunnen zien, is de master een verzameling van drie processen:
- kube-apiserver: Dit is de service die het hele cluster beheert, inclusief het verwerken van REST-bewerkingen, het valideren en bijwerken van Kubernetes-objecten, het uitvoeren van authenticatie en autorisatie
- kube-controller-manager: Dit is de daemon die de kerncontrolelus insluit geleverd met Kubernetes, waarbij de nodige wijzigingen worden aangebracht om de huidige staat af te stemmen op de gewenste staat van het cluster
- kube-planner: Deze service let op ongeplande pods en bindt ze aan knooppunten afhankelijk van de gevraagde middelen en andere beperkingen
Kubernetes-knooppunten: De knooppunten in een Kubernetes-cluster zijn de machines waarop onze containers draaien. Elk knooppunt bevat de nodige services om de containers uit te voeren:
- kubelet: Dit is de primaire knooppuntagent die ervoor zorgt dat de containers beschreven in PodSpecs geleverd door kube-apiserver rennen en gezond zijn
- kube-proxy: Dit is de netwerkproxy die op elk knooppunt draait en voert eenvoudige TCP-, UDP-, SCTP-stream-forwarding of round-robin-forwarding uit over een reeks backends
- container runtime: Dit is de looptijd waarin de container in de pods wordt uitgevoerd, zijn er verschillende mogelijke containerruntimes voor Kubernetes, waaronder de meest gebruikte, Docker-runtime

4.2. Kubernetes-objecten

In de laatste sectie hebben we verschillende Kubernetes-objecten gezien die persistente entiteiten zijn in het Kubernetes-systeem. Ze weerspiegelen de toestand van het cluster op elk moment in de tijd.

Laten we enkele van de veelgebruikte Kubernetes-objecten bespreken:

Pods: pod is een basiseenheid voor uitvoering in Kubernetes en kan bestaan uit een of meer containers, de containers in een Pod worden op dezelfde host ingezet
Implementatie: implementatie is de aanbevolen manier om pods in Kubernetes te implementeren, biedt het functies zoals het continu afstemmen van de huidige status van pods met de gewenste status
Diensten: Diensten in Kubernetes bieden een abstracte manier om een groep pods bloot te leggen, waarbij de groepering is gebaseerd op selectors die podlabels targeten

Er zijn verschillende andere Kubernetes-objecten die dienen om containers effectief op een gedistribueerde manier uit te voeren.

4.3. Voorbeeld

Dus nu kunnen we proberen onze Docker-container in het Kubernetes-cluster te lanceren. Kubernetes biedt Minikube, een tool die Kubernetes-cluster met één knooppunt op een virtuele machine uitvoert. We hebben ook kubectl nodig, de Kubernetes-opdrachtregelinterface om met het Kubernetes-cluster te werken.

Nadat we kubectl en Minikube hebben geïnstalleerd, kunnen we onze container implementeren op het Kubernetes-cluster met één knooppunt binnen Minikube. We moeten de basis Kubernetes-objecten in een YAML-bestand definiëren:

# hello-kubernetes.yaml apiVersion: apps / v1 soort: implementatie metadata: naam: hallo-world spec: replica's: 1 sjabloon: metadata: labels: app: hallo-world spec: containers: - naam: hallo-world afbeelding: hallo -world: nieuwste poorten: - containerPort: 9001 --- apiVersion: v1 soort: Service metadata: naam: hallo-world-service spec: selector: app: hallo-world type: LoadBalancer poorten: - poort: 9001 targetPort: 9001

Een gedetailleerde analyse van dit definitiebestand is hier niet mogelijk, maar laten we eens kijken naar de belangrijkste punten:

We hebben een Inzet met labels in de selector
We definiëren het aantal replica's dat we nodig hebben voor deze implementatie
We hebben ook de details van de containerimage geleverd als sjabloon voor de implementatie
We hebben ook een Onderhoud met de juiste selector
We hebben de aard van de service gedefinieerd als LoadBalancer

Ten slotte kunnen we de container implementeren en alle gedefinieerde Kubernetes-objecten maken via kubectl:

kubectl toepassen -f yaml / hallo-kubernetes.yaml

5. Mesos versus Kubernetes

Nu hebben we genoeg context doorgenomen en ook de basisimplementatie uitgevoerd op zowel Marathon als Kubernetes. We kunnen proberen te begrijpen waar ze staan ten opzichte van elkaar.

Maar een voorbehoud, het is niet helemaal eerlijk om Kubernetes rechtstreeks met Mesos te vergelijken. De meeste van de functies voor containerorkestratie die we zoeken, worden geleverd door een van de Mesos-frameworks zoals Marathon. Om de zaken in het juiste perspectief te houden, we zullen proberen Kubernetes te vergelijken met Marathon en niet direct Mesos.

We zullen deze orkestratiesystemen vergelijken op basis van enkele van de gewenste eigenschappen van een dergelijk systeem.

5.1. Ondersteunde workloads

Mesos is ontworpen om omgaan met verschillende soorten werklasten die gecontaineriseerd of zelfs niet-gecontaineriseerd kunnen zijn. Het hangt af van het raamwerk dat we gebruiken. Zoals we hebben gezien, is het vrij eenvoudig om gecontaineriseerde workloads in Mesos te ondersteunen met een framework als Marathon.

Kubernetes, aan de andere kant, werkt uitsluitend met de gecontaineriseerde werklast. Meestal gebruiken we het met Docker-containers, maar het heeft ondersteuning voor andere containerruntimes zoals Rkt. In de toekomst ondersteunt Kubernetes mogelijk meer soorten workloads.

5.2. Ondersteuning voor schaalbaarheid

Marathon ondersteunt schaalvergroting via de toepassingsdefinitie of de gebruikersinterface. Autoscaling wordt ook ondersteund in Marathon. We kunnen ook applicatiegroepen schalen, waardoor alle afhankelijkheden automatisch worden geschaald.

Zoals we eerder zagen, is Pod de fundamentele uitvoeringseenheid in Kubernetes. Pods kunnen worden geschaald wanneer ze worden beheerd door Deployment, dit is de reden dat pods altijd worden gedefinieerd als een implementatie. Het schalen kan handmatig of geautomatiseerd zijn.

5.3. Omgaan met hoge beschikbaarheid

Toepassingsinstanties in Marathon zijn gedistribueerd over Mesos-agenten die hoge beschikbaarheid bieden. Een Mesos-cluster bestaat doorgaans uit meerdere agents. Bovendien biedt ZooKeeper hoge beschikbaarheid voor het Mesos-cluster door middel van quorum- en leidersverkiezingen.

Evenzo zijn pods in Kubernetes gerepliceerd over meerdere knooppunten voor een hoge beschikbaarheid. Een Kubernetes-cluster bestaat doorgaans uit meerdere werkknooppunten. Bovendien kan het cluster ook meerdere masters hebben. Daarom is het Kubernetes-cluster in staat om hoge beschikbaarheid aan containers te bieden.

5.4. Serviceopsporing en taakverdeling

Mesos-DNS kan service-detectie en een basisbelastingverdeling bieden voor toepassingen. Mesos-DNS genereert een SRV-record voor elke Mesos-taak en vertaalt deze naar het IP-adres en de poort van de machine die de taak uitvoert. Voor Marathon-toepassingen kunnen we Marathon-lb ook gebruiken om poortgebaseerde detectie te bieden met behulp van HAProxy.

Bij implementatie in Kubernetes worden pods dynamisch gemaakt en vernietigd. Daarom stellen we over het algemeen pods in Kubernetes bloot via Service, die service-detectie biedt. Service in Kubernetes fungeert als een dispatcher voor de pods en biedt dus ook load balancing.

5.5 Upgrades uitvoeren en terugdraaien

Wijzigingen in toepassingsdefinities in Marathon worden behandeld als implementatie. Inzet ondersteunt het starten, stoppen, upgraden of schalen van applicaties. Marathon ondersteunt ook rollende starts om nieuwere versies van de applicaties te implementeren. Terugdraaien is echter net zo eenvoudig en vereist doorgaans de implementatie van een bijgewerkte definitie.

Implementatie in Kubernetes ondersteunt zowel upgraden als terugdraaien. We kunnen de strategie bieden voor implementatie die moet worden uitgevoerd terwijl oude pods worden vervangen door nieuwe. Typisch strategieën zijn recreëren of rollende update. De uitrolgeschiedenis van de implementatie wordt standaard bijgehouden in Kubernetes, waardoor het eenvoudig is om terug te gaan naar een eerdere revisie.

5.6. Logboekregistratie en monitoring

Mesos heeft een diagnostisch hulpprogramma dat alle clustercomponenten scant en stelt gegevens beschikbaar met betrekking tot gezondheids- en andere statistieken. De gegevens kunnen worden opgevraagd en geaggregeerd via beschikbare API's. Veel van deze gegevens kunnen we verzamelen met een externe tool zoals Prometheus.

Kubernetes publiceer gedetailleerde informatie met betrekking tot verschillende objecten als resource metrische gegevens of volledige metrische pijplijnen. Typische praktijk is om een externe tool zoals ELK of Prometheus + Grafana in te zetten op het Kubernetes-cluster. Dergelijke tools kunnen clusterstatistieken opnemen en deze op een veel gebruikersvriendelijke manier presenteren.

5.7. Opslag

Mesos heeft persistente lokale volumes voor stateful toepassingen. We kunnen alleen persistente volumes maken op basis van de gereserveerde bronnen. Het kan ook externe opslag ondersteunen, met enkele beperkingen. Mesos heeft experimentele ondersteuning voor Container Storage Interface (CSI), een gemeenschappelijke set API's tussen opslagleveranciers en het containerorkestratieplatform.

Kubernetes biedt meerdere typen persistent volume voor stateful containers. Dit omvat opslag zoals iSCSI, NFS. Bovendien ondersteunt het ook externe opslag zoals AWS, GCP. Het Volume-object in Kubernetes ondersteunt dit concept en is er in verschillende typen, waaronder CSI.

5.8. Netwerken

Containerruntime in Mesos biedt twee soorten netwerkondersteuning, IP-per-container en netwerkpoorttoewijzing. Mesos definieert een gemeenschappelijke interface om netwerkinformatie voor een container op te geven en op te halen. Marathontoepassingen kunnen een netwerk definiëren in hostmodus of bridge-modus.

Netwerken in Kubernetes wijst een uniek IP-adres toe aan elke pod. Dit maakt het overbodig om containerpoorten aan de hostpoort toe te wijzen. Het definieert verder hoe deze pods via knooppunten met elkaar kunnen praten. Dit wordt in Kubernetes geïmplementeerd door netwerkplug-ins zoals Cilium, Contiv.

6. Wanneer wat te gebruiken?

Ten slotte verwachten we in vergelijking meestal een duidelijk vonnis! Het is echter niet helemaal eerlijk om de ene technologie beter te verklaren dan de andere, hoe dan ook. Zoals we hebben gezien, zowel Kubernetes als Mesos zijn krachtige systemen en biedt behoorlijk concurrerende functies.

Prestaties zijn echter een vrij cruciaal aspect. Een Kubernetes-cluster kan worden geschaald tot 5000 knooppunten, terwijl bekend is dat Marathon op Mesos-cluster tot 10.000 agents ondersteunt. In de meeste praktische gevallen zullen we niet met zulke grote clusters te maken hebben.

Ten slotte komt het neer op de flexibiliteit en soorten workloads die we hebben. Als we opnieuw beginnen en we zijn alleen van plan om gecontaineriseerde workloads te gebruiken, Kubernetes kan een snellere oplossing bieden. Als we echter bestaande workloads hebben, die een mix zijn van containers en niet-containers, kan Mesos met Marathon een betere keuze zijn.

7. Andere alternatieven

Kubernetes en Apache Mesos zijn behoorlijk krachtig, maar het zijn niet de enige systemen in deze ruimte. Er zijn nogal wat veelbelovende alternatieven voor ons beschikbaar. Hoewel we niet op hun details ingaan, laten we er snel een paar opsommen:

Docker Swarm: Docker Swarm is een open-source clustering- en planningstool voor Docker-containers. Het wordt geleverd met een opdrachtregelprogramma om een cluster van Docker-hosts te beheren. Het is beperkt tot Docker-containers, in tegenstelling tot Kubernetes en Mesos.
Nomad: Nomad is een flexibele workload orchestrator van HashiCorp om elke gecontaineriseerde of niet-containerapplicatie te beheren. Nomad maakt declaratieve infrastructuur-als-code mogelijk voor het implementeren van applicaties zoals Docker-container.
OpenShift: OpenShift is een containerplatform van Red Hat, georkestreerd en beheerd door Kubernetes eronder. OpenShift biedt veel functies bovenop wat Kubernetes biedt, zoals een geïntegreerd image-register, een source-to-image build, een native netwerkoplossing, om er maar een paar te noemen.

8. Conclusie

Samenvattend hebben we in deze zelfstudie containers en containerorkestratiesystemen besproken. We hebben kort twee van de meest gebruikte containerorkestratiesystemen doorgenomen, Kubernetes en Apache Mesos. We hebben dit systeem ook vergeleken op basis van verschillende kenmerken. Ten slotte zagen we enkele van de andere alternatieven in deze ruimte.

Voordat we sluiten, moeten we begrijpen dat het doel van een dergelijke vergelijking is om gegevens en feiten te verstrekken. Dit is op geen enkele manier om de ene beter te verklaren dan de andere, en dat hangt normaal gesproken af van de use-case. We moeten dus de context van ons probleem toepassen om de beste oplossing voor ons te bepalen.

streamalism.org