streamalism.org

1. Oversigt

I denne vejledning forstår vi det grundlæggende behov for et containerorkestreringssystem.

Vi vurderer den ønskede egenskab ved et sådant system. Derefter forsøger vi at sammenligne to af de mest populære container orkestreringssystemer, der er i brug i dag, Apache Mesos og Kubernetes.

2. Containerorkestrering

Før vi begynder at sammenligne Mesos og Kubernetes, lad os bruge lidt tid på at forstå, hvad containere er, og hvorfor vi trods alt har brug for containerorkestrering.

2.1. Beholdere

ENcontainer er en standardiseret softwareenhed, der pakker kode og alle dens krævede afhængigheder.

Derfor giver det platformuafhængighed og operationel enkelhed. Docker er en af ​​de mest populære containerplatforme i brug.

Docker udnytter Linux-kernen funktioner som CGgrupper og navneområder for at give isolation af forskellige processer. Derfor kan flere containere køre uafhængigt og sikkert.

Det er ret trivielt at oprette dockerbilleder, alt hvad vi har brug for er en Dockerfile:

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

Så disse få linjer er gode nok til at oprette et Docker-billede af en Spring Boot-applikation ved hjælp af Docker CLI:

docker build -t hello_world.

2.2. Containerorkestrering

Så vi har set, hvordan containere kan gøre applikationsinstallation pålidelig og gentagelig. Men hvorfor har vi brug for containerorkestrering?

Nu, mens vi har et par containere at administrere, har vi det godt med Docker CLI. Vi kan også automatisere nogle af de enkle opgaver. Men hvad sker der, når vi skal administrere hundreder af containere?

Tænk for eksempel på arkitektur med flere mikrotjenester, alle med forskellige krav til skalerbarhed og tilgængelighed.

Derfor kan ting hurtigt komme ud af kontrol, og det er her fordelene ved et containerorkestrationssystem indser. ENcontainer orkestrering system behandler en klynge af maskiner med en multi-container applikation som en enkelt implementeringsenhed. Det giver automatisering fra første implementering, planlægning, opdateringer til andre funktioner som overvågning, skalering og failover.

3. Kort oversigt over Mesos

Apache Mesos er en open source cluster manager udviklet oprindeligt hos UC Berkeley. Det giver applikationer API'er til ressourcestyring og planlægning på tværs af klyngen. Mesos giver os fleksibiliteten til at køre både containeriseret og ikke-containeriseret arbejdsbyrde på en distribueret måde.

3.1. Arkitektur

Mesos arkitektur består af Mesos Master, Mesos Agent og Application Frameworks:

Lad os forstå arkitekturens komponenter her:

• Rammer: Disse er de faktiske applikationer, der kræver distribueret udførelse af opgaver eller arbejdsbyrde. Typiske eksempler er Hadoop eller Storm. Rammer i Mesos består af to primære komponenter:
  • Planlægning: Dette er ansvarlig for registrering med Master Node sådan at mesteren kan begynde at tilbyde ressourcer
  • Eksekutor: Dette er den proces, der bliver lanceret på agentknudepunkterne at køre rammens opgaver
• Mesos Agenter: Disse er ansvarlig for faktisk at køre opgaverne. Hver agent offentliggør sine tilgængelige ressourcer som CPU og hukommelse til mesteren. Efter at have modtaget opgaver fra mesteren tildeler de nødvendige ressourcer til rammens eksekutor.
• Mesos Master: Dette er ansvarlig for planlægning af opgaver modtaget fra Frameworks på en af ​​de tilgængelige agentknudepunkter. Master laver ressourstilbud til Frameworks. Framework's planlægning kan vælge at køre opgaver på disse tilgængelige ressourcer.

3.2. Marathon

Som vi lige så, er Mesos ret fleksibel og giver rammer mulighed for at planlægge og udføre opgaver gennem veldefinerede API'er. Det er dog ikke praktisk at implementere disse primitiver direkte, især når vi vil planlægge brugerdefinerede applikationer. For eksempel orkestrering af applikationer pakket som containere.

