Mesos vs Kubernetes

1. Prehľad

V tomto tutoriáli pochopíme základné potreby systému orchestrácie kontajnerov.

Zhodnotíme požadovanú charakteristiku takého systému. Z toho sa pokúsime porovnať dva najpopulárnejšie systémy orchestrácie kontajnerov, ktoré sa dnes používajú, Apache Mesos a Kubernetes.

2. Orchestrácia kontajnera

Predtým, ako začneme porovnávať Mesos a Kubernetes, venujme nejaký čas pochopeniu toho, čo sú to kontejnery a prečo nakoniec potrebujeme orchestráciu kontajnerov.

2.1. Kontajnery

Acontainer je štandardizovaná jednotka softvéru, ktorá balí kód a všetky jeho požadované závislosti.

Poskytuje teda nezávislosť na platforme a prevádzkovú jednoduchosť. Docker je jednou z najpopulárnejších používaných kontajnerových platforiem.

Docker využíva linuxové jadro funkcie ako CGroups a menné priestory, ktoré poskytujú izoláciu rôznych procesov. Viaceré kontajnery preto môžu bežať nezávisle a bezpečne.

Vytváranie docker obrázkov je dosť maličkosti, všetko, čo potrebujeme, je súbor Docker:

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

Týchto pár riadkov je teda dosť dobrých na to, aby ste pomocou aplikácie Docker CLI vytvorili Dockerov obraz aplikácie Spring Boot:

docker build -t hello_world.

2.2. Kontajnerová orchestrácia

Takže sme videli, ako kontajnery môžu zabezpečiť spoľahlivé a opakovateľné nasadenie aplikácií. Prečo však potrebujeme orchestráciu kontajnerov?

Teraz, keď máme na správu niekoľko kontajnerov, sme v poriadku s Docker CLI. Môžeme tiež automatizovať niektoré jednoduché práce. ale čo sa stane, keď budeme musieť spravovať stovky kontajnerov?

Napríklad, myslite na architektúru s niekoľkými mikroslužbami, všetky s výraznými požiadavkami na škálovateľnosť a dostupnosť.

V dôsledku toho sa veci môžu rýchlo dostať spod kontroly a tam si uvedomujú výhody systému orchestrácie kontajnerov. Asystém orchestrácie kontajnerov zaobchádza s klastrom strojov s aplikáciou viacerých kontajnerov ako s jednou entitou nasadenia. Poskytuje automatizáciu od počiatočného nasadenia, plánovania, aktualizácií ďalších funkcií, ako je monitorovanie, zmena mierky a prepnutie po zlyhaní.

3. Stručný prehľad Mesos

Apache Mesos je open-source klastrový manažér vyvinutý pôvodne v UC Berkeley. Poskytuje aplikácie s API na správu zdrojov a plánovanie v rámci klastra. Mesos nám dáva flexibilitu na prevádzkovanie kontajnerovaného aj nekontaminovaného pracovného zaťaženia distribuovaným spôsobom.

3.1. Architektúra

Architektúra Mesos pozostáva z Mesos Master, Mesos Agent a Application Frameworks:

Poďme tu pochopiť komponenty architektúry:

  • Rámcov: Toto sú skutočné aplikácie, ktoré si vyžadujú distribuované vykonávanie úloh alebo pracovného vyťaženia. Typickými príkladmi sú Hadoop alebo Storm. Rámce v systéme Mesos pozostávajú z dvoch základných komponentov:
    • Plánovač: Toto je zodpovedný za registráciu na hlavnom uzle také, aby pán mohol začať ponúkať zdroje
    • Exekútor: Toto je proces, ktorý sa spustí na uzloch agenta na vykonávanie úloh rámca
  • Agenti spoločnosti Mesos: Toto sú zodpovedný za skutočné vykonávanie úloh. Každý agent publikuje svoje dostupné zdroje ako CPU a pamäť na hlavný server. Pri prijímaní úloh od hlavného počítača prideľujú požadované zdroje vykonávateľovi rámca.
  • Majster Mesos: Toto je zodpovedný za plánovanie úloh prijatých z rámcov na jednom z dostupných uzlov agenta. Majster dáva ponuky rámcov. Plánovač frameworku si môže zvoliť spustenie úloh na týchto dostupných zdrojoch.

3.2. Maratón

