कुबेरनेट्स की समस्या निवारण के लिए एक विज़ुअल गाइड

टिप्पणी। अनुवाद।: यह आलेख सार्वजनिक डोमेन में प्रकाशित परियोजना सामग्री का हिस्सा है 8s, कुबेरनेट्स के साथ काम करने के लिए कंपनियों और व्यक्तिगत प्रशासकों को प्रशिक्षण देना। इसमें, प्रोजेक्ट मैनेजर डेनियल पोलेंसिक, K8s क्लस्टर पर चल रहे अनुप्रयोगों के साथ सामान्य समस्याओं के मामले में क्या कदम उठाने चाहिए, इस पर दृश्य निर्देश साझा करते हैं।

टीएल;डीआर: यहां एक आरेख है जो आपको कुबेरनेट्स में तैनाती को डीबग करने में मदद करेगा:

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

कुबेरनेट्स पर किसी एप्लिकेशन को तैनात करते समय, आमतौर पर तीन घटक होते हैं जिन्हें आपको परिभाषित करने की आवश्यकता होती है:

• तैनाती - यह किसी एप्लिकेशन की प्रतियां बनाने का एक प्रकार का नुस्खा है, जिसे पॉड्स कहा जाता है;
• सर्विस - आंतरिक लोड बैलेंसर जो पॉड्स के बीच ट्रैफ़िक वितरित करता है;
• प्रवेश - बाहरी दुनिया से सेवा तक ट्रैफ़िक कैसे पहुंचेगा इसका विवरण।

यहां एक त्वरित ग्राफिकल सारांश दिया गया है:

1) कुबेरनेट्स में, एप्लिकेशन लोड बैलेंसर्स की दो परतों के माध्यम से बाहरी दुनिया से ट्रैफ़िक प्राप्त करते हैं: आंतरिक और बाहरी।

2) आंतरिक बैलेंसर को सर्विस कहा जाता है, बाहरी को इनग्रेस कहा जाता है।

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 सेवा कुछ भी हो सकती है. विभिन्न सेवाएँ एक ही पोर्ट का उपयोग कर सकती हैं क्योंकि उनके पास अलग-अलग आईपी पते हैं।

निम्नलिखित चित्र उपरोक्त सभी को आलेखीय रूप में दर्शाता है:

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 सेवा।

यदि कनेक्शन स्थापित हो गया है, तो सेटिंग्स सही हैं।

यदि कनेक्शन विफल हो जाता है, तो लेबल में कोई समस्या है या पोर्ट मेल नहीं खाते हैं।

सेवा और प्रवेश के बीच संबंध

एप्लिकेशन तक पहुंच प्रदान करने का अगला चरण इनग्रेस की स्थापना से संबंधित है। इंग्रेस को यह जानने की जरूरत है कि सेवा कैसे ढूंढी जाए, फिर पॉड कैसे ढूंढें और उन पर ट्रैफ़िक कैसे निर्देशित करें। इनग्रेस नाम और खुले पोर्ट के आधार पर आवश्यक सेवा ढूंढता है।

इनग्रेस और सर्विस के विवरण में दो पैरामीटर मेल खाने चाहिए:

1. servicePort Ingress पैरामीटर से मेल खाना चाहिए port सेवा में;
2. serviceName इनग्रेस को फ़ील्ड से मेल खाना चाहिए name सेवा में।

निम्नलिखित चित्र पोर्ट कनेक्शन का सारांश प्रस्तुत करता है:

1) जैसा कि आप पहले से ही जानते हैं, सेवा एक निश्चित बात सुनती है port:

2) इनग्रेस का एक पैरामीटर है जिसे कहा जाता है 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: /

कैसे जांचें कि इनग्रेस चल रही है या नहीं?

आप विधि का उपयोग कर सकते हैं kubectl port-forward, लेकिन सेवा के बजाय आपको इनग्रेस कंट्रोलर से कनेक्ट करने की आवश्यकता है।

