کبرنیٹس کو حل کرنے کے لیے ایک بصری گائیڈ

نوٹ. ترجمہ: یہ مضمون عوامی ڈومین میں شائع ہونے والے پروجیکٹ مواد کا حصہ ہے۔ learnk8s, تربیتی کمپنیوں اور انفرادی منتظمین کو Kubernetes کے ساتھ کام کرنے کے لیے۔ اس میں، ڈینیئل پولینسک، پروجیکٹ مینیجر، بصری ہدایات شیئر کرتے ہیں کہ K8s کلسٹر پر چلنے والی ایپلی کیشنز کے ساتھ عام مسائل کی صورت میں کیا اقدامات کیے جائیں۔

TL;DR: یہاں ایک خاکہ ہے جو آپ کو کبرنیٹس میں ڈیبگ تعیناتی میں مدد کرے گا۔

کلسٹر میں غلطیوں کو تلاش کرنے اور ٹھیک کرنے کے لیے فلو چارٹ۔ اصل (انگریزی میں) پر دستیاب ہے۔ PDF и تصویر کے طور پر.

Kubernetes پر ایپلیکیشن تعینات کرتے وقت، عام طور پر تین اجزاء ہوتے ہیں جن کی آپ کو وضاحت کرنے کی ضرورت ہوتی ہے:

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

یہاں ایک فوری گرافیکل خلاصہ ہے:

1) Kubernetes میں، ایپلی کیشنز لوڈ بیلنسرز کی دو تہوں کے ذریعے بیرونی دنیا سے ٹریفک وصول کرتی ہیں: اندرونی اور بیرونی۔

2) اندرونی توازن کو سروس کہا جاتا ہے، بیرونی کو Ingress کہا جاتا ہے۔

3) تعیناتی پوڈ بناتی ہے اور ان کی نگرانی کرتی ہے (وہ دستی طور پر نہیں بنائے جاتے ہیں)۔

ہم کہتے ہیں کہ آپ ایک سادہ ایپلیکیشن a la کو تعینات کرنا چاہتے ہیں۔ ہیلو ورلڈ. اس کے لیے YAML کنفیگریشن اس طرح نظر آئے گی:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

تعریف کافی لمبی ہے اور یہ الجھن میں پڑنا آسان ہے کہ اجزاء کا ایک دوسرے سے کیا تعلق ہے۔

مثال کے طور پر:

• آپ کو پورٹ 80 کب استعمال کرنا چاہیے اور 8080 کب استعمال کرنا چاہیے؟
• کیا مجھے ہر سروس کے لیے ایک نیا پورٹ بنانا چاہیے تاکہ وہ تنازعہ نہ کریں؟
• کیا لیبل کے نام اہم ہیں؟ کیا انہیں ہر جگہ ایک جیسا ہونا چاہیے؟

ڈیبگنگ پر توجہ مرکوز کرنے سے پہلے، آئیے یاد رکھیں کہ تینوں اجزاء ایک دوسرے سے کیسے متعلق ہیں۔ آئیے تعیناتی اور سروس کے ساتھ شروع کرتے ہیں۔

تعیناتی اور سروس کے درمیان تعلق

آپ حیران ہوں گے، لیکن تعیناتیاں اور خدمات کسی بھی طرح سے منسلک نہیں ہیں۔ اس کے بجائے، سروس تعیناتی کو نظرانداز کرتے ہوئے براہ راست پوڈز کی طرف اشارہ کرتی ہے۔

اس طرح، ہم اس بات میں دلچسپی رکھتے ہیں کہ پوڈس اور سروسز کا ایک دوسرے سے کیا تعلق ہے۔ تین چیزیں یاد رکھیں:

1. سلیکٹر (selectorسروس کے لیے کم از کم ایک پوڈ لیبل سے مماثل ہونا چاہیے۔
2. targetPort ملنا چاہئے containerPort پوڈ کے اندر کنٹینر.
3. port خدمت کچھ بھی ہو سکتی ہے۔ مختلف سروسز ایک ہی پورٹ استعمال کر سکتی ہیں کیونکہ ان کے مختلف IP پتے ہیں۔

مندرجہ ذیل خاکہ گرافیکل شکل میں مندرجہ بالا سبھی کی نمائندگی کرتا ہے:

1) تصور کریں کہ سروس ٹریفک کو کسی خاص پوڈ کی طرف لے جاتی ہے:

