streamalism.org

1. Áttekintés

Ebben az oktatóanyagban megértjük a konténeres hangszerelési rendszer alapvető szükségességét.

Értékelni fogjuk egy ilyen rendszer kívánt jellemzőit. Ebből megpróbáljuk összehasonlítani a manapság használt két legnépszerűbb konténeres hangszerelési rendszert, az Apache Mesos-t és a Kubernetes-t.

2. Konténeres hangszerelés

Mielőtt hozzákezdenénk a Mesos és a Kubernetes összehasonlításához, töltsünk el egy kis időt annak megértésével, hogy melyek is a konténerek, és miért is van szükség mégis a konténerek hangszerelésére.

2.1. Konténerek

AA container a szoftver szabványosított egysége, amely csomagolja a kódot és az összes szükséges függőséget.

Ennélfogva platformfüggetlenséget és egyszerű üzemeltetést biztosít. A Docker az egyik legnépszerűbb konténerplatform.

A Docker kihasználja a Linux kernelt olyan funkciók, mint a CGroups és a névterek az elkülönítés érdekében különböző folyamatok. Ezért több konténer függetlenül és biztonságosan futhat.

Docker képek készítése meglehetősen triviális, csak egy Docker fájlra van szükségünk:

AZ openjdk-ból: 8-jdk-alpine VOLUME / tmp COPY target / hello-world-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java", "- jar", "/ app.jar"] EXPOZÍCIÓ

Tehát ez a néhány sor elég jó ahhoz, hogy a Spring Boot alkalmazás Docker képét létrehozhassa a Docker CLI használatával:

docker build -t hello_world.

2.2. Konténeres hangszerelés

Láttuk tehát, hogy a konténerek hogyan tehetik megbízhatóvá és megismételhetővé az alkalmazás telepítését. De miért van szükségünk konténeres hangszerelésre?

Most, hogy néhány tárolót kezelnünk kell, jól vagyunk a Docker CLI-vel. Automatizálhatunk néhány egyszerű feladatot is. De mi történik, amikor több száz konténert kell kezelnünk?

Gondoljon például az architektúrára, amely több mikroszolgáltatással rendelkezik, amelyek mindegyike különálló skálázhatósági és elérhetőségi követelményekkel rendelkezik.

Következésképpen a dolgok gyorsan kikerülhetnek az irányítás alól, és itt megértik a konténeres hangszerelési rendszer előnyeit. AA tároló-hangszerelő rendszer egy több tárolót tartalmazó alkalmazással rendelkező gépfürtöt egyetlen telepítési entitásként kezel. Automatizálást biztosít a kezdeti telepítéstől, ütemezéstől, frissítésektől más funkciókig, például figyelés, méretezés és feladatátvétel.

3. Mesos rövid áttekintése

Apache Mesos az egy nyílt forráskódú klasztermenedzser, amelyet eredetileg az UC Berkeley-n fejlesztettek ki. Alkalmazásokat biztosít API-kkal az erőforrás-kezeléshez és ütemezéshez a fürtön keresztül. A Mesos rugalmasságot biztosít számunkra mind a konténeres, mind a nem konténeres munkaterhelés elosztott módon történő futtatásához.

3.1. Építészet

A Mesos architektúrája a Mesos Master, a Mesos Agent és az Alkalmazáskeretekből áll:

Értsük meg itt az építészet összetevőit:

• Keretek: Ezek az elosztott futtatást igénylő tényleges alkalmazások feladatok vagy terhelés. Tipikus példák a Hadoop vagy a Storm. A mezosi keretek két elsődleges összetevőből állnak:
  • Ütemező: Ez felelős a Master Node-nál történő regisztrációért hogy a mester elkezdhesse az erőforrások felajánlását
  • Végrehajtó: Ez az ügynök csomópontjain elindított folyamat hogy a keretrendszer feladatait futtassa
• Mesos ügynökök: Ezek felelős a feladatok tényleges lebonyolításáért. Minden ügynök közzéteszi az elérhető erőforrásait, például a CPU-t és a memóriát a master számára. A feladatok kézhezvételekor a mestertől kiosztják a szükséges erőforrásokat a keretrendszer végrehajtójának.
• Mesos Mester: Ez felelős a keretrendszerektől kapott feladatok ütemezéséért az egyik rendelkezésre álló ügynök csomóponton. A Master erőforrás-ajánlatokat tesz a keretrendszerhez. A Framework ütemezője választhatja a feladatok futtatását ezeken az elérhető erőforrásokon.

3.2. Maraton