सबसे पहले आपको इनग्रेस कंट्रोलर के साथ पॉड का नाम पता करना होगा:

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 परिभाषा में सेवा कुछ भी हो सकती है। विभिन्न सेवाएँ एक ही पोर्ट का उपयोग कर सकती हैं क्योंकि उनके पास अलग-अलग आईपी पते हैं;
4. servicePort प्रवेश का मिलान होना चाहिए port सेवा की परिभाषा में;
5. सेवा का नाम फ़ील्ड से मेल खाना चाहिए serviceName प्रवेश में.

दुर्भाग्य से, यह जानना पर्याप्त नहीं है कि YAML कॉन्फ़िगरेशन को ठीक से कैसे तैयार किया जाए।

क्या होता है जब चीजें गलत हो जाती हैं?

पॉड प्रारंभ नहीं हो सकता है या क्रैश हो सकता है.

कुबेरनेट्स में एप्लिकेशन समस्याओं के निदान के लिए 3 चरण

इससे पहले कि आप अपनी तैनाती को डीबग करना शुरू करें, आपको यह अच्छी तरह से समझना होगा कि कुबेरनेट्स कैसे काम करता है।

चूँकि K8s में डाउनलोड किए गए प्रत्येक एप्लिकेशन में तीन घटक होते हैं, उन्हें बहुत नीचे से शुरू करके एक निश्चित क्रम में डीबग किया जाना चाहिए।

1. पहले आपको यह सुनिश्चित करना होगा कि पॉड्स काम कर रहे हैं, फिर...
2. जांचें कि क्या सेवा पॉड्स को ट्रैफ़िक प्रदान करती है, और फिर...
3. जांचें कि क्या इनग्रेस सही ढंग से कॉन्फ़िगर किया गया है।

दृश्य प्रतिनिधित्व:

1) आपको समस्याओं की तलाश बिल्कुल नीचे से शुरू करनी चाहिए। पहले जांचें कि पॉड्स में स्टेटस हैं या नहीं Ready и Running:

2) यदि फलियाँ तैयार हैं (Ready), आपको यह पता लगाना चाहिए कि क्या सेवा पॉड्स के बीच ट्रैफ़िक वितरित करती है:

3) अंत में, आपको सेवा और इनग्रेस के बीच संबंध का विश्लेषण करने की आवश्यकता है:

1. फली का निदान

В большинстве случаев проблема связана с pod’ом. Убедитесь, что pod’ы значатся как 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

कुछ त्रुटियाँ दूसरों की तुलना में अधिक सामान्य हैं। यहां कुछ सबसे सामान्य त्रुटियां हैं और उन्हें कैसे ठीक किया जाए।

इमेजपुलबैकऑफ़

यह त्रुटि तब प्रकट होती है जब कुबेरनेट्स पॉड कंटेनरों में से किसी एक के लिए एक छवि प्राप्त करने में असमर्थ होता है। इसके तीन सबसे सामान्य कारण यहां दिए गए हैं:

1. छवि का नाम गलत है - उदाहरण के लिए, आपने इसमें कोई गलती की है, या छवि मौजूद नहीं है;
2. छवि के लिए एक गैर-मौजूद टैग निर्दिष्ट किया गया था;
3. छवि एक निजी रजिस्ट्री में संग्रहीत है और कुबेरनेट्स के पास इसे एक्सेस करने की अनुमति नहीं है।

पहले दो कारणों को ख़त्म करना आसान है - बस छवि का नाम और टैग सही करें। बाद के मामले में, आपको सीक्रेट में बंद रजिस्ट्री के लिए क्रेडेंशियल दर्ज करना होगा और पॉड्स में इसके लिंक जोड़ना होगा। कुबेरनेट्स दस्तावेज़ में एक उदाहरण है यह कैसे किया जा सकता है.

क्रैश लूप बैक ऑफ

क्यूबनेट्स एक त्रुटि फेंकता है CrashLoopBackOff, यदि कंटेनर प्रारंभ नहीं हो सकता। ऐसा आमतौर पर तब होता है जब:

1. एप्लिकेशन में एक बग है जो इसे लॉन्च होने से रोकता है;
2. कंटेनर ग़लत तरीके से कॉन्फ़िगर किया गया;
3. लाइवनेस परीक्षण कई बार विफल रहा है।