2) پوڈ بناتے وقت، آپ کو ضرور بتانا چاہیے۔ containerPort پھلیوں میں ہر کنٹینر کے لئے:

3) سروس بناتے وقت، آپ کو بتانا ضروری ہے۔ port и targetPort. لیکن کنٹینر سے جڑنے کے لیے کون سا استعمال ہوتا ہے؟

4) کے ذریعے targetPort. یہ میچ ہونا چاہئے containerPort.

5) مان لیں کہ پورٹ 3000 کنٹینر میں کھلا ہے۔ پھر ویلیو targetPort ایک ہی ہونا چاہئے.

YAML فائل میں، لیبل اور ports / targetPort ملنا چاہیے:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

لیبل کے بارے میں کیا ہے track: canary تعیناتی سیکشن کے سب سے اوپر؟ کیا یہ میچ ہونا چاہئے؟

یہ لیبل تعیناتی کے لیے مخصوص ہے اور سروس کے ذریعے ٹریفک کو روٹ کرنے کے لیے استعمال نہیں کیا جاتا ہے۔ دوسرے الفاظ میں، اسے ہٹایا جا سکتا ہے یا ایک مختلف قدر تفویض کی جا سکتی ہے۔

سلیکٹر کے بارے میں کیا خیال ہے؟ matchLabels?

یہ ہمیشہ پوڈ کے لیبلز سے مماثل ہونا چاہیے۔چونکہ یہ تعیناتی کے ذریعے پوڈس کو ٹریک کرنے کے لیے استعمال کیا جاتا ہے۔

آئیے فرض کریں کہ آپ نے درست ترامیم کی ہیں۔ انہیں کیسے چیک کریں؟

آپ پوڈ لیبل کو درج ذیل کمانڈ سے چیک کر سکتے ہیں۔

kubectl get pods --show-labels

یا، اگر پوڈز کا تعلق متعدد ایپلی کیشنز سے ہے:

kubectl get pods --selector any-name=my-app --show-labels

Где any-name=my-app ایک لیبل ہے any-name: my-app.

کیا کوئی مشکلات باقی ہیں؟

آپ پوڈ سے جڑ سکتے ہیں! ایسا کرنے کے لیے آپ کو کمانڈ استعمال کرنے کی ضرورت ہے۔ port-forward kubectl میں یہ آپ کو سروس سے جڑنے اور کنکشن چیک کرنے کی اجازت دیتا ہے۔

kubectl port-forward service/<service name> 3000:80

یہاں:

• service/<service name> - سروس کا نام؛ ہمارے معاملے میں یہ ہے my-service;
• 3000 وہ پورٹ ہے جسے کمپیوٹر پر کھولنے کی ضرورت ہے۔
• 80 - فیلڈ میں مخصوص پورٹ port سروس

اگر کنکشن قائم کیا گیا تھا، تو ترتیبات درست ہیں.

اگر کنکشن ناکام ہوجاتا ہے تو، لیبلز کے ساتھ کوئی مسئلہ ہے یا بندرگاہیں مماثل نہیں ہیں۔

خدمت اور داخلے کے درمیان تعلق

درخواست تک رسائی فراہم کرنے کا اگلا مرحلہ Ingress کو ترتیب دینے سے متعلق ہے۔ Ingress کو یہ جاننے کی ضرورت ہے کہ سروس کیسے تلاش کی جائے، پھر پوڈز تلاش کریں اور ان پر براہ راست ٹریفک کریں۔ Ingress نام اور کھلی بندرگاہ کے ذریعہ مطلوبہ خدمت تلاش کرتا ہے۔

Ingress اور Service کی تفصیل میں دو پیرامیٹرز کا مماثل ہونا ضروری ہے:

1. servicePort Ingress میں پیرامیٹر سے مماثل ہونا ضروری ہے۔ port سروس میں؛
2. serviceName Ingress میدان سے مماثل ہونا ضروری ہے name سروس میں.

