🥇Kubernetes: open source a vendorossal szemben

Helló, a nevem Dmitrij Krasnov. Több mint öt éve foglalkozom Kubernetes klaszterek adminisztrálásával és összetett mikroszerviz architektúrák kialakításával. Az év elején elindítottuk a Kubernetes klaszterek kezelésére szolgáló szolgáltatást a Containerum alapjain. Használva az alkalmat, mesélek arról, hogy mi az a Kubernetes, és miben különbözik a gyártóval való integráció az open source megoldásoktól.

Először is, mi az Kubernetes. Ez egy rendszer a konténerek kezelésére nagy számú hoszton. A görögből egyébként "pilóta" vagy "kormányos" jelentéssel bír. Eredetileg a Google fejlesztette ki, majd technológiai hozzájárulásként átadták a Cloud Native Computing Foundation-nak, egy nemzetközi, nonprofit szervezetnek, amely a világ vezető fejlesztőit, végfelhasználóit és konténertechnológiai szolgáltatóit egyesíti.

Irányítani a sok konténert

Most nézzük meg, hogy mik is azok a konténerek. Ezek olyan alkalmazások, amelyek az összes környezetükkel rendelkeznek - főként a program működéséhez szükséges könyvtárakkal. Mindez archívumokba van csomagolva, és egy olyan képként jelenik meg, amely függetlenül az operációs rendszertől futtatható, tesztelhető és más céllal is felhasználható. De van egy probléma - a konténerek nagy számú hoszton történő kezelése nagyon nehéz. Éppen ezért hozták létre a Kubernetest.

A konténerképe egy alkalmazás plusz a függőségei. Az alkalmazás, a függőségei és az operációs rendszer fájlrendszerének képe különböző részein találhatóak a képen, az úgynevezett rétegekben. A rétegek újra felhasználhatók különböző konténerekhez. Például a cég összes alkalmazásához felhasználható a Ubuntu alaprész. A konténerek futtatásakor nincs szükség arra, hogy a hoszton sok hasonló alapréteget tároljunk. Ez lehetővé teszi a tárolás és a képek átadásának optimalizálását.

Amikor egy alkalmazást akarunk elindítani egy konténerből, a szükséges rétegek egymásra helyeződnek, és létrejön egy átfedő fájlrendszer. A tetejére egy írási réteg kerül, amely a konténer leállításakor eltávolításra kerül. Ez garantálja, hogy amikor a konténert elindítjuk, az alkalmazás mindig azonos környezetben működjön, amely nem változtatható meg. Ez biztosítja a környezet reprodukálhatóságát különböző gazda operációs rendszereken. Legyen szó Ubuntu-ról vagy CentOS-ról, a környezet mindig azonos marad. Ezen kívül a konténer a Linux kernelbe épített mechanizmusok által izolálva van a gazdától. A konténerben lévő alkalmazások nem látják a gazda fájljait, folyamatait és a szomszédos konténereket. Az alkalmazások gazda operációs rendszertől való izolációja további biztonsági réteget biztosít.

A konténerek gazda oldalán való kezelésére számos eszköz áll rendelkezésre. A legnépszerűbb ezek közül a Docker. Ez lehetővé teszi a konténerek teljes életciklusának kezelését. Azonban csak egy gazdán működik. Ha szükséges a konténerek kezelésére több gazdán, akkor a Docker az mérnökök életét pokollá teheti. Ezért hozták létre a Kubernetes-t.

A Kubernetes iránti kereslet éppen a lehetőségből fakad, hogy több gazdán csoportos konténereket egységes entitásokká irányítsunk. A rendszer népszerűsége lehetővé teszi a DevOps vagy Development Operations felépítését, ahol a Kubernetes a DevOps folyamatait indítja el.

1. ábra. A Kubernetes működésének elvi ábrázolása

Teljes automatizálás

A DevOps alapvetően a fejlesztési folyamat automatizálását jelenti. Durván fogalmazva, a fejlesztők kódot írnak, amely a tárolóba kerül. Ezután ez a kód automatikusan összegyűjthető egy konténerbe az összes könyvtárral, tesztelhető, és kiadható a következő szakaszba – Staging, majd azonnal a Production-ra.