Det er her, en ramme som Marathon kan hjælpe os. Marathon er en container orkestreringsramme, der kører på Mesos. I denne henseende fungerer Marathon som en ramme for Mesos-klyngen. Marathon giver adskillige fordele, som vi typisk forventer af en orkestrationsplatform som f.eks. Opdagelse af tjenester, belastningsbalancering, metrics og containeradministrations-API'er.

Marathon behandler en langvarig tjeneste som en applikation og en applikationsinstans som en opgave. Et typisk scenario kan have flere applikationer med afhængigheder, der danner det, der kaldes applikationsgrupper.

3.3. Eksempel

Så lad os se, hvordan vi kan bruge Marathon til at implementere vores enkle Docker-billede, vi oprettede tidligere. Bemærk, at installation af en Mesos-klynge kan være lidt involveret, og derfor kan vi bruge en mere ligetil løsning som Mesos Mini. Mesos Mini giver os mulighed for at spinde en lokal Mesos-klynge op i et Docker-miljø. Det inkluderer en Mesos Master, en enkelt Mesos Agent og Marathon.

Når vi først har kørt Mesos sammen med Marathon, kan vi implementere vores container som en langvarig applikationstjeneste. Alt hvad vi har brug for en lille JSON-applikationsdefinition:

# hello-marathon.json {"id": "marathon-demo-applikation", "cpus": 1, "mem": 128, "disk": 0, "instances": 1, "container": {"type ":" DOCKER "," docker ": {" image ":" hello_world: seneste "," portMappings ": [{" containerPort ": 9001," hostPort ": 0}]}}," netværk ": [{" tilstand ":" vært "}]}

Lad os forstå, hvad der lige sker her:

• Vi har angivet et id til vores ansøgning
• Derefter definerede vi ressourcekravene til vores applikation
• Vi definerede også, hvor mange forekomster vi gerne vil køre
• Derefter har vi leveret containeroplysningerne til at starte en app fra
• Endelig har vi defineret netværkstilstand, så vi kan få adgang til applikationen

Vi kan starte denne applikation ved hjælp af REST API'er leveret af Marathon:

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

4. Kort oversigt over Kubernetes

Kubernetes er et open-source container orkestreringssystem, der oprindeligt blev udviklet af Google. Det er nu en del af Cloud Native Computing Foundation (CNCF). Det giver en platform til automatisering af implementering, skalering og drift af applikationscontainer på tværs af en klynge af værter.

4.1. Arkitektur

Kubernetes arkitektur består af en Kubernetes Master og Kubernetes Nodes:

Lad os gennemgå de største dele af denne arkitektur på højt niveau:

• Kubernetes Master: Det master er ansvarlig for at opretholde den ønskede tilstand af klyngen. Det administrerer alle noder i klyngen. Som vi kan se, er mesteren en samling af tre processer:
  • kube-apiserver: Dette er den service, der administrerer hele klyngen, herunder behandling af REST-operationer, validering og opdatering af Kubernetes-objekter, udførelse af godkendelse og godkendelse
  • kube-controller-manager: Dette er dæmonen, der indlejrer kernekontrolsløjfen leveres med Kubernetes, hvilket foretager de nødvendige ændringer for at matche den aktuelle tilstand til den ønskede tilstand af klyngen
  • kube-scheduler: Denne service holder øje med ikke-planlagte bælg og binder dem til noder afhængigt af krævede ressourcer og andre begrænsninger
• Kubernetes noder: Knudepunkterne i en Kubernetes-klynge er de maskiner, der kører vores containere. Hver node indeholder de nødvendige tjenester til at køre containerne:
  • kubelet: Dette er den primære knudepunktagent som sikrer, at containerne beskrevet i PodSpecs leveret af kube-apiserver løber og er sunde
  • kube-proxy: Dette er netværksproxyen kører på hver node og udfører simpel TCP-, UDP-, SCTP-stream-forwarding eller round-robin-forwarding på tværs af et sæt backends
  • container runtime: Dette er kørselstiden, hvor containeren inde i bælgene køres, der er flere mulige container-driftstider for Kubernetes, herunder den mest anvendte Docker-runtime