Ako sme práve videli, program Mesos je dosť flexibilný a umožňuje rámcom plánovať a vykonávať úlohy prostredníctvom dobre definovaných rozhraní API. Nie je však vhodné implementovať tieto primitívne prvky priamo, najmä ak chceme naplánovať vlastné aplikácie. Napríklad orchestrácia aplikácií zabalených ako kontajnery.

Tu nám môže pomôcť rámec ako Marathon. Maratón je rámec orchestrácie kontajnerov, ktorý beží na systéme Mesos. V tomto ohľade Marathon funguje ako rámec pre klaster Mesos. Marathon poskytuje niekoľko výhod, ktoré zvyčajne očakávame od orchestračnej platformy, ako sú objavovanie služieb, vyvažovanie záťaže, metriky a rozhrania API na správu kontajnerov.

Maratón považuje dlhodobú službu za aplikáciu a inštancia aplikácie ako úloha. Typický scenár môže mať viac aplikácií so závislosťami, ktoré tvoria takzvané Skupiny aplikácií.

3.3. Príklad

Pozrime sa teda, ako môžeme použiť Marathon na nasadenie nášho jednoduchého obrazu Dockeru, ktorý sme vytvorili skôr. Upozorňujeme, že inštalácia klastra Mesos môže byť málo zapojená, a preto môžeme použiť priamočiarejšie riešenie, ako je Mesos Mini. Mesos Mini nám umožňuje roztočiť lokálny klaster Mesos v prostredí Docker. Zahŕňa Mesos Master, samostatného agenta Mesos a Marathon.

Keď už sme klaster Mesos s Marathonom v prevádzke, môžeme nasadiť náš kontajner ako dlho fungujúcu aplikačnú službu. Všetko, čo potrebujeme, je malá definícia aplikácie JSON:

# hello-marathon.json {"id": "marathon-demo-application", "cpus": 1, "mem": 128, "disk": 0, "inštancie": 1, "container": {"typ ":" DOCKER "," docker ": {" image ":" hello_world: latest "," portMappings ": [{" containerPort ": 9001," hostPort ": 0}]}}," siete ": [{" režim ":" hostiteľ "}]}

Poďme pochopiť, čo sa tu presne deje:

  • Poskytli sme ID pre našu aplikáciu
  • Potom sme definovali požiadavky na zdroje pre našu aplikáciu
  • Tiež sme definovali, koľko inštancií by sme chceli spustiť
  • Potom sme poskytli podrobnosti o kontajneri, z ktorého sa má aplikácia spustiť
  • Nakoniec sme definovali sieťový režim, aby sme mali prístup k aplikácii

Túto aplikáciu môžeme spustiť pomocou rozhraní REST API, ktoré poskytuje Marathon:

curl -X POST \ // localhost: 8080 / v2 / apps \ -d @ hello-marathon.json \ -H "Typ obsahu: aplikácia / json"

4. Stručný prehľad Kubernetes

Kubernetes je systém orchestrácie kontajnerov s otvoreným zdrojom pôvodne vyvinutý spoločnosťou Google. Teraz je súčasťou Cloud Native Computing Foundation (CNCF). Poskytuje platformu na automatizáciu nasadenia, škálovania a operácií aplikačného kontajnera v klastri hostiteľov.

4.1. Architektúra

Architektúra Kubernetes sa skladá z uzlov Kubernetes Master a Kubernetes:

Poďme si prejsť hlavné časti tejto architektúry na vysokej úrovni:

  • Majster Kubernetes: master je zodpovedný za udržiavanie požadovaného stavu klastra. Spravuje všetky uzly v klastri. Ako vidíme, master je súborom troch procesov:
    • kube-apiserver: Toto je služba, ktorá spravuje celý klaster, vrátane spracovania operácií REST, validácie a aktualizácie objektov Kubernetes, vykonávania autentifikácie a autorizácie
    • kube-kontrolór-manažér: Toto je démon, ktorý vloží riadiacu slučku jadra dodávané s Kubernetes, čo robí nevyhnutné zmeny, aby sa súčasný stav zosúladil s požadovaným stavom klastra
    • kube-scheduler: Táto služba sleduje neplánované pody a viaže ich na uzly v závislosti od požadovaných zdrojov a ďalších obmedzení
  • Uzly Kubernetes: Uzly v klastri Kubernetes sú stroje, ktoré prevádzkujú naše kontajnery. Každý uzol obsahuje služby potrebné na spustenie kontajnerov:
    • kubelet: Toto je agent primárneho uzla ktorá zaisťuje, že kontajnery popísané v PodSpecs poskytované serverom kube-apiserver sú behavé a zdravé
    • kube-proxy: Toto je sieťový proxy server bežiaci na každom uzle a vykonáva jednoduché presmerovanie toku TCP, UDP, SCTP alebo presmerovanie typu každý s každým cez celý rad koncových zariadení
    • runtime kontajnera: Toto je runtime, kde je spustený kontajner vo vnútri podov, pre Kubernetes existuje niekoľko možných runtime kontajnera vrátane najpoužívanejšieho runtime modulu Docker

