streamalism.org

1. Oversikt

I denne opplæringen vil vi forstå det grunnleggende behovet for et containerorkestrasjonssystem.

Vi vil evaluere ønsket karakteristikk av et slikt system. Fra det prøver vi å sammenligne to av de mest populære containerorkestrasjonssystemene som er i bruk i dag, Apache Mesos og Kubernetes.

2. Containerorkestrering

Før vi begynner å sammenligne Mesos og Kubernetes, la oss bruke litt tid på å forstå hva containere er og hvorfor vi tross alt trenger containerorkestrering.

2.1. Beholdere

ENcontainer er en standardisert programvareenhet som pakker kode og alle nødvendige avhengigheter.

Derfor gir det plattformuavhengighet og operativ enkelhet. Docker er en av de mest populære containerplattformene i bruk.

Docker utnytter Linux-kjernen funksjoner som CGgrupper og navnerom for å gi isolasjon av forskjellige prosesser. Derfor kan flere containere kjøre uavhengig og sikkert.

Det er ganske trivielt å lage dockerbilder, alt vi trenger er en Dockerfile:

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

Så disse få linjene er gode nok til å lage et Docker-bilde av et Spring Boot-program ved hjelp av Docker CLI:

docker build -t hallo_verden.

2.2. Containerorkestrering

Så vi har sett hvordan containere kan gjøre applikasjonsdistribusjon pålitelig og repeterbar. Men hvorfor trenger vi orkestrering av containere?

Nå, mens vi har noen containere å administrere, har vi det bra med Docker CLI. Vi kan også automatisere noen av de enkle gjøremålene. Men hva skjer når vi skal administrere hundrevis av containere?

Tenk for eksempel på arkitektur med flere mikrotjenester, alle med forskjellige krav til skalerbarhet og tilgjengelighet.

Følgelig kan ting raskt komme ut av kontroll, og det er der fordelene med et containerorkestrasjonssystem blir klar. ENcontainer orkestrasjonssystem behandler en klynge av maskiner med en multi-container-applikasjon som en enkelt distribusjonsenhet. Det gir automatisering fra første distribusjon, planlegging, oppdateringer til andre funksjoner som overvåking, skalering og failover.

3. Kort oversikt over Mesos

Apache Mesos er en åpen kildekode-klyngesjef utviklet opprinnelig ved UC Berkeley. Det gir applikasjoner APIer for ressursadministrasjon og planlegging på tvers av klyngen. Mesos gir oss fleksibiliteten til å kjøre både containerisert og ikke-containerisert arbeidsmengde på en distribuert måte.

3.1. Arkitektur

Mesos-arkitekturen består av Mesos Master, Mesos Agent og Application Frameworks:

La oss forstå komponentene i arkitekturen her:

• Rammeverk: Disse er de faktiske applikasjonene som krever distribuert kjøring av oppgaver eller arbeidsmengde. Typiske eksempler er Hadoop eller Storm. Rammeverk i Mesos består av to hovedkomponenter:
  • Planlegger: Dette er ansvarlig for registrering med Master Node slik at mesteren kan begynne å tilby ressurser
  • Leder: Dette er prosessen som blir lansert på agentnodene å kjøre rammeverkets oppgaver
• Mesos Agenter: Disse er ansvarlig for å faktisk kjøre oppgavene. Hver agent publiserer sine tilgjengelige ressurser som CPU og minne til mesteren. Når de mottar oppgaver fra mesteren, tildeler de nødvendige ressurser til rammeverket.
• Mesos Mester: Dette er ansvarlig for planlegging av oppgaver mottatt fra Frameworks på en av de tilgjengelige agentnodene. Master gir ressurstilbud til Frameworks. Framework's planlegger kan velge å kjøre oppgaver på disse tilgjengelige ressursene.

3.2. Maraton

