Mesos protiv Kubernetesa

1. Pregled

U ovom ćemo uputstvu razumjeti osnovnu potrebu za sustavom orkestracije spremnika.

Procijenit ćemo željenu karakteristiku takvog sustava. Iz toga ćemo pokušati usporediti dva najpopularnija sustava za orkestraciju spremnika koji se danas koriste, Apache Mesos i Kubernetes.

2. Orkestracija kontejnera

Prije nego što počnemo uspoređivati ​​Mesos i Kubernetes, provedimo neko vrijeme u razumijevanju što su kontejneri i zašto nam je nakon svega potrebna orkestracija kontejnera.

2.1. Spremnici

Acontainer je standardizirana jedinica softvera koja pakira kôd i sve njegove potrebne ovisnosti.

Stoga pruža neovisnost o platformi i operativnu jednostavnost. Docker je jedna od najpopularnijih kontejnerskih platformi u uporabi.

Docker koristi Linux kernel značajke poput CGroups i prostora imena za pružanje izolacije različitih procesa. Stoga više spremnika može raditi samostalno i sigurno.

Stvaranje slika dockera prilično je trivijalno, potreban nam je samo Dockerfile:

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

Dakle, ovih nekoliko redaka dovoljno je dobro da stvorite Dockerovu sliku Spring Boot aplikacije pomoću Docker CLI:

docker build -t hello_world.

2.2. Orkestracija kontejnera

Dakle, vidjeli smo kako spremnici mogu implementaciju aplikacije učiniti pouzdanom i ponovljivom. Ali zašto nam treba orkestracija kontejnera?

Sada, dok imamo nekoliko spremnika za upravljanje, dobro nam je Docker CLI. Možemo automatizirati i neke jednostavne poslove. Ali što se događa kad moramo upravljati stotinama spremnika?

Na primjer, razmislite o arhitekturi s nekoliko mikroservisa, a svi s različitim zahtjevima skalabilnosti i dostupnosti.

Slijedom toga, stvari mogu brzo izmaći kontroli i tu se uviđaju prednosti sustava orkestracije spremnika. Asustav orkestracije spremnika klaster strojeva s aplikacijom s više spremnika tretira kao jedan entitet implementacije. Pruža automatizaciju od početne implementacije, raspoređivanja, ažuriranja drugih značajki poput nadzora, skaliranja i preusmjeravanja.

3. Kratki pregled Mesosa

Apache Mesos je menadžer klastera otvorenog koda razvijen izvorno u UC Berkeley. Pruža aplikacijama API-je za upravljanje resursima i raspoređivanje kroz klaster. Mesos nam daje fleksibilnost da distribuiramo rad u kontejnerskim i nekontejneriranim radnim opterećenjima.

3.1. Arhitektura

Mesos arhitektura se sastoji od Mesos Master, Mesos Agent i Application Frameworks:

Razumijemo ovdje komponente arhitekture:

  • Okviri: Ovi su stvarne aplikacije koje zahtijevaju distribuirano izvršavanje zadataka ili radnog opterećenja. Tipični primjeri su Hadoop ili Oluja. Okviri u Mesosu sastoje se od dvije primarne komponente:
    • Planer: Ovo je odgovoran za registraciju u glavnom čvoru takav da gospodar može početi nuditi resurse
    • Izvršitelj: Ovo je proces koji se pokreće na čvorovima agenta za pokretanje zadataka okvira
  • Mesos agenti: Ovi su odgovoran za stvarno izvršavanje zadataka. Svaki agent glavom objavljuje svoje dostupne resurse poput CPU-a i memorije. Po primanju zadataka od master-a dodijeljuju potrebna sredstva izvršitelju okvira.
  • Učitelj Mesos: Ovo je odgovoran za raspoređivanje zadataka primljenih iz okvira na jednom od dostupnih čvorova agenata. Master daje resurse za Frameworks. Planer Framework-a može odabrati pokretanje zadataka na ovim dostupnim resursima.

3.2. Maraton

Kao što smo upravo vidjeli, Mesos je prilično fleksibilan i omogućava okvirima za planiranje i izvršavanje zadataka putem dobro definiranih API-ja. Međutim, nije prikladno izravno implementirati ove primitive, posebno kada želimo zakazati prilagođene aplikacije. Na primjer, orkestriranje aplikacija pakiranih kao spremnici.