Mint az imént láttuk, a Mesos meglehetősen rugalmas, és lehetővé teszi a keretrendszerek számára, hogy pontosan meghatározott API-k segítségével ütemezzék és hajthassák végre a feladatokat. Azonban nem kényelmes ezeket a primitíveket közvetlenül megvalósítani, különösen, ha egyedi alkalmazásokat akarunk ütemezni. Például konténerekként csomagolt alkalmazások hangszerelése.

Itt segíthet nekünk egy olyan keret, mint a Marathon. Maraton egy konténeres hangszerelési keretrendszer, amely Mesoson fut. Ebben a tekintetben a Marathon a Mesos klaszter keretrendszere. A Marathon számos előnnyel jár, amelyeket általában elvárunk egy hangszerelési platformtól, például a szolgáltatás felfedezése, a terheléselosztás, a mutatók és a tárolókezelés API-k.

Maraton a régóta futó szolgáltatást alkalmazásként kezeli és egy alkalmazáspéldány feladatként. Egy tipikus forgatókönyvnek több olyan alkalmazása is lehet, amelyek függőségekkel alkotják az úgynevezett alkalmazáscsoportokat.

3.3. Példa

Lássuk, hogyan használhatjuk a Marathont a korábban létrehozott egyszerű Docker képünk telepítéséhez. Ne feledje, hogy a Mesos-fürt telepítése kevéssé lehet érintett, ezért használhatunk olyan egyszerűbb megoldást, mint a Mesos Mini. A Mesos Mini lehetővé teszi számunkra, hogy egy helyi Mesos-fürtöt felpörgetjünk egy Docker-környezetben. Magában foglalja a Mesos Master-t, a Mesos Agent egyetlen ügynökét és a Marathon-t.

Miután a Mesos klasztert elindítottuk és elindítottuk a Maratonnal, telepíthetjük tárolónkat egy régóta futó alkalmazásszolgáltatásként. Mindössze egy kis JSON alkalmazás-meghatározásra van szükségünk:

# hello-marathon.json {"id": "marathon-demo-application", "cpus": 1, "mem": 128, "disk": 0, "példányok": 1, "container": {"type ":" DOCKER "," docker ": {" image ":" hello_world: legújabb "," portMappings ": [{" containerPort ": 9001," hostPort ": 0}]}}," hálózatok ": [{" mode ":" host "}]}

Értsük meg, mi történik pontosan itt:

• Megadtuk az alkalmazásunk azonosítóját
• Ezután meghatároztuk az alkalmazás erőforrásigényét
• Meghatároztuk azt is, hogy hány példányt szeretnénk futtatni
• Ezután megadtuk a tároló adatait, amelyekből elindíthat egy alkalmazást
• Végül meghatároztuk a hálózati módot, hogy hozzáférhessünk az alkalmazáshoz

Ezt az alkalmazást a Marathon által biztosított REST API-k segítségével indíthatjuk el:

curl -X POST \ // localhost: 8080 / v2 / apps \ -d @ hello-marathon.json \ -H "Tartalom típusa: application / json"

4. A Kubernetes rövid áttekintése

Kubernetes az egy nyílt forráskódú konténeres hangszerelési rendszer, amelyet eredetileg a Google fejlesztett ki. Most a Cloud Native Computing Foundation (CNCF) része. Platformot kínál az alkalmazástárolók telepítésének, méretezésének és műveleteinek automatizálásához a gazdagépek fürtjén keresztül.

4.1. Építészet

A Kubernetes architektúra egy Kubernetes Master és Kubernetes csomópontokból áll:

Menjünk át ennek a magas szintű építészetnek a főbb részein:

• Kubernetes mester: A a master felelős a klaszter kívánt állapotának fenntartásáért. A fürt összes csomópontját kezeli. Mint láthatjuk, a mester három folyamat gyűjteménye:
  • kube-apiserver: Ez a teljes fürtöt kezelő szolgáltatás, beleértve a REST műveletek feldolgozását, a Kubernetes objektumok érvényesítését és frissítését, hitelesítés és hitelesítés végrehajtását
  • kube-controller-manager: Ez a démon, amely beágyazza a mag vezérlő hurokját a Kubernetesszel együtt szállítva, elvégezve a szükséges módosításokat, hogy az aktuális állapot és a fürt kívánt állapota megfeleljen
  • kube-ütemező: Ez a szolgáltatás figyeli az ütemezés nélküli hüvelyeket, és csomópontokhoz köti őket a kért erőforrásoktól és egyéb korlátoktól függően