4.2. Kubernetes objekter

I det sidste afsnit så vi flere Kubernetes-objekter, der er vedvarende enheder i Kubernetes-systemet. De afspejler klyngens tilstand på ethvert tidspunkt.

Lad os diskutere nogle af de almindeligt anvendte Kubernetes-objekter:

• Pods: Pod er en grundlæggende eksekveringsenhed i Kubernetes og kan bestå af en eller flere containere, containerne inde i en Pod indsættes på den samme vært
• Implementering: Implementering er den anbefalede måde at indsætte bælg i Kubernetes på, det giver funktioner som kontinuerlig afstemning af den aktuelle tilstand af bælg med den ønskede tilstand
• Services: Services i Kubernetes giver en abstrakt måde at udsætte en gruppe bælg på, hvor grupperingen er baseret på selektorer, der målretter podetiketter

Der er flere andre Kubernetes-objekter, der tjener formålet med at køre containere på en distribueret måde effektivt.

4.3. Eksempel

Så nu kan vi prøve at starte vores Docker-container i Kubernetes-klyngen. Kubernetes leverer Minikube, et værktøj, der kører Kubernetes-klynge med en enkelt node på en virtuel maskine. Vi har også brug for kubectl, Kubernetes Command Line Interface til at arbejde med Kubernetes-klyngen.

Når vi har kubectl og Minikube installeret, kan vi distribuere vores container på Kubernetes-klyngen med en enkelt node i Minikube. Vi skal definere de grundlæggende Kubernetes-objekter i en YAML-fil:

# hello-kubernetes.yaml apiVersion: apps / v1 kind: Implementeringsmetadata: navn: hello-world spec: replikaer: 1 skabelon: metadata: labels: app: hello-world spec: containere: - navn: hallo-world image: hej -verden: nyeste porte: - containerPort: 9001 --- apiVersion: v1 slags: Servicemetadata: navn: hallo-world-service spec: vælger: app: hej-verdenstype: LoadBalancer-porte: - port: 9001 targetPort: 9001

En detaljeret analyse af denne definitionsfil er ikke mulig her, men lad os gennemgå højdepunkterne:

• Vi har defineret en Implementering med etiketter i vælgeren
• Vi definerer antallet af replikaer, vi har brug for til denne implementering
• Vi har også leveret detaljer om containerbilledet som en skabelon til implementeringen
• Vi har også defineret en Service med passende vælger
• Vi har defineret tjenestens art som LoadBalancer

Endelig kan vi distribuere containeren og oprette alle definerede Kubernetes-objekter gennem kubectl:

kubectl anvende -f yaml / hej-kubernetes.yaml

5. Mesos vs. Kubernetes

Nu har vi gennemgået nok kontekst og også udført grundlæggende implementering på både Marathon og Kubernetes. Vi kan forsøge at forstå, hvor de står i forhold til hinanden.

Bare en advarsel er det ikke helt fair at sammenligne Kubernetes med Mesos direkte. De fleste af de funktioner til containerorkestrering, vi søger, leveres af en af ​​Mesos-rammerne som Marathon. Derfor for at holde tingene i det rigtige perspektiv, Vi forsøger at sammenligne Kubernetes med Marathon og ikke direkte Mesos.

Vi sammenligner disse orkestrationssystemer baseret på nogle af de ønskede egenskaber ved et sådant system.

5.1. Understøttede arbejdsbelastninger

Mesos er designet til håndtere forskellige typer arbejdsbelastninger som kan være containeriseret eller endda ikke-containeriseret. Det afhænger af de rammer, vi bruger. Som vi har set, er det ret nemt at understøtte containeriserede arbejdsbelastninger i Mesos ved hjælp af en ramme som Marathon.