4.2. Objekty Kubernetes

V poslednej časti sme videli niekoľko objektov Kubernetes, ktoré sú pretrvávajúcimi entitami v systéme Kubernetes. Odrážajú stav klastra v ktoromkoľvek okamihu.

Poďme diskutovať o niektorých bežne používaných objektoch Kubernetes:

  • Pods: Pod je základná jednotka popravy v Kubernetes a môže pozostávať z jedného alebo viacerých kontajnerov, kontajnery vo vnútri modulu Pod sú umiestnené na rovnakom hostiteľovi
  • Nasadenie: Nasadenie je odporúčaný spôsob nasadenia podov v Kubernetes, poskytuje funkcie ako neustále zosúlaďovanie aktuálneho stavu podov s požadovaným stavom
  • Služby: Služby v Kubernetes poskytujú abstraktný spôsob vystavenia skupiny toboliek, kde je zoskupenie založené na selektoroch zacielených na štítky pod

Existuje niekoľko ďalších objektov Kubernetes, ktoré slúžia na účel efektívneho prevádzkovania kontajnerov.

4.3. Príklad

Teraz sa teda môžeme pokúsiť spustiť náš kontajner Docker do klastra Kubernetes. Kubernetes poskytuje Minikube, nástroj, ktorý spúšťa klaster Kubernetes s jedným uzlom na virtuálnom stroji. Na prácu s klastrom Kubernetes by sme potrebovali aj kubectl, rozhranie príkazového riadku Kubernetes.

Po nainštalovaní kubectl a Minikube môžeme nasadiť náš kontajner na klaster Kubernetes s jedným uzlom v rámci Minikube. Musíme definovať základné objekty Kubernetes v súbore YAML:

# hello-kubernetes.yaml apiVerzia: druh aplikácií / v1: metadáta nasadenia: názov: hello-world spec: repliky: 1 šablóna: metadáta: štítky: app: hello-world spec: kontejnery: - názov: hello-world obrázok: hello -world: najnovšie porty: - containerPort: 9001 --- apiVerzia: druh v1: metaúdaje služby: názov: hello-world-service spec: selektor: aplikácia: hello-world typ: porty LoadBalancer: - port: 9001 targetPort: 9001

Podrobná analýza tohto súboru s definíciami tu nie je možná, ale poďme na to, čo je najdôležitejšie:

  • Definovali sme a Nasadenie so štítkami vo selektore
  • Definujeme počet replík, ktoré potrebujeme pre toto nasadenie
  • Ďalej sme poskytli podrobnosti obrázka kontajnera ako šablónu pre nasadenie
  • Definovali sme tiež a Služby s príslušným selektorom
  • Charakter služby sme definovali ako LoadBalancer

Nakoniec môžeme nasadiť kontajner a vytvárať všetky definované objekty Kubernetes prostredníctvom kubectl:

kubectl použiť -f yaml / ahoj-kubernetes.yaml

5. Mesos vs. Kubernetes

Teraz sme prešli dostatočnými súvislosťami a vykonali sme aj základné nasadenie na Maratóne aj Kubernetes. Môžeme sa pokúsiť pochopiť, kde sú v porovnaní s ostatnými.

Je to však len výstraha nie je úplne fér porovnávať Kubernetes s Mesosom priamo. Väčšina funkcií orchestrácie kontajnerov, ktoré hľadáme, poskytuje jeden z rámcov Mesos, ako je Marathon. Preto, aby sme udržali veci v správnej perspektíve, pokúsime sa porovnať Kubernetes s Marathon a nie priamo Mesos.

Tieto orchestračné systémy porovnáme na základe niektorých požadovaných vlastností takého systému.

5.1. Podporované pracovné zaťaženia

Mesos je navrhnutý tak, aby zvládnuť rôzne typy pracovných záťaží ktoré môžu byť v kontajneroch alebo dokonca bez kontajnerov. Závisí to od rámca, ktorý používame. Ako sme videli, je celkom ľahké podporovať kontajnerované pracovné zaťaženie v aplikácii Mesos pomocou rámca ako Marathon.

