Az alkalmazás működik. Aztán frissítés érkezik, egy szerver meghibásodik, vagy több részleg egyszerre kér nagyobb kapacitást. A Kubernetes megszervezi, hol fussanak a konténerek, és hogyan álljon helyre a meghatározott működési állapot. Az alkalmazás megbízhatósága a teljes architektúrától függ.

Vegyünk egy belső rendelési portált: a munkatársak rendeléseket rögzítenek, egy interfész továbbítja ezeket a készletkezelő rendszernek, egy háttérfolyamat pedig dokumentumokat készít. Ezeket külön konténerek végezhetik. Aki egyenként indítja őket, annak a frissítéseket, újraindításokat és a gépek közötti elhelyezést is össze kell hangolnia. Itt lép be az orkesztráció.

A kívánt állapot lesz az üzemeltetés alapja

A Kubernetesben például előírható, hogy egy webalkalmazás két példánya adott szoftververzióval fusson. A platform folyamatosan összeveti ezt a kívánt állapotot a ténylegessel. A Deployment leírja a telepítést, és ReplicaSet-vezérlővel kezeli a Podokat. Ha egy példány hiányzik, a vezérlés megpróbálja pótolni.

Ez frissítéskor is hasznos: az új verzió fokozatosan vezethető be. Ehhez az erőforrásoknak, az indulási viselkedésnek és a frissítési stratégiának is illeszkednie kell. A technikailag sikeres kiadás nem bizonyítja a rendelés helyes feldolgozását. Ez továbbra is az alkalmazás és tesztjeinek feladata.

A legfontosabb fogalmak a rendelési portál példáján

Konténerképfájl

Az alkalmazás csomagolt alapja a szükséges fájlokkal és futtatási összetevőkkel. Ebből indulnak a futó konténerek.

Pod

A Kubernetes legkisebb telepíthető egysége. Általában egy alkalmazáskonténert tartalmaz; szorosan összetartozó konténerek közös Podban osztozhatnak többek között a hálózati névtéren. A webalkalmazás két példánya rendszerint két Podot jelent.

Csomópont

Podokat futtató gép. Lehet virtuális gép vagy fizikai szerver. A Kubernetes ezért kiegészítheti a virtualizációs réteget, nem feltétlenül váltja ki.

Klaszter és vezérlősík

A klaszter összekapcsolja a vezérlést a munkaterhelést futtató csomópontokkal. A vezérlősík része az API-szerver, az állapotadatbázis, az ütemező és a vezérlők. A csomópontokon a kubelet és a konténer-futtatókörnyezet végzi a futtatást.

Service

Stabil logikai hozzáférési pont Podok csoportjához. A Podok címe cseréjükkor változhat. A Service elválasztja az elérést az egyes rövid életű példányoktól.

Mi történik ténylegesen meghibásodáskor?

Ha egy csomópont kiesik, a kezelt Podok más megfelelő csomópontokon újra elindíthatók. Ehhez hibafelismerés, elegendő tartalékkapacitás és a szükséges adatok elérése kell. Ugyanazon fizikai gép második példánya nem véd a gép hibájától. Azonos áramellátási vagy hálózati tartomány több szervere is osztozhat egy hibaponton.

A portálnál ez azt jelenti, hogy a webes felület gyorsan pótolható. Egy már elindult dokumentumfeladatot viszont úgy kell kialakítani, hogy ismétlése ne hozzon létre dupla számlát vagy rendelést. A munkamenetek nem veszhetnek el ellenőrizetlenül példánycserekor. Ezek a tulajdonságok a szoftverarchitektúrától és a kapcsolódó rendszerektől függnek.

Három szerver tehát önmagában nem rendelkezésreállási terv. A vezérlést, alkalmazásokat, hálózatot, tárolást és a hiba után megmaradó kapacitást együtt kell vizsgálni. Ez felhőben vagy menedzselt Kubernetesnél is igaz: a tényleges szolgáltatási kör dönti el a szolgáltató és a vállalat felelősségét.

A tartós adatok saját tervet igényelnek

A Podok cserélhetők. Az üzleti adatok ezért nem létezhetnek kizárólag egy konténer írható fájlrendszerében. A Kubernetes Persistent Volume-okkal és a hozzájuk tartozó Persistent Volume Claim igényekkel kapcsolhat tartós tárolást. A StorageClass leírja a megfelelő tárolás biztosításának módját.

Ezek az objektumok nem teszik automatikusan hibatűrővé a háttértárolót. A helyi lemez az infrastruktúrájához kötött; a külső tárolószolgáltatásnak saját teljesítmény- és hibajellemzői vannak. A klaszteren kívüli adatbázis is jó megoldás lehet. Az alkalmazástámogatás, az adatkonzisztencia, az elérési útvonalak és a megállapodott helyreállítás döntő.

A portálnál ezért külön meghatározzuk az elfogadható kiesést, az adatvesztést és a visszaállítás tesztjét. Az a klaszter, amely a véletlen törlést megbízhatóan minden példányra továbbítja, nem helyettesíti a mentést. További részletek: mentés és helyreállítás.

Mikor éri meg a többletkiépítés?

A Kubernetes akkor érdekes, ha több alkalmazást rendszeresen frissítenek, ismételhető telepítés kell, vagy a terhelést és a rendelkezésre álló gépeket tudatosan kell kiosztani. Emellett platformfrissítési, hozzáférés-kezelési, hálózati, tárolási és felügyeleti feladatokat hoz létre.

Egyetlen stabil alkalmazáshoz a megfelelően karbantartott Docker Compose-szerver vagy hagyományos virtuális gép gazdaságosabb lehet. A döntés a kívánt működésből induljon: milyen megszakítás fér bele, milyen gyakori a változás, és ki érti a környezetet, illetve állítja helyre hiba esetén?

A hasznos pilot céljai ellenőrizhetők

• Jellemző üzleti folyamat tesztelése valószerű adatmennyiséggel, éles ügyféladatok nélkül.
• Frissítés és a tervezett visszaút elpróbálása. Az adatbázisséma változásait külön kell értékelni.
• Egy példány és egy tervezett infrastruktúra-összetevő kiesésének ellenőrzött tesztje.
• Mentés visszaállítása külön tesztkörnyezetbe, majd megnyitása az üzleti adatok használhatóságának igazolására.
• Név szerinti felelősök kijelölése a riasztásokhoz, a platformhoz és az alkalmazáshoz.

A DAXS segít értékelni az alkalmazást, kiválasztani a megfelelő infrastruktúrát , valamint megvalósítani és a megállapodás szerint üzemeltetni. Konkrét használati eset és világos átvételi feltételek alapján végzett első felmérés jó gyakorlati kezdés.

Források: Kubernetes: a platform szerepe és korlátai · A klaszter összetevői · Podok és életciklusuk · Deploymentek és frissítések · Service-ek · Tartós tárolás · Éles környezetek tervezése