درج ذیل خاکہ پورٹ کنکشن کا خلاصہ کرتا ہے:

1) جیسا کہ آپ پہلے ہی جانتے ہیں، سروس ایک خاص بات سنتی ہے۔ port:

2) Ingress نامی ایک پیرامیٹر ہے۔ servicePort:

3) یہ پیرامیٹر (servicePort) ہمیشہ مماثل ہونا چاہئے۔ port سروس کی تعریف میں:

4) اگر سروس میں پورٹ 80 کی وضاحت کی گئی ہے، تو یہ ضروری ہے۔ servicePort 80 کے برابر بھی تھا:

عملی طور پر، آپ کو مندرجہ ذیل لائنوں پر توجہ دینے کی ضرورت ہے:

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

کیسے چیک کریں کہ آیا Ingress چل رہا ہے؟

آپ کے ساتھ طریقہ استعمال کر سکتے ہیں kubectl port-forward، لیکن سروس کے بجائے آپ کو Ingress کنٹرولر سے جڑنے کی ضرورت ہے۔

پہلے آپ کو Ingress کنٹرولر کے ساتھ پوڈ کا نام معلوم کرنا ہوگا:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Ingress pod تلاش کریں (یہ مختلف نام کی جگہ میں ہو سکتا ہے) اور کمانڈ چلائیں۔ describeپورٹ نمبر معلوم کرنے کے لیے:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

آخر میں، پوڈ سے جڑیں:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

اب جب بھی آپ اپنے کمپیوٹر پر پورٹ 3000 پر کوئی درخواست بھیجیں گے، اسے Ingress کنٹرولر کے ساتھ پوڈ کے پورٹ 80 پر بھیج دیا جائے گا۔ کے پاس جا کر http://localhost:3000، آپ کو درخواست کے ذریعہ تیار کردہ صفحہ دیکھنا چاہئے۔

بندرگاہوں کا خلاصہ

آئیے ایک بار پھر یاد رکھیں کہ کن بندرگاہوں اور لیبلز کا مماثل ہونا ضروری ہے:

1. سروس کی تعریف میں سلیکٹر کا پوڈ کے لیبل سے مماثل ہونا چاہیے۔
2. targetPort تعریف میں سروس کا مماثل ہونا ضروری ہے۔ containerPort پھلی کے اندر کنٹینر؛
3. port تعریف میں سروس کچھ بھی ہو سکتی ہے۔ مختلف سروسز ایک ہی پورٹ استعمال کر سکتی ہیں کیونکہ ان کے مختلف IP پتے ہیں۔
4. servicePort داخل ہونا ضروری ہے۔ port سروس کی تعریف میں؛
5. سروس کا نام فیلڈ سے مماثل ہونا چاہیے۔ serviceName داخلے میں

بدقسمتی سے، یہ جاننا کافی نہیں ہے کہ YAML کنفیگریشن کو صحیح طریقے سے کیسے بنایا جائے۔

جب چیزیں غلط ہوجاتی ہیں تو کیا ہوتا ہے؟

پھلی شروع نہیں ہوسکتی ہے یا یہ گر سکتی ہے۔

Kubernetes میں درخواست کے مسائل کی تشخیص کے لیے 3 اقدامات

اپنی تعیناتی کو ڈیبگ کرنا شروع کرنے سے پہلے، آپ کو یہ اچھی طرح سمجھنا ہوگا کہ Kubernetes کیسے کام کرتا ہے۔

چونکہ K8s میں ڈاؤن لوڈ کی گئی ہر ایپلیکیشن میں تین اجزاء ہوتے ہیں، اس لیے انہیں ایک خاص ترتیب میں ڈیبگ کیا جانا چاہیے، بالکل نیچے سے شروع ہو کر۔

1. پہلے آپ کو یہ یقینی بنانا ہوگا کہ پوڈ کام کر رہے ہیں، پھر...
2. چیک کریں کہ آیا سروس پوڈز کو ٹریفک فراہم کرتی ہے، اور پھر...
3. چیک کریں کہ آیا داخلے کو صحیح طریقے سے ترتیب دیا گیا ہے۔

بصری نمائندگی:

1) آپ کو نیچے سے مسائل کی تلاش شروع کرنی چاہیے۔ سب سے پہلے چیک کریں کہ پوڈ کے سٹیٹس ہیں۔ Ready и Running:

2) اگر پھلیاں تیار ہیں (Ready)، آپ کو یہ معلوم کرنا چاہیے کہ آیا سروس pods کے درمیان ٹریفک کو تقسیم کرتی ہے:

3) آخر میں، آپ کو خدمت اور داخلے کے درمیان تعلق کا تجزیہ کرنے کی ضرورت ہے:

1. پھلیوں کی تشخیص

زیادہ تر معاملات میں، مسئلہ پوڈ سے متعلق ہے. اس بات کو یقینی بنائیں کہ پھلی اس طرح درج ہیں۔ Ready и Running. آپ کمانڈ کا استعمال کرتے ہوئے اسے چیک کر سکتے ہیں:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

اوپر کمانڈ آؤٹ پٹ میں، آخری پوڈ درج ہے۔ Running и Readyتاہم، یہ دوسرے دو کے لیے ایسا نہیں ہے۔

کیسے سمجھیں کہ کیا غلط ہوا؟

پوڈ کی تشخیص کے لیے چار مفید حکم ہیں:

1. kubectl logs <имя pod'а> آپ کو پوڈ میں کنٹینرز سے لاگز نکالنے کی اجازت دیتا ہے؛
2. kubectl describe pod <имя pod'а> آپ کو پوڈ سے وابستہ واقعات کی فہرست دیکھنے کی اجازت دیتا ہے۔
3. kubectl get pod <имя pod'а> آپ کو Kubernetes میں ذخیرہ شدہ پوڈ کی YAML کنفیگریشن حاصل کرنے کی اجازت دیتا ہے۔
4. kubectl exec -ti <имя pod'а> bash آپ کو پوڈ کنٹینرز میں سے ایک میں ایک انٹرایکٹو کمانڈ شیل لانچ کرنے کی اجازت دیتا ہے۔

آپ کو کون سا انتخاب کرنا چاہئے؟

حقیقت یہ ہے کہ کوئی عالمگیر حکم نہیں ہے۔ ان کا ایک مجموعہ استعمال کیا جانا چاہئے.

عام پھلی کے مسائل

پوڈ کی غلطیوں کی دو اہم قسمیں ہیں: اسٹارٹ اپ کی غلطیاں اور رن ٹائم کی غلطیاں۔

آغاز کی خرابیاں:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

رن ٹائم کی خرابیاں:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

کچھ غلطیاں دوسروں سے زیادہ عام ہیں۔ یہاں کچھ سب سے عام غلطیاں ہیں اور انہیں کیسے ٹھیک کیا جائے۔

امیج پل بیک آف

یہ خرابی اس وقت ظاہر ہوتی ہے جب Kubernetes پوڈ کنٹینرز میں سے ایک کے لیے تصویر حاصل کرنے سے قاصر ہوتا ہے۔ یہاں اس کی تین سب سے عام وجوہات ہیں:

1. تصویر کا نام غلط ہے - مثال کے طور پر، آپ نے اس میں غلطی کی ہے، یا تصویر موجود نہیں ہے؛
2. تصویر کے لیے ایک غیر موجود ٹیگ متعین کیا گیا تھا۔
3. تصویر نجی رجسٹری میں محفوظ ہے اور Kubernetes کو اس تک رسائی کی اجازت نہیں ہے۔

پہلی دو وجوہات کو ختم کرنا آسان ہے - صرف تصویر کا نام اور ٹیگ درست کریں۔ مؤخر الذکر کی صورت میں، آپ کو سیکریٹ میں بند رجسٹری کے لیے اسناد داخل کرنے اور پوڈز میں اس کے لنکس شامل کرنے کی ضرورت ہے۔ Kubernetes دستاویزات میں ایک مثال ہے یہ کیسے کیا جا سکتا ہے.

کریش لوپ بیک آف

Kubenetes ایک غلطی پھینکتا ہے۔ CrashLoopBackOff، اگر کنٹینر شروع نہیں ہوسکتا ہے۔ یہ عام طور پر ہوتا ہے جب:

1. ایپلی کیشن میں ایک بگ ہے جو اسے شروع ہونے سے روکتا ہے۔
2. کنٹینر غلط طریقے سے ترتیب دیا گیا ہے۔;
3. Liveness ٹیسٹ بہت بار ناکام ہو چکا ہے۔

اس کی ناکامی کی وجہ جاننے کے لیے آپ کو کنٹینر سے لاگز تک پہنچنے کی کوشش کرنی چاہیے۔ اگر لاگز تک رسائی مشکل ہے کیونکہ کنٹینر بہت تیزی سے دوبارہ شروع ہوتا ہے، تو آپ درج ذیل کمانڈ استعمال کر سکتے ہیں:

kubectl logs <pod-name> --previous

یہ کنٹینر کے پچھلے اوتار سے غلطی کے پیغامات دکھاتا ہے۔

RunContainerError

یہ خرابی اس وقت ہوتی ہے جب کنٹینر شروع ہونے میں ناکام ہوجاتا ہے۔ یہ ایپلیکیشن لانچ ہونے سے پہلے کے لمحے سے مطابقت رکھتا ہے۔ یہ عام طور پر غلط ترتیبات کی وجہ سے ہوتا ہے، مثال کے طور پر:

• غیر موجود والیوم کو ماؤنٹ کرنے کی کوشش کرنا جیسے ConfigMap یا Secrets؛
• صرف پڑھنے کے حجم کو پڑھنے لکھنے کے طور پر ماؤنٹ کرنے کی کوشش۔

ٹیم ایسی غلطیوں کا تجزیہ کرنے کے لیے موزوں ہے۔ kubectl describe pod <pod-name>.

پوڈز زیر التواء حالت میں ہیں۔

ایک بار بننے کے بعد، پھلی حالت میں رہتی ہے۔ Pending.

ایسا کیوں ہوتا ہے؟

یہاں ممکنہ وجوہات ہیں (میں فرض کر رہا ہوں کہ شیڈولر ٹھیک کام کر رہا ہے):

1. پوڈ کو چلانے کے لیے کلسٹر کے پاس اتنے وسائل نہیں ہیں، جیسے پروسیسنگ پاور اور میموری۔
2. آبجیکٹ مناسب نام کی جگہ پر انسٹال ہے۔ ResourceQuota اور پوڈ بنانے سے نام کی جگہ کوٹہ سے آگے بڑھ جائے گی۔
3. Pod Pending کا پابند ہے۔ PersistentVolumeClaim.

اس صورت میں، یہ کمانڈ استعمال کرنے کی سفارش کی جاتی ہے kubectl describe اور سیکشن چیک کریں۔ Events:

kubectl describe pod <pod name>

سے متعلق غلطیوں کی صورت میں ResourceQuotas، کمانڈ کا استعمال کرتے ہوئے کلسٹر لاگز کو دیکھنے کی سفارش کی جاتی ہے۔

kubectl get events --sort-by=.metadata.creationTimestamp

پھلیاں تیار نہیں ہیں۔

اگر پوڈ کے طور پر درج ہے۔ Running، لیکن حالت میں نہیں ہے۔ Ready، کا مطلب ہے اس کی تیاری کی جانچ کرنا (تیاری کی تحقیقات) ناکام

جب ایسا ہوتا ہے، پوڈ سروس سے منسلک نہیں ہوتا ہے اور اس پر کوئی ٹریفک نہیں آتی ہے۔ تیاری ٹیسٹ میں ناکامی درخواست میں دشواریوں کی وجہ سے ہوتی ہے۔ اس صورت میں، غلطی کو تلاش کرنے کے لئے، آپ کو سیکشن کا تجزیہ کرنے کی ضرورت ہے Events کمانڈ آؤٹ پٹ میں kubectl describe.

2. سروس کی تشخیص

اگر پھلی کے طور پر درج ہیں۔ Running и Ready، لیکن ابھی تک ایپلیکیشن کی طرف سے کوئی جواب نہیں ہے، آپ کو سروس سیٹنگز کو چیک کرنا چاہیے۔

