اگر آپ سافٹ ویئر ڈیولپمنٹ کی دنیا میں کام کرتے ہیں، تو آپ نے یقیناً Kubernetes کے بارے میں سنا ہوگا۔ لیکن یہ بالکل کیا ہے، اور کنٹینرائزڈ ایپلیکیشنز کے انتظام کے لیے یہ ڈی-فیکٹو سٹینڈرڈ کیوں بن گیا ہے؟ یہ گائیڈ آپ کو بنیادی باتوں سے بنیادی تصورات تک لے جائے گا، عملی مثالوں اور ڈایاگرامز کے ساتھ۔
Kubernetes سے پہلے: تھوڑی سی تاریخ
Kubernetes کیوں اتنا انقلابی ہے اس کو سمجھنے کے لیے، آئیے ایک قدم پیچھے ہٹتے ہیں۔
- روایتی ڈیپلائمنٹ: ابتدائی طور پر، ایپلیکیشنز فزیکل سرورز پر چلائی جاتی تھیں۔ یہ طریقہ مہنگا، اسکیل کرنا مشکل اور وسائل کے تنازعات کا شکار تھا۔
- ورچوئلائزڈ ڈیپلائمنٹ: پھر ورچوئل مشینز (VMs) آئیں۔ VMs نے ایک ہی ہارڈویئر پر متعدد الگ الگ ایپلیکیشنز چلانے کی اجازت دی، وسائل کے استعمال اور سیکیورٹی کو بہتر بنایا۔ تاہم، ہر VM ایک مکمل آپریٹنگ سسٹم چلاتی ہے، بہت سے وسائل خرچ کرتی ہے۔
- کنٹینرائزڈ ڈیپلائمنٹ: کنٹینرز (جیسے Docker) اگلا ارتقاء ہے۔ یہ ایک ہی ہوسٹ آپریٹنگ سسٹم شیئر کرتے ہیں لیکن الگ الگ پروسیسز چلاتے ہیں۔ یہ ہلکے، تیزی سے شروع ہونے والے اور پورٹیبل ہیں۔
کنٹینرز نے پورٹیبلٹی کا مسئلہ حل کیا لیکن ایک اور مسئلہ پیدا کیا: پروڈکشن ماحول میں سینکڑوں (یا ہزاروں) کنٹینرز کا انتظام کیسے کریں؟ کیسے یقینی بنائیں کہ وہ ہمیشہ چل رہے ہیں، ایک دوسرے سے بات چیت کر سکتے ہیں، اور لوڈ کی بنیاد پر اسکیل ہو سکتے ہیں؟
یہاں Kubernetes آتا ہے۔
Kubernetes کیا ہے؟
Kubernetes (اکثر K8s کے طور پر مختصر) کنٹینر آرکیسٹریشن کے لیے ایک اوپن سورس پلیٹ فارم ہے۔ سادہ الفاظ میں، یہ کنٹینرائزڈ ایپلیکیشنز کی ڈیپلائمنٹ، اسکیلنگ اور مینجمنٹ کو خودکار بناتا ہے۔ Google نے بنایا اور اب Cloud Native Computing Foundation (CNCF) نے برقرار رکھا ہے، Kubernetes اسکیل پر مائیکرو سروسز کے ساتھ کام کرنے والے ہر شخص کے لیے بنیادی ٹول بن گیا ہے۔
Kubernetes Cluster کا فن تعمیر
Kubernetes ماحول کو cluster کہا جاتا ہے۔ ایک cluster مشینوں کے ایک سیٹ پر مشتمل ہوتا ہے، جنہیں nodes کہا جاتا ہے، جو ہماری ایپلیکیشنز چلاتے ہیں۔ فن تعمیر دو اہم حصوں میں تقسیم ہے: Control Plane اور Worker Nodes۔
Control Plane
Control Plane cluster کا "دماغ" ہے۔ یہ عالمی فیصلے کرتا ہے (جیسے شیڈولنگ) اور cluster ایونٹس کا پتہ لگاتا اور جواب دیتا ہے۔ اس کے اہم اجزاء ہیں:
- API Server (
kube-apiserver): یہ cluster کا گیٹ وے ہے۔ یہ Kubernetes API فراہم کرتا ہے، جسے صارفین (kubectlکے ذریعے)، cluster اجزاء اور بیرونی ٹولز مواصلات کے لیے استعمال کرتے ہیں۔ - etcd: ایک مستقل اور انتہائی دستیاب کی-ویلیو ڈیٹا بیس۔ یہ تمام cluster ڈیٹا ذخیرہ کرتا ہے، سسٹم کی مطلوبہ اور موجودہ حالت کی نمائندگی کرتا ہے۔
- Scheduler (
kube-scheduler): نئے بنائے گئے Pods کو دستیاب Worker Node کو تفویض کرتا ہے، وسائل کی ضروریات، پالیسیوں اور دیگر رکاوٹوں کو مدنظر رکھتے ہوئے۔ - Controller Manager (
kube-controller-manager): کنٹرولرز چلاتا ہے، جو کنٹرول لوپس ہیں جو cluster کی حالت کی نگرانی کرتے ہیں اور اسے مطلوبہ حالت میں لانے کے لیے کام کرتے ہیں۔ مثال کے طور پر،Node Controllernodes کا انتظام کرتا ہے، جبکہReplication Controllerاس بات کو یقینی بناتا ہے کہ Pods کی صحیح تعداد چل رہی ہے۔
Worker Node
Worker Nodes وہ مشینیں ہیں (فزیکل یا ورچوئل) جہاں ایپلیکیشنز اصل میں چلتی ہیں۔ ہر node Control Plane کے ذریعے منظم ہوتا ہے اور درج ذیل اجزاء پر مشتمل ہوتا ہے:
- Kubelet: ایک ایجنٹ جو ہر node پر چلتا ہے۔ یہ یقینی بناتا ہے کہ Pods میں بیان کردہ کنٹینرز چل رہے ہیں اور صحت مند ہیں۔
- Kube-proxy: ایک نیٹ ورک پراکسی جو nodes پر نیٹ ورک کے قواعد کا انتظام کرتا ہے۔ یہ cluster کے اندر یا باہر سے Pods تک نیٹ ورک مواصلات کی اجازت دیتا ہے۔
- Container Runtime: کنٹینرز چلانے کا ذمہ دار سافٹ ویئر۔ Docker سب سے مشہور ہے، لیکن Kubernetes دوسرے runtimes جیسے
containerdاورCRI-Oکو بھی سپورٹ کرتا ہے۔
بنیادی Kubernetes آبجیکٹس
Kubernetes میں سب کچھ آبجیکٹس کے ذریعے ظاہر ہوتا ہے۔ یہ آبجیکٹس "ارادے کے ریکارڈ" ہیں: ایک بار جب آپ آبجیکٹ بناتے ہیں، Kubernetes مسلسل کام کرتا ہے یہ یقینی بنانے کے لیے کہ یہ موجود ہے اور مطلوبہ حالت سے میل کھاتا ہے۔
یہاں سب سے اہم ہیں:
Pod
Pod Kubernetes میں سب سے چھوٹی عملداری اکائی ہے۔ یہ ایک یا زیادہ کنٹینرز کی نمائندگی کرتا ہے جو ایک ہی node پر اکٹھے چلتے ہیں، نیٹ ورک اور اسٹوریج جیسے وسائل شیئر کرتے ہیں۔
عام طور پر، آپ فی Pod صرف ایک کنٹینر چلاتے ہیں، لیکن ترقی یافتہ منظرناموں میں (جیسے لاگنگ یا مانیٹرنگ کے لیے "sidecar containers")، آپ کے پاس زیادہ ہو سکتے ہیں۔
آپ تقریباً کبھی بھی براہ راست Pods نہیں بناتے۔ آپ Deployments جیسے اعلیٰ سطحی تجریدات استعمال کرتے ہیں۔
Deployment
ایک Deployment وہ آبجیکٹ ہے جسے آپ سب سے زیادہ استعمال کریں گے۔ یہ ایک جیسے Pods کے ایک گروپ کے لیے مطلوبہ حالت بیان کرتا ہے۔ Deployment کنٹرولر ذمہ دار ہے:
- ایک ReplicaSet بنانے اور منظم کرنے کا (ایک اور آبجیکٹ جو یقینی بناتا ہے کہ Pod کی ایک مخصوص تعداد کی نقلیں ہمیشہ چل رہی ہیں)۔
- Pods کی تعداد کو اوپر یا نیچے اسکیل کرنے کا۔
- ایپلیکیشن اپ ڈیٹس کو کنٹرولڈ طریقے سے منظم کرنے کا (مثلاً Rolling Update)، ڈاؤن ٹائم کے بغیر۔
یہاں ایک NGINX سرور کی 3 نقلیں چلانے والے Deployment کے لیے ایک مثال YAML فائل ہے:
# nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
Service
Kubernetes میں Pods عارضی ہیں: وہ کسی بھی وقت بنائے اور تباہ کیے جا سکتے ہیں۔ ہر Pod کا اپنا IP ایڈریس ہوتا ہے، لیکن یہ IP مستحکم نہیں ہے۔ تو، ہم اپنی ایپلیکیشن کو قابل اعتماد طریقے سے کیسے ظاہر کریں؟
ایک Service کے ساتھ۔ ایک Service ایک تجرید ہے جو Pods کا ایک منطقی سیٹ اور ان تک رسائی کی پالیسی کی تعریف کرتا ہے۔ یہ Pods کے ایک گروپ کے لیے ایک مستحکم رسائی نقطہ (ایک ورچوئل IP ایڈریس اور ایک DNS نام) فراہم کرتا ہے۔
Service labels پر مبنی ایک selector استعمال کرتا ہے وہ Pods تلاش کرنے کے لیے جن پر ٹریفک بھیجنا ہے۔
ہمارے NGINX Deployment کے لیے ایک Service بنانے کا طریقہ:
# nginx-service.yaml apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP # Default - exposes the service only within the cluster
مختلف قسم کی Services ہیں:
ClusterIP: cluster-اندرونی IP پر service ظاہر کرتا ہے (ڈیفالٹ)۔NodePort: ہر Worker Node پر ایک جامد پورٹ پر service ظاہر کرتا ہے۔LoadBalancer: کلاؤڈ پرووائیڈر (مثلاً AWS، GCP) میں ایک بیرونی لوڈ بیلنسر بناتا ہے اور service کو ایک پبلک IP تفویض کرتا ہے۔
Ingress
ایک LoadBalancer Service بہت اچھا ہے، لیکن ہر service کے لیے ایک بنانا مہنگا ہو سکتا ہے۔ بیرونی دنیا میں متعدد HTTP/HTTPS services ظاہر کرنے کے لیے، آپ ایک Ingress استعمال کرتے ہیں۔
ایک Ingress بیرونی ٹریفک کے لیے ایک "ذہین راؤٹر" کے طور پر کام کرتا ہے۔ یہ آپ کو host (مثلاً api.mysite.com) یا path (مثلاً mysite.com/api) پر مبنی راؤٹنگ قواعد بیان کرنے کی اجازت دیتا ہے۔
Ingress کی ایک مثال:
# example-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: mysite.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 8080 - path: /ui pathType: Prefix backend: service: name: ui-service port: number: 3000
دیگر مفید آبجیکٹس
- Namespace: ایک فزیکل cluster کے اندر "ورچوئل clusters" بنانے کی اجازت دیتا ہے۔ ماحول (مثلاً
development،staging،production) یا ٹیموں کو الگ کرنے کے لیے مفید۔ - ConfigMap اور Secret: کنٹینر امیج سے الگ کنفیگریشن ڈیٹا اور رازوں (جیسے پاسورڈز یا API کیز) کا انتظام کرنے کے لیے۔
- StatefulSet: Deployment سے ملتا جلتا، لیکن اسٹیٹ فل ایپلیکیشنز (جیسے ڈیٹا بیسز) کے لیے مخصوص جن کو مستحکم نیٹ ورک شناخت اور مستقل اسٹوریج کی ضرورت ہوتی ہے۔
- PersistentVolume (PV) اور PersistentVolumeClaim (PVC): cluster میں مستقل اسٹوریج کا انتظام کرنے کے لیے۔
نتیجہ
Kubernetes ایک ناقابل یقین حد تک طاقتور ٹول ہے، لیکن اس کی سیکھنے کی منحنی کھڑی ہو سکتی ہے۔ اس گائیڈ نے صرف سطح کو کھرچا ہے، لیکن ہم امید کرتے ہیں کہ اس نے آپ کو بنیادی تصورات کی ٹھوس سمجھ دی ہے۔
اب کیا کریں؟
- مقامی طور پر تجربہ کریں: اپنے کمپیوٹر پر Kubernetes cluster بنانے کے لیے Minikube یا Kind انسٹال کریں۔
kubectlاستعمال کریں:kubectlکمانڈ سے واقف ہوں، cluster کے ساتھ تعامل کے لیے آپ کا بنیادی ٹول۔ اس مضمون سے NGINX Deployment اور Service بنانے کی کوشش کریں۔- سرکاری ٹیوٹوریلز دریافت کریں: Kubernetes دستاویزات مثالوں سے بھرا ایک شاندار وسیلہ ہے۔
کنٹینر آرکیسٹریشن کلاؤڈ-نیٹو دنیا میں ایک بنیادی مہارت ہے، اور Kubernetes پر عبور حاصل کرنا امکانات کی ایک دنیا کھول دے گا۔ لطف اٹھائیں!