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:
- Egy címkét ad mindazon pod-okhoz, amelyeket a Service-ünkkel el szeretnénk érni, és
- 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:
kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured
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:
kubectl get pod -l app=sa-frontend NAME READY STATUS RESTARTS AGE sa-frontend 1/1 Running 0 2h sa-frontend2 1/1 Running 0 2h
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:
apiVersion: v1 kind: Service # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer # 2 ports: - port: 80 # 3 protocol: TCP # 4 targetPort: 80 # 5 selector: # 6 app: sa-frontend # 7
Magyarázat:
- Kind: a leírás fajtája (esetünkben “Service”)
- 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
- Port: azt a port-ot definiálja, ahol a Service-ünk kéréseket fogad
- Protocol: a kommunikációs protokollt határozza meg.
- TargetPort: az a port, amelyre a beérkező kérések továbbítva lesznek
- Selector: egy objektum, amely a kiválasztandó pod-ok tulajdonságait tartalmazza.
- 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:
kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created A Service állapotát az alábbi paranccsal tudhatjuk meg: kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE sa-frontend-lb LoadBalancer 10.101.244.40 <pending> 80:30708/TCP 7m
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:
minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser...
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