Tu nam može pomoći okvir poput Marathona. Maraton je okvir za orkestraciju spremnika koji radi na Mesosu. S tim u vezi, Marathon djeluje kao okvir za klaster Mesos. Marathon pruža nekoliko pogodnosti koje obično očekujemo od platforme za orkestraciju, poput otkrivanja usluga, uravnoteženja opterećenja, mjernih podataka i API-ja za upravljanje spremnikom.

Maraton dugotrajnu uslugu tretira kao aplikaciju a instanca aplikacije kao zadatak. Tipični scenarij može imati više aplikacija sa ovisnostima koje tvore ono što se naziva aplikacijskim grupama.

3.3. Primjer

Pa, pogledajmo kako možemo koristiti Marathon za postavljanje naše jednostavne Dockerove slike koju smo stvorili ranije. Imajte na umu da instaliranje Mesos klastera može biti malo uključeno i stoga možemo koristiti jednostavnije rješenje poput Mesos Mini. Mesos Mini omogućuje nam okretanje lokalnog Mesos klastera u Docker okruženju. Uključuje Mesos Master, jednog Mesos Agenta i Marathon.

Jednom kad Mesos klaster s Marathonom bude pokrenut i pokrenut, možemo spremiti svoj spremnik kao dugotrajnu uslugu aplikacija. Sve što nam treba mala definicija JSON aplikacije:

# hello-marathon.json {"id": "marathon-demo-application", "cpus": 1, "mem": 128, "disk": 0, "instance": 1, "container": {"vrsta ":" DOCKER "," docker ": {" slika ":" hello_world: najnovije "," portMappings ": [{" containerPort ": 9001," hostPort ": 0}]}}," mreže ": [{" način rada: "domaćin"}]}

Shvatimo što se točno ovdje događa:

  • Dali smo ID za našu prijavu
  • Zatim smo definirali zahtjeve za resursima za našu aplikaciju
  • Također smo definirali koliko instanci želimo pokrenuti
  • Zatim smo naveli detalje spremnika iz kojih ćemo pokrenuti aplikaciju
  • Napokon, definirali smo mrežni način kako bismo mogli pristupiti aplikaciji

Ovu aplikaciju možemo pokrenuti pomoću REST API-ja koje pruža Marathon:

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

4. Kratki pregled Kubernetesa

Kubernetes je sustav orkestracije spremnika s otvorenim kodom koji je u početku razvio Google. Sada je dio Cloud Native Computing Foundation (CNCF). Pruža platformu za automatizaciju implementacije, skaliranja i rada spremnika aplikacija na klasteru hostova.

4.1. Arhitektura

Arhitektura Kubernetes sastoji se od Kubernetes Master i Kubernetes čvorova:

Prođimo kroz glavne dijelove ove arhitekture na visokoj razini:

  • Majstor Kubernetes: The master odgovoran je za održavanje željenog stanja klastera. Upravlja svim čvorovima u klasteru. Kao što vidimo, master je zbirka tri procesa:
    • kube-apiserver: Ovo je usluga koja upravlja cijelim klasterom, uključujući obradu REST operacija, provjeru valjanosti i ažuriranje Kubernetes objekata, obavljanje provjere autentičnosti i autorizacije
    • kube-kontrolor-menadžer: Ovo je demon koji ugrađuje krug upravljanja jezgrom isporučen s Kubernetesom, čineći potrebne promjene kako bi se trenutno stanje uskladilo sa željenim stanjem klastera
    • kube-planer: Ova usluga pazi na neplanirane mahune i veže ih za čvorove ovisno o zatraženim resursima i ostalim ograničenjima
  • Kubernetesovi čvorovi: Čvorovi u Kubernetesovom klasteru strojevi su koji pokreću naše spremnike. Svaki čvor sadrži potrebne usluge za pokretanje spremnika:
    • kubelet: Ovo je primarni agent čvora koji osigurava da spremnici opisani u PodSpecs-u pružaju kube-apiserver su trčeći i zdravi
    • kube-proxy: Ovo je mrežni proxy pokrenut na svakom čvoru i izvodi jednostavno TCP, UDP, SCTP prosljeđivanje toka ili kružno prosljeđivanje kroz skup pozadinskih mreža
    • vrijeme izvođenja spremnika: Ovo je vrijeme izvođenja gdje se izvodi spremnik unutar mahuna, postoji nekoliko mogućih vremena rada spremnika za Kubernetes, uključujući najčešće korišteno, Docker runtime

