कुबेरनेट्स के लिए दृश्य समस्या निवारण गाइड

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



TL; DR: यहाँ एक चित्र है जो आपको कुबेरनेट्स में तैनाती में मदद करेगा:



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

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

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

यहाँ एक संक्षिप्त चित्रमय सारांश है:

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

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

1) कल्पना कीजिए कि सेवा एक निश्चित फली के लिए यातायात को निर्देशित करती है:



2) पॉड बनाते समय, आपको कंटेनर में प्रत्येक कंटेनर के लिए पॉडपॉट निर्दिष्ट करना होगा:



3) सेवा बनाते समय, आपको port और targetPort निर्दिष्ट करना होगा। लेकिन कंटेनर किसके माध्यम से जुड़ रहा है?



4) वाया targetPort । यह कंटेनरपॉर्ट से मेल खाना चाहिए।



5) मान लें कि पोर्ट 3000 कंटेनर में खुला है। फिर targetPort वैल्यू समान होनी चाहिए।



targetPort फ़ाइल में, लेबल और 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 बारे में क्या track: canary परिनियोजन अनुभाग के शीर्ष पर 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 लेबल

क्या कोई मुश्किलें हैं?

आप फली से जुड़ सकते हैं! ऐसा करने के लिए, kubectl में port-forward कमांड का उपयोग करें। यह आपको सेवा से जुड़ने और कनेक्शन की जांच करने की अनुमति देता है।

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

यहां:

• service/<service name> - सेवा का नाम; हमारे मामले में यह my-service ;
• 3000 - वह पोर्ट जिसे आप कंप्यूटर पर खोलना चाहते हैं;
• 80 - सेवा के port क्षेत्र में निर्दिष्ट port ।

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

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

सेवा और प्रगति का कनेक्शन

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

प्रगति और सेवा के विवरण में, दो मापदंडों का मिलान होना चाहिए:

1. servicePort में सेवा में port पैरामीटर से मेल खाना चाहिए;
2. serviceName में name का name सेवा में 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: / 

कैसे जाँच करें कि क्या Ingress काम कर रहा है?

आप kubectl port-forward साथ विधि का उपयोग कर सकते kubectl port-forward , लेकिन सेवा के बजाय आपको 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 Ingress को सेवा परिभाषा में port मेल खाना चाहिए;
5. सेवा का नाम Ingress में 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'> आपको Kubernetes में संग्रहीत 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. छवि को एक निजी रजिस्ट्री में संग्रहीत किया जाता है, और कुबेरनेट्स के पास इसे एक्सेस करने का अधिकार नहीं है।

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

CrashLoopBackOff

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

1. आवेदन में एक त्रुटि है जो इसे शुरू होने से रोकती है;
2. कंटेनर गलत तरीके से कॉन्फ़िगर किया गया है ;
3. कई बार लाईनेस टेस्ट भी फेल हुआ।

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

 kubectl logs <pod-name> --previous 

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

RunContainerError

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

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

kubectl describe pod <pod-name> कमांड ऐसी त्रुटियों का विश्लेषण करने के लिए अच्छी तरह से अनुकूल है।

पॉड्स लंबित

निर्माण के बाद, फली लंबवत स्थिति में रहती है।

ऐसा क्यों हो रहा है?

यहाँ संभावित कारण हैं (मुझे लगता है कि अनुसूचक ठीक काम कर रहा है):

1. फली को चलाने के लिए क्लस्टर में संसाधन और मेमोरी जैसे पर्याप्त संसाधन नहीं होते हैं।
2. ResourceQuota ऑब्जेक्ट को संबंधित नेमस्पेस में स्थापित किया जाता है और एक पॉड बनाने से नेमस्पेस कोटा से परे चला जाएगा।
3. पोड लंबित PersistentVolumeClaim से बंधा हुआ है।

इस स्थिति में, kubectl describe का उपयोग कमांड का kubectl describe और Events अनुभाग की जांच करने के लिए किया जाता है:

 kubectl describe pod <pod name> 

रिसोर्सक्वाट्स से संबंधित त्रुटियों के मामले में, कमांड का उपयोग करके क्लस्टर लॉग देखने की सिफारिश की जाती है

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

फली तैयार नहीं

यदि फली को Running रूप में सूचीबद्ध किया गया है, लेकिन Ready स्थिति में नहीं है, तो तत्परता की जांच असफल है।

जब ऐसा होता है, तो फली सेवा से कनेक्ट नहीं होती है, और ट्रैफ़िक इसमें प्रवाहित नहीं होता है। अनुप्रयोग समस्याओं के कारण तत्परता परीक्षण विफल हो गया। इस स्थिति में, त्रुटि को खोजने के लिए, आपको kubectl describe कमांड के आउटपुट में Events अनुभाग का विश्लेषण करने की आवश्यकता है।

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 से जुड़ने के लिए serviceName और servicePort का उपयोग करती है। आपको सत्यापित करना चाहिए कि वे सही तरीके से कॉन्फ़िगर किए गए हैं। आप कमांड का उपयोग करके ऐसा कर सकते हैं:

 kubectl describe ingress <ingress-name> 

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

• सार्वजनिक इंटरनेट से प्रवेश पहुंच सेटिंग्स;
• सार्वजनिक इंटरनेट से क्लस्टर एक्सेसिबिलिटी सेटिंग्स।

आप सीधे 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 

अंत में, फली से कनेक्ट करें:

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

अब कंप्यूटर पर पोर्ट 3000 के लिए सभी अनुरोधों को 80 पॉड पोर्ट के लिए पुनर्निर्देशित किया जाएगा।

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

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

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

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

डिबगिंग एक Ingin Nginx नियंत्रक

Ingress-nginx प्रोजेक्ट में kubectl के लिए एक आधिकारिक प्लगइन है । kubectl ingress-nginx कमांड का उपयोग इसके लिए किया जा सकता है:

• लॉग, बैकएंड, प्रमाण पत्र, आदि का विश्लेषण;
• कांग्रेस से संबंध;
• वर्तमान विन्यास का अध्ययन।

निम्नलिखित तीन टीमें इसमें आपकी मदद करेंगी:

• kubectl ingress-nginx lint nginx.conf - चेक nginx.conf ;
• kubectl ingress-nginx backend - kubectl ingress-nginx backend खोज करता है ( kubectl describe ingress <ingress-name> समान है kubectl describe ingress <ingress-name> );
• kubectl ingress-nginx logs - चेक लॉग।

कृपया ध्यान दें कि कुछ मामलों में --namespace <name> flag का उपयोग करके --namespace <name> कंट्रोलर के लिए सही नेमस्पेस निर्दिष्ट करना आवश्यक हो सकता है।

सारांश

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

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

बहुमूल्य टिप्पणियों और परिवर्धन के लिए गेर्गली रिस्को , डैनियल वीबेल और चार्ल्स क्रिस्टियराज का धन्यवाद।

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

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

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