ہینڈ آن لیب کے ساتھ ٹوٹے ہوئے Kubernetes رول آؤٹ کو کیسے ڈیبگ کریں۔

اپنی تعیناتی کو اپ ڈیٹ کریں اور اسے چلائیں۔ kubectl rollout statusاور انتظار کرو۔ کمانڈ کا وقت ختم ہو گیا۔ تاہم، اگر آپ سروس کو کوئی درخواست بھیجتے ہیں، تو وہ پھر بھی جواب دے گی۔ تو کیا اپ ڈیٹ ختم ہو گیا ہے؟ اگر نہیں، تو کون سا پوڈ ٹریفک کو سنبھال رہا ہے؟

آپ کوبرنیٹس لیب میں صورتحال کی چھان بین کریں گے۔ جب میں ایک صحت مند ایپلیکیشن شروع کرتا ہوں تو مجھے تین غلطیاں ملتی ہیں: ایک ایسی تصویر جو حاصل نہیں کی جا سکتی، ایک ریڈی نیس پروب جو کبھی نہیں گزرتی، اور ایک پوڈ جو شیڈول نہیں کیا جا سکتا۔ آپ آگے بڑھنے سے پہلے مسدود نظرثانی کی شناخت کریں گے، شواہد کی جانچ کریں گے اور بازیابی کی تصدیق کریں گے۔

تعیناتی نے لاگ ان امیج کی غلطیوں میں ان دونوں شرائط کی اطلاع دی۔ یہ جدول JSON سنیپ شاٹ سے اخذ کیا گیا ہے۔

صورت حال	صورت حال	وجہ
دستیاب	سچائی	کم از کم نقلیں دستیاب ہیں۔
جاری ہے۔	جھوٹ	پیش رفت کی آخری تاریخ سے تجاوز کر گیا ہے۔

یہ شرائط دوسرے سوالات کے جوابات دیتی ہیں۔ مندرجہ ذیل تجربہ یہ ظاہر کرتا ہے کہ اپ ڈیٹ میں خلل کے دوران کوئی ایپلیکیشن درخواستوں کا جواب کیوں جاری رکھ سکتی ہے۔

انڈیکس

لیب قائم کرنے کا طریقہ

آپ کو کنٹینرز، تعیناتیوں، ReplicaSets، pods، خدمات اور بنیادی باتوں سے واقف ہونا چاہیے۔ kubectl حکم لیب میں، ہم ڈوکر کنٹینر کے اندر واحد کبرنیٹس نوڈ چلانے کے لیے قسموں کا استعمال کرتے ہیں۔

ریکارڈ شدہ ماحول یہ ہے:

عنصر	ورژن یا ترتیب
ماسٹر	macOS 15.7.4، Apple Silicon، 16GiB RAM
کولیما	0.10.3، ڈوکر رن ٹائم، 4 CPUs، تقریباً 5.77 GiB ڈوکر کو دکھائی دیتا ہے
ڈاکر	کلائنٹ 29.4.3، سرور 29.2.1
قسم	0.33.0
کیوبیکٹل	1.36.0
Kubernetes سرور	1.37.0

ساتھی اسکرپٹ کو کولیما اور ورائٹی 0.33.0 کے ساتھ macOS ARM64 درکار ہے۔ میں نے لینکس، ونڈوز، یا انٹیل کمپیوٹرز کا تجربہ نہیں کیا ہے۔ یہ میموری نمبر ہمارے ٹیسٹ سسٹم کی وضاحت کرتے ہیں اور یہ کم از کم تقاضے نہیں ہیں۔

آپ کے پاس Docker CLI، Colima، kind، اور kubectl پہلے سے انسٹال ہونا چاہیے، Colima چل رہا ہے، اور Docker Hub تک انٹرنیٹ کی رسائی ہونی چاہیے۔

ساتھی کوڈ یہاں سے ڈاؤن لوڈ کریں۔ اسے ایک نئی ڈائرکٹری میں ان زپ کریں اور اس ڈائرکٹری کو ٹرمینل میں کھولیں۔ Bash شروع کریں، وہ شیل جسے میں استعمال کر رہا ہوں، اور پھر سیٹ اپ چلائیں۔

bash
bash setup.sh