4.2. Kubernetesovi objekti

U posljednjem smo odjeljku vidjeli nekoliko Kubernetes objekata koji su trajni entiteti u Kubernetesovom sustavu. Oni odražavaju stanje nakupine u bilo kojem trenutku vremena.

Razmotrimo neke od najčešće korištenih Kubernetes objekata:

  • Mahune: Mahuna je osnovna izvršna jedinica u Kubernetesu i može se sastojati od jednog ili više spremnika, spremnici unutar Pod su raspoređeni na istom hostu
  • Raspoređivanje: Raspoređivanje je preporučeni način raspoređivanja mahuna u Kubernetesu, pruža značajke poput kontinuiranog usklađivanja trenutnog stanja mahuna sa željenim stanjem
  • Usluge: Usluge u Kubernetesu pružaju apstraktan način izlaganja skupine mahuna, gdje se grupiranje temelji na selektorima koji ciljaju oznake mahuna

Postoji nekoliko drugih Kubernetes objekata koji služe u svrhu učinkovitog pokretanja spremnika na distribuiran način.

4.3. Primjer

Dakle, sada možemo pokušati lansirati naš Docker spremnik u klaster Kubernetes. Kubernetes nudi Minikube, alat koji pokreće Kubernetes klaster s jednim čvorom na virtualnom stroju. Također bi nam trebao kubectl, sučelje naredbenog retka Kubernetes za rad s klasterom Kubernetes.

Nakon što instaliramo kubectl i Minikube, možemo spremiti naš spremnik na Kubernetes klaster s jednim čvorom unutar Minikubea. Moramo definirati osnovne Kubernetes objekte u YAML datoteci:

# hello-kubernetes.yaml apiVersion: apps / v1 vrsta: Metapodaci implementacije: ime: hello-world spec: replike: 1 predložak: metapodaci: oznake: app: hello-world spec: kontejneri: - ime: hello-world image: hello -world: najnoviji portovi: - containerPort: 9001 --- apiVersion: v1 vrsta: Metapodaci usluge: ime: hello-world-service spec: selector: app: hello-world type: LoadBalancer ports: - port: 9001 targetPort: 9001

Detaljna analiza ove datoteke definicije ovdje nije moguća, ali prođimo kroz najvažnije dijelove:

  • Definirali smo a Raspoređivanje s oznakama u biraču
  • Definiramo broj replika potrebnih za ovu implementaciju
  • Također, pružili smo detalje slike spremnika kao predložak za implementaciju
  • Također smo definirali a Servis s odgovarajućim selektorom
  • Prirodu usluge definirali smo kao LoadBalancer

Konačno, možemo rasporediti spremnik i stvoriti sve definirane Kubernetes objekte putem kubectl:

kubectl primijeniti -f yaml / hello-kubernetes.yaml

5. Mesos protiv Kubernetesa

Sada smo prošli kroz dovoljno konteksta i izvršili smo osnovnu implementaciju na Marathonu i Kubernetesu. Možemo pokušati razumjeti gdje stoje u usporedbi jedni s drugima.

Ipak, samo upozorenje, to je nije posve pošteno uspoređivati ​​Kubernetesa s Mesosom izravno. Većinu značajki orkestracije spremnika koje tražimo pruža jedan od Mesos-ovih okvira poput Marathona. Stoga, da bi se stvari održale u pravoj perspektivi, pokušat ćemo usporediti Kubernetesa s Marathonom a ne izravno Mesos.

Usporedit ćemo ove sustave orkestracije na temelju nekih željenih svojstava takvog sustava.

5.1. Podržana opterećenja

Mesos je dizajniran da nositi se s različitim vrstama radnih opterećenja koji mogu biti kontejnerirani ili čak nekontejnerirani. Ovisi o okviru koji koristimo. Kao što smo vidjeli, prilično je jednostavno podržati kontejnerizirana radna opterećenja u Mesosu koristeći okvir poput Marathona.