A Kubernetes-szel a DevOps automatizálni tudja ezt a folyamatot, így az gyakorlatilag a fejlesztők közreműködése nélkül zajlik. Ennek köszönhetően jelentősen felgyorsul a buildelés, mivel a fejlesztőnek nem kell ezzel a saját számítógépén foglalkoznia — elég, ha csak megír egy kódrészletet, feltölti a kódot a tárolóba, majd elindul egy pipeline, amely magába foglalhatja a buildelés, tesztelés és kiadási folyamatokat. Ez minden commitnál megtörténik, így a tesztelés folyamatosan zajlik.

A konténer használatával biztosak lehetünk abban, hogy a program teljes környezete a productionbe pontosan abban az állapotban kerül, ahogyan azt teszteltük. Tehát nem merül fel olyan probléma, hogy „a teszten más verziók voltak, productionben pedig mások, és amikor telepítettük, minden összeomlott”. Mivel manapság a mikroszolgáltatás-architektúra trendje jellemző, amikor egy hatalmas helyett száz kis alkalmazás van, rengeteg munkatársat igényelne ennek manuális adminisztrálása. Ezért használjuk a Kubernetes-t.

Előnyök, előnyök, előnyök

Ha a Kubernetes platform előnyeiről beszélünk, akkor jelentős előnyöket nyújt a mikroszolgáltatás-architektúra kezelés szempontjából.

Több replikában való kezelés. A legfontosabb az, hogy a konténerek menedzsmentje több hoszton történik. Ami még fontosabb, hogy a konténerben lévő alkalmazások sok replikájának kezelését egyes entitásként végezzük. Ennek köszönhetően a mérnököknek nem kell minden egyes konténerrel foglalkozniuk. Ha egy konténer leáll, a Kubernetes észleli ezt, és újraindítja.
Klaszternet. A Kubernetes-nek van egy úgynevezett klaszternet-képessége a saját címzési térrel. Ennek köszönhetően minden pod saját címmel rendelkezik. A pod a klaszter minimális szerkezeti egysége, amelyben a konténerek közvetlenül futnak. Továbbá a Kubernetes rendelkezik egy funkcióval, amely ötvözi a terheléselosztót és a Service Discovery-t. Ez lehetővé teszi, hogy megszabaduljunk az IP-címek manuális kezelésétől, és ezt a feladatot a Kubernetesre bízzuk. Az automatikus health checkek segítenek a problémák észlelésében, és a forgalmat a működő podokra irányítják.
Konfigurációk kezelése. Amikor sok alkalmazást kezelünk, nehézségeket okoz az alkalmazások konfigurációjának kezelése. Erre a Kubernetes-ben speciális ConfigMap erőforrások állnak rendelkezésre. Ezek lehetővé teszik a konfigurációk központosított tárolását, amelyeket a konténerek automatikusan beillesztenek az alkalmazások indításakor. Ez a mechanizmus biztosítja a konfigurációk konzisztenciáját akár tíz, akár száz alkalmazás példány esetén.
Tartós tárolók. A konténerek alapvetően immutable (tartós) állapotban vannak, és ha egy konténert leállítanak, minden, a fájlrendszerre írt adat megsemmisül. De egyes alkalmazások közvetlenül a lemezen tárolják az adatokat. Ennek a problémának a megoldására a Kubernetes-ben van tárolókezelési funkció - Tartós tárolók. Ez a mechanizmus külső tárolót használ az adatokhoz, és állandó tárolót, blokkolt vagy fájltámogatást kínálhat a konténerek számára. Ez a megoldás lehetővé teszi az adatok elkülönítését a munkásoktól, ami megvédi őket a munkások meghibásodása esetén.
Terheléselosztó. Bár a Kubernetes-ben absztrakt entitásokat, például Deployment, StatefulSet stb. kezelünk, végső soron a konténerek hagyományos virtuális gépekben vagy fizikai szervereken futnak. Ezek nem tökéletesek, és bármikor leállhatnak. A Kubernetes ezt észleli, és a belső forgalmat más példányokra irányítja. De mi a teendő a külső forgalommal? Ha a forgalmat egyszerűen az egyik munkásra irányítjuk, és az leáll, a szolgáltatás elérhetetlenné válik. Erre a problémára a Kubernetes-ben a terheléselosztó típusú szolgáltatások állnak rendelkezésre. Ezek célja, hogy automatikusan beállítsák a külső felhői terheléselosztót az összes munkás számára a klaszterben. Ez a külső terheléselosztó irányítja a külső forgalmat a munkásokhoz, és önállóan figyeli azok állapotát. Ha az egyik vagy több munkás elérhetetlenné válik, a forgalom átirányításra kerül másokra. Ez lehetővé teszi a magas rendelkezésre állású szolgáltatások létrehozását a Kubernetes segítségével.