Kubernetes derimod, fungerer udelukkende med den containeriserede arbejdsbyrde. Mest almindeligt bruger vi det med Docker-containere, men det understøtter andre container-driftstider som Rkt. I fremtiden understøtter Kubernetes muligvis flere typer arbejdsbelastninger.

5.2. Støtte til skalerbarhed

Marathon understøtter skalering gennem applikationsdefinitionen eller brugergrænsefladen. Autoskalering understøttes også i Marathon. Vi kan også skalere applikationsgrupper, der automatisk skalerer alle afhængigheder.

Som vi så tidligere, er Pod den grundlæggende enhed for henrettelse i Kubernetes. Bælter kan skaleres, når de administreres af Deployment, dette er grunden til, at bælg altid er defineret som en implementering. Skaleringen kan være manuel eller automatiseret.

5.3. Håndtering af høj tilgængelighed

Ansøgningsforekomster i Marathon er distribueret på tværs af Mesos-agenter, der giver høj tilgængelighed. Typisk består en Mesos-klynge af flere agenter. Derudover giver ZooKeeper høj tilgængelighed til Mesos-klyngen gennem beslutningsdygtighed og ledervalg.

Tilsvarende er bælg i Kubernetes replikeret på tværs af flere noder, der giver høj tilgængelighed. Typisk består en Kubernetes-klynge af flere arbejdsknudepunkter. Desuden kan klyngen også have flere mestre. Derfor er Kubernetes-klyngen i stand til at give containere høj tilgængelighed.

5.4. Serviceopdagelse og belastningsafbalancering

Mesos-DNS kan levere serviceopdagelse og en grundlæggende belastningsafbalancering til applikationer. Mesos-DNS genererer en SRV-post for hver Mesos-opgave og oversætter dem til IP-adressen og porten på den maskine, der kører opgaven. Til Marathon-applikationer kan vi også bruge Marathon-lb til at levere havnebaseret opdagelse ved hjælp af HAProxy.

Implementering i Kubernetes skaber og ødelægger bælg dynamisk. Derfor udsætter vi generelt bælg i Kubernetes igennem Service, der giver serviceopdagelse. Service i Kubernetes fungerer som en afsender til bælgene og giver dermed også belastningsbalancering.

5.5 Udførelse af opgraderinger og tilbageførsel

Ændringer af applikationsdefinitioner i Marathon håndteres som implementering. Implementering understøtter start, stop, opgradering eller skala af applikationer. Marathon understøtter også rullende starter at implementere nyere versioner af applikationerne. At rulle tilbage er dog lige lige frem og kræver typisk implementering af en opdateret definition.

Implementering i Kubernetes understøtter opgradering såvel som tilbageførsel. Vi kan give strategien for implementering, der skal tages, mens vi forbinder gamle bælg med nye. Typisk strategier er genskab eller rullende opdatering. Implementeringsudrulningshistorik opretholdes som standard i Kubernetes, hvilket gør det trivielt at rulle tilbage til en tidligere revision.

5.6. Logning og overvågning

Mesos har en diagnostisk hjælpeprogram, der scanner alle klyngekomponenter og stiller data til rådighed relateret til sundheds- og andre metrics. Dataene kan forespørges og aggregeres gennem tilgængelige API'er. Meget af disse data kan vi indsamle ved hjælp af et eksternt værktøj som Prometheus.

Kubernetes offentliggøre detaljerede oplysninger relateret til forskellige objekter som ressource-metrics eller komplette metrics-rørledninger. Typisk praksis er at implementere et eksternt værktøj som ELK eller Prometheus + Grafana på Kubernetes-klyngen. Sådanne værktøjer kan indtage klyngemålinger og præsentere dem på en meget brugervenlig måde.

5.7. Opbevaring

