ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
Pod ရဲ့ IP address က ယာယီပါ — Deployment က pod အသစ် create လိုက်တိုင်း IP ပြောင်းသွားနိုင်ပါတယ်။ Frontend က backend ကို ချိတ်ဆက်ချင်ရင် IP အမြဲပြောင်းနေတာကို လိုက်မှီမနိုင်ပါဘူး — ဒါကြောင့် Service ကို သုံးပါတယ်။ Service က label ကိုက်ညီတဲ့ pod တွေကို 'ရှေ့ကနေ ကိုယ်စားပြုပေးတဲ့' stable network address (နာမည်တစ်ခုနဲ့) ပေးပါတယ် — pod ဘယ်နှစ်ခု ပြောင်းနေနေ Service address ကတော့ မပြောင်းပါဘူး။ Service type ၃ မျိုး အသုံးအများဆုံး ရှိပါတယ် — ClusterIP (cluster အတွင်းပဲ ချိတ်ဆက်လို့ရ), NodePort (server ရဲ့ port ကနေ outside access ရ), LoadBalancer (cloud provider ရဲ့ load balancer ကို auto-create).
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Frontend pod က `backend-service` ဆိုတဲ့ nameကို ချိတ်ဆက်ရင် (IP လိုမလို) Kubernetes ရဲ့ built-in DNS က backend pod (label ကိုက်တဲ့) ကို route လုပ်ပေးပါတယ် — backend pod ဘယ်နှစ်ခု scale up/down ဖြစ်နေနေ Service name ကတော့ အမြဲတည်ငြိမ်ပါတယ်။ Local minikube မှာ LoadBalancer type ကို စမ်းချင်ရင် `minikube tunnel` သုံးရပါမယ် (cloud provider မရှိလို့).
အတူတူ ကြည့်မယ်
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: ClusterIP
selector:
app: web
ports:
- port: 80
targetPort: 80$ kubectl apply -f service.yaml
service/web-service created
$ kubectl get service web-service
NAME TYPE CLUSTER-IP PORT(S) AGE
web-service ClusterIP 10.96.45.201 80/TCP 5s၅ မိနစ် စမ်းကြည့်
web-service ကို deployments lesson က web-deployment နဲ့ ချိတ်ဆက်ကြည့်ပါ (selector: app: web ကို ကိုက်ညီအောင်ထားပါ) — `kubectl get endpoints web-service` နဲ့ pod IP တွေ ချိတ်ဆက်ပြီးလားဆိုတာ ကြည့်ပါ။
သတိလေးတစ်ချက်
Service ကို ဖျက်လိုက်ရင် ဒီ Service ကို ပြောင်းရင်း ချိတ်ဆက်ထားတဲ့ app အားလုံး connection ပြတ်သွားနိုင်ပါတယ် — production မှာ Service ဖျက်တဲ့အခါ သတိထားပါ။