A Kubernetes legjobban a mikro-szolgáltatás architektúrák futtatásakor mutatkozik meg. A rendszert klasszikus architektúrába is integrálhatjuk, de értelmetlen. Ha az alkalmazás nem tud több példányban működni, akkor mi a különbség – Kubernetes vagy nem?

Nyílt forráskódú Kubernetes

A nyílt forráskódú Kubernetes – nagyszerű dolog: telepíted, és működik. Telepítheted a saját szervereidre, a saját infrastruktúrádba, beállíthatsz egy mestert és munkásokat, ahol az összes alkalmazás futni fog. És ami a legfontosabb – mindez ingyenes. Azonban vannak árnyalatok.

Az első – az adminisztrátorok és mérnökök tudásának és tapasztalatának követelménye, akik mindezt beállítják és karbantartják. Mivel az ügyfél teljes szabadságot kap a klaszterben, a klaszter működtetéséért ő viseli a felelősséget. És itt nagyon könnyű mindent tönkretenni.
A második – az integrációk hiánya. Ha Kubernetes-t indítasz anélkül, hogy lenne valamilyen népszerű virtualizációs platformod, akkor nem kapod meg a program minden előnyét. Ilyenek például a Persistent Volumes és a Load balancer szolgáltatások használata.

2. ábra. A k8s architektúrája

Kubernetes egy szolgáltatótól

Az integráció a felhőszolgáltatóval két lehetőséget ad:

Először is, a felhasználó egyszerűen rákattinthat a „klaszter létrehozása” gombra, és máris egy beállított és működésre kész klasztert kap.
Másodszor, a szolgáltató saját maga telepíti a klasztert, és beállítja az integrációt a felhővel.

Hogyan zajlik ez nálunk. Az a mérnök, aki elindítja a klasztert, megadja, hogy hány munkásra van szüksége és milyen paraméterekkel (például 5 munkás, mindegyik 10 CPU-val, 16 GB RAM-mal és mondjuk 100 GB lemezhellyel). Ezután hozzáférést kap az már kialakított klaszterhez. A munkások, amelyeken a terhelés fut, teljes mértékben az ügyfél rendelkezésére állnak, de az összes management plane a szolgáltató felelősségi körében marad (ha a szolgáltatást managed service modellben nyújtják).

Azonban ennek a sémának megvannak a hátrányai. Mivel a management plane a szolgáltatónál marad, a szolgáltató nem ad teljes hozzáférést az ügyfélnek, ami csökkenti a Kubernetes-ra vonatkozó rugalmasságot. Néha az történik, hogy az ügyfél szeretne egy speciális funkciót csatolni a Kubernetes-hez, például LDAP-on keresztüli hitelesítést, de a management plane konfigurációja ezt nem engedi.

3. ábra. Példa egy Kubernetes klaszterre egy felhőszolgáltatótól

Mit válasszunk: nyílt forráskódú vagy szolgáltatói

Tehát, open source Kubernetes vagy vendoros? Ha open source Kubernetes-t választunk, akkor a felhasználó azt csinál, amit csak akar. De nagy a kockázata, hogy saját magának árthat. A vendorossal bonyolultabb, mert a cég mindent átgondolt és beállított. Az open source Kubernetes legnagyobb hátránya a szakemberek iránti igény. A vendorossal a cég megszabadul ettől a fejfájástól, de döntenie kell: fizessen a saját szakembereinek vagy a vendorának.

Nos, az előnyök nyilvánvalóak, a hátrányok is ismertek. Egy dolog változatlan: a Kubernetes számos problémát megold, automatizálva a konténerek sokaságának kezelését. Hogy melyiket válasszuk, open source-t vagy vendorost, azt mindenki maga dönti el.