Kubernetes, s druge strane, radi isključivo s radnim opterećenjem u kontejneru. Najšire ga koristimo s Docker spremnicima, ali ima podršku za druga vremena izvođenja spremnika poput Rkt. U budućnosti će Kubernetes možda podržavati više vrsta radnih opterećenja.

5.2. Podrška za skalabilnost

Marathon podržava skaliranje kroz definiciju aplikacije ili korisničko sučelje. Autoscaling je također podržan u Marathonu. Također možemo skalirati aplikacijske grupe koje automatski skaliraju sve ovisnosti.

Kao što smo ranije vidjeli, Pod je temeljna izvršna jedinica u Kubernetesu. Podovi se mogu skalirati ako njima upravlja Deployment, to je razlog što se mahune uvijek definiraju kao raspoređivanje. Skaliranje može biti ručno ili automatizirano.

5.3. Rukovanje velikom dostupnošću

Primjeri aplikacija u Marathonu su distribuirana po Mesos agentima pružajući visoku dostupnost. Mesos klaster se obično sastoji od više agenata. Uz to, ZooKeeper omogućuje visoku dostupnost klastera Mesos kroz kvorum i izbore čelnika.

Slično tome, mahune u Kubernetesu jesu replicirano na više čvorova pružajući visoku dostupnost. Obično se Kubernetesov klaster sastoji od više radničkih čvorova. Štoviše, klaster također može imati više master-a. Stoga je Kubernetes klaster sposoban pružiti visoku dostupnost spremnicima.

5.4. Otkrivanje usluga i uravnoteženje opterećenja

Mesos-DNS može pružiti otkrivanje usluge i osnovno uravnoteženje opterećenja za aplikacije. Mesos-DNS generira SRV zapis za svaki Mesos zadatak i prevodi ih na IP adresu i priključak stroja koji izvodi zadatak. Za aplikacije Marathon, također možemo koristiti Marathon-lb za ​​pružanje otkrivanja na bazi luka pomoću HAProxy-a.

Implementacija u Kubernetesu dinamički stvara i uništava mahune. Stoga općenito izlažemo mahune u Kubernetesu Usluga koja pruža otkrivanje usluge. Služba u Kubernetesu djeluje kao otpremnik mahuna, a time pruža i uravnoteženje tereta.

5.5 Izvođenje nadogradnji i vraćanje

Promjene definicija aplikacija u Marathonu tretiraju se kao postavljanje. Raspoređivanje podržava pokretanje, zaustavljanje, nadogradnju ili opseg aplikacija. Maraton također podržava pokretanje kotrljanja za razmještanje novijih verzija aplikacija. Međutim, vraćanje unatrag ravno je naprijed i obično zahtijeva primjenu ažurirane definicije.

Raspoređivanje u Kubernetes podržava nadogradnju kao i vraćanje unazad. Možemo pružiti strategiju za primjenu prilikom uspoređivanja starih mahuna s novim. Tipično strategije su Ponovno stvaranje ili Pokretno ažuriranje. Povijest uvođenja implementacije održava se prema zadanim postavkama u Kubernetesu, što čini trivijalnim vraćanje na prethodnu reviziju.

5.6. Sječa i nadzor

Mesos ima dijagnostički program koji skenira sve komponente klastera i čini dostupnim podatke koji se odnose na zdravstvenu i druge metrike. Podaci se mogu upitati i prikupiti putem dostupnih API-ja. Mnogo tih podataka možemo prikupiti pomoću vanjskog alata poput Prometeja.

Kubernetes objaviti detaljne informacije povezane s različitim objektima kao metrike resursa ili cjelokupne cjevovode mjernih podataka. Tipična praksa je postavljanje vanjskog alata poput ELK ili Prometheus + Grafana na klaster Kubernetes. Takvi alati mogu unijeti mjerne podatke klastera i prikazati ih na mnogo jednostavniji način.

5.7. Skladištenje

Mesos je postojani lokalni volumeni za aplikacije sa statusom. Trajne sveske možemo stvoriti samo iz rezerviranih resursa. Također može podržati vanjsku pohranu s određenim ograničenjima. Mesos ima eksperimentalnu podršku za Container Storage Interface (CSI), uobičajeni skup API-ja između dobavljača skladišta i platforme za orkestraciju spremnika.