• Kubernetes csomópontok: A Kubernetes-fürt csomópontjai azok a gépek, amelyek futtatják a tárolóinkat. Minden csomópont tartalmazza a tárolók futtatásához szükséges szolgáltatásokat:
  • kubelet: Ez az elsődleges csomópont-ügynök amely biztosítja, hogy a PodSpecs által leírt konténerek kube-apiserver futnak és egészségesek
  • kube-proxy: Ez az egyes csomópontokon futó hálózati proxy és egyszerű TCP, UDP, SCTP adatfolyam továbbítást vagy körkörös továbbítást hajt végre egy sor háttérprogramon keresztül
  • konténer futásideje: Ez az a futási idő, amikor a hüvely belsejében lévő konténer fut, számos lehetséges konténer futási idő létezik a Kubernetes számára, beleértve a legszélesebb körben használt Docker futási időt

4.2. Kubernetes objektumok

Az utolsó részben több Kubernetes objektumot láttunk, amelyek állandó entitások a Kubernetes rendszerben. Ezek tükrözik a klaszter állapotát az idő bármely pontján.

Beszéljünk néhány gyakran használt Kubernetes objektumról:

• Pods: Pod van végrehajtási alapegység Kubernetesben és egy vagy több konténerből állhatnak, a Pod belsejében lévő konténerek ugyanazon a gazdagépen vannak elhelyezve
• Telepítés: A telepítés az a hüvelyek Kubernetesben történő telepítésének ajánlott módja, olyan szolgáltatásokat nyújt, mint például a hüvelyek aktuális állapotának folyamatos egyeztetése a kívánt állapottal
• Szolgáltatások: Szolgáltatások Kubernetesben absztrakt módot nyújt a hüvelyek egy csoportjának leleplezésére, ahol a csoportosítás a pod címkéket célzó szelektorokon alapul

Számos más Kubernetes-objektum is hatékonyan szolgálja a konténerek elosztott módon történő futtatását.

4.3. Példa

Tehát most megpróbálhatjuk elindítani Docker konténerünket a Kubernetes fürtbe. A Kubernetes biztosítja a Minikube eszközt, amely egycsomópontú Kubernetes-fürtöt futtat egy virtuális gépen. Szükségünk lenne a kubectl-re, a Kubernetes parancssori felületre is, hogy a Kubernetes-fürttel működjünk.

A kubectl és a Minikube telepítése után telepíthetjük tárolónkat a Minikube egycsomópontos Kubernetes fürtjébe. Meg kell határoznunk az alapvető Kubernetes objektumokat egy YAML fájlban:

# hello-kubernetes.yaml apiVersion: apps / v1 kind: Deployment metadata: name: hello-world spec: replicas: 1 template: metadata: labels: app: hello-world spec: container: - name: hello-world image: hello -world: legújabb portok: - containerPort: 9001 --- apiVersion: v1 fajta: Szolgáltatás metaadatai: név: hello-world-service spec: választó: app: hello-world típus: LoadBalancer portok: - port: 9001 targetPort: 9001

A definíciós fájl részletes elemzése itt nem lehetséges, de nézzük át a legfontosabbakat:

• Meghatároztuk a Telepítés címkékkel a választóban
• Meghatározzuk a telepítéshez szükséges replikák számát
• Ezenkívül megadtuk a tároló képének részleteit is a sablonként a telepítéshez
• Meghatároztuk a Szolgáltatás megfelelő választóval
• A szolgáltatás jellegét úgy határoztuk meg Terhelés elosztó

Végül telepíthetjük a tárolót, és az összes meghatározott Kubernetes objektumot létrehozhatjuk a kubectl-en keresztül:

kubectl Apply -f yaml / hello-kubernetes.yaml

5. Mesos kontra Kubernetes

Most már eléggé átéltük a kontextust, és elvégeztük az alapvető telepítést a Maratonon és a Kubernetesen egyaránt. Megpróbálhatjuk megérteni, hogy hol állnak egymáshoz képest.

Csak egy figyelmeztetés nem teljesen igazságos Kubernetes és Mesos közvetlen összehasonlítása. A keresett konténeres hangszerelési funkciók nagy részét az egyik Mesos-keret biztosítja, például a Marathon. Ezért, hogy a dolgokat a megfelelő perspektívában tartsuk, megpróbáljuk összehasonlítani Kubernetes-t a Marathonnal és nem közvetlenül Mesos.

Összehasonlítjuk ezeket az hangszerelési rendszereket egy ilyen rendszer kívánt tulajdonságai alapján.

5.1. Támogatott munkaterhelések

