ڪبرنيٽس کي حل ڪرڻ لاءِ هڪ بصري گائيڊ

نوٽ. ترجمو: هي آرٽيڪل عوامي ڊومين ۾ شايع ٿيل منصوبي جي مواد جو حصو آهي learnk8s، ٽريننگ ڪمپنيون ۽ انفرادي منتظمين ڪبرنيٽس سان ڪم ڪرڻ لاءِ. ان ۾، ڊينيئل پولينسڪ، پروجيڪٽ مئنيجر، بصري هدايتون شيئر ڪري ٿو ته ڪي 8s ڪلستر تي هلندڙ ايپليڪيشنن سان عام مسئلن جي صورت ۾ ڪهڙا قدم کڻڻ گهرجن.

TL؛ DR: هتي هڪ خاڪو آهي جيڪو توهان کي ڪبرنيٽس ۾ ڊيبگ ڊيبگ ڪرڻ ۾ مدد ڪندو:

فلو چارٽ هڪ ڪلستر ۾ غلطيون ڳولڻ ۽ درست ڪرڻ لاء. اصل (انگريزي ۾) موجود آهي تي ڪر PDF и تصوير وانگر.

جڏهن ڪوبرنيٽس ڏانهن ايپليڪيشن کي ترتيب ڏيڻ، اتي عام طور تي ٽي حصا آهن جيڪي توهان کي وضاحت ڪرڻ جي ضرورت آهي:

• رنيجرز - هي ايپليڪيشن جون ڪاپيون ٺاهڻ جو هڪ قسم جو طريقو آهي، جنهن کي پوڊ سڏيو ويندو آهي؛
• خدمت - اندروني لوڊ بيلنس ڪندڙ جيڪو پوڊ جي وچ ۾ ٽرئفڪ کي ورهائي ٿو؛
• اندر اچڻ - هڪ وضاحت ڪيئن ٽريفڪ ٻاهرئين دنيا کان سروس تائين پهچي ويندي.

هتي هڪ تڪڙو گرافڪ خلاصو آهي:

1) ڪبرنيٽس ۾، ايپليڪيشنون ٽريفڪ وصول ڪن ٿيون ٻاهرين دنيا مان لوڊ بيلنس جي ٻن تہن ذريعي: اندروني ۽ بيروني.

2) اندروني بيلنس کي خدمت سڏيو ويندو آهي، ٻاهرئين هڪ کي Ingress سڏيو ويندو آهي.

3) تعیناتي پوڊ ٺاهي ٿي ۽ انهن جي نگراني ڪري ٿي (اهي دستي طور تي نه ٺاهيا ويا آهن).

اچو ته چئو ته توهان هڪ سادي ايپليڪيشن کي ترتيب ڏيڻ چاهيو ٿا هيلو ورلڊ. ان لاءِ 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?

اهو هميشه پوڊ جي ليبل سان ملائڻ گهرجي, ڇاڪاڻ ته ان کي استعمال ڪيو ويندو آهي deployment ذريعي پوڊ کي ٽريڪ ڪرڻ لاء.

اچو ته سمجهون ته توهان صحيح تبديليون ڪيون آهن. ان کي ڪيئن چيڪ ڪرڻ لاء؟

توھان ھيٺ ڏنل حڪم سان پوڊ ليبل چيڪ ڪري سگھو ٿا:

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 نالي ۽ اوپن پورٽ ذريعي گهربل خدمت ڳولي ٿو.

داخلا ۽ خدمت جي وضاحت ۾ ٻه پيرا ميٽر ملن ٿا:

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 ڪنٽرولر سان ڳنڍڻ جي ضرورت آهي.

پهرين توهان کي انگريس ڪنٽرولر سان پوڊ جو نالو ڳولڻ جي ضرورت آهي:

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
Ports:         80/TCP, 443/TCP, 18080/TCP

آخرڪار، پوڊ سان ڳنڍيو:

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

هاڻي هر ڀيري جڏهن توهان پنهنجي ڪمپيوٽر تي پورٽ 3000 تي هڪ درخواست موڪليندا آهيو، اهو انگريس ڪنٽرولر سان پوڊ جي پورٽ 80 ڏانهن موڪليو ويندو. وڃڻ سان http://localhost:3000، توھان کي ڏسڻ گھرجي اھو صفحو جيڪو ايپليڪيشن پاران ٺاھيل آھي.

بندرگاهن جو خلاصو

اچو ته هڪ ڀيرو ٻيهر ياد رکون ته ڪهڙيون بندرگاهن ۽ ليبل ملن ٿا:

1. خدمت جي تعريف ۾ چونڊيندڙ کي لازمي طور تي پوڊ جي ليبل سان ملندو؛
2. targetPort تعريف ۾ خدمت کي ملائڻ گهرجي containerPort پوڊ اندر ڪنٽينر؛
3. port تعريف ۾ خدمت ڪجھ به ٿي سگھي ٿو. مختلف خدمتون ساڳئي بندرگاهن کي استعمال ڪري سگهن ٿيون ڇاڪاڻ ته انهن وٽ مختلف IP پتا آهن؛
4. servicePort داخل ٿيڻ لازمي آهي port خدمت جي تعريف ۾؛
5. خدمت جو نالو فيلڊ سان ملائڻ گهرجي serviceName داخل ٿيڻ ۾.

بدقسمتي سان، اهو ڄاڻڻ ڪافي ناهي ته YAML ترتيب کي صحيح طريقي سان ڪيئن ٺاهيو وڃي.

ڇا ٿيندو جڏهن شيون غلط ٿي وڃن؟

پوڊ شروع نه ٿي سگھي ٿو يا اهو حادثو ٿي سگھي ٿو.

ڪبرنيٽس ۾ ايپليڪيشن مسئلن جي تشخيص لاءِ 3 مرحلا

ان کان اڳ جو توھان پنھنجي ڊيبنگ کي ڊيبگ ڪرڻ شروع ڪريو، توھان کي چڱيءَ طرح سمجھڻ گھرجي ته ڪبرنيٽس ڪيئن ڪم ڪري ٿو.

جيئن ته K8s ۾ ڊائون لوڊ ڪيل هر ايپليڪيشن جا ٽي حصا آهن، انهن کي هڪ خاص ترتيب ۾ ڊيبگ ڪيو وڃي، بلڪل هيٺان کان شروع ٿئي ٿو.

1. پهرين توهان کي پڪ ڪرڻ جي ضرورت آهي ته پوڊ ڪم ڪري رهيا آهن، پوء ...
2. چيڪ ڪريو ته خدمت پوڊز کي ٽرئفڪ فراهم ڪري ٿي، ۽ پوءِ...
3. چيڪ ڪريو ته Ingress صحيح ترتيب ڏنل آهي.

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

1) توھان کي ھيٺين کان مسئلن کي ڳولڻ شروع ڪرڻ گھرجي. پهرين چيڪ ڪريو ته پوڊ جون حالتون آهن Ready и Running:

2) جيڪڏهن ٻج تيار آهن (Ready)، توهان کي اهو معلوم ڪرڻ گهرجي ته ڇا خدمت پوڊ جي وچ ۾ ٽرئفڪ کي ورهائي ٿو:

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'а> توھان کي اجازت ڏئي ٿو YAML ترتيب حاصل ڪرڻ لاءِ ڪبرنيٽس ۾ ذخيرو ٿيل پوڊ جي؛
4. kubectl exec -ti <имя pod'а> bash توهان کي پوڊ ڪنٽينرز مان هڪ ۾ هڪ انٽرويو ڪمانڊ شيل لانچ ڪرڻ جي اجازت ڏئي ٿي

توهان کي ڪهڙو چونڊڻ گهرجي؟

حقيقت اها آهي ته ڪو عالمگير حڪم ناهي. انهن جو هڪ ميلاپ استعمال ڪرڻ گهرجي.

عام پوڊ مسئلا

پوڊ غلطين جا ٻه مکيه قسم آهن: شروعاتي غلطيون ۽ رن ٽائم غلطيون.

شروعاتي غلطيون:

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

رن ٽائم غلطيون:

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

ڪجهه غلطيون ٻين کان وڌيڪ عام آهن. هتي ڪجھ سڀ کان عام غلطيون آهن ۽ انهن کي ڪيئن حل ڪجي.

ImagePullBackOff

هي غلطي تڏهن ٿيندي آهي جڏهن ڪبرنيٽس پوڊ ڪنٽينرز مان هڪ لاءِ تصوير حاصل ڪرڻ جي قابل ناهي. هتي هن جا ٽي سڀ کان عام سبب آهن:

1. تصوير جو نالو غلط آهي - مثال طور، توهان ان ۾ غلطي ڪئي، يا تصوير موجود ناهي؛
2. تصوير لاءِ هڪ غير موجود ٽيگ بيان ڪيو ويو آهي؛
3. تصوير هڪ خانگي رجسٽري ۾ ذخيرو ٿيل آهي ۽ ڪبرنيٽس کي ان تائين رسائي جي اجازت ناهي.