Kubernetes na druhej strane pracuje výlučne s kontajnerovaným pracovným zaťažením. Najčastejšie ho používame s kontajnermi Docker, ale má podporu pre ďalšie runtime kontajnerov, ako je Rkt. V budúcnosti bude Kubernetes podporovať viac druhov pracovných záťaží.

5.2. Podpora škálovateľnosti

Marathon podporuje škálovanie prostredníctvom definície aplikácie alebo používateľského rozhrania. V programe Marathon je podporované aj automatické škálovanie. Môžeme tiež škálovať aplikačné skupiny, ktoré automaticky škálujú všetky závislosti.

Ako sme už videli skôr, Pod je základnou popravnou jednotkou v Kubernetes. Modely Pods je možné škálovať, ak ich spravuje nasadenie, z tohto dôvodu sú pody vždy definované ako nasadenie. Mierka môže byť manuálna alebo automatická.

5.3. Spracovanie vysokej dostupnosti

Príklady aplikácií v Maratóne sú distribuované medzi agentmi Mesos, ktoré poskytujú vysokú dostupnosť. Klaster Mesos sa zvyčajne skladá z viacerých agentov. ZooKeeper navyše poskytuje vysokú dostupnosť klastru Mesos prostredníctvom volieb kvóra a lídrov.

Podobne sú na tom aj tobolky v Kubernetes replikované na viacerých uzloch poskytujúcich vysokú dostupnosť. Klaster Kubernetes sa zvyčajne skladá z viacerých pracovných uzlov. Klaster môže mať navyše aj viacerých matríc. Klaster Kubernetes je preto schopný poskytnúť kontajnerom vysokú dostupnosť.

5.4. Zisťovanie služieb a vyvažovanie záťaže

Mesos-DNS môže poskytnúť vyhľadávanie služieb a základné vyvažovanie záťaže pre aplikácie. Mesos-DNS generuje záznam SRV pre každú úlohu Mesos a prekladá ich na adresu IP a port stroja, na ktorom je úloha vykonaná. Pre aplikácie Marathon môžeme tiež použiť Marathon-lb na zabezpečenie portového objavu pomocou HAProxy.

Nasadenie v Kubernetes dynamicky vytvára a ničí pody. Preto všeobecne vystavujeme tobolky v Kubernetes Služba, ktorá poskytuje vyhľadávanie služieb. Služba v Kubernetes slúži ako dispečer pre pody, a preto poskytuje aj vyváženie záťaže.

5.5 Vykonávanie aktualizácií a vrátenie zmien

Zmeny v definíciách aplikácií v Maratone sa riešia ako nasadenie. Nasadenie podporuje spustenie, zastavenie, aktualizáciu alebo škálu aplikácií. Maratón podporuje aj rolovacie štarty nasadiť novšie verzie aplikácií. Vrátenie späť je však rovnako priame a zvyčajne si vyžaduje nasadenie aktualizovanej definície.

Nasadenie v Kubernetes podporuje inováciu aj vrátenie zmien. Môžeme poskytnúť stratégiu nasadenia, ktorá sa má prijať pri prepojení starých podov s novými. Typické stratégie sú Recreate alebo Rolling Update. História nasadenia sa v Kubernetes predvolene udržiava, čo umožňuje triviálne vrátenie sa k predchádzajúcej revízii.

5.6. Protokolovanie a monitorovanie

Mesos má a diagnostický nástroj, ktorý kontroluje všetky komponenty klastra a sprístupňuje údaje týkajúce sa zdravia a ďalšie metriky. Údaje je možné dopytovať a agregovať pomocou dostupných rozhraní API. Veľa z týchto údajov môžeme zhromaždiť pomocou externého nástroja, ako je Prometheus.

Kubernetes publikovať podrobné informácie týkajúce sa rôznych objektov ako metriky zdrojov alebo celé kanály metrík. Typickým postupom je nasadenie externého nástroja, ako je ELK alebo Prometheus + Grafana, do klastra Kubernetes. Takéto nástroje môžu prijímať klastrové metriky a prezentovať ich užívateľsky veľmi príjemným spôsobom.

5.7. Skladovanie