Mesos célja az kezelni a különféle típusú terheléseket amelyek konténerbe vagy akár nem konténerbe is kerülhetnek. Az általunk használt kerettől függ. Mint láttuk, nagyon egyszerű támogatni a konténeres munkaterheléseket Mesosban egy olyan keretrendszer segítségével, mint a Marathon.

Kubernetes viszont kizárólag a konténeres munkaterheléssel működik. Legszélesebb körben a Docker konténerekkel használjuk, de támogatja az egyéb konténer futásokat, például az Rkt-t. A jövőben a Kubernetes többféle terhelést támogathat.

5.2. A méretezhetőség támogatása

A Marathon támogatja a méretezést az alkalmazásdefiníción vagy a felhasználói felületen keresztül. Az automatikus skálázást a Marathon is támogatja. Méretezhetünk alkalmazáscsoportokat is, amelyek automatikusan méretezik az összes függőséget.

Mint korábban láttuk, Pod a végrehajtás alapvető egysége Kubernetesben. A hüvelyek méretezhetők, ha a telepítés kezeli őket, ez az oka annak, hogy a podokat változatlanul telepítésként definiálják. A méretezés lehet manuális vagy automatizált.

5.3. Magas rendelkezésre állás kezelése

A Marathon alkalmazáspéldányai magas rendelkezésre állást biztosító Mesos-ügynökök között terjesztve. A Mesos-klaszter általában több ügynökből áll. Ezenkívül a ZooKeeper a kvórumon és a vezetőválasztáson keresztül magas szintű hozzáférést biztosít a Mesos klaszterhez.

Hasonlóképpen a Kubernetes hüvelyei is több csomóponton replikálva, magas rendelkezésre állást biztosítva. A Kubernetes-fürt általában több dolgozói csomópontból áll. Ezenkívül a klaszternek több mestere is lehet. Ezért a Kubernetes-fürt képes magas rendelkezésre állást biztosítani a konténerek számára.

5.4. Szolgáltatásfeltárás és terheléselosztás

A Mesos-DNS szolgáltatás feltárást és alapvető terheléselosztást biztosít alkalmazásokhoz. A Mesos-DNS minden Mesos-feladatra létrehoz egy SRV-rekordot, és lefordítja a feladatot futtató gép IP-címére és portjára. A Marathon alkalmazásokhoz a Marathon-lb-t is használhatjuk port alapú felfedezés biztosításához a HAProxy segítségével.

A Kubernetesben történő bevezetés dinamikusan hozza létre és pusztítja a hüvelyeket. Ezért általában a hüvelyeket tesszük ki Kubernetesben Szolgáltatás, amely szolgáltatás felfedezést nyújt. A Kubernetes szolgáltatása a hüvelyek diszpécserjeként működik, és így terheléselosztást is biztosít.

5.5 Frissítés és visszagörgetés

A Marathon alkalmazásdefinícióinak módosításait telepítésként kezelik. Telepítés támogatja az alkalmazások indítását, leállítását, frissítését vagy skáláját. Maraton támogatja a gördülő indításokat is az alkalmazások újabb verzióinak telepítéséhez. A visszagörgetés azonban ugyanolyan előrelépés, és általában egy frissített definíció telepítését igényli.

Bevezetés A Kubernetes támogatja a frissítést és a visszagörgetést is. Biztosíthatjuk a bevezetés stratégiáját, miközben a régi hüvelyeket újakkal viszonozzuk. Tipikus stratégiák a Újrateremtés vagy a Frissített frissítés. A központi telepítés előzményeit alapértelmezés szerint a Kubernetes tartja fenn, ami elenyészővé teszi az előző verzióra való visszatérést.

5.6. Naplózás és figyelés

Mesosnak van egy diagnosztikai segédprogram, amely beolvassa a fürt összes elemét és elérhetővé teszi az egészséggel és egyéb mutatókkal kapcsolatos adatokat. Az adatok lekérdezhetők és összesíthetők a rendelkezésre álló API-k segítségével. Ezen adatok nagy részét egy olyan külső eszköz segítségével gyűjthetjük, mint a Prometheus.

Kubernetes tegye közzé a különböző objektumokkal kapcsolatos részletes információkat erőforrás-mérőszámként vagy teljes mérőszám-csővezetékként. Tipikus gyakorlat egy olyan külső eszköz telepítése, mint az ELK vagy a Prometheus + Grafana a Kubernetes-fürtön. Az ilyen eszközök beolvashatják a fürtmutatókat, és sokkal felhasználóbarátabban jeleníthetik meg azokat.

5.7. Tárolás