Som vi nettopp så, er Mesos ganske fleksibel og lar rammer planlegge og utføre oppgaver gjennom veldefinerte APIer. Det er imidlertid ikke praktisk å implementere disse primitivene direkte, spesielt når vi vil planlegge tilpassede applikasjoner. For eksempel orkestrering av applikasjoner pakket som containere.

Det er her et rammeverk som Marathon kan hjelpe oss. Maraton er et rammeverk for containerorkestrering som kjører på Mesos. I denne forbindelse fungerer Marathon som et rammeverk for Mesos-klyngen. Marathon gir flere fordeler som vi vanligvis forventer fra en orkestreringsplattform som funn av tjenester, lastbalansering, beregninger og containeradministrasjons-APIer.

Maraton behandler en langvarig tjeneste som en applikasjon og en applikasjonsinstans som en oppgave. Et typisk scenario kan ha flere applikasjoner med avhengigheter som danner det som kalles applikasjonsgrupper.

3.3. Eksempel

Så la oss se hvordan vi kan bruke Marathon til å distribuere vårt enkle Docker-bilde vi opprettet tidligere. Merk at installering av en Mesos-klynge kan være lite involvert, og derfor kan vi bruke en mer enkel løsning som Mesos Mini. Mesos Mini lar oss spinne opp en lokal Mesos-klynge i et Docker-miljø. Den inkluderer en Mesos Master, single Mesos Agent og Marathon.

Når vi har Mesos klynget med Marathon i gang, kan vi distribuere containeren vår som en langvarig applikasjonstjeneste. Alt vi trenger en liten JSON-applikasjonsdefinisjon:

# 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}]}}," nettverk ": [{" modus ":" vert "}]}

La oss forstå hva som skjer her:

• Vi har gitt en id for søknaden vår
• Deretter definerte vi ressurskravene for applikasjonen vår
• Vi definerte også hvor mange forekomster vi vil kjøre
• Deretter har vi gitt containerinformasjonen for å starte en app fra
• Til slutt har vi definert nettverksmodus for at vi skal kunne få tilgang til applikasjonen

Vi kan starte denne applikasjonen ved hjelp av REST API-ene levert av Marathon:

krøll -X POST \ // localhost: 8080 / v2 / apps \ -d @ hallo-marathon.json \ -H "Innholdstype: applikasjon / json"

4. Kort oversikt over Kubernetes

Kubernetes er et åpen kildekode container orkestrasjonssystem opprinnelig utviklet av Google. Det er nå en del av Cloud Native Computing Foundation (CNCF). Det gir en plattform for automatisering av distribusjon, skalering og drift av applikasjonsbeholder over en klynge av verter.

4.1. Arkitektur

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

La oss gå gjennom de viktigste delene av denne høynivåarkitekturen:

• Kubernetes Master: The master er ansvarlig for å opprettholde ønsket tilstand av klyngen. Den administrerer alle noder i klyngen. Som vi kan se, er mesteren en samling av tre prosesser:
  • kube-apiserver: Dette er tjenesten som administrerer hele klyngen, inkludert behandling av REST-operasjoner, validering og oppdatering av Kubernetes-objekter, utføring av godkjenning og autorisasjon
  • kube-controller-manager: Dette er demonen som legger inn kjernekontrollsløyfen leveres med Kubernetes, og gjør de nødvendige endringene for å matche nåværende tilstand til ønsket tilstand av klyngen
  • kube-planlegger: Denne tjenesten ser etter ikke-planlagte belger og binder dem til noder avhengig av etterspurte ressurser og andre begrensninger
• Kubernetes noder: Nodene i en Kubernetes-klynge er maskinene som kjører containerne våre. Hver node inneholder de nødvendige tjenestene for å kjøre containerne:
  • kubelet: Dette er den primære nodeagenten som sørger for at containerne beskrevet i PodSpecs levert av kube-apiserver er løpende og sunne
  • kube-proxy: Dette er nettverksproxyen som kjører på hver node og utfører enkel TCP-, UDP-, SCTP-videresending av strøm eller videresending av robin over et sett med backends
  • container kjøretid: Dette er kjøretiden der containeren inne i belgene kjøres, det er flere mulige containertider for Kubernetes, inkludert den mest brukte Docker-kjøretiden

