Kubernetes alkalmazás monitorozása és pingelése

2021-2022 ősz

Szoftver

Téma leírása

Feladat ismertetése

Egy Kubernetes klaszterben működő alkalmazás általában több komponensből, több szolgáltatásból áll. A Kubernetes health check szolgáltatása képes a belső komponenseket periodikusan pingelni, és hiba esetén újraindítani őket. A hibáról azonban nem értesít minket. Elérhető viszont több olyan külső szolgáltatás, amely az alkalmazásunkat kívülről pingeli, és hiba esetén értesít minket (pl. Freshping). Ezzel viszont az a gond, hogy egy sok szolgáltatából álló rendszer pingeléséhez mindegyik szolgáltatást elérhetővé kell tenni a klaszteren kívülről is, ami biztonsági kérdéseket vet fel.

A feladat egy olyan Go vagy ASP.NET Core alkalmazás elkészítése, amely a klaszteren belül fut, onnan pingeli a belső szolgáltatásainkat, és kifelé publikálja az állapotot. Az alkalmazás konfigurálhatósága által lehetőséget teremt arra is, hogy a belső szolgáltatásainkat csoportosítsuk, és aggregált elérhetőségi információt publikáljunk.

Előkövetelmény

A feladat megoldásához elengedhetetlen a Kubernetes alapvető ismerete. Nem szükséges nagy tapasztalat, a téma folyamán el lehet mélyülni benne, de a téma nem alkalmas a Kubernetessel való ismerkedésre.

Ha bizonytalan vagy ezzel kapcsolatban, egyeztessünk a jelentkezés előtt.

Konkrét feladat

Az alkalmazás készülhet Go nyelven vagy ASP.NET Core platformon. Az alkalmazás a klaszteren belül konténerizáltan fut és konfiguráció alapján pingeli a megadott belső szolgáltatásokat adott gyakorisággal és ezt az állapotot egy egyszerű webes felületen elérhetővé teszi. A belső pingelés konfigurálható a Kubernetes health check-ekhez hasonlóan (pl. időköz, timeout, sikertelenségi ráta, ...).

Az alkalmazás rendelkezik továbbá egy publikus http végponttal is, ahol kívülről lekérdezhető az egyes belső szolgáltatások állapota. A külső, független pingelő szolgáltatás ezt a végpontot hívja, és az URL-ben azonosítja azt a belső szolgáltatást, amelyik állapotára kíváncsi.

A belső végpontok konfigráció alapján csoportosíthatóak: megadható például, hogy az A, B, és C belső szolgáltatások mind a "backend" kategóriába tartoznak, és ha a "backend" szolgáltatás állapotát kérdezik, akkor az akkor elérhető, ha mind az A, B és C is elérhető. Ezáltal a külső, független pingelő szolgáltatás felé csak aggregált információ kerül kiadásra (és így például a rendszer belső szerkezete se kerül publikálásra).

További funkció az aggregáláshoz hasonlóan annak eldöntése, hogy egy horizontálisan skálázott komponensből hány példány érhető el. Tehát, ha az X szolgáltatás 3 példányban fut, akkor rendben fut az alkalmazás, ha legalább 2 példánya elérhető és válaszol a belső pingre. Ilyenkor, bár tranziensen van hiba az alkalmazásban, a külső, független pingelő szolgátatás számára nem jelzünk hibát, mert a rendszer egésze még működőképes. Ez szintén konfiguráció alapján szabályzott.

Félév végére elérendő cél

A pontos tárgy függvényében (önlab/szakdolgozat/diplomaterv) a célokat az alábbiak figyelembevételével határozzuk meg egy vagy két féléves munkára tervezve.

Minimum követelmény (azaz a teljesítéshez feltétlenül szükséges)
- Elkészül a Go / ASP.NET Core alkalmazás, pingeli a belső szolgáltatásokat
- Lekérdezhető kívülről minden szolgáltatás állapota
- A konfiguráció fájl alapú
- A szolgáltatás Docker konténerben fut
- Legalább a periodikusság szabályozható

Elvárt követelmény (ez szükséges a jó jegy eléréséhez)
- A periodikusság mellett szabályozható a timeout, sikerességi ráta, stb.
- A szolgátatások elréhetősége aggregálható
- A pingelendő végpontokat a rendszer a Kubernetes API-ja segítségével automatikusan felderíti induláskor, a konfigurációt annotációkból veszi
- Egyszerű webes felületen vizuálisan megtekinthető minden belső szolgáltatás állapota
- Az alkalmazás GitHub-on publikusan elérhető
- GitHub Actions CI pipeline előállítja a Docker konténert, publikája azt (Docker Hub vagy GitHub Container Registry)

A jeleshez ill. iMsc pontok megszerzéséhez szükséges
- Rendszeres beszámoló a munka menetéről és folyamatos, látható előrehaladás
- A pingelés nem csak az egyes service-eket pingeli, hanem a mögöttük álló podokat (ez szükséges a következő ponthoz)
- Horizontálisan skálázott alkalmazás esetén "minimum N darab, vagy M% fusson" jellegű szabály támogatása
- A pingelendő végpontokat a rendszer a Kubernetes API-ja segítségével folyamatosan figyeli, és új szolgáltatás/pod megjelenésekor és változásakor azt is bevonja a pingelendő körébe
- Az alkalmazáshoz készül Helm chart

Jelentkezés

A témára való jelentkezés előtt egyeztessünk. Keress Teams-en vagy emailben, és kérlek, kezdd azzal, hogy miért ez a téma érdekel téged.

Feltételek

  • Kubernetes alapszintű ismerete

Maximális létszám: 2 fő