Mesosnak van állandó helyi kötetek az állapotfelmérő alkalmazásokhoz. Csak tartós köteteket hozhatunk létre a fenntartott forrásokból. Bizonyos korlátozásokkal támogatja a külső tárolást is. A Mesos kísérleti támogatást nyújt a Container Storage Interface (CSI) számára, amely egy közös API-készlet a tárhely-gyártók és a tároló-hangszerelési platform között.

Kubernetes ajánlatok többféle tartós térfogat állapotos tárolókhoz. Ez magában foglalja az iSCSI és az NFS tárolását. Sőt, támogatja az olyan külső tárolókat is, mint az AWS, a GCP. A Kubernetesben található Volume objektum támogatja ezt a koncepciót, és különféle típusúak lehetnek, beleértve a CSI-t is.

5.8. Hálózatépítés

Konténeres futási idő Mesosban kínál kétféle hálózati támogatás, IP-tartályonként és hálózati-port-leképezés. Mesos meghatároz egy közös felületet a tároló hálózati információinak megadásához és lekéréséhez. A maratoni alkalmazások meghatározhatják a hálózatot gazda módban vagy híd módban.

Hálózatépítés Kubernetesben minden egyes podhoz egyedi IP-t rendel. Ez semmissé teszi a konténer portok feltérképezésének szükségességét a gazdagép portjára. Továbbá meghatározza, hogy ezek a hüvelyek miként beszélhetnek egymással a csomópontokon keresztül. Ezt a Kubernetesben olyan hálózati bővítmények valósítják meg, mint a Cilium, a Contiv.

6. Mikor kell használni?

Végül ehhez képest általában egyértelmű ítéletet várunk! Mindazonáltal nem teljesen igazságos az egyik technológiát a másiknál ​​jobbnak nyilvánítani. Mint láttuk, a Kubernetes és a Mesos egyaránt erős rendszerek és meglehetősen versengő funkciókat kínál.

A teljesítmény azonban meglehetősen döntő szempont. Egy Kubernetes-fürt 5000 csomópontra képes méretezni, miközben a Mesos-fürtön a Marathon akár 10 000 ügynököt is támogat. A legtöbb gyakorlati esetben nem fogunk ekkora klaszterekkel foglalkozni.

Végül ez a rugalmasság és a megterhelés típusa. Ha újrakezdjük és csak konténeres munkaterheléseket tervezünk használni, a Kubernetes gyorsabb megoldást tud ajánlani. Ha azonban meglévő munkaterhelésünk van, amelyek a konténerek és a nem konténerek keverékét jelentik, a Mesos és a Marathon együttes jobb választás lehet.

7. Egyéb alternatívák

A Kubernetes és az Apache Mesos meglehetősen erősek, de nem ők az egyetlen rendszerek ezen a téren. Számos ígéretes alternatíva áll rendelkezésünkre. Bár nem térünk ki a részletekre, soroljunk fel néhányat közülük gyorsan:

• Docker raj: Docker raj az nyílt forráskódú fürtözési és ütemezési eszköz a Docker-tárolókhoz. Parancssori segédprogrammal érkezik a Docker-állomások fürtjének kezeléséhez. A Docker konténerekre korlátozódik, ellentétben a Kubernetes-sel és a Mesos-szal.
• Nomád: Nomád az a HashiCorp rugalmas munkaterhelésű hangszerelője bármilyen konténeres vagy nem konténeres alkalmazás kezeléséhez. A Nomad deklaratív infrastruktúra-kódként engedélyezi az olyan alkalmazások telepítését, mint a Docker konténer.
• OpenShift: Az OpenShift az egy konténer platform a Red Hat-től, alatta Kubernetes vezényli és irányítja. Az OpenShift számos funkcióval rendelkezik azon felül, amit a Kubernetes nyújt: integrált képregiszter, forrás-kép összeállítás, natív hálózati megoldás, hogy csak néhányat említsünk.

8. Következtetés

Összefoglalva, ebben az oktatóanyagban a tárolókat és a tároló hangszerelési rendszereket vitattuk meg. Röviden átnéztük a két legszélesebb körben használt konténeres hangszerelési rendszert, a Kuberneteset és az Apache Mesos-t. Ezeket a rendszereket több jellemző alapján is összehasonlítottuk. Végül láttunk néhány más alternatívát ezen a téren.

Zárás előtt meg kell értenünk, hogy egy ilyen összehasonlítás célja adatok és tények megadása. Ez semmiképpen sem jelenti azt, hogy valaki jobbnak nyilvánul, mint mások, és ez általában a használati esettől függ. Tehát a problémánk kontextusát kell alkalmaznunk a számunkra legjobb megoldás meghatározásában.