1~
2اگر آپ سافٹ ویئر ڈیولپمنٹ کی دنیا میں کام کرتے ہیں، تو آپ نے یقیناً Kubernetes کے بارے میں سنا ہوگا۔ لیکن یہ بالکل کیا ہے، اور کنٹینرائزڈ ایپلیکیشنز کے انتظام کے لیے یہ ڈی-فیکٹو سٹینڈرڈ کیوں بن گیا ہے؟ یہ گائیڈ آپ کو بنیادی باتوں سے بنیادی تصورات تک لے جائے گا، عملی مثالوں اور ڈایاگرامز کے ساتھ۔
3~
4## Kubernetes سے پہلے: تھوڑی سی تاریخ
5~
6Kubernetes کیوں اتنا انقلابی ہے اس کو سمجھنے کے لیے، آئیے ایک قدم پیچھے ہٹتے ہیں۔
7~
81.  **روایتی ڈیپلائمنٹ**: ابتدائی طور پر، ایپلیکیشنز فزیکل سرورز پر چلائی جاتی تھیں۔ یہ طریقہ مہنگا، اسکیل کرنا مشکل اور وسائل کے تنازعات کا شکار تھا۔
92.  **ورچوئلائزڈ ڈیپلائمنٹ**: پھر ورچوئل مشینز (VMs) آئیں۔ VMs نے ایک ہی ہارڈویئر پر متعدد الگ الگ ایپلیکیشنز چلانے کی اجازت دی، وسائل کے استعمال اور سیکیورٹی کو بہتر بنایا۔ تاہم، ہر VM ایک مکمل آپریٹنگ سسٹم چلاتی ہے، بہت سے وسائل خرچ کرتی ہے۔
103.  **کنٹینرائزڈ ڈیپلائمنٹ**: کنٹینرز (جیسے Docker) اگلا ارتقاء ہے۔ یہ ایک ہی ہوسٹ آپریٹنگ سسٹم شیئر کرتے ہیں لیکن الگ الگ پروسیسز چلاتے ہیں۔ یہ ہلکے، تیزی سے شروع ہونے والے اور پورٹیبل ہیں۔
11~
12کنٹینرز نے پورٹیبلٹی کا مسئلہ حل کیا لیکن ایک اور مسئلہ پیدا کیا: پروڈکشن ماحول میں سینکڑوں (یا ہزاروں) کنٹینرز کا انتظام کیسے کریں؟ کیسے یقینی بنائیں کہ وہ ہمیشہ چل رہے ہیں، ایک دوسرے سے بات چیت کر سکتے ہیں، اور لوڈ کی بنیاد پر اسکیل ہو سکتے ہیں؟
13~
14یہاں **Kubernetes** آتا ہے۔
15~
16## Kubernetes کیا ہے؟
17~
18Kubernetes (اکثر **K8s** کے طور پر مختصر) کنٹینر آرکیسٹریشن کے لیے ایک اوپن سورس پلیٹ فارم ہے۔ سادہ الفاظ میں، یہ کنٹینرائزڈ ایپلیکیشنز کی ڈیپلائمنٹ، اسکیلنگ اور مینجمنٹ کو خودکار بناتا ہے۔ Google نے بنایا اور اب Cloud Native Computing Foundation (CNCF) نے برقرار رکھا ہے، Kubernetes اسکیل پر مائیکرو سروسز کے ساتھ کام کرنے والے ہر شخص کے لیے بنیادی ٹول بن گیا ہے۔
19~
20## Kubernetes Cluster کا فن تعمیر
21~
22Kubernetes ماحول کو **cluster** کہا جاتا ہے۔ ایک cluster مشینوں کے ایک سیٹ پر مشتمل ہوتا ہے، جنہیں **nodes** کہا جاتا ہے، جو ہماری ایپلیکیشنز چلاتے ہیں۔ فن تعمیر دو اہم حصوں میں تقسیم ہے: Control Plane اور Worker Nodes۔
23~
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32~
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39~
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45~
46    A -- "Communicates with" --> E
47    A -- "Communicates with" --> J
48    User -- "kubectl" --> A
49    C -- "Assigns Pods to Nodes" --> E
50    D -- "Maintains state" --> A
51    A -- "Saves/Reads state" --> B
52```
53~
54### Control Plane
55~
56Control Plane cluster کا "دماغ" ہے۔ یہ عالمی فیصلے کرتا ہے (جیسے شیڈولنگ) اور cluster ایونٹس کا پتہ لگاتا اور جواب دیتا ہے۔ اس کے اہم اجزاء ہیں:
57~
58-   **API Server (`kube-apiserver`)**: یہ cluster کا گیٹ وے ہے۔ یہ Kubernetes API فراہم کرتا ہے، جسے صارفین (`kubectl` کے ذریعے)، cluster اجزاء اور بیرونی ٹولز مواصلات کے لیے استعمال کرتے ہیں۔
59-   **etcd**: ایک مستقل اور انتہائی دستیاب کی-ویلیو ڈیٹا بیس۔ یہ تمام cluster ڈیٹا ذخیرہ کرتا ہے، سسٹم کی مطلوبہ اور موجودہ حالت کی نمائندگی کرتا ہے۔
60-   **Scheduler (`kube-scheduler`)**: نئے بنائے گئے Pods کو دستیاب Worker Node کو تفویض کرتا ہے، وسائل کی ضروریات، پالیسیوں اور دیگر رکاوٹوں کو مدنظر رکھتے ہوئے۔
61-   **Controller Manager (`kube-controller-manager`)**: کنٹرولرز چلاتا ہے، جو کنٹرول لوپس ہیں جو cluster کی حالت کی نگرانی کرتے ہیں اور اسے مطلوبہ حالت میں لانے کے لیے کام کرتے ہیں۔ مثال کے طور پر، `Node Controller` nodes کا انتظام کرتا ہے، جبکہ `Replication Controller` اس بات کو یقینی بناتا ہے کہ Pods کی صحیح تعداد چل رہی ہے۔
62~
63### Worker Node
64~
65Worker Nodes وہ مشینیں ہیں (فزیکل یا ورچوئل) جہاں ایپلیکیشنز اصل میں چلتی ہیں۔ ہر node Control Plane کے ذریعے منظم ہوتا ہے اور درج ذیل اجزاء پر مشتمل ہوتا ہے:
66~
67-   **Kubelet**: ایک ایجنٹ جو ہر node پر چلتا ہے۔ یہ یقینی بناتا ہے کہ Pods میں بیان کردہ کنٹینرز چل رہے ہیں اور صحت مند ہیں۔
68-   **Kube-proxy**: ایک نیٹ ورک پراکسی جو nodes پر نیٹ ورک کے قواعد کا انتظام کرتا ہے۔ یہ cluster کے اندر یا باہر سے Pods تک نیٹ ورک مواصلات کی اجازت دیتا ہے۔
69-   **Container Runtime**: کنٹینرز چلانے کا ذمہ دار سافٹ ویئر۔ Docker سب سے مشہور ہے، لیکن Kubernetes دوسرے runtimes جیسے `containerd` اور `CRI-O` کو بھی سپورٹ کرتا ہے۔
70~
71## بنیادی Kubernetes آبجیکٹس
72~
73Kubernetes میں سب کچھ **آبجیکٹس** کے ذریعے ظاہر ہوتا ہے۔ یہ آبجیکٹس "ارادے کے ریکارڈ" ہیں: ایک بار جب آپ آبجیکٹ بناتے ہیں، Kubernetes مسلسل کام کرتا ہے یہ یقینی بنانے کے لیے کہ یہ موجود ہے اور مطلوبہ حالت سے میل کھاتا ہے۔
74~
75یہاں سب سے اہم ہیں:
76~
77### Pod
78~
79**Pod** Kubernetes میں سب سے چھوٹی عملداری اکائی ہے۔ یہ ایک یا زیادہ کنٹینرز کی نمائندگی کرتا ہے جو ایک ہی node پر اکٹھے چلتے ہیں، نیٹ ورک اور اسٹوریج جیسے وسائل شیئر کرتے ہیں۔
80~
81عام طور پر، آپ فی Pod صرف ایک کنٹینر چلاتے ہیں، لیکن ترقی یافتہ منظرناموں میں (جیسے لاگنگ یا مانیٹرنگ کے لیے "sidecar containers")، آپ کے پاس زیادہ ہو سکتے ہیں۔
82~
83آپ تقریباً کبھی بھی براہ راست Pods نہیں بناتے۔ آپ Deployments جیسے اعلیٰ سطحی تجریدات استعمال کرتے ہیں۔
84~
85### Deployment
86~
87ایک **Deployment** وہ آبجیکٹ ہے جسے آپ سب سے زیادہ استعمال کریں گے۔ یہ ایک جیسے Pods کے ایک گروپ کے لیے مطلوبہ حالت بیان کرتا ہے۔ Deployment کنٹرولر ذمہ دار ہے:
88~
89-   ایک **ReplicaSet** بنانے اور منظم کرنے کا (ایک اور آبجیکٹ جو یقینی بناتا ہے کہ Pod کی ایک مخصوص تعداد کی نقلیں ہمیشہ چل رہی ہیں)۔
90-   Pods کی تعداد کو اوپر یا نیچے **اسکیل** کرنے کا۔
91-   ایپلیکیشن **اپ ڈیٹس** کو کنٹرولڈ طریقے سے منظم کرنے کا (مثلاً *Rolling Update*)، ڈاؤن ٹائم کے بغیر۔
92~
93یہاں ایک NGINX سرور کی 3 نقلیں چلانے والے Deployment کے لیے ایک مثال YAML فائل ہے:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120Kubernetes میں Pods عارضی ہیں: وہ کسی بھی وقت بنائے اور تباہ کیے جا سکتے ہیں۔ ہر Pod کا اپنا IP ایڈریس ہوتا ہے، لیکن یہ IP مستحکم نہیں ہے۔ تو، ہم اپنی ایپلیکیشن کو قابل اعتماد طریقے سے کیسے ظاہر کریں؟
121~
122ایک **Service** کے ساتھ۔ ایک Service ایک تجرید ہے جو Pods کا ایک منطقی سیٹ اور ان تک رسائی کی پالیسی کی تعریف کرتا ہے۔ یہ Pods کے ایک گروپ کے لیے ایک **مستحکم رسائی نقطہ** (ایک ورچوئل IP ایڈریس اور ایک DNS نام) فراہم کرتا ہے۔
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "Request to nginx-service" --> A
141```
142~
143Service `labels` پر مبنی ایک `selector` استعمال کرتا ہے وہ Pods تلاش کرنے کے لیے جن پر ٹریفک بھیجنا ہے۔
144~
145ہمارے NGINX Deployment کے لیے ایک Service بنانے کا طریقہ:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - exposes the service only within the cluster
161```
162~
163مختلف قسم کی Services ہیں:
164- `ClusterIP`: cluster-اندرونی IP پر service ظاہر کرتا ہے (ڈیفالٹ)۔
165- `NodePort`: ہر Worker Node پر ایک جامد پورٹ پر service ظاہر کرتا ہے۔
166- `LoadBalancer`: کلاؤڈ پرووائیڈر (مثلاً AWS، GCP) میں ایک بیرونی لوڈ بیلنسر بناتا ہے اور service کو ایک پبلک IP تفویض کرتا ہے۔
167~
168### Ingress
169~
170ایک `LoadBalancer` Service بہت اچھا ہے، لیکن ہر service کے لیے ایک بنانا مہنگا ہو سکتا ہے۔ بیرونی دنیا میں متعدد HTTP/HTTPS services ظاہر کرنے کے لیے، آپ ایک **Ingress** استعمال کرتے ہیں۔
171~
172ایک Ingress بیرونی ٹریفک کے لیے ایک "ذہین راؤٹر" کے طور پر کام کرتا ہے۔ یہ آپ کو host (مثلاً `api.mysite.com`) یا path (مثلاً `mysite.com/api`) پر مبنی راؤٹنگ قواعد بیان کرنے کی اجازت دیتا ہے۔
173~
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185~
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190~
191Ingress کی ایک مثال:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### دیگر مفید آبجیکٹس
220~
221-   **Namespace**: ایک فزیکل cluster کے اندر "ورچوئل clusters" بنانے کی اجازت دیتا ہے۔ ماحول (مثلاً `development`، `staging`، `production`) یا ٹیموں کو الگ کرنے کے لیے مفید۔
222-   **ConfigMap اور Secret**: کنٹینر امیج سے الگ کنفیگریشن ڈیٹا اور رازوں (جیسے پاسورڈز یا API کیز) کا انتظام کرنے کے لیے۔
223-   **StatefulSet**: Deployment سے ملتا جلتا، لیکن اسٹیٹ فل ایپلیکیشنز (جیسے ڈیٹا بیسز) کے لیے مخصوص جن کو مستحکم نیٹ ورک شناخت اور مستقل اسٹوریج کی ضرورت ہوتی ہے۔
224-   **PersistentVolume (PV) اور PersistentVolumeClaim (PVC)**: cluster میں مستقل اسٹوریج کا انتظام کرنے کے لیے۔
225~
226## نتیجہ
227~
228Kubernetes ایک ناقابل یقین حد تک طاقتور ٹول ہے، لیکن اس کی سیکھنے کی منحنی کھڑی ہو سکتی ہے۔ اس گائیڈ نے صرف سطح کو کھرچا ہے، لیکن ہم امید کرتے ہیں کہ اس نے آپ کو بنیادی تصورات کی ٹھوس سمجھ دی ہے۔
229~
230**اب کیا کریں؟**
231- **مقامی طور پر تجربہ کریں**: اپنے کمپیوٹر پر Kubernetes cluster بنانے کے لیے [Minikube](https://minikube.sigs.k8s.io/docs/start/) یا [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) انسٹال کریں۔
232- **`kubectl` استعمال کریں**: `kubectl` کمانڈ سے واقف ہوں، cluster کے ساتھ تعامل کے لیے آپ کا بنیادی ٹول۔ اس مضمون سے NGINX Deployment اور Service بنانے کی کوشش کریں۔
233- **سرکاری ٹیوٹوریلز دریافت کریں**: [Kubernetes دستاویزات](https://kubernetes.io/docs/tutorials/) مثالوں سے بھرا ایک شاندار وسیلہ ہے۔
234~
235کنٹینر آرکیسٹریشن کلاؤڈ-نیٹو دنیا میں ایک بنیادی مہارت ہے، اور Kubernetes پر عبور حاصل کرنا امکانات کی ایک دنیا کھول دے گا۔ لطف اٹھائیں!
236~