Kubernetes nudi više vrsta trajnog volumena za spremnike sa statusom. To uključuje pohranu poput iSCSI, NFS. Štoviše, podržava i vanjsku pohranu poput AWS-a, GCP-a. Objekt Volume u Kubernetesu podržava ovaj koncept i dolazi u raznim vrstama, uključujući CSI.

5.8. Umrežavanje

Vrijeme izvođenja kontejnera u Mesosu dvije vrste mrežne podrške, IP-po-spremniku i mapiranje mrežnih priključaka. Mesos definira zajedničko sučelje za specificiranje i dohvaćanje mrežnih podataka za spremnik. Maratonske aplikacije mogu definirati mrežu u načinu hosta ili mostu.

Umrežavanje u Kubernetesu svakoj jedinici dodjeljuje jedinstveni IP. To negira potrebu mapiranja kontejnerskih luka na luku domaćina. Dalje definira kako ove mahune mogu međusobno razgovarati preko čvorova. To u Kubernetes implementiraju mrežni dodaci poput Cilium, Contiv.

6. Kada koristiti što?

Napokon, u usporedbi s tim, obično očekujemo jasnu presudu! Međutim, nije posve pošteno proglašavati jednu tehnologiju boljom od druge, bez obzira na to. Kao što smo vidjeli, i Kubernetes i Mesos moćni su sustavi i nudi prilično konkurentne značajke.

Izvedba je, međutim, presudan aspekt. Klaster Kubernetes može se skalirati na 5000 čvorova, dok je poznato da Marathon na Mesos klasteru podržava do 10.000 agenata. U većini praktičnih slučajeva nećemo imati posla s tako velikim nakupinama.

Napokon, to se svodi na fleksibilnost i vrste radnih opterećenja koja imamo. Ako krenemo iznova i planiramo koristiti samo radna opterećenja u kontejneru, Kubernetes može ponuditi brže rješenje. Međutim, ako imamo postojeće opterećenje, koje je kombinacija kontejnera i nekontejnera, Mesos s Marathonom može biti bolji izbor.

7. Ostale alternative

Kubernetes i Apache Mesos prilično su moćni, ali nisu jedini sustavi na ovom prostoru. Dostupno nam je nekoliko obećavajućih alternativa. Iako nećemo ulaziti u njihove detalje, nabrojimo brzo neke od njih:

  • Docker Roj: Docker Roj je alat za klasteriranje i raspoređivanje otvorenog koda za Docker spremnike. Dolazi s uslužnim programom naredbenog retka za upravljanje klasterom Dockerovih hostova. Ograničen je na Dockerove kontejnere, za razliku od Kubernetesa i Mesosa.
  • Nomad: Nomad jest fleksibilni orkestrator radnog opterećenja iz tvrtke HashiCorp za upravljanje bilo kojom kontejnerskom ili nekontejneriranom aplikacijom. Nomad omogućuje deklarativnu infrastrukturu-kao-kôd za postavljanje aplikacija poput Docker spremnika.
  • OpenShift: OpenShift je kontejnerska platforma tvrtke Red Hat, dirigirao i vodio Kubernetes ispod. OpenShift nudi mnoge značajke povrh onoga što Kubernetes nudi, poput integriranog registra slika, izradu izvora do slike, nativno mrežno rješenje, da nabrojimo samo neke.

8. Zaključak

Da rezimiramo, u ovom uputstvu raspravljali smo o spremnicima i sustavima za orkestraciju spremnika. Kratko smo prošli dva najčešće korištena sustava za orkestraciju kontejnera, Kubernetes i Apache Mesos. Također smo usporedili ovaj sustav na temelju nekoliko značajki. Napokon smo vidjeli i neke druge alternative u ovom prostoru.

Prije zatvaranja moramo shvatiti da je svrha takve usporedbe pružanje podataka i činjenica. To ni na koji način ne može jednog proglasiti boljim od drugih, a to obično ovisi o slučaju upotrebe. Dakle, moramo primijeniti kontekst svog problema u određivanju najboljeg rješenja za nas.


Popularni Postovi

Najnoviji postovi

Copyright hr.streamalism.org 2024
$config[zx-auto] not found$config[zx-overlay] not found