4.2. Kubernetes objekter

I den siste delen så vi flere Kubernetes-objekter som er vedvarende enheter i Kubernetes-systemet. De gjenspeiler klyngens tilstand når som helst.

La oss diskutere noen av de ofte brukte Kubernetes-objektene:

• Pods: Pod er en grunnleggende enhet for henrettelse i Kubernetes og kan bestå av en eller flere containere, containerne inne i en Pod er distribuert på samme vert
• Implementering: Implementering er den anbefalte måten å distribuere pods i Kubernetes, det gir funksjoner som kontinuerlig å avstemme den nåværende tilstanden til pods med ønsket tilstand
• Tjenester: Tjenester i Kubernetes gi en abstrakt måte å avsløre en gruppe bøtter på, hvor grupperingen er basert på selektorer som målretter podetiketter

Det er flere andre Kubernetes-objekter som tjener formålet med å kjøre containere på en distribuert måte effektivt.

4.3. Eksempel

Så, nå kan vi prøve å starte Docker-containeren vår i Kubernetes-klyngen. Kubernetes gir Minikube, et verktøy som kjører Kubernetes-klyngen med en node på en virtuell maskin. Vi trenger også kubectl, Kubernetes Command Line Interface for å jobbe med Kubernetes-klyngen.

Etter at vi har kubectl og Minikube installert, kan vi distribuere containeren vår på Kubernetes-klyngen med en node i Minikube. Vi må definere de grunnleggende Kubernetes-objektene i en YAML-fil:

# hallo-kubernetes.yaml apiVersjon: apps / v1 type: Distribusjonsmetadata: navn: hallo-world spec: replikaer: 1 mal: metadata: labels: app: hallo-world spec: containere: - navn: hallo-world image: hallo -verden: siste porter: - containerPort: 9001 --- apiVersjon: v1 type: Tjenestemetadata: navn: hallo-world-service spesifikasjon: velger: app: hallo-verdenstype: LoadBalancer-porter: - port: 9001 targetPort: 9001

En detaljert analyse av denne definisjonsfilen er ikke mulig her, men la oss gå gjennom høydepunktene:

• Vi har definert en Utplassering med etiketter i velgeren
• Vi definerer antall kopier vi trenger for denne distribusjonen
• Vi har også gitt detaljer om containerbildet som en mal for distribusjonen
• Vi har også definert en Service med passende velger
• Vi har definert tjenestens natur som LoadBalancer

Til slutt kan vi distribuere containeren og opprette alle definerte Kubernetes-objekter gjennom kubectl:

kubectl gjelder -f yaml / hallo-kubernetes.yaml

5. Mesos vs Kubernetes

Nå har vi gått gjennom nok kontekst og også utført grunnleggende distribusjon på både Marathon og Kubernetes. Vi kan prøve å forstå hvor de står i forhold til hverandre.

Bare en advarsel, skjønt, det er ikke helt rettferdig å sammenligne Kubernetes med Mesos direkte. De fleste av container orkestrasjonsfunksjonene vi søker er levert av en av Mesos-rammene som Marathon. Derfor, for å holde ting i riktig perspektiv, Vi prøver å sammenligne Kubernetes med Marathon og ikke direkte Mesos.

Vi sammenligner disse orkestrasjonssystemene basert på noen av de ønskede egenskapene til et slikt system.

5.1. Støttede arbeidsmengder

Mesos er designet for å håndtere forskjellige typer arbeidsmengder som kan containeriseres eller til og med ikke-containeriseres. Det avhenger av rammene vi bruker. Som vi har sett, er det ganske enkelt å støtte containeriserte arbeidsbelastninger i Mesos ved hjelp av et rammeverk som Marathon.