انسٹالر fcc-rollout-lab کلسٹر اور rollout-lab نام کی جگہ۔ اپنی اسناد لکھیں۔ ./kubeconfigماؤنٹ ایپلیکیشن کے ذرائع کو ناقابل تبدیل کنفیگ میپ، تعینات، سروس، اور کے ذریعے http-client پی او ڈی اپنی مرضی کے مطابق تصویر بنانے کی ضرورت نہیں ہے۔

اس کے بعد یہ v1 اور v2 کو چیک کرتا ہے اور اسنیپ شاٹ اور HTTP جواب کو ثبوت کے محفوظ شدہ دستاویزات میں محفوظ کرتا ہے۔ سیٹ اپ ایک موجودہ لیب کلسٹر یا مقامی kubeconfig کو اوور رائٹ کرنے سے انکار کرتا ہے۔ نوڈ امیجز اور ازگر کی تصاویر ماخذ کے ڈائجسٹ کے ذریعے لنگر انداز ہوتی ہیں۔

کامیاب سیٹ اپ کے بعد، ساتھی ڈائرکٹری میں اس فنکشن کی وضاحت کریں۔

LAB_ROOT="$PWD"
k() {
  kubectl --kubeconfig "$LAB_ROOT/kubeconfig" \
    --context kind-fcc-rollout-lab \
    --namespace rollout-lab "$@"
}

ساتھی بھی شامل ہیں۔ failures.shمقدمات اور جانچ پڑتال کا خودکار پنروتپادن۔ دستی پریکٹس کے لیے، نیچے دیے گئے حکموں پر عمل کریں: خودکار ایگزیکیوٹرز تسلسل کو دوبارہ پیش کرنے کا ایک متبادل طریقہ ہیں۔

یہاں، k یہ باش فنکشن ہے جس پر عمل کیا جاتا ہے۔ kubectl اس لیب کے لیے kubeconfig، سیاق و سباق اور نام کی جگہ پہلے سے ہی منتخب ہے۔ مثال کے طور پر k get pods اپنی لیبارٹری میں پھلیوں کی فہرست بنائیں۔ اس Bash ٹرمینل میں ایک بار اوپر دی گئی تعریف کو چلائیں اور پوری مشق میں اسی ٹرمینل اور اس کے ساتھ والی ڈائرکٹری کا استعمال جاری رکھیں۔

صحت مند رول آؤٹ کیسے بنایا جائے۔

ٹربل شوٹنگ سے پہلے یقینی بنائیں کہ آپ کا رول آؤٹ پاتھ اور سروس کام کر رہی ہے۔ انسٹالر صرف درج ذیل آئٹمز کو تبدیل کرکے v1 سے v2 تک اپ ڈیٹ کرتا ہے۔ APP_VERSION Pod ٹیمپلیٹ میں ماحولیاتی متغیرات۔

ایپلیکیشن ایک چھوٹا Python HTTP سرور ہے۔ GET / کنفیگر شدہ ورژن اور پوڈ کا نام لوٹاتا ہے۔ /ready HTTP 200 لوٹاتا ہے۔ دیگر تمام راستے HTTP 404 لوٹاتے ہیں۔ پوڈ کے نام اس سے لیے گئے ہیں: metadata.name نیچے کی طرف API کے ذریعے۔

یہاں روٹنگ منطق ہے: app/server.py:

if self.path == "/":
    status = 200
    payload = {
        "version": os.environ["APP_VERSION"],
        "pod": os.environ.get("POD_NAME", "local-test"),
    }
elif self.path == "/ready":
    status = 200
    payload = {"ready": True}
else:
    status = 404
    payload = {"error": "unknown path"}

تیاری کی جانچ پڑتال کریں۔ /ready پورٹ 8080 پر۔ یہ سیٹنگز ہیں۔ spec کو manifests/deployment.yaml. یہ ایک اقتباس ہے، ایک اسٹینڈ مینی فیسٹ نہیں۔

replicas: 2
minReadySeconds: 5
progressDeadlineSeconds: 180
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

یہ رول آؤٹ سیٹ اپ کنٹرولر کو ایک متبادل پوڈ شامل کرنے کی اجازت دیتا ہے۔ دو صحت مند پرانی نقلوں کو کم کرنے سے پہلے متبادل کی دستیابی کا انتظار کریں۔ ایک نیا پوڈ دستیاب سمجھا جانے کے لیے 5 سیکنڈ تک تیار رہنا چاہیے۔ آخری تاریخ 180 سیکنڈ ہے۔