خدمات ان کے لیبلز کے لحاظ سے ٹریفک کو پوڈ پر روٹ کرنے کے لیے ذمہ دار ہیں۔ لہذا، سب سے پہلے آپ کو یہ چیک کرنے کی ضرورت ہے کہ سروس کے ساتھ کتنے پوڈ کام کرتے ہیں۔ ایسا کرنے کے لیے، آپ سروس میں آخری پوائنٹس کو چیک کر سکتے ہیں:

kubectl describe service <service-name> | grep Endpoints

اختتامی نقطہ فارم کی اقدار کا ایک جوڑا ہے۔ <IP-адрес:порт>، اور کم از کم ایک ایسا جوڑا آؤٹ پٹ میں موجود ہونا چاہیے (یعنی سروس کے ساتھ کم از کم ایک پوڈ کام کرتا ہے)۔

اگر سیکشن Endpoins خالی، دو اختیارات ممکن ہیں:

1. صحیح لیبل کے ساتھ کوئی پوڈ نہیں ہے (اشارہ: چیک کریں کہ آیا نام کی جگہ صحیح طریقے سے منتخب ہوئی ہے)؛
2. سلیکٹر میں سروس لیبلز میں ایک خرابی ہے۔

اگر آپ کو اختتامی پوائنٹس کی فہرست نظر آتی ہے لیکن پھر بھی آپ ایپلی کیشن تک رسائی حاصل نہیں کر سکتے ہیں، تو ممکنہ طور پر مجرم ایک بگ ہے targetPort سروس کی تفصیل میں۔

سروس کی فعالیت کو کیسے چیک کریں؟

سروس کی قسم سے قطع نظر، آپ کمانڈ استعمال کر سکتے ہیں۔ kubectl port-forward اس سے جڑنے کے لیے:

kubectl port-forward service/<service-name> 3000:80

یہاں:

• <service-name> - سروس کا نام؛
• 3000 وہ پورٹ ہے جسے آپ کمپیوٹر پر کھولتے ہیں۔
• 80 - سروس سائیڈ پر پورٹ۔

3. داخلی تشخیص

اگر آپ نے یہ اب تک پڑھا ہے تو:

• pods کے طور پر درج ہیں Running и Ready;
• سروس کامیابی سے ٹریفک کو پوڈز میں تقسیم کرتی ہے۔

تاہم، آپ اب بھی ایپ تک نہیں پہنچ سکتے۔

اس کا مطلب یہ ہے کہ Ingress کنٹرولر زیادہ تر ممکنہ طور پر صحیح طریقے سے ترتیب نہیں دیا گیا ہے۔ چونکہ Ingress کنٹرولر کلسٹر میں فریق ثالث کا جزو ہے، اس لیے اس کی قسم کے لحاظ سے ڈیبگنگ کے مختلف طریقے ہیں۔

لیکن اس سے پہلے کہ آپ Ingress کو ترتیب دینے کے لیے خصوصی ٹولز کا سہارا لیں، آپ کچھ بہت آسان کر سکتے ہیں۔ Ingress استعمال کرتا ہے serviceName и servicePort سروس سے منسلک کرنے کے لئے. آپ کو یہ چیک کرنے کی ضرورت ہے کہ آیا وہ صحیح طریقے سے تشکیل شدہ ہیں۔ آپ کمانڈ کا استعمال کرتے ہوئے یہ کر سکتے ہیں:

kubectl describe ingress <ingress-name>

اگر کالم Backend خالی، ترتیب کی خرابی کا زیادہ امکان ہے۔ اگر بیک اینڈ اپنی جگہ پر ہیں، لیکن ایپلیکیشن ابھی تک قابل رسائی نہیں ہے، تو پھر مسئلہ اس سے متعلق ہو سکتا ہے:

• عوامی انٹرنیٹ سے رسائی کی ترتیبات میں داخل ہونا؛
• عوامی انٹرنیٹ سے کلسٹر رسائی کی ترتیبات۔

آپ انگریس پوڈ سے براہ راست جڑ کر انفراسٹرکچر کے مسائل کی نشاندہی کر سکتے ہیں۔ ایسا کرنے کے لیے، پہلے Ingress Controller pod تلاش کریں (یہ مختلف نام کی جگہ میں ہو سکتا ہے):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

