Zoltán Vígh

Vigh Zoltán

  · 4 min read

Kubernetes érthetően - 1. Mi a kubernetes

A napokban gondolkoztam azon, hogy érdemes lenne egy cikksorozatot írni, hogy mi is a Kubernetes “érthető” nyelven. A cikk nem feltétlenül a szakmai emberek számára, hanem inkább a döntéshozók és a felsővezetők számára íródott, akik nem szakmabeliek, de szeretnék megérteni a k8s előnyeit és hátrányait, annak érdekében, hogy ha döntési helyzetbe kerülnek, tudjanak választani. Így ez a kis cikk inkább a felsővezetőknek szól és nem az IT szakembereknek.

A napokban gondolkoztam azon, hogy érdemes lenne egy cikksorozatot írni, hogy mi is a Kubernetes “érthető” nyelven. A cikk nem feltétlenül a szakmai emberek számára, hanem inkább a döntéshozók és a felsővezetők számára íródott, akik nem szakmabeliek, de szeretnék megérteni a k8s előnyeit és hátrányait, annak érdekében, hogy ha döntési helyzetbe kerülnek, tudjanak választani. Így ez a kis cikk inkább a felsővezetőknek szól és nem az IT szakembereknek.

Kezdjük is az első témával, hogy kicsit kifejtsük, mi is az a Kubernetes.

A Kubernetes egy nyílt forráskódú, container orchestration platform, amely segít a containerizált (microservice) alkalmazások deployolásában, üzemeltetésében és skálázásában. A Kubernetes a Google által fejlesztett Borg rendszer alapján jött létre, és ma már az egyik legnépszerűbb platform a container orchestration területén. Természetesen nem az egyetlen, de ahogy írtam is, jelenleg a legnépszerűbb megoldás a piacon. A cikksorozatban a k8s-szel fogok foglalkozni, mivel alapvetően az a fő profilunk a Code Factory-ben, így technikai tudásunk ott van.

Az egyik legnagyobb előnye a Kubernetes-nek, hogy lehetővé teszi a containerizált microservice alkalmazások automatikus skálázását és üzemeltetését. A Kubernetes segítségével a containerizált alkalmazásokat könnyedén deployolhatjuk, üzemeltethetjük és skálázhatjuk, anélkül, hogy az alkalmazás működését befolyásolnánk. Természetesen ehhez szükséges egy paradigmaváltás a fejlesztői oldalon, így ha egy cég azon gondolkozik, hogy Kubernetest szeretne használni, először fel kell mérni a fejlesztőknek a tudását, és esetlegesen edukálni kell őket.

Mire is gondolok? Alapvetően, ha egy nagyvállalatról beszélünk, ahol már vannak fejlesztő csapatok, valamint aktív fejlesztés, és megfogalmazódott a gondolat, hogy szeretnének microservice architektúrára váltani, az első és legfontosabb dolog véleményem szerint a fejlesztők edukációja. Itt érdemes a cloud native alapelvekkel kapcsolatos oktatásokon résztvenni, hogy milyen változásokat hozhat egy áttérés monolitikus fejlesztésről microservice fejlesztésre.

cloud-native

A monolitikus architektúra sikeresen működött évtizedekig, de a változó piaccal és az új technológiák kialakulásával paradigmaváltás történt az informatikai iparágban. A legtöbb nagyvállalat még mindig monolitként alkalmaz nagyvállalati megoldásokat, de egyre több problémával kell szembenézni ezzel az architektúrával. Update: Természetesen a monolitikus alkalmazásoknak is megvan a helye, szóval nem azt jelenti, hogy a microservice mindenre is megoldást nyújt!

A monolitikus architektúra hátrányai:

  • Rugalmasság: A monolitikus szerkezet nem rugalmas. Nem használhatunk különböző technológiákat rajta keresztül. A technológiai keret a kezdeteknél eldől és mindvégig csak erre a meghatározott keretre lehet hagyatkozni.
  • Megbízhatóság: A monolitikus megoldás nem megbízható. Ha az alkalmazás egyik szolgáltatása leáll, vagy hibára fut, az egész alkalmazás működésében is kiesést okozhat.
  • Fejlesztési sebesség: A fejlesztés lassú a monolitikus architektúra esetén. Kihívást jelent az új csapattagok számára, hogy megértsék és módosítsák egy meglévő monolitikus alkalmazás kódját. A kód minősége pedig idővel csökken, ahogy növekszik a kód mérete.
  • Skálázhatóság: A monolitikus alkalmazásokat egyre nehezebb lesz skálázni, a méretük függvényében, mivel a teljes alkalmazást kell skálázni, nem csak annak egy részét.

Hogyan válaszol a microservice architekrúra a monolitikus architektúra hátrányaira:

  • Rugalmasság: a microservice architektúra meglehetősen rugalmas. Különböző mikro-szolgáltatásokat lehet kifejleszteni a különböző technológiák segítségével, alkalmazkodva az adott környezethez.
  • Megbízhatóság: A microservice architektúra nagyon megbízhatónak bizonyul. Ha egy funkció leáll, a teljes alkalmazás nem áll meg.
  • Fejlesztési sebesség: A fejlesztés nagyon gyors a microservice architektúrában. Mivel a kód mennyisége sokkal kevesebb, egy csapat új tagjai számára sem nehéz megérteni és módosítani a kódot.
  • Komplex alkalmazások építése: Microservice architektúrával könnyű összetett alkalmazásokat készíteni. Ha az alkalmazás jellemzőit megfelelően elemezzük, akkor független alkotóelemekre bonthatjuk őket, amelyek egymástól függetlenül telepíthetők. Ha ezeket a feladatokat megléptük, természetesen az üzemeltetési oldalon is el kell kezdeni a tanulást, mivel a Kubernetes nagyon sok előnnyel jár, viszont üzemeltetése elég komplex feladat, így az üzemeltető csapatoknak fel kell készülni, hogy új dolgokat kell megtanulni, és folyamatosan kell implementálni és tanulni az újdonságokat.

Kubernetes Architecture Diagram

Természetesen ne gondoljuk azt, hogy a Kubernetesnek nincsenek hátrányai, és mindenre megoldást nyújt. Sokan abba a hibába esnek, hogy azt hiszik, hogy egy k8s cluster segítségével minden problémát meg lehet oldani fejlesztési és üzemeltetési oldalon. Sajnos azt kell mondanom, hogy megfelelő tervezés nélkül a k8s is csak egy rendszer, ami vagy működik vagy nem, de inkább nem.

Szóval mielőtt elgondolkozunk azon, hogy Kubernetest használunk, mérjük fel azt, hogy milyen előnyökkel járhat számunkra, és milyen tudással kell rendelkezni.

Csak néhány kompetencia a teljesség igénye nélkül, ami szükséges ahhoz, hogy a teljes ökoszisztémát összerakjuk, ami kell egy jól működő és fenntartható rendszerhez.

  • Virtualizáció
  • Kubernetes
  • Hálózat
  • Security
  • Log
  • Tracing
  • CI/CD

A következő cikkben azzal fogunk foglalkozni, melyik virtualizációt és kubernetes disztribúciót érdemes használni egy onprem környezetben. :)

Back to Blog