Kubernetes a gyakorlatban – szolgáltatások (Services)

A Kubernetes használatát bemutató cikksorozatunj 4. részében foglalkoztunk az erőforrások címkézésével, és a címkék használatával egy Service-szel kapcsolatban, valamint definiáltunk és létre is hoztunk egy LoadBalancer szolgáltatást. Így az alkalmazásunk skálázható és az érkező terhelés eloszthatóvá vált egy load balancer szolgáltatás segítségével.

Kubernetes cikksorozatunkat Rinor Maloku (http://rinormaloku.com) “Learn Kubernetes in Under 3 Hours: A Detailed Guide to Orchestrating Containers” posztjának fordítására alapozzuk, a szerző engedélyével. Az eredeti angol nyelvű poszt itt olvasható.

A Kubernetes által nyújtott “Services” erőforrás arra szolgál, hogy egy közös belépési pontot adjon a több pod-on futó azonos funkcionalitást nyújtó alkalmazásokhoz. Ez az erőforrás végzi el a legkeményebb munkát helyettünk, hiszen segít a szolgáltatások nyilvántartásában, belső felderítésében és a terhelés elosztásában.

Kubernetes cluster-ünkben számos pod-unk lesz, melyek különböző szolgáltatásokat nyújtanak. (A frontend, a Spring web alkalmazás és a Flask Python alkalmazás).

Jó kérdés, hogy a Service vajon honnan tudja, mely pod-ot/okat kell megszólítani? Vagyis hogyan állítja elő a pod-okra vontakozó végpontok listáját.

Ezt úgynevezett címkék, label-ek segítségével oldja meg egy két lépéses folyamatban:

  1. Egy címkét ad mindazon pod-okhoz, amelyeket a Service-ünkkel el szeretnénk érni, és
  2. Egy úgynevezett “selector”-ral meghatározzuk a service-ünknek, hogy mely pod-okat vegyen számításba.

Vizuálisan ez sokkal egyszerűbb, mint fentebb leírva:

Az ábrán azt látjuk, hogy a pod-ok egy “app: sa-frontend” címkét kaptak és a service az ilyen label-ekkel ellátott pod-okat használja.

Címkék

Címkék segítségével egyszerűen és könnyen rendszerezhetjük Kubernetes-es erőforrásainkat. A címkék valójában kulcs-érték párok, melyek bármilyen erőforrásra rátehetők. A feladatunk most az, hogy módosítsuk a pod-ok manifest file-jait, hogy a fenti árbán található állapotot érjük el.

A módosítások után mentsük el a file-okat, és az alábbi parancsokat adjuk ki:

Kapunk egy figyelmeztetést (ezt tudomásul vesszük). A második sorban látjuk, hogy az “sa-frontend” és “sa-frontend2” podokat konfiguráljuk. A megfelelő címkézést az alábbi paranccsal ellenőrizhetjük:

A címkék ellenőrzésének másik módja, ha fenti parancshoz a –show-labels kapcsolót adjuk. Ennek hatására minden egyes pod címkéit egyszerre láthatjuk.

Nagyszerű! A pod-jaink fel vannak címkézve, így egy Service-szel megfelelően megcélozhatjuk őket. Kezdjük el létrehozni a Service-einket, kezdve a load balancer-rel, amint az a lenti ábrán is látható.

Service definíció

A load balancer YAML definíciója al alábbiak szerint alakul:

Magyarázat:

  1. Kind: a leírás fajtája (esetünkben “Service”)
  2. Type: a specifikáció típusa, esetünkben ez legyen LoadBalancer, hiszen a pod-jaink közötti terhelés vezérlését szeretnék ezzel a Service-szel megoldani
  3. Port: azt a port-ot definiálja, ahol a Service-ünk kéréseket fogad
  4. Protocol: a kommunikációs protokollt határozza meg.
  5. TargetPort: az a port, amelyre a beérkező kérések továbbítva lesznek
  6. Selector: egy objektum, amely a kiválasztandó pod-ok tulajdonságait tartalmazza.
  7. app: sa-frontend, amely meghatározza, hogy mely pod-okat célozzuk meg; csak azokat, amelyek címkéje “app: sa-frontend”.

A Service létrehozásához adjuk ki az alábbi parancsot:

Az “External-IP” még “függő” állapotban van (ennek megváltozására ne várjunk, mert nem fog megváltozni). Ez azért van, mert Minikube-ot használunk. Ha mindezeket egy valódi felhő szolgáltatónál hajtottuk volna végre, pl. az Azure-ban, vagy a GCP-ben, akkor ott valódi publikus IP címet is kapnánk, vagyis a szolgáltatásunk a nagyvilág számára is elérhető lenne.

A Minikube azonban nem enged csak úgy el minket ezen a ponton, egy hasznos, lokális hibakeresésre való parancsot ad segítségül:

Ez a parancs egy böngészőt nyit, amely a szolgáltatás IP címére mutat. Amint a szolgáltatáshoz kérés érkezik, azt azonnal továbbítja az egyik pod-nak (hogy pontosan melyiknek, az nem számít). Ez az absztrakció lehetővé teszi, hogy bármennyi pod-unk van is, azt mi egységesen egyként kezeljük, egynek tekintjük, melyhez a belépési pont a Service.

Service összefoglaló

Ebben a részben foglalkoztunk az erőforrások címkézésével, és a címkék használatával egy Service-szel kapcsolatban, valamint definiáltunk és létre is hoztunk egy LoadBalancer szolgáltatást. Ezzel teljesítettük azt az igényünket, hogy az alkalmazásunk skálázható (nincs más dolgunk, mint újabb pod-okat hozzáadni a megfelelő címkével a szolgáltatáshoz) és az érkező terhelés elosztható egy load balancer szolgáltatás segítségével.

Kubernetes cikksorozatunk előző részei:

Kubernetes 3 óra alatt: részletes útmutató – 1. rész: Kiindulás a microservices alkalmazásokból

Kubernetes 3 óra alatt – 2. rész: konténerekbe szervezés

Kubernetes 3 óra alatt: részletes útmutató – 3. Rész: Kubernetes

Kubernetes a gyakorlatban: a Deploymentek

Az alábbi területeket fedtük le:

  • Felépítettünk, becsomagoltunk, és futtattunk ReactJS, Java és Python alkalmazásokat
  • Megismerkedtünk a Docker konténerekkel: hogyan definiálhatunk és építhetünk ilyeneket Dockerfile-ok segítségével
  • Konténer Registry-ket is használtunk: a Docker Hub-ot használtuk a példánkban
  • A Kubernetes legfontosabb részeit lefedtük:
    • Pod-ok
    • Service-ek
    • Deployment-ek
    • Leállás nélküli kitelepítések
    • Skálázható alkalmazásokat készítettünk
    • És mindeközben átmigráltunk egy microservice-ekre épülő alkalmazást a Kubernetes platform-ra.

 

 

Kubernetes a gyakorlatban: a Deploymentek

Kubernetes cikksorozatunkat Rinor Maloku (http://rinormaloku.com) “Learn Kubernetes in Under 3 Hours: A Detailed Guide to Orchestrating Containers” posztjának fordítására alapozzuk,…