کاروباری ایپلیکیشنز کے لیے Kubernetes کی بنیادی باتیں

کاروباری ٹیموں کے لیے Kubernetes کا ایک عملی، بے کم و کاست تعارف: بنیادی آبجیکٹس کیا کام کرتے ہیں، ایک کارآمد deployment جسے آپ کاپی کر سکتے ہیں، اور PDPL ڈیٹا رہائش کے لیے اسے اندرونِ مملکت Skyline Cloud انفراسٹرکچر پر چلانے کا طریقہ۔

SKYLINE Engineering @skyline

شائع شدہ Jun 8, 2026 | پڑھنے کا دورانیہ 6 منٹ

کاروباری ایپلیکیشنز کے لیے Kubernetes کی بنیادی باتیں

Kubernetes (اکثر مختصراً "K8s" کہا جاتا ہے) پروڈکشن میں containerized ایپلیکیشنز چلانے کا معیار ہے۔ کسی کاروبار کے لیے اس کی افادیت ٹھوس ہے: جب کوئی سرور ناکام ہو جائے تو یہ آپ کی ایپ کو چلتا رکھتا ہے، بوجھ کے تحت اسے اسکیل اپ کرتا ہے، بغیر کسی تعطل کے نئے ورژن رول آؤٹ کرتا ہے، اور آپ کی ٹیم کو ایک billing API سے لے کر کسٹمر پورٹل تک ہر چیز چلانے کا ایک ہم آہنگ طریقہ فراہم کرتا ہے۔

یہ ٹیوٹوریل بنیادی بلڈنگ بلاکس کی وضاحت کرتا ہے، ایک حقیقی deployment سے گزارتا ہے جسے آپ کاپی کر سکتے ہیں، اور دکھاتا ہے کہ اسے اندرونِ مملکت انفراسٹرکچر پر کیسے چلایا جائے تاکہ آپ کا ڈیٹا سعودی PDPL، NCA، اور SDAIA کی ضروریات کے تابع رہے۔

کوئی کاروبار Kubernetes کیوں استعمال کرے گا

آپ کو کسی ایک چھوٹی ویب سائٹ کے لیے Kubernetes کی ضرورت نہیں ہوتی۔ آپ کو اس کی ضرورت اس وقت پیش آنا شروع ہوتی ہے جب آپ کے پاس متعدد سروسز، متعدد ماحول (environments)، یا اپ ٹائم کی پابندیاں ہوں۔ اس کے عملی فوائد یہ ہیں:

• خود مرمت (Self-healing): کریش ہونے والا container خود بخود دوبارہ چلایا جاتا ہے؛ غیر صحت مند node کو خالی (drain) کر دیا جاتا ہے۔
• افقی اسکیلنگ (Horizontal scaling): ٹریفک کے اچانک اضافے کو سنبھالنے کے لیے replicas شامل کریں، پھر واپس کم کر دیں۔
• بغیر تعطل ریلیز (Zero-downtime releases): rolling updates پرانے pods کو بتدریج بدلتے ہیں اور ناکامی پر واپس رول بیک کر دیتے ہیں۔
• منتقلی کی صلاحیت (Portability): وہی manifests آپ کے لیپ ٹاپ، ٹیسٹ کلسٹر، اور پروڈکشن پر چلتے ہیں۔

بنیادی آبجیکٹس، آسان الفاظ میں

Kubernetes میں ہر چیز ایک declarative آبجیکٹ ہے جسے آپ YAML میں بیان کرتے ہیں۔ کلسٹر مسلسل کام کرتا ہے تاکہ حقیقت آپ کی بیان کردہ صورتحال سے مطابقت رکھے۔

آپ شاذ و نادر ہی براہِ راست pods بناتے ہیں۔ آپ ایک Deployment بناتے ہیں، اور وہ آپ کے لیے pods کو منظم کرتا ہے۔

ایک کارآمد مثال

یہاں ایک service کے پیچھے stateless ویب ایپ کا مکمل، کم سے کم deployment پیش ہے۔ اسے app.yaml کے نام سے محفوظ کریں۔

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

یہاں دو چیزیں سمجھنے کے لائق ہیں۔ selector فیلڈ وہ طریقہ ہے جس سے Deployment اور Service اپنے pods تلاش کرتے ہیں: وہ ناموں پر نہیں بلکہ لیبل app: web پر مطابقت کرتے ہیں۔ اور readinessProbe Kubernetes کو بتاتا ہے کہ کسی pod کو اس وقت تک ٹریفک نہ بھیجے جب تک وہ واقعتاً پورٹ 80 پر جواب نہ دینے لگے — یہی وہ چیز ہے جو rolling updates کو محفوظ بناتی ہے۔

اسے اپلائی کریں اور اسے converge ہوتے دیکھیں:

kubectl apply -f app.yaml
kubectl get pods -l app=web
kubectl rollout status deployment/web

آپ تین pods کو Running تک پہنچتے دیکھیں گے۔ خود مرمت کو عمل میں دیکھنے کے لیے ایک کو ختم (kill) کریں:

kubectl delete pod -l app=web --field-selector=status.phase=Running --grace-period=0 | head -1
kubectl get pods -l app=web   # a replacement is already being created