Mesos har vedvarende lokale mængder til stateful applikationer. Vi kan kun oprette vedvarende diskenheder fra de reserverede ressourcer. Det kan også understøtte ekstern lagring med nogle begrænsninger. Mesos har eksperimentel support til Container Storage Interface (CSI), et fælles sæt API'er mellem lagerleverandører og containerorkestrationsplatform.

Kubernetes tilbud flere typer vedvarende volumen til statefulde containere. Dette inkluderer opbevaring som iSCSI, NFS. Desuden understøtter den ekstern lagring som AWS, GCP også. Volume-objektet i Kubernetes understøtter dette koncept og findes i en række forskellige typer, herunder CSI.

5.8. Netværk

Container runtime i Mesos tilbyder to typer netværksunderstøttelse, IP-per-container og netværksport-kortlægning. Mesos definerer en fælles grænseflade til at specificere og hente netværksoplysninger til en container. Marathon-applikationer kan definere et netværk i værtstilstand eller brotilstand.

Netværk i Kubernetes tildeler en unik IP til hver pod. Dette negerer behovet for at kortlægge containerporte til værtsporten. Det definerer yderligere, hvordan disse bælg kan tale med hinanden på tværs af noder. Dette implementeres i Kubernetes af netværksplugins som Cilium, Contiv.

6. Hvornår skal jeg bruge hvad?

Endelig til sammenligning forventer vi normalt en klar dom! Det er dog ikke helt rimeligt at erklære en teknologi bedre end en anden uanset. Som vi har set, både Kubernetes og Mesos er stærke systemer og tilbyder ganske konkurrerende funktioner.

Ydeevne er dog et ganske afgørende aspekt. En Kubernetes-klynge kan skaleres til 5000 noder, mens Marathon på Mesos-klyngen er kendt for at understøtte op til 10.000 agenter. I de fleste praktiske tilfælde har vi ikke at gøre med så store klynger.

Endelig koges det ned til den fleksibilitet og typer af arbejdsbelastninger, vi har. Hvis vi starter forfra og vi planlægger kun at bruge containerbelastede arbejdsbelastninger, Kubernetes kan tilbyde en hurtigere løsning. Men hvis vi har eksisterende arbejdsbelastninger, som er en blanding af containere og ikke-containere, kan Mesos med Marathon være et bedre valg.

7. Andre alternativer

Kubernetes og Apache Mesos er ret magtfulde, men de er ikke de eneste systemer i dette rum. Der er ret mange lovende alternativer til rådighed for os. Selvom vi ikke går nærmere ind på deres detaljer, skal vi hurtigt liste nogle få af dem:

• Docker Swarm: Docker Swarm er et open source klyngesystem og planlægningsværktøj til Docker-containere. Den leveres med et kommandolinjeværktøj til at styre en klynge af Docker-værter. Det er begrænset til Docker-containere i modsætning til Kubernetes og Mesos.
• Nomad: Nomad er en fleksibel arbejdsbelastningsorkestrator fra HashiCorp til at administrere enhver containeriseret eller ikke-containeriseret applikation. Nomad muliggør deklarativ infrastruktur-som-kode til implementering af applikationer som Docker-container.
• OpenShift: OpenShift er en containerplatform fra Red Hat, orkestreret og administreret af Kubernetes nedenunder. OpenShift tilbyder mange funktioner ud over, hvad Kubernetes leverer som integreret billedregistrering, en kilde-til-billede-opbygning, en indbygget netværksløsning, for at nævne nogle få.

8. Konklusion

For at opsummere diskuterede vi i denne vejledning containere og container orkestreringssystemer. Vi gennemgik kort to af de mest udbredte container orkestreringssystemer, Kubernetes og Apache Mesos. Vi sammenlignede også dette system baseret på flere funktioner. Endelig så vi nogle af de andre alternativer i dette rum.

Før vi lukker, skal vi forstå, at formålet med en sådan sammenligning er at give data og fakta. Dette er på ingen måde at erklære en bedre end andre, og det afhænger normalt af brugssagen. Så vi skal anvende konteksten af ​​vores problem til at bestemme den bedste løsning for os.