Mesos má trvalé miestne zväzky pre stavové aplikácie. Trvalé zväzky môžeme vytvárať iba z vyhradených zdrojov. Môže tiež podporovať externé úložisko s určitými obmedzeniami. Mesos má experimentálnu podporu pre Container Storage Interface (CSI), spoločnú sadu API medzi dodávateľmi úložných zariadení a platformou orchestrácie kontajnerov.

Kubernetes ponúka niekoľko typov trvalého objemu pre stavové kontajnery. Patria sem úložiská ako iSCSI, NFS. Ďalej podporuje externé úložiská ako AWS, GCP. Objekt Volume v Kubernetes podporuje tento koncept a je dodávaný v rôznych typoch, vrátane CSI.

5.8. Siete

Prevádzková doba kontajnera v ponukách Mesos dva typy podpory sietí, IP na kontajner a mapovanie sieťových portov. Mesos definuje spoločné rozhranie na špecifikáciu a načítanie sieťových informácií pre kontajner. Aplikácie Marathon môžu definovať sieť v hostiteľskom režime alebo v režime mosta.

Siete v Kubernetes každému podu pridelí jedinečnú IP. To vylučuje potrebu mapovania portov kontajnera na hostiteľský port. Ďalej definuje, ako môžu tieto pody medzi sebou komunikovať cez uzly. To je v Kubernetes implementované sieťovými doplnkami ako Cilium, Contiv.

6. Kedy použiť čo?

Napokon v porovnaní zvyčajne očakávame jasný verdikt! Nie je však úplne spravodlivé vyhlásiť jednu technológiu za lepšiu ako druhú bez ohľadu na to. Ako sme videli, Kubernetes aj Mesos sú výkonné systémy a ponúka celkom konkurenčné funkcie.

Výkon je však dosť zásadným aspektom. Klaster Kubernetes sa môže škálovať na 5 000 uzlov, zatiaľ čo je známe, že Marathon v klastri Mesos podporuje až 10 000 agentov. Vo väčšine praktických prípadov nebudeme riešiť také veľké zhluky.

Nakoniec sa scvrkávame na flexibilitu a typy pracovných záťaží, ktoré máme. Ak začíname odznova a plánujeme používať iba kontajnerové pracovné záťaže, Kubernetes môže ponúknuť rýchlejšie riešenie. Ak však máme existujúce pracovné zaťaženia, ktoré sú kombináciou kontajnerov a iných kontajnerov, môže byť Mesos s Marathon lepšou voľbou.

7. Ďalšie alternatívy

Kubernetes a Apache Mesos sú dosť výkonné, ale nie sú to jediné systémy v tomto priestore. Existuje pomerne veľa sľubných alternatív. Aj keď sa nebudeme podrobne venovať ich podrobnostiam, poďme rýchlo uviesť niekoľko z nich:

  • Docker Swarm: Docker Swarm je nástroj na vytváranie klastrov a plánovanie open-source pre kontajnery Docker. Dodáva sa s nástrojom príkazového riadku na správu klastra hostiteľov Dockeru. Na rozdiel od Kubernetes a Mesos je obmedzený na Dockerove kontajnery.
  • Nomad: Nomad je flexibilný orchestrátor pracovnej záťaže od HashiCorp na správu akejkoľvek kontajnerovej alebo nekontejnerovej aplikácie. Nomad umožňuje deklaratívnu infraštruktúru ako kód na nasadenie aplikácií, ako je kontajner Docker.
  • OpenShift: OpenShift je kontajnerová plošina od Red Hat, organizované a spravované Kubernetesom pod ním. OpenShift ponúka mnoho ďalších funkcií okrem toho, čo poskytuje Kubernetes, ako je napríklad integrovaný register obrázkov, vytváranie zdrojov od obrazov, natívne sieťové riešenie.

8. Záver

Ak to zhrnieme, v tomto tutoriáli sme diskutovali o kontajneroch a systémoch orchestrácie kontajnerov. Krátko sme prešli dvoma najpoužívanejšími systémami orchestrácie kontajnerov, Kubernetes a Apache Mesos. Tieto systémy sme tiež porovnali na základe niekoľkých funkcií. Nakoniec sme videli niektoré ďalšie alternatívy v tomto priestore.

Pred uzavretím musíme pochopiť, že účelom takéhoto porovnania je poskytnúť údaje a fakty. To v žiadnom prípade neznamená, že je niekto lepší ako ostatní, a to zvyčajne závisí od prípadu použitia. Musíme teda použiť kontext nášho problému pri určovaní najlepšieho riešenia pre nás.


$config[zx-auto] not found$config[zx-overlay] not found