इसकी विफलता का कारण जानने के लिए आपको कंटेनर से लॉग प्राप्त करने का प्रयास करना चाहिए। यदि लॉग तक पहुंचना मुश्किल है क्योंकि कंटेनर बहुत तेज़ी से पुनरारंभ होता है, तो आप निम्न कमांड का उपयोग कर सकते हैं:

kubectl logs <pod-name> --previous

यह कंटेनर के पिछले अवतार से त्रुटि संदेश प्रदर्शित करता है।

RunContainerError

यह त्रुटि तब होती है जब कंटेनर प्रारंभ होने में विफल रहता है। यह एप्लिकेशन लॉन्च होने से पहले के क्षण से मेल खाता है। यह आमतौर पर गलत सेटिंग्स के कारण होता है, उदाहरण के लिए:

• कॉन्फ़िगमैप या सीक्रेट्स जैसे गैर-मौजूद वॉल्यूम को माउंट करने का प्रयास;
• केवल पढ़ने योग्य वॉल्यूम को पढ़ने-लिखने के रूप में माउंट करने का प्रयास।

ऐसी त्रुटियों का विश्लेषण करने के लिए टीम उपयुक्त है 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. प्रवेश निदान

यदि आपने यह अब तक पढ़ा है, तो:

• पॉड्स को इस प्रकार सूचीबद्ध किया गया है Running и Ready;
• सेवा पॉड्स में ट्रैफ़िक को सफलतापूर्वक वितरित करती है।

हालाँकि, आप अभी भी ऐप तक नहीं पहुँच सकते।

इसका मतलब यह है कि इनग्रेस कंट्रोलर संभवतः सही ढंग से कॉन्फ़िगर नहीं किया गया है। चूंकि इनग्रेस कंट्रोलर क्लस्टर में एक तृतीय-पक्ष घटक है, इसलिए इसके प्रकार के आधार पर अलग-अलग डिबगिंग विधियां हैं।

लेकिन इससे पहले कि आप इनग्रेस को कॉन्फ़िगर करने के लिए विशेष टूल का उपयोग करें, आप कुछ बहुत ही सरल कार्य कर सकते हैं। प्रवेश का उपयोग करता है 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 पर पुनर्निर्देशित किया जाएगा।

क्या यह अब काम करता है?

• यदि हां, तो समस्या बुनियादी ढांचे को लेकर है. यह पता लगाना आवश्यक है कि ट्रैफ़िक को क्लस्टर तक कैसे रूट किया जाता है।
• यदि नहीं, तो समस्या इनग्रेस नियंत्रक के साथ है।

यदि आप इनग्रेस कंट्रोलर को काम पर नहीं ला पाते हैं, तो आपको इसे डीबग करना होगा।

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

इनग्रेस 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>.

सारांश

यदि आप नहीं जानते कि कहां से शुरू करें तो कुबेरनेट्स का समस्या निवारण चुनौतीपूर्ण हो सकता है। आपको समस्या को हमेशा नीचे से ऊपर की ओर से देखना चाहिए: पॉड्स से शुरू करें, और फिर सेवा और प्रवेश की ओर बढ़ें। इस आलेख में वर्णित डिबगिंग तकनीकों को अन्य ऑब्जेक्ट्स पर लागू किया जा सकता है, जैसे:

• निष्क्रिय नौकरियाँ और क्रोनजॉब्स;
• स्टेटफुलसेट्स और डेमनसेट्स।

मैं अपना आभार व्यक्त करता हूं गेर्गेली रिस्को, डेनियल वीबेल и Charles Christyraj बहुमूल्य टिप्पणियों और परिवर्धन के लिए।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «Kubernetes पॉड्स में डिबगिंग के लिए kubectl-debug प्लगइन";
• «कुबेरनेट्स के संचालन में 6 मनोरंजक सिस्टम बग [और उनका समाधान]";
• «कुबेरनेट्स पर चलने वाले एप्लिकेशन के डेवलपर्स के लिए उपकरण";
• «हमारे एसआरई रोजमर्रा की जिंदगी से 6 व्यावहारिक कहानियाँ '.

स्रोत: www.habr.com