Kubernetes derimot, fungerer utelukkende med den containeriserte arbeidsmengden. Mest brukt bruker vi den med Docker-containere, men den har støtte for andre container-kjøretider som Rkt. I fremtiden kan Kubernetes støtte flere typer arbeidsbelastninger.

5.2. Støtte for skalerbarhet

Marathon støtter skalering gjennom applikasjonsdefinisjonen eller brukergrensesnittet. Autoskalering støttes også i Marathon. Vi kan også skalere applikasjonsgrupper som automatisk skalerer alle avhengigheter.

Som vi så tidligere, er Pod den grunnleggende henrettelsesenheten i Kubernetes. Pods kan skaleres når de administreres av Deployment, dette er grunnen til at pods alltid er definert som en distribusjon. Skaleringen kan være manuell eller automatisert.

5.3. Håndtering av høy tilgjengelighet

Søknadstilfeller i Marathon er distribuert over Mesos-agenter som gir høy tilgjengelighet. Vanligvis består en Mesos-klynge av flere agenter. I tillegg gir ZooKeeper høy tilgjengelighet til Mesos-klyngen gjennom quorum og ledervalg.

Tilsvarende er pods i Kubernetes replikert på tvers av flere noder som gir høy tilgjengelighet. Vanligvis består en Kubernetes-klynge av flere arbeidernoder. Videre kan klyngen også ha flere mestere. Derfor er Kubernetes-klyngen i stand til å gi containere høy tilgjengelighet.

5.4. Service Discovery and Load Balancing

Mesos-DNS kan tilby tjenesteoppdagelse og en grunnleggende belastningsbalansering for applikasjoner. Mesos-DNS genererer en SRV-post for hver Mesos-oppgave og oversetter dem til IP-adressen og porten til maskinen som kjører oppgaven. For Marathon-applikasjoner kan vi også bruke Marathon-lb til å gi portbasert oppdagelse ved hjelp av HAProxy.

Distribusjon i Kubernetes skaper og ødelegger belg dynamisk. Derfor utsetter vi vanligvis belger i Kubernetes gjennom Service, som gir serviceoppdagelse. Service i Kubernetes fungerer som en utsender til belgene og gir dermed også lastbalansering.

5.5 Utføre oppgraderinger og tilbakestilling

Endringer i applikasjonsdefinisjoner i Marathon håndteres som distribusjon. Utplassering støtter start, stopp, oppgradering eller skala av applikasjoner. Maraton støtter også rullende starter for å distribuere nyere versjoner av applikasjonene. Å rulle tilbake er imidlertid like rett frem og krever vanligvis distribusjon av en oppdatert definisjon.

Distribusjon i Kubernetes støtter oppgradering så vel som tilbakeføring. Vi kan tilby strategien for implementering som skal tas mens vi forbinder gamle belger med nye. Typisk strategier er Gjenopprett eller Rullende oppdatering. Distribusjonshistorikken for distribusjon opprettholdes som standard i Kubernetes, noe som gjør det trivielt å gå tilbake til en tidligere revisjon.

5.6. Logging og overvåking

Mesos har en diagnostisk verktøy som skanner alle klyngekomponentene og gjør tilgjengelig data relatert til helse og andre beregninger. Dataene kan spørres og samles gjennom tilgjengelige API-er. Mye av disse dataene kan vi samle inn ved hjelp av et eksternt verktøy som Prometheus.

Kubernetes publisere detaljert informasjon relatert til forskjellige objekter som ressursberegninger eller rør for komplette beregninger. Typisk praksis er å distribuere et eksternt verktøy som ELK eller Prometheus + Grafana på Kubernetes-klyngen. Slike verktøy kan innta klyngemålinger og presentere dem på en mye brukervennlig måte.

5.7. Oppbevaring

Mesos har vedvarende lokale volumer for stateful applikasjoner. Vi kan bare lage vedvarende volumer fra de reserverte ressursene. Det kan også støtte ekstern lagring med noen begrensninger. Mesos har eksperimentell støtte for Container Storage Interface (CSI), et vanlig sett med API-er mellom lagringsleverandører og containerorkestrasjonsplattform.