کمانڈ استعمال کریں۔ describeپورٹ سیٹ کرنے کے لیے:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

آخر میں، پوڈ سے جڑیں:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

اب کمپیوٹر پر پورٹ 3000 کی تمام درخواستوں کو پوڈ کے پورٹ 80 پر بھیج دیا جائے گا۔

کیا یہ اب کام کرتا ہے؟

• اگر ہاں، تو مسئلہ بنیادی ڈھانچے کا ہے۔ یہ معلوم کرنا ضروری ہے کہ ٹریفک کو کلسٹر تک کیسے پہنچایا جاتا ہے۔
• اگر نہیں، تو مسئلہ Ingress کنٹرولر کے ساتھ ہے۔

اگر آپ Ingress کنٹرولر کو کام کرنے کے لیے حاصل نہیں کر سکتے ہیں، تو آپ کو اسے ڈیبگ کرنا پڑے گا۔

Ingress کنٹرولرز کی بہت سی قسمیں ہیں۔ سب سے زیادہ مقبول ہیں Nginx، HAProxy، Traefik، وغیرہ۔ (موجودہ حل کے بارے میں مزید معلومات کے لیے، دیکھیں ہمارا جائزہ - تقریبا. ترجمہ) آپ کو متعلقہ کنٹرولر دستاویزات میں ٹربل شوٹنگ گائیڈ سے رجوع کرنا چاہیے۔ کیونکہ Nginx میں داخل ہونا سب سے زیادہ مقبول Ingress کنٹرولر ہے، ہم نے اس سے متعلق مسائل کو حل کرنے کے لیے مضمون میں کچھ نکات شامل کیے ہیں۔

Ingress Nginx کنٹرولر کو ڈیبگ کرنا

Ingress-nginx پروجیکٹ کا ایک اہلکار ہے۔ kubectl کے لیے پلگ ان. ٹیم kubectl ingress-nginx کے لئے استعمال کیا جا سکتا ہے:

• لاگز، بیک اینڈ، سرٹیفکیٹ وغیرہ کا تجزیہ؛
• داخلے سے کنکشن؛
• موجودہ ترتیب کا مطالعہ.

درج ذیل تین احکامات اس میں آپ کی مدد کریں گے۔

• kubectl ingress-nginx lint --.چیک nginx.conf;
• kubectl ingress-nginx backend - پسدید کو دریافت کرتا ہے (کی طرح kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - نوشتہ جات کو چیک کرتا ہے۔

نوٹ کریں کہ کچھ معاملات میں آپ کو جھنڈے کا استعمال کرتے ہوئے Ingress کنٹرولر کے لیے صحیح نام کی جگہ بتانے کی ضرورت پڑ سکتی ہے۔ --namespace <name>.

خلاصہ

اگر آپ نہیں جانتے ہیں کہ کہاں سے شروع کرنا ہے تو Kubernetes کا ازالہ کرنا مشکل ہو سکتا ہے۔ آپ کو ہمیشہ نیچے سے اوپر والے طریقے سے مسئلہ سے رجوع کرنا چاہیے: پوڈز سے شروع کریں، اور پھر سروس اور انگریس پر جائیں۔ اس مضمون میں بیان کردہ ڈیبگنگ تکنیکوں کو دیگر اشیاء پر لاگو کیا جا سکتا ہے، جیسے:

• بیکار نوکریاں اور کرون جابس؛
• اسٹیٹفول سیٹس اور ڈیمون سیٹس۔

میں اظہار تشکر کرتا ہوں۔ Gergely Risko, ڈینیئل ویبل и چارلس کرسٹیراج قیمتی تبصرے اور اضافے کے لیے۔

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes pods میں ڈیبگ کرنے کے لیے kubectl-debug پلگ ان؛ "
• «Kubernetes کے آپریشن میں 6 تفریحی سسٹم کیڑے [اور ان کا حل]؛ "
• «Kubernetes پر چلنے والی ایپلیکیشنز کے ڈویلپرز کے لیے ٹولز؛ "
• «ہماری SRE روزمرہ کی زندگی سے 6 عملی کہانیاں '.

ماخذ: www.habr.com