Kubernetes समस्या निवारण को लागी एक भिजुअल गाइड

नोट। अनुवाद।: यो लेख सार्वजनिक डोमेनमा प्रकाशित परियोजना सामग्रीहरूको अंश हो सिक्ने 8s, प्रशिक्षण कम्पनीहरू र व्यक्तिगत प्रशासकहरू Kubernetes सँग काम गर्न। यसमा, डेनियल पोलेन्सिक, परियोजना प्रबन्धक, K8s क्लस्टरमा चलिरहेको अनुप्रयोगहरूमा सामान्य समस्याहरूको मामलामा के कदम चाल्ने भन्ने बारे दृश्य निर्देशनहरू साझा गर्दछ।

TL; DR: यहाँ एउटा रेखाचित्र छ जसले तपाईंलाई Kubernetes मा डिबग डिबग गर्न मद्दत गर्नेछ:

क्लस्टरमा त्रुटिहरू फेला पार्न र समाधान गर्नको लागि फ्लोचार्ट। मूल (अंग्रेजीमा) मा उपलब्ध छ पीडीएफ и चित्रको रूपमा.

Kubernetes मा एप्लिकेसन डिप्लोइ गर्दा, तपाईले परिभाषित गर्न आवश्यक पर्ने तीनवटा कम्पोनेन्टहरू छन्:

• तैनाथ - यो एक प्रकारको नुस्खा हो जुन एप्लिकेसनको प्रतिलिपिहरू सिर्जना गर्नका लागि पोड भनिन्छ;
• सेवा - पोडहरू बीच ट्राफिक वितरण गर्ने आन्तरिक लोड ब्यालेन्सर;
• आक्रामक - बाहिरी संसारबाट सेवामा कसरी ट्राफिक आउँछ भन्ने विवरण।

यहाँ एक द्रुत ग्राफिकल सारांश छ:

1) Kubernetes मा, अनुप्रयोगहरूले लोड ब्यालेन्सरहरूको दुई तहहरू मार्फत बाहिरी संसारबाट ट्राफिक प्राप्त गर्दछ: आन्तरिक र बाह्य।

२) आन्तरिक ब्यालेन्सरलाई सेवा भनिन्छ, बाहिरीलाई इन्ग्रेस भनिन्छ।

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.

५) मानौं पोर्ट ३००० कन्टेनरमा खुला छ। त्यसपछि मान 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 नाम र खुला पोर्ट द्वारा आवश्यक सेवा फेला पार्छ।

प्रवेश र सेवाको विवरणमा दुई प्यारामिटरहरू मिल्नुपर्छ:

1. servicePort Ingress मा प्यारामिटर मिल्नुपर्छ port सेवामा;
2. serviceName Ingress मा क्षेत्र मिल्नुपर्छ name सेवामा।

निम्न रेखाचित्रले पोर्ट जडानहरू संक्षेप गर्दछ:

1) तपाईलाई पहिले नै थाहा छ, सेवाले निश्चित कुरा सुन्छ port:

2) Ingress भनिने प्यारामिटर छ servicePort:

३) यो प्यारामिटर (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 कन्फिगरेसन कसरी ठीकसँग संरचना गर्ने भनेर जान्न पर्याप्त छैन।

चीजहरू गलत हुँदा के हुन्छ?

पोड सुरु नहुन सक्छ वा यो क्र्यास हुन सक्छ।

Kubernetes मा आवेदन समस्याहरू निदान गर्न 3 चरणहरू

तपाईंले आफ्नो डिप्लोयमेन्ट डिबग गर्न सुरु गर्नु अघि, तपाईंले Kubernetes कसरी काम गर्छ भन्ने राम्रोसँग बुझ्नुपर्छ।

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'а> तपाईंलाई Kubernetes मा भण्डारण गरिएको पोडको YAML कन्फिगरेसन प्राप्त गर्न अनुमति दिन्छ;
4. kubectl exec -ti <имя pod'а> bash तपाईंलाई पोड कन्टेनरहरू मध्ये एकमा अन्तरक्रियात्मक आदेश शेल सुरु गर्न अनुमति दिन्छ

तपाईंले कुन रोज्नुपर्छ?

तथ्य यो हो कि त्यहाँ कुनै विश्वव्यापी आदेश छैन। यी को संयोजन प्रयोग गर्नुपर्छ।

सामान्य पोड समस्याहरू

त्यहाँ दुई मुख्य प्रकारका पोड त्रुटिहरू छन्: स्टार्टअप त्रुटिहरू र रनटाइम त्रुटिहरू।

स्टार्टअप त्रुटिहरू:

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

रनटाइम त्रुटिहरू:

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

केही त्रुटिहरू अरू भन्दा बढी सामान्य छन्। यहाँ केहि सामान्य त्रुटिहरू छन् र तिनीहरूलाई कसरी समाधान गर्ने।

ImagePullBackOff

Kubernetes पोड कन्टेनर मध्ये एक को लागी छवि प्राप्त गर्न असमर्थ हुँदा यो त्रुटि देखा पर्दछ। यहाँ यसको लागि तीन सबैभन्दा सामान्य कारणहरू छन्:

1. छविको नाम गलत छ - उदाहरणका लागि, तपाईंले यसमा गल्ती गर्नुभयो, वा छवि अवस्थित छैन;
2. छविको लागि अवस्थित नभएको ट्याग निर्दिष्ट गरिएको थियो;
3. छवि एक निजी रजिस्ट्री मा भण्डारण गरिएको छ र Kubernetes यसलाई पहुँच गर्न अनुमति छैन।

पहिलो दुई कारणहरू हटाउन सजिलो छ - केवल छविको नाम र ट्याग सच्याउनुहोस्। पछिल्लो को मामला मा, तपाईं गोप्य मा बन्द रजिस्ट्री को लागी प्रमाणहरु प्रविष्ट गर्न र पोड मा लिंक थप्न आवश्यक छ। Kubernetes कागजातमा एउटा उदाहरण छ यो कसरी गर्न सकिन्छ।

क्र्यास लूप ब्याक अफ

Kubenetes ले एउटा त्रुटि फ्याँक्यो CrashLoopBackOff, यदि कन्टेनर सुरु गर्न सक्दैन। यो सामान्यतया हुन्छ जब:

1. अनुप्रयोगमा एउटा बग छ जसले यसलाई सुरु हुनबाट रोक्छ;
2. कंटेनर गलत कन्फिगर गरियो;
3. Liveness परीक्षण धेरै पटक असफल भएको छ।

तपाईंले यसको विफलताको कारण पत्ता लगाउन कन्टेनरबाट लगहरूमा पुग्न प्रयास गर्नुपर्छ। यदि कन्टेनर धेरै चाँडै पुन: सुरु हुने कारण लगहरू पहुँच गर्न गाह्रो छ भने, तपाइँ निम्न आदेश प्रयोग गर्न सक्नुहुन्छ:

kubectl logs <pod-name> --previous

यसले कन्टेनरको अघिल्लो अवतारबाट त्रुटि सन्देशहरू प्रदर्शन गर्दछ।

रन कन्टेनर त्रुटि

यो त्रुटि तब हुन्छ जब कन्टेनर सुरु गर्न असफल हुन्छ। यो अनुप्रयोग सुरु हुनु अघि क्षण संग मेल खान्छ। यो सामान्यतया गलत सेटिंग्स को कारण हो, उदाहरण को लागी:

• ConfigMap वा Secrets जस्ता अस्तित्वहीन भोल्युम माउन्ट गर्ने प्रयास गर्दै;
• पढ्ने-लेखनको रूपमा पढ्ने मात्र भोल्युम माउन्ट गर्ने प्रयास।

टोली त्यस्ता त्रुटिहरूको विश्लेषणको लागि उपयुक्त छ kubectl describe pod <pod-name>.

पोडहरू विचाराधीन अवस्थामा छन्

एक पटक सिर्जना भएपछि, पोड राज्यमा रहन्छ Pending.

यो किन हुन्छ?

यहाँ सम्भावित कारणहरू छन् (म अनुसूचकले राम्रो काम गरिरहेको छ भनी मान्दै छु):

1. क्लस्टरसँग पोड चलाउनको लागि प्रशोधन शक्ति र मेमोरी जस्ता पर्याप्त स्रोतहरू छैनन्।
2. वस्तु उपयुक्त नाम स्थानमा स्थापित छ ResourceQuota र पोड सिर्जना गर्दा नेमस्पेस कोटा भन्दा बाहिर जानेछ।
3. पोड पेन्डिङमा बाँधिएको छ 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 कन्फिगर गर्न विशेष उपकरणहरू प्रयोग गर्नु अघि, तपाईंले धेरै सरल कुरा गर्न सक्नुहुन्छ। प्रवेश प्रयोग गर्दछ serviceName и servicePort सेवामा जडान गर्न। तपाईंले जाँच गर्न आवश्यक छ कि तिनीहरू सही रूपमा कन्फिगर गरिएका छन्। तपाईं आदेश प्रयोग गरेर यो गर्न सक्नुहुन्छ:

kubectl describe ingress <ingress-name>

यदि स्तम्भ Backend खाली, कन्फिगरेसन त्रुटिको उच्च सम्भावना छ। यदि ब्याकएन्डहरू ठाउँमा छन्, तर अनुप्रयोग अझै पहुँचयोग्य छैन, तब समस्या निम्नसँग सम्बन्धित हुन सक्छ:

• सार्वजनिक इन्टरनेटबाट पहुँच सेटिङहरू प्रवेश गर्नुहोस्;
• सार्वजनिक इन्टरनेटबाट क्लस्टर पहुँच सेटिङहरू।

तपाईले इन्ग्रेस पोडमा सिधै जडान गरेर पूर्वाधारमा समस्याहरू पहिचान गर्न सक्नुहुन्छ। यो गर्नका लागि, पहिले इन्ग्रेस कन्ट्रोलर पोड फेला पार्नुहोस् (यो फरक नेमस्पेसमा हुन सक्छ):

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 नियन्त्रकलाई काम गर्न प्राप्त गर्न सक्नुहुन्न भने, तपाईंले यसलाई डिबग गर्नुपर्नेछ।

त्यहाँ प्रवेश नियन्त्रकहरूको धेरै किस्महरू छन्। सबैभन्दा लोकप्रिय Nginx, HAProxy, Traefik, आदि हुन्। (अवस्थित समाधानहरूको बारेमा थप जानकारीको लागि, हेर्नुहोस् हाम्रो समीक्षा - लगभग। अनुवाद।) तपाईंले सान्दर्भिक नियन्त्रक कागजातमा समस्या निवारण गाइडलाई सन्दर्भ गर्नुपर्छ। किनकि त्यो Nginx प्रवेश गर्नुहोस् सबैभन्दा लोकप्रिय प्रवेश नियन्त्रक हो, हामीले यससँग सम्बन्धित समस्याहरू समाधान गर्न लेखमा केही सुझावहरू समावेश गरेका छौं।

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 - लगहरू जाँच गर्दछ।

याद गर्नुहोस् कि केहि अवस्थामा तपाईले झण्डा प्रयोग गरेर प्रवेश नियन्त्रकको लागि सही नाम स्थान निर्दिष्ट गर्न आवश्यक पर्दछ --namespace <name>.

सारांश

यदि तपाइँ कहाँ सुरु गर्ने थाहा छैन भने Kubernetes समस्या निवारण चुनौतीपूर्ण हुन सक्छ। तपाईंले जहिले पनि समस्यालाई तल-माथिको तरिकामा सम्पर्क गर्नुपर्छ: पोडहरूबाट सुरु गर्नुहोस्, र त्यसपछि सेवा र प्रवेशमा जानुहोस्। यस लेखमा वर्णन गरिएको डिबगिङ प्रविधिहरू अन्य वस्तुहरूमा लागू गर्न सकिन्छ, जस्तै:

• निष्क्रिय काम र क्रोनजब्स;
• StatefulSets र DaemonSets।

कृतज्ञता व्यक्त गर्दछु Gergely Risko, डेनियल Weibel и चार्ल्स क्रिस्टीराज मूल्यवान टिप्पणी र थपको लागि।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes pods मा डिबग गर्न को लागी kubectl-debug प्लगइन»;
• «Kubernetes को सञ्चालनमा 6 मनोरञ्जन प्रणाली बगहरू [र तिनीहरूको समाधान]»;
• «Kubernetes मा चलिरहेको अनुप्रयोगहरूको विकासकर्ताहरूको लागि उपकरण»;
• «हाम्रो SRE दैनिक जीवनबाट 6 व्यावहारिक कथाहरू "।

स्रोत: www.habr.com