Azon vállalkozások életében, amelyek fő hajtóereje egy alkalmazás vagy egy informatikai rendszer, a skálázhatóság, a stabilitás és a megvalósítás gyorsasága hatalmas szerepet játszik. Emiatt egyre több vállalat fordul a konténerezés felé. A konténerezés az alkalmazáselemek (folyamatai, függőségei, könyvtárai, konfigurációs fájljai vagy helyi adatbázisai) dinamikusan kezelt tárolókba történő elhelyezéséről szól.
A konténerezésnek számos előnye van. Az egyik az áthelyezhetőség, ami azt jelenti, hogy az egyszer megírt rendszer különféle környezetekben futtatható. Ennek köszönhetően a fejlesztők új funkciók létrehozására fordíthatják az idejüket, ahelyett, hogy a rendszert az infrastruktúra követelményeihez igazítanák. Maga a megvalósítási folyamat is egyszerűbb, gyorsabb és biztonságosabb.
Egy ezer vagy millió konténerből álló, kiterjedt rendszer esetén azonban a kezeléshez szükségünk van egy alkalmazáskezelő (ang. ún. orchestration) platformra. Az „orchestration” lehetővé teszi az automatizálás, a csoportmenedzsment, a fejlett folyamatfigyelés, a változásszabályozás vagy -felderítés és a hibák automatikus javításának bevezetését.
A legnépszerűbb alkalmazáskezelő platformok közé tartozik a Kubernetes és a Docker Swarm. Az alábbiakban bemutatjuk a megoldások közötti fontos különbségeket, illetve azok előnyeit és hátrányait.
A Kubernetes, vagy röviden K8s egy nyílt forráskódú, konténer alapú alkalmazáskezelő szoftver. Támogatja az automatikus bevezetéseket, az alkalmazások skálázását, kezeli a konténereket és figyeli a folyamatokat és a változásokat. Segít a klaszterek (egymással együttműködő gépek csoportja) és node-ok (egy-egy gép a klaszteren belül) tömeges kezelésében, így lerövidíti a folyamatot, amellyel az alkalmazást az infrastruktúrához igazítjuk, és leegyszerűsíti a változások bevezetését és új elemek hozzáadását a rendszerhez.
A Kubernetes platformot a Google fejlesztette ki 20 évvel ezelőtt azzal a céllal, hogy támogassa a cég éles üzemét, heti milliárd konténer elindításával. 2014-ben a projektet átadták a Cloud Native Computing Foundationnek (CNCF; a Linux Foundation része), a program licencét pedig Apache 2.0-ra változtatták. Ettől kezdve a platformot a CNCF támogatja, és folyamatosan fejleszti az azt használó közösség segítségével.
A Kubernetes elérhető a Google Cloud Platformon mint Kubernetes as a Service (Google Kubernetes Engine szolgáltatás – GKE).
További információt találhatsz a K8s-ről az alábbi cikkben “Kubernetes – mi ez, és hogyan kezdjük el használni?”.
A Docker Swarm a Kuberneteshez hasonlóan egy konténeres alkalmazáskezelő eszköz a legkülönbözőbb infrastrukturális környezetek számára. Ez egy nyílt forráskódú platform, amelynek forráskódja az Apache 2.0 licenc alatt érhető el. A Swarmot a gyártó (Docker) biztosítja és támogatja, valamint az azt használó közösség segítségével is fejlesztik.
A Docker Swarm az egyes elemek és teljes klaszterek (fizikai vagy virtuális gépek csoportjai) kezelésére szolgál a Docker Engine használatával. Így megkönnyíti az alkalmazás kezelésének folyamatát, felgyorsítja az új bevezetéseket, és sok DevOps-tevékenységet kezel a fejlesztők helyett, például a szoftvert az adott infrastruktúra követelményeihez igazítja. Hibátlanul működik minden olyan alkalmazással, amely a Dockert használja a konténerezéshez.
Kubernetes:
Az alkalmazás telepíthető és elindítható a podok, szolgáltatások (services) vagy mikroszolgáltatások (microservice) kombinációjának és deployment (az alkalmazás életciklusát kezelő megvalósítási objektum) segítségével.
Docker Swarm:
Az alkalmazások telepíthetők szolgáltatásként (services) vagy mikroszolgáltatásként (microservices) a klaszterekben. A YAML fájlok lehetővé teszik több konténer definiálását. Az alkalmazást a Docker Compose segítségével is telepíthető.
Kubernetes:
A Kubernetes támogatja az alkalmazások magas rendelkezésre állását. A telepítés lehetővé teszi podok (összekapcsolt konténerek csoportjai) telepítését nodok (a klaszterben lévő gépek) között a magas rendelkezésre állás biztosítása érdekében, még hiba esetén is. A load balancinggal (terheléselosztó funkcióval) rendelkező webhelyek a nem megfelelően működő podokat kiszűrik, és eltávolítják őket.
Docker Swarm:
A Docker Swarm is magas elérhetőségre törekszik. A szolgáltatások node-okban replikálhatók, és a fő node (swarm manager) felelős a teljes klaszterért, és ez kezeli az erőforrások elosztását az elemei között.
Kubernetes:
A Kubernetes beépített load balancing (a gépek közötti terheléselosztási technika) technikával rendelkezik, amely kézi konfigurálást és aktiválást igényel. A podokat szolgáltatásként definiálják, és load-balancerként használhatók egy klaszterben. A load balancinghoz ingress vezérlőt használnak – egy API objektumot, amely kívülről kezeli a klaszterhez való hozzáférést, például HTTP és HTTPS protokollok segítségével.
Docker Swarm:
A Swarm egy olyan DNS-összetevővel rendelkezik, amely a szolgáltatásoknak küldött kéréseket kezeli. A szolgáltatások a felhasználó által megadott portokon futhatnak, vagy automatikusan hozzárendelhetők.
Kubernetes:
Az alkalmazások Kubernetes deploymenttel történő kezelése kiterjed az alkalmazás frissítésének módjára. A deployment legfőbb előnye, hogy a rendelkezésre álló stratégiákon belül kiszámítható módon elindíthatja és leállíthatja a podokat: rolling-update (a meglévő podok cseréje) és recreate (a meglévő podok eltávolítása az új létrehozása előtt). Rolling update esetén a megvalósítás menete és hatása módosítható a maxUnavailable (lehetővé teszi a nem elérhető podok számának korlátozását) és a maxSurge (meghatározza az újonnan létrehozott alhálózatok számának korlátját) opcióval.
Docker Swarm:
Alapértelmezés szerint a frissítési ütemezés egy-egy feladatot futtat. A Docker Swarm lehetővé teszi az egyidejű frissítések számának konfigurálását és annak megjelölését, hogy a frissítő programnak milyen feladatot kell elvégeznie hiba esetén (különben a program leállítja a frissítést). A Docker Swarm lehetővé teszi az ütemezett frissítések közötti időintervallumok konfigurálását.
Kubernetes:
Kétféle health checkkel rendelkezik liveness, amely ellenőrzi az alkalmazás reakciókészségét és a readiness-t, ami az alkalmazás készenlétét erősíti meg (az alkalmazás reszponzív, de pl. jelenleg olyan folyamatot hajt végre, amely felfüggeszti az azonnali válaszadás lehetőségét). A K8s rendelkezik egy „beépített” naplózási mechanizmussal, amely lehetővé teszi az adott podot alkotó tárolók közötti tevékenység figyelemmel kísérését.
Docker Swarm:
A health check csak a szolgáltatásokra korlátozódik. Ha a szolgáltatást támogató konténer nem indul el, akkor új konténert indít el. A felhasználó manuálisan beállíthatja az állapotellenőrzési funkciót a HEALTHCHECK utasítással.
Kubernetes:
A Kubernetes két API-val rendelkezik a tároláshoz: PersistentVolume (PV) és PersistentVolumeClaim (PVC). A PersistentVolume a klaszter memóriaeleme (a rendszergazda hozhatja létre, vagy dinamikusan is létrehozható a memóriaosztályokon keresztül). Az API rögzíti a tárhely megvalósításának részleteit, például az NFS-t, az iSCSI-t vagy egy felhőszolgáltató-specifikus tárolórendszert, például a PersistentDisk-et for Google Cloud Platformot. A PersistentVolumeClaim olyan megőrzési kérelmet tartalmaz, amelyet a felhasználó küldött ki. A PVC hasonló a podhoz; pod felhasználja a node erőforrásait, a PVC pedig PV erőforrásait. Speciális méreteket és hozzáférési módokat kérhet (pl. Egyszer telepíthetők, egyszer írhatók, vagy egyszerre többször is).
A Docker démon által egy node-on használt memóriaforrások módosítása ideiglenesen eltávolíthatja a node-ot a klaszterből.
Docker Swarm:
A Docker Engine és a Docker Swarm platform támogatja a kötetek konténerekbe helyezését. A protokollokat tartalmazó kötetek (pl. NFS, iSCSI) a node-okban konfigurálhatók. A beépülő modulok figyelembe veszik a különböző platformokat, beleértve az Azure-t, a Google Cloud Platformot, a NetAppot vagy Dell EMC-t.
Kubernetes:
A platform lapos hálózati modellel rendelkezik, amely lehetővé teszi a podok közötti kommunikációt. A hálózati házirendek meghatározzák, hogy az alállomások hogyan cserélnek információt egymással. A Kuberneteshez két CIDR-re van szükség (Classless Inter-Domain Routing): az egyik, ahonnan a podok IP-címeket fogadnak, a másik pedig a szolgáltatásokhoz.
Docker Swarm:
A Docker Swarm szolgáltatásban több állomás közötti hálózati kommunikáció kezelhető egy átfedő hálózat létrehozásával. Létrehozhat hídhálózatokat is, amelyek lehetővé teszik a kommunikációt a gazdagépen belül. A felhasználók átfedő hálózat létrehozásakor titkosíthatják a konténerben lévő adatforgalmat (data traffic).
Kubernetes:
A Kubernetes 1.18 verziója legfeljebb 5000 node-ot tartalmazó klasztereket támogat. Támogatja a következő konfigurációkat is:
A Kubernetes két SLO (Service Level Objectives) alapján nyújt skálázhatóságot:
Docker Swarm:
A Docker képes akár 30.000 konténer és 1000 node skálázására, amelyeket egy Swarm kezelő kezel (fő node).
Kubernetes vs. Docker Swarm – a platformok előnyei és hátrányai
A Kubernetes előnyei:
A Kubernetes hátrányai:
A Docker Swarm előnyei:
A Docker Swarm hátrányai:
Az eszköz kiválasztása a szervezet jellegétől és a fejlesztendő terméktől függ. Ha a fő érték a megvalósítás sebessége (különösen, ha a termék nem túl összetett és igényes), akkor érdemes a Docker Swarmhoz fordulni. Vitathatatlan előnyei a telepítés egyszerűsége, a tanulás sebessége és a Docker környezettel való kompatibilitás.
Ha azonban a fő érték a fejlődés stabilitása és kiszámíthatósága, akkor jobb a Kubernetes platformot választani. Különösen akkor, ha egy kiterjedt, több ezer vagy millió konténerből álló rendszerre van szükség. A platform képességeinek kiismeréséhez szükséges idő hosszabb, de a befektetett idő számos hasznos funkció és hozzáférés formájában térül meg, melyek segítségével a platformot a vállalkozás igényeihez igazíthatjuk.
Cookie | Duration | Description |
---|---|---|
pll_language | 1 year | Polylang sets this cookie to remember the language the user selects when returning to the website and get the language information when unavailable in another way. |
Cookie | Duration | Description |
---|---|---|
_ga | 1 year 1 month 4 days | Google Analytics sets this cookie to calculate visitor, session and campaign data and track site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognise unique visitors. |
_ga_* | 1 year 1 month 4 days | Google Analytics sets this cookie to store and count page views. |
_gat_gtag_UA_* | 1 minute | Google Analytics sets this cookie to store a unique user ID. |
_gid | 1 day | Google Analytics sets this cookie to store information on how visitors use a website while also creating an analytics report of the website's performance. Some of the collected data includes the number of visitors, their source, and the pages they visit anonymously. |
CONSENT | 2 years | YouTube sets this cookie via embedded YouTube videos and registers anonymous statistical data. |
Cookie | Duration | Description |
---|---|---|
test_cookie | 15 minutes | doubleclick.net sets this cookie to determine if the user's browser supports cookies. |
VISITOR_INFO1_LIVE | 5 months 27 days | YouTube sets this cookie to measure bandwidth, determining whether the user gets the new or old player interface. |
YSC | session | Youtube sets this cookie to track the views of embedded videos on Youtube pages. |
yt-remote-connected-devices | never | YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. |
yt-remote-device-id | never | YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. |
yt.innertube::nextId | never | YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. |
yt.innertube::requests | never | YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. |
Cookie | Duration | Description |
---|---|---|
Murloc7A6B62905CA54C13DCDD11A0962E47EC21BBA94193C61D5987195FF6B7CAB838 | 1 day | Description is currently not available. |
SiteMapId | session | Description is currently not available. |
SWLOCALE | 30 years | Description is currently not available. |
SWSESSIONID | session | Description is currently not available. |