Kubernetes tilbyr flere typer vedvarende volum for stateful containere. Dette inkluderer lagring som iSCSI, NFS. Videre støtter den ekstern lagring som AWS, GCP også. Volum-objektet i Kubernetes støtter dette konseptet og kommer i en rekke typer, inkludert CSI.

5.8. Nettverk

Container runtime i Mesos tilbyr to typer nettverksstøtte, IP-per-container og nettverksport-kartlegging. Mesos definerer et felles grensesnitt for å spesifisere og hente nettverksinformasjon for en container. Maratonapplikasjoner kan definere et nettverk i vertsmodus eller bromodus.

Nettverk i Kubernetes tildeler en unik IP til hver pod. Dette negerer behovet for å kartlegge containerporter til vertsporten. Den definerer videre hvordan disse podene kan snakke med hverandre på tvers av noder. Dette er implementert i Kubernetes av Network Plugins som Cilium, Contiv.

6. Når skal jeg bruke hva?

Til slutt, til sammenligning, forventer vi vanligvis en klar dom! Det er imidlertid ikke helt rettferdig å erklære en teknologi bedre enn en annen, uansett. Som vi har sett, både Kubernetes og Mesos er kraftige systemer og tilbyr ganske konkurrerende funksjoner.

Ytelse er imidlertid ganske viktig. En Kubernetes-klynge kan skaleres til 5000 noder mens Marathon on Mesos-klyngen er kjent for å støtte opptil 10.000 agenter. I de fleste praktiske tilfeller vil vi ikke håndtere så store klynger.

Til slutt koker det ned til fleksibiliteten og typer arbeidsbelastninger som vi har. Hvis vi begynner på nytt og vi bare planlegger å bruke containerbelastninger, Kubernetes kan tilby en raskere løsning. Imidlertid, hvis vi har eksisterende arbeidsbelastninger, som er en blanding av containere og ikke-containere, kan Mesos med Marathon være et bedre valg.

7. Andre alternativer

Kubernetes og Apache Mesos er ganske kraftige, men de er ikke de eneste systemene i dette rommet. Det er ganske mange lovende alternativer tilgjengelig for oss. Selv om vi ikke går inn på detaljene deres, la oss raskt liste opp noen av dem:

• Docker Swarm: Docker Swarm er et åpen kildekode-klynge- og planleggingsverktøy for Docker-containere. Den leveres med et kommandolinjeverktøy for å administrere en klynge av Docker-verter. Det er begrenset til Docker-containere, i motsetning til Kubernetes og Mesos.
• Nomad: Nomad er en fleksibel arbeidsbelastningsorkester fra HashiCorp for å administrere et hvilket som helst containerisert eller ikke-containerisert program. Nomad muliggjør deklarativ infrastruktur-som-kode for distribusjon av applikasjoner som Docker container.
• OpenShift: OpenShift er en containerplattform fra Red Hat, orkestrert og administrert av Kubernetes under. OpenShift tilbyr mange funksjoner på toppen av hva Kubernetes tilbyr som integrert bilderegister, en kilde-til-bilde-bygging, en innfødt nettverksløsning, for å nevne noen.

8. Konklusjon

For å oppsummere, i denne veiledningen, diskuterte vi containere og container orkestreringssystemer. Vi gikk kort gjennom to av de mest brukte containerorkestrasjonssystemene, Kubernetes og Apache Mesos. Vi sammenlignet også dette systemet basert på flere funksjoner. Til slutt så vi noen av de andre alternativene i dette rommet.

Før vi avslutter, må vi forstå at formålet med en slik sammenligning er å gi data og fakta. Dette er på ingen måte å erklære en bedre enn andre, og det avhenger normalt av brukssaken. Så vi må bruke konteksten av problemet vårt ved å bestemme den beste løsningen for oss.