maxUnavailable: 0 یہ اس کی رہائی کو محدود کرتا ہے۔ یہ پرانے پھلیوں کو غیر متعلقہ غلطیوں سے محفوظ نہیں رکھتا ہے۔ فعال نقلوں کی تعداد سے تجاوز کرنے کے بعد بھی ختم ہونے والی پوڈ دکھائی دے سکتی ہے۔ یہ ترتیبات صرف تربیتی اختیار ہیں اور پیداوار کی دستیابی کی ضمانت نہیں دیتی ہیں۔

ہر ریکارڈ شدہ کنٹرول کامیابی کے ساتھ مکمل ہوا اور 10 درست سروس جوابات لوٹے۔ یہ جدول دو تعیناتی سنیپ شاٹس سے اخذ کیا گیا ہے۔

کنٹرول	نظر ثانی	اپ ڈیٹ	تیار	دستیاب	درست HTTP جواب
v1	1	2	2	2	10/10
v2	2	2	2	2	10/10

مثال کے طور پر، لاگ ان v2 درخواستوں میں سے ایک کے لیے ڈی کوڈ شدہ رسپانس باڈی درج ذیل ہے:

{"version": "v2", "pod": "rollout-demo-5b4b45f68f-qrntz"}

پھلی کے نام مختلف ہو سکتے ہیں۔ موجودہ حالت چیک کریں۔

k get deployment rollout-demo -o json
k get pods -l app=rollout-demo -o wide

اس وقت تک انتظار کریں جب تک کہ بالکل دو ایپلیکیشن پوڈز تیار نہ ہوں اور جاری رکھنے سے پہلے ختم نہ ہوں۔ آپ کی تعیناتی میں دو نقلیں ہونی چاہئیں جو اپ ڈیٹ، تیار اور دستیاب ہوں۔ status.observedGeneration ملاپ metadata.generation.

اس کے بعد کی کوئی بھی ناکامی غیر تبدیل شدہ رہتی ہے۔ APP_VERSION=v2. اس لیے جواب میں Pod کا نام ضروری ہے۔ اکیلے ورژن آپ کو پرانے اور نئے ترمیمات میں فرق کرنے کی اجازت نہیں دیتا ہے۔

تصویر کی درآمد میں ناکامیوں کی تشخیص کیسے کریں۔

پہلی ناکامی صرف تصویری حوالہ کو ایک ٹیگ میں تبدیل کرتی ہے جو جان بوجھ کر عوامی Python ذخیرہ سے غائب ہے۔

k apply -f failure-lab/manifests/image.json
k rollout status deployment/rollout-demo --timeout=10s

ریکارڈ شدہ رنز کی ایک مختصر گھڑی کوڈ 1 اور درج ذیل غلطی کے ساتھ ختم ہوئی:

error: timed out waiting for the condition

ورزش کے لیے اس کی توقع کی جانی چاہیے۔ تصدیق، کنکشن، یا دیگر خرابیوں کے لیے دیگر تشخیص کی ضرورت ہوتی ہے۔ کسی بھی غیر صفر اخراج کو مطلوبہ نتیجہ نہ سمجھیں۔

مسدود نظرثانی تلاش کریں۔

تعیناتیوں اور متعلقہ اشیاء کا معائنہ کریں۔

k get deployment rollout-demo
k get deployment rollout-demo -o json
k describe deployment rollout-demo
k get replicasets -l app=rollout-demo -o wide
k get pods -l app=rollout-demo -o wide

موازنہ metadata.generation کے ساتھ status.observedGeneration. اگر مؤخر الذکر کم ہے، تو کنٹرولر نے ابھی تک موجودہ مطلوبہ حالت کا مشاہدہ نہیں کیا ہے۔ ریلیز کی حیثیت کی تشریح کرنے سے پہلے براہ کرم دوبارہ چیک کریں۔

لاگ ان ایرر اسنیپ شاٹ میں تین نقلیں شامل ہیں۔ ایک اپ ڈیٹ ہے، دو تیار ہیں، اور دو دستیاب ہیں۔ لہذا تیاریوں کی تعداد جو صحت مند لگتی ہے مکمل طور پر پچھلے ترمیم سے آ سکتی ہے.