پهرين ٻن سببن کي ختم ڪرڻ آسان آهي - صرف تصوير جو نالو ۽ ٽيگ درست ڪريو. بعد جي صورت ۾، توهان کي رازداري ۾ بند ٿيل رجسٽري لاءِ سندون داخل ڪرڻ ۽ پوڊز ۾ ان لاءِ لنڪ شامل ڪرڻ جي ضرورت آهي. Kubernetes دستاويزن ۾ هڪ مثال آهي اهو ڪيئن ڪري سگهجي ٿو.

ڪرش لوپ واپس بند

Kubenetes هڪ غلطي اڇلائي ٿو CrashLoopBackOff، جيڪڏهن ڪنٽينر شروع نه ٿي سگهي. اهو عام طور تي ٿئي ٿو جڏهن:

1. ايپليڪيشن ۾ هڪ بگ آهي جيڪو ان کي لانچ ڪرڻ کان روڪي ٿو؛
2. ڪنٽرول غلط ترتيب ڏنل;
3. Liveness ٽيسٽ ڪيترائي ڀيرا ناڪام ٿي چڪي آهي.

توهان کي ڪوشش ڪرڻ گهرجي ته ڪنٽينر مان لاگز حاصل ڪرڻ لاء ان جي ناڪامي جو سبب ڳولڻ لاء. جيڪڏهن لاگز تائين رسائي ڪرڻ ڏکيو آهي ڇو ته ڪنٽينر تمام جلدي ٻيهر شروع ٿئي ٿو، توهان هيٺ ڏنل حڪم استعمال ڪري سگهو ٿا:

kubectl logs <pod-name> --previous

اهو ڪنٽينر جي پوئين اوتار کان غلطي پيغام ڏيکاري ٿو.

رن ڪنٽينر جي غلطي

هي غلطي ٿيندي آهي جڏهن ڪنٽينر شروع ٿيڻ ۾ ناڪام ٿيندو آهي. اهو ايپليڪيشن شروع ٿيڻ کان اڳ واري لمحي سان ملندو آهي. اهو عام طور تي غلط سيٽنگن جي ڪري آهي، مثال طور:

• هڪ غير موجود حجم کي نصب ڪرڻ جي ڪوشش ڪرڻ جهڙوڪ ConfigMap يا راز؛
• صرف پڙهڻ واري حجم کي پڙهڻ جي طور تي لکڻ جي ڪوشش.

ٽيم اهڙين غلطين جو تجزيو ڪرڻ لاءِ موزون آهي kubectl describe pod <pod-name>.

پوڊز التوا ۾ آهن

هڪ دفعو پيدا ٿيو، پوڊ رياست ۾ رهي ٿو Pending.

ائين ڇو ٿو ٿئي؟

هتي ممڪن سبب آهن (مان سمجهان ٿو ته شيڊولر ٺيڪ ڪم ڪري رهيو آهي):

1. ڪلستر وٽ ڪافي وسيلا نه آهن، جهڙوڪ پروسيسنگ پاور ۽ ميموري، پوڊ کي هلائڻ لاءِ.
2. اعتراض مناسب نالي واري جاء تي نصب ڪيو ويو آهي ResourceQuota ۽ پوڊ ٺاھڻ سبب نالي جي جڳھ ڪوٽا کان ٻاھر ٿي ويندي.
3. پوڊ 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>.

خلاصو

ڪبرنيٽس کي حل ڪرڻ مشڪل ٿي سگهي ٿو جيڪڏهن توهان کي خبر ناهي ته ڪٿان شروع ڪجي. توھان کي ھميشه ھيٺئين پاسي کان مسئلي ڏانھن وڃڻ گھرجي: پوڊس سان شروع ڪريو، ۽ پوءِ خدمت ۽ داخل ٿيڻ ڏانھن وڃو. هن آرٽيڪل ۾ بيان ڪيل ڊيبگنگ ٽيڪنڪ ٻين شين تي لاڳو ٿي سگهن ٿيون، جهڙوڪ:

• بيڪار نوڪريون ۽ ڪرون جابس؛
• StatefulSets ۽ DaemonSets.

مان شڪر گذار آهيان گرجلي رسڪو, دانييل ويبل и چارلس ڪرسٽيراج قيمتي تبصرن ۽ اضافو لاءِ.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

• «Kubernetes pods ۾ ڊيبگ ڪرڻ لاءِ kubectl-debug پلگ ان"؛
• «6 دلچسپ سسٽم بگ جڏهن ڪبرنيٽس استعمال ڪندي [۽ انهن جو حل]"؛
• «ايپليڪيشنن جي ڊولپرز لاءِ اوزار جيڪي ڪبرنيٽس تي هلن ٿا"؛
• «اسان جي SRE روزاني زندگيءَ مان 6 عملي ڳالهيون ».

جو ذريعو: www.habr.com