اسکیلنگ اور محفوظ ریلیزز

اسکیلنگ ایک ہی لائن کا کام ہے، اور یہ وہی کمانڈ ہے جسے آپ بعد میں خودکار بنائیں گے:

kubectl scale deployment/web --replicas=6

نیا ورژن بھیجنے کے لیے، image تبدیل کریں اور Kubernetes ایک rolling update انجام دیتا ہے — نئے pods اوپر لاتا ہے اور پرانے کو صرف اسی وقت ہٹاتا ہے جب نئے اپنا readiness probe پاس کر لیں:

kubectl set image deployment/web web=nginx:1.27.1
kubectl rollout status deployment/web
# if something is wrong:
kubectl rollout undo deployment/web

پروڈکشن ٹریفک کے انداز کے لیے، ایک HorizontalPodAutoscaler شامل کریں تاکہ کلسٹر CPU کی بنیاد پر خود بخود replicas شامل کرے:

kubectl autoscale deployment/web --min=3 --max=10 --cpu-percent=70

کنفیگریشن اور سیکریٹس

کنفیگریشن کو اپنے image سے باہر رکھیں۔ اسے runtime پر inject کریں:

kubectl create configmap web-config --from-literal=APP_ENV=production
kubectl create secret generic web-secret --from-literal=DB_PASSWORD='change-me'

پھر pod spec میں انہیں envFrom کے ذریعے ریفرنس کریں۔ یہ وہی image کو staging اور production میں بغیر کسی تبدیلی کے چلنے دیتا ہے، جہاں credentials علیحدہ طور پر منظم ہوں اور کبھی build میں شامل نہ کیے جائیں۔

اسے مملکت کے اندر چلانا

سعودی اور GCC کاروباروں کے لیے، کلسٹر کہاں چلتا ہے یہ اتنا ہی اہم ہے جتنا کہ کیسے چلتا ہے۔ PDPL کے تحت، سعودی رہائشیوں کے ذاتی ڈیٹا کو عموماً ڈیٹا سبجیکٹ کی توقعات اور قابلِ اطلاق منتقلی کے قواعد کو مدِنظر رکھتے ہوئے پروسیس کیا جانا چاہیے، اور NCA/SDAIA فریم ورک ضابطہ بند workloads کو اندرونِ مملکت ہوسٹنگ کی طرف دھکیلتے ہیں۔ اپنے nodes، persistent volumes، اور بیک اپس کو سعودی ڈیٹا سینٹر کے اندر چلانا اس ڈیٹا کو مقامی طور پر مقیم رکھتا ہے اور آڈٹس کو آسان بناتا ہے۔

Skyline Cloud ایک اندرونِ مملکت فراہم کنندہ ہے، چنانچہ آپ مملکت کے اندر cloud servers اور VPS پر Kubernetes worker nodes چلا سکتے ہیں، persistent volumes اور بیک اپس کے لیے اندرونِ مملکت block اور object storage منسلک کر سکتے ہیں، اور جب رات 2 بجے کچھ خراب ہو جائے تو ایک مقامی عربی بولنے والی ٹیم تک پہنچ سکتے ہیں۔ اگر آپ کی ایپلیکیشن کسٹمر کو اطلاعات یا رسیدیں بھی بھیجتی ہے، تو اسے اسی اندرونِ مملکت footprint پر کاروباری ای میل ہوسٹنگ کے ساتھ جوڑنا اس ڈیٹا کو بھی مقامی طور پر مقیم رکھتا ہے۔ managed clusters اور آپریشنل ماڈل پر گہری نظر کے لیے، ہمارا سعودی عرب میں managed Kubernetes ہب دیکھیں۔

زیادہ تر کاروباروں کے لیے ایک معقول پہلا کلسٹر تین چھوٹے worker nodes ہیں: اتنے کہ کسی node کی ناکامی سے بچا جا سکے اور بغیر زیادہ خرچ کیے rolling updates کو حقیقت پسندانہ طور پر آزمایا جا سکے۔

ایک عملی ابتدائی چیک لسٹ

1. پہلے کسی ایک stateless service کو containerize کریں؛ شروع میں databases کو managed storage پر چھوڑ دیں۔
2. اوپر دی گئی مثال کی طرح ایک Deployment + Service لکھیں اور ایک صاف rollout status حاصل کریں۔
3. readiness probes اور resource requests/limits شامل کریں — یہی وہ چیزیں ہیں جو کلسٹر کو درست طرز عمل پر لاتی ہیں۔
4. کنفیگ کو ConfigMaps اور Secrets میں منتقل کریں۔
5. بنیادی چیزیں مستحکم ہو جانے کے بعد ایک autoscaler اور ایک Ingress شامل کریں۔

Skyline Cloud پر آغاز کریں

آپ منٹوں میں worker nodes کھڑے کر سکتے ہیں، اندرونِ مملکت storage منسلک کر سکتے ہیں، اور اپنے ڈیٹا کو سعودی دائرہ اختیار کے تحت رکھ سکتے ہیں۔ اپنا Skyline Cloud اکاؤنٹ بنائیں اور مقامی سپورٹ کی پشت پناہی کے ساتھ اپنا پہلا کلسٹر deploy کریں۔