kubectl describe deployment شناخت کرتا ہے NewReplicaSet. ReplicaSet اور ReplicaSet کی ملکیت والے کسی بھی غیر تیار شدہ پوڈ کو چیک کرتا ہے۔ اپنے آؤٹ پٹ کے نام کے ساتھ نیچے دونوں قدروں کو تبدیل کریں۔

NEW_RS='replace-with-the-new-replicaset-name'
BAD_POD='replace-with-its-unready-pod-name'
k get replicaset "$NEW_RS" -o json
k get pod "$BAD_POD" -o json
k describe pod "$BAD_POD"

ReplicaSet میں metadata.ownerReferencesاگلی شے ہے۔ controller: true آپ کو اپنی تعیناتی کا UID نام بتانا ہوگا۔ پوڈ کے مالک کے حوالہ میں کنٹرولر UID اس کے ReplicaSet کے UID سے مماثل ہونا چاہیے۔ نئے ReplicaSet کی ٹیمپلیٹ تعیناتی میں موجودہ ٹیمپلیٹ سے میل کھاتی ہے، ماسوائے تیار کردہ ٹیمپلیٹ ہیش لیبل کے۔ نظرثانی کے تبصرے تعیناتی نظرثانی سے مماثل ہیں۔

لیبلز آپ کی تلاش کو محدود کرتے ہیں۔ UID ملکیت کا سلسلہ قائم کرتا ہے کہ کون سی اشیاء ایک ساتھ ہیں۔ پہلے سے طے شدہ تعلقات کے لیے مالک کے حوالہ کی دستاویزات دیکھیں۔

ناکامی کا پیغام پڑھیں

اس عین مطابق Pod مثال کے لیے واقعات حاصل کرتا ہے۔

POD_UID="$(
  k get pod "$BAD_POD" -o jsonpath="{.metadata.uid}"
)"
k get events --field-selector "involvedObject.uid=$POD_UID" \
  --sort-by=.metadata.creationTimestamp -o yaml

تصویری پوڈ محفوظ ہے۔ PodScheduled=Trueکے ساتھ nodeName سیٹ کنٹینر ہے۔ ErrImagePullپھر ImagePullBackOff دوبارہ کوششوں کے درمیان۔ پوڈ اسٹیج وہی رہا ہے۔ Pending. رجسٹری کی خرابی درج ذیل درست متن کے ساتھ ختم ہوئی:

docker.io/library/python:fcc-rollout-missing-20260928: not found

پیغام گمشدہ ٹیگ کی شناخت کرتا ہے۔ تصویر کی درآمد کی خرابیاں رجسٹری کی اسناد، پابندیوں، DNS، یا نیٹ ورک کے مسائل کی وجہ سے بھی ہو سکتی ہیں۔ ہر چیز کو فرض کرنے کے بجائے ایونٹ کے پیغامات کی تشخیص کریں۔ ImagePullBackOff اس کی ایک ہی وجہ ہے۔

پوڈ اسٹیج سے کیوبیکٹل اسٹیٹس ڈسپلے کو بھی الگ کریں۔ ImagePullBackOff کنٹینرز کے انتظار کی یہی وجہ ہے Pending یہ ایک قدم ہے۔ پوڈ لائف سائیکل حوالہ فرق کی وضاحت کرتا ہے۔

اس بات کا تعین کریں کہ کون سا پوڈ درخواست کو سنبھال رہا ہے۔

سروس کے EndpointSlices کا معائنہ کرتا ہے اور کلسٹر کے اندر سروس کے ذریعے درخواستیں بھیجتا ہے۔

k get endpointslices -l kubernetes.io/service-name=rollout-demo -o json
k exec --pod-running-timeout=30s --request-timeout=60s http-client -- \
  python -u /app/probe.py --url http://rollout-demo:8080/ \
  --expected-version v2 --count 10 --interval 0.2

پروب اسٹیٹس اور ورژن کو چیک کرتا ہے اور جواب دینے والے پوڈ کا نام ریکارڈ کرتا ہے۔ اس کے نام کا موازنہ پچھلی صحت مند ReplicaSet پوڈ سے کریں۔ EndpointSlices کا موازنہ کریں۔ targetRef.uid قدر UID کے ساتھ بھی استعمال ہوتی ہے۔

ریکارڈ شدہ رن میں، تمام 10 جوابات دو پچھلے نظرثانی پوڈز سے آئے۔ آپ کا EndpointSlice آئٹم اب تیار ہے۔ بلاک شدہ تصویری پوڈز بھی درج ہیں، لیکن ان کے اختتامی نکات ہیں۔ ready: false اور serving: false.

چونکہ نئے پوڈ دستیاب نہیں تھے، کنٹرولر نے تمام پرانی، صحت مند نقلیں رکھی تھیں۔ سروس کے نمونے نے تصدیق کی کہ پوڈ نے جواب دیا۔ دس کامیاب درخواستیں اس بات کا تعین کرتی ہیں کہ ان نمونوں کے دوران کیا ہوا۔ پیمائش پیمائش کے درمیان بلاتعطل سروس کا مظاہرہ نہیں کرتی ہے۔

دو ٹائم آؤٹ کے درمیان فرق کیسے کریں۔

پہلا ٹائم آؤٹ ٹرمینل میں ہوا۔ kubectl rollout status --timeout=10s کلائنٹ سائڈ ٹائم آؤٹ کے بعد انتظار کرنا بند ہو گیا۔ آپ نے اپ ڈیٹ کو منسوخ یا پچھلی ترتیب کو بحال نہیں کیا۔ کمانڈ کا حوالہ متعلقہ واچ ڈاگ ٹائم آؤٹ کو بیان کرتا ہے۔

دوسرا تعیناتی کنٹرولر سے تعلق رکھتا ہے۔ مقررہ تاریخ کی وجہ کا انتظار کریں اور پھر پوری حالت کا معائنہ کریں۔

k wait --for=jsonpath="{.status.conditions[?(@.type=="Progressing")].reason}"=ProgressDeadlineExceeded \
  deployment/rollout-demo --timeout=240s
k get deployment rollout-demo -o json

240 سیکنڈ کا ٹائم آؤٹ ان الگ الگ انتظار کے اوقات کو محدود کرتا ہے۔ اسے چیک کریں۔ Progressing ہے False وجہ کے ساتھ ProgressDeadlineExceeded. kubectl انتظار حوالہ دستاویزات JSONPath انتظار ہے۔

اصل تاریخ میں، ان پروگریس حالت کے لیے آخری اپ ڈیٹ کا وقت اس طرح تبدیل کیا گیا تھا: 04:57:14Z کو 05:00:15Z: 181 سیکنڈ، کنفیگرڈ ڈیڈ لائن 180 ہے۔ کنٹرولر ٹائمنگ دیوار کی گھڑی کے عین وقفوں کی ضمانت نہیں دیتا۔

Available=True پرانی پھلیاں باقی رہیں کیونکہ انہوں نے ضروری دستیابی فراہم کی تھی۔ Progressing=False ٹوٹے ہوئے اپ ڈیٹ کی اطلاع دی۔ الٹا، Progressing=True ہمیشہ نقل کی وجہ اور تعداد کو پڑھیں کیونکہ وہ کامیاب رول آؤٹ کے بعد رہ سکتے ہیں۔

تعیناتی کنٹرولر خود بخود پیچھے ہٹے بغیر آخری تاریخ کی اطلاع دیتا ہے۔ گمشدہ تصویر اب بھی وہی تصویر تھی جو میں مقررہ تاریخ کے سنیپ شاٹ میں چاہتا تھا۔

اب سروس چیک کو دہرائیں۔ آخری تاریخ کے بعد لاگ ان تمام 10 درخواستیں بھی پچھلے پوڈ سے آئی تھیں۔ اس ٹیوٹوریل میں، صرف امیج کیس کنٹرولر کی آخری تاریخ کا انتظار کرتا ہے۔

نارمل کنفیگریشن کو کیسے بحال کریں۔

اس سے پہلے کہ کوئی اور خرابی پیش آجائے ابھی مرمت کریں۔ برقرار رکھنا BAD_POD ناکام پوڈ پر سیٹ کریں جس کا آپ نے ابھی معائنہ کیا ہے۔

k apply -f failure-lab/manifests/healthy.json
k rollout status deployment/rollout-demo --timeout=300s
k wait --for=delete "pod/$BAD_POD" --timeout=120s
k get deployment rollout-demo -o json
k get replicasets -l app=rollout-demo -o wide
k get pods -l app=rollout-demo -o wide
k get endpointslices -l kubernetes.io/service-name=rollout-demo -o json
k exec --pod-running-timeout=30s --request-timeout=60s http-client -- \
  python -u /app/probe.py --url http://rollout-demo:8080/ \
  --expected-version v2 --count 10 --interval 0.2

مکمل بحالی کو یقینی بنائیں، نہ صرف رول آؤٹ کمانڈ کی کامیابی۔ مطلوبہ وضاحتیں مماثل ہونی چاہئیں۔ healthy.json. کنٹرولر کو یہ دیکھنا چاہیے کہ نقلیں، تازہ ترین نقلیں، تیار نقلیں، اور دستیاب نقلیں سبھی 2 ہیں۔

بالکل دو ایپلیکیشن پوڈز باقی ہونے چاہئیں، دونوں فی الحال ReplicaSet کی ملکیت ہیں، دونوں تیار ہیں اور ختم نہیں ہیں۔ وہ UID ایک تیار سروس اینڈ پوائنٹ ہونا چاہیے اور HTTP کے نمونے کو اس پوڈ نام میں v2 لوٹانا چاہیے۔

اصل تجربے میں، ریکوری نے وہی دو پوڈز دوبارہ استعمال کیے جو موجودہ صحت مند ریپلیکا سیٹ ہیں۔ ٹیمپلیٹ پہلے سے بحال شدہ ترتیب سے مماثل ہے۔ ناکام ReplicaSets کو 0 میں ایڈجسٹ کر دیا گیا ہے۔

نظر ثانی کی تشریح بدل گئی ہے حالانکہ صحت مند پھلیاں باقی ہیں۔ درج ذیل اقدار ریکارڈ شدہ رن سے ہیں۔

مثال	ناکامی سے پہلے	ناکام نظر ثانی	صحت یابی کے بعد
ویڈیو	2	3	4
تیاری	4	5	6
شیڈولنگ	6	7	8

آپ کے نمبر مختلف ہو سکتے ہیں۔ ان مثالوں کے نظرثانی نمبروں پر بھروسہ کرنے کے بجائے معلوم اچھی خصوصیات کو بحال کریں۔

ناکام تیاری کی تشخیص کیسے کریں۔

بحالی کی تصدیق کے بعد، دوسری ناکامی کا اطلاق کریں.

k apply -f failure-lab/manifests/readiness.json
k rollout status deployment/rollout-demo --timeout=10s

یہ صرف بدلتا ہے۔ readinessProbe.httpGet.pathپر /ready کو /not-ready. مختصر گھڑی دوبارہ ختم ہو گئی.

امیج کیس پر معائنہ کی ترتیب کو دہرائیں۔ نئے ReplicaSet کی شناخت کریں، دوبارہ ترتیب دیں۔ NEW_RS اور BAD_POD اسے کیس کے نام کے ساتھ شامل کریں اور نئے Pod UID کا استعمال کرتے ہوئے واقعات کے لیے استفسار کریں۔ اس بار کنٹینر چلتا ہے، لیکن پھلی تیار نہیں ہوتی۔

درج ذیل اقدار ریکارڈ شدہ پوڈ سنیپ شاٹس سے اخذ کی گئی ہیں:

میدان	قدر
قدم	چل رہا ہے
پوڈ محفوظ	سچائی
تیار	جھوٹ
کنٹینر دوبارہ شروع ہونے کی تعداد	0

فورڈ کا ایونٹ کا پیغام اس کی وجہ بتاتا ہے۔

Readiness probe failed: HTTP probe failed with statuscode: 404

آپ کی ایپ میں اس کے لیے کوئی ہینڈلر نہیں ہے: /not-ready. HTTP تحقیقات 200 سے 399 تک جوابات کو قبول کرتی ہیں، لہذا یہ 404 تیاری کی جانچ میں ناکام ہوجاتا ہے۔ ناکام تیاری کی جانچ کنٹینر کو چلتی چھوڑ دیتی ہے، اسے تیار نہیں کے طور پر نشان زد کرتی ہے، اور تحقیقات جاری رکھتی ہے۔ براہ کرم تحقیقاتی دستاویزات کا حوالہ دیں۔

ریکارڈنگ بھی مختصراً شروع ہوئی۔ connection refused واقعہ یہ اکیلے اس خرابی کا سبب نہیں بنے گا۔ یہ صحت مند سرور کے سننا شروع کرنے سے پہلے ہوسکتا ہے۔ بعد میں آنے والا 404 ظاہر کرتا ہے کہ اس سرور نے درخواست کا جواب دیا۔ معلوم راستوں کو واحد تبدیل شدہ فیلڈز کے ساتھ ملا کر غلط تحقیقاتی راستوں کی شناخت کریں۔

تیاری کی ناکامی کی وجہ سے کنٹینر دوبارہ شروع نہیں ہوا۔ دوبارہ شروع ہونے والوں کی تعداد 0 تھی۔ یہ واقعہ کریش لوپ نہیں تھا۔

EndpointSlice اور سروس چیک کو دہرائیں۔ نیا پوڈ اب بھی ریکارڈ شدہ EndpointSlice میں درج ہوگا۔ ready: false، serving: falseاور terminating: false. پچھلے دو پوڈز کے پاس تیار اختتامی پوائنٹس تھے اور تمام 10 جوابات ان سے آئے تھے۔

یہ سروس فعال نہیں ہے۔ publishNotReadyAddresses. چونکہ اختتامی نقطہ کی تیاری اور شٹ ڈاؤن سیٹنگز اہم ہیں، اس مشاہدے کو تمام سروس کنفیگریشنز پر عام نہ کریں۔ EndpointSlice دستاویزات ان شرائط اور استثناء کو بیان کرتی ہیں۔

پس منظر کے لیے، FreeCodeCamp کے Kubernetes Self-healing Tutorial میں بھی تیاری کی کھوج کی گئی ہے۔ یہاں، ایک ناکام تحقیقات بتاتی ہے کہ نیا ریلیز کیوں مکمل نہیں کیا جا سکتا۔

اس اسٹیجنگ پوڈ کا استعمال کرتے ہوئے بحالی کی پوری ترتیب کو اس طرح دوبارہ چلائیں: BAD_POD. جاری رکھنے سے پہلے نارمل v2 کو چیک کریں۔

تعیناتی کی رکاوٹوں کی تشخیص کیسے کریں۔

تیسری ناکامی اس سلیکٹر کو Pod ٹیمپلیٹ میں شامل کرتی ہے۔

nodeSelector:
  rollout-lab.example.com/placement: no-matching-node

چیک کرنے کے بعد درخواست دیں کہ آیا کوئی مماثل نوڈس نہیں ہیں۔

k get nodes -l rollout-lab.example.com/placement=no-matching-node
k apply -f failure-lab/manifests/scheduling.json
k rollout status deployment/rollout-demo --timeout=10s

اگر پہلی کمانڈ نوڈس کی فہرست بناتی ہے، مطلوبہ مماثل سلیکٹر کا منظر نامہ برقرار نہیں رہتا ہے۔ جاری رکھنے سے پہلے اپنے لیبل کی ترتیب کو چیک کریں۔

بار بار ملکیت اور واقعہ کی تصدیق کو اپ ڈیٹ کرتا ہے۔ NEW_RS، BAD_PODاور POD_UID اس صورت میں. نیا فورڈ Pendingبالکل تصویر کی ناکامی کی طرح۔ لیکن Pending تصویری ڈاؤن لوڈز سمیت شیڈولنگ قطاروں اور کنٹینر سیٹ اپ قطاروں دونوں کا احاطہ کرتا ہے۔

درج کردہ اختلافات یہ ہیں:

ثبوت	تصویر کی خرابی	شیڈول کی ناکامی
پوڈ محفوظ	سچائی	غلط، وجہ ریزرویشن ممکن نہیں۔
نوڈ کا نام	تفویض کردہ لیب نوڈس	غیر حاضر
کنٹینر کی حیثیت	اسٹینڈ بائی کنٹینر	غیر حاضر
تشخیصی واقعہ	تصویر کی درآمد ناکام ہو گئی۔	ریزرویشن ناکام ہو گیا۔

کیلنڈر کے واقعات نے کہا:

0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

پوڈ کوبیلیٹ کو تفویض نہیں کیا گیا ہے کیونکہ کوئی نوڈس سلیکٹر کو مطمئن نہیں کرتا ہے۔ تصویر کی تلاش شروع نہیں ہوئی ہے۔ Kubernetes کو کسی بھی چیز سے ملنے کے لیے ایک نوڈ کی ضرورت ہوتی ہے۔ nodeSelector ان پر لیبل لگائیں جیسا کہ نوڈ سلیکشن آرٹیکل میں بیان کیا گیا ہے۔

سروس چیک کو دہرائیں۔ اس غیر شیڈول پوڈ میں کوئی Pod IP یا EndpointSlice اندراجات نہیں ہیں۔ اصل پوڈ نے تمام 10 ریکارڈ شدہ جوابات فراہم کیے ہیں۔

اس مخصوص پوڈ کا استعمال کرتے ہوئے مکمل بحالی کے سلسلے کو ایک بار اور لاگو کریں: BAD_POD. صحت مند v2 چیک کریں اور سروس کے جواب کو درست کریں۔ اپنے تجربات میں، ہم وسائل کی تھکن یا شیڈولنگ کی کسی بھی ممکنہ ناکامی کے بجائے سلیکٹر کی تضادات کی جانچ کرتے ہیں۔

صفائی کا طریقہ

ثبوت محفوظ کرنے کے بعد ڈسپوزایبل لیب کو ڈیلیٹ کر دیں۔

bash cleanup.sh

اسکرپٹ کولیما کے ڈوکر سیاق و سباق کو منتخب کرتی ہے اور اسے حذف کرتی ہے۔ fcc-rollout-labواضح طور پر لیب کی kubeconfig پاس کریں۔ نتائج کو ریکارڈ کریں اور تصدیق کریں کہ دیگر قسم کے کلسٹر کے نام تبدیل نہیں کیے گئے ہیں۔ یہ لیب کے کام کا بوجھ ختم کرتا ہے۔

ثبوت کا ایک ذخیرہ مقامی ساتھی ڈائرکٹری میں رہتا ہے۔ اگر آپ ٹیوٹوریل کو دوبارہ چلانا چاہتے ہیں، تو صفائی کے بعد تازہ عرق استعمال کریں۔ کنفیگریشن جان بوجھ کر پچھلے kubeconfig کو دوبارہ استعمال کرنے سے انکار کرتی ہے۔

نتیجہ

جبکہ پچھلی نظرثانی لاگ ان درخواستوں کا جواب دیتی رہی، نئی نظر ثانی تین مختلف غلطیوں کی وجہ سے روک دی گئی۔

مثال	جہاں رک گیا	سب سے مضبوط ثبوت	نمونہ کامیاب خرابی کی حالت
ویڈیو	کنٹینر کی تصویر کی تلاش	محفوظ پوڈ ٹیگ کی خرابی غائب ہے۔	دونوں بیچوں میں 20/20
تیاری	تیاری چیک کریں۔	چلنے والی پھلی؛ HTTP 404; تیار = غلط	10/10
شیڈولنگ	نوڈ کا انتخاب	PodScheduled=false; سلیکٹر کی مماثلت	10/10

اگلی تاخیر سے ریلیز کے لیے، ملکیت تعیناتی سے متعلقہ ReplicaSets اور Pods تک ہوتی ہے۔ یقینی بنائیں کہ پوڈ شیڈول ہے، کنٹینر شروع ہو چکا ہے، اور یہ تیار ہے۔ آپ غلطیاں تلاش کرنے کے لیے حالات اور واقعات کا استعمال کرتے ہیں، اور پھر یہ معلوم کرنے کے لیے سروس کے جوابات کا استعمال کرتے ہیں کہ اصل میں کس پوڈ نے جواب دیا۔

آخر میں، ہم کلائنٹ واچ ڈاگ ٹائم آؤٹ کو کنٹرولر پروگریس ڈیڈ لائن سے ممتاز کرتے ہیں اور کوئی نتیجہ اخذ کرنے سے پہلے مکمل بحالی کو یقینی بناتے ہیں۔ یہ نتائج ایک واحد نوڈ مقامی لیب اور محدود HTTP نمونوں سے ہیں۔ یہ پیداواری رویے یا مسلسل دستیابی کو قائم نہیں کرتا ہے۔