कुबेरनेट्स पॉड्स में डिबगिंग के लिए कुबेटल-डिबग प्लगइन

पिछले साल के अंत में, Reddit ने kubectl के लिए एक प्लगइन पेश किया , जो Kubernetes क्लस्टर की पॉड्स में डीबग करने में मदद करता है - kubectl-debug । यह विचार हमारे इंजीनियरों को तुरंत दिलचस्प और उपयोगी लगा, इसलिए हमने इसके क्रियान्वयन को देखने का फैसला किया और अपने परिणामों को हब्र के पाठकों के साथ साझा करने में प्रसन्नता हुई।

यह क्यों आवश्यक है?

फिलहाल, फली के ढांचे के भीतर कुछ डिबगिंग की प्रक्रिया में एक गंभीर असुविधा है। कंटेनर छवि को इकट्ठा करते समय मुख्य लक्ष्य इसे कम करना है, अर्थात। इसे आकार में जितना संभव हो उतना छोटा और अंदर जितना संभव हो सके उतना कम "अतिरिक्त" बनाएं। हालाँकि, जब कंटेनरों में अंतिम सॉफ़्टवेयर के संचालन में समस्याएं आती हैं या क्लस्टर / बाहर अन्य सेवाओं के साथ इसके संचार को डीबग करना होता है ... न्यूनतावाद हम पर एक चाल खेलता है - आखिरकार, समस्याओं को खोजने की वास्तविक प्रक्रिया के लिए कंटेनरों में कुछ भी नहीं है। एक नियम के रूप में, उपयोगिताओं जैसे कि netstat / ip / ping / curl / wget, आदि उपलब्ध नहीं हैं।

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

इसकी मदद से, आप एक कमांड के साथ एक समस्या पॉड के संदर्भ में बोर्ड पर सभी आवश्यक उपकरणों के साथ एक कंटेनर लॉन्च कर सकते हैं और अंदर से होने वाली "सभी प्रक्रियाओं" का अध्ययन कर सकते हैं। यदि आप कभी कुबेरनेट्स समस्या निवारण में भाग लेते हैं, तो यह आकर्षक लगता है, है ना?

यह प्लगइन क्या है?

सामान्य शब्दों में, इस समाधान की वास्तुकला कुबेटेल के लिए प्लगइन्स के एक समूह की तरह दिखती है और एक एजेंट जो डेमनसेट नियंत्रक का उपयोग करना शुरू करता है। प्लगइन kubectl debug … साथ शुरू होने वाले आदेशों को प्रदान करता है kubectl debug … और क्लस्टर नोड्स पर एजेंटों के साथ बातचीत करता है। एजेंट, बदले में, मेजबान नेटवर्क पर चलता है, और इस सर्वर पर कंटेनरों तक पूरी पहुंच के लिए एजेंट पॉड में होस्ट docker.sock लगाया जाता है।

तदनुसार, जब निर्दिष्ट फली में डिबग कंटेनर लॉन्च करने का अनुरोध किया जाता है:
hostIP पहचान करने के लिए एक प्रक्रिया है, और एजेंट को एक उपयुक्त मेजबान पर काम करने के लिए एक अनुरोध भेजा जाता है ताकि लक्ष्य पॉड के अनुरूप नामस्थान में डिबग कंटेनर लॉन्च किया जा सके।

इन चरणों का अधिक विस्तृत दृश्य परियोजना प्रलेखन में उपलब्ध है।

काम के लिए क्या आवश्यक है?

कुबेटेल-डिबग के लेखक कुबेरनेट्स क्लाइंट / क्लस्टर 1.12.0+ के संस्करणों के साथ संगत होने का दावा करते हैं, हालांकि, मेरे पास K8s 1.10.8 हाथ में था, जिस पर सब कुछ दिखाई देने वाली समस्याओं के बिना काम किया ... एकल नोट के साथ kubectl debug टीम के लिए काम करने के लिए। इस रूप में, kubectl संस्करण ठीक 1.12+ है । अन्यथा, सभी आदेश समान हैं, लेकिन केवल kubectl-debug … माध्यम से कहा जाता है kubectl-debug …

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

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

डिबगर के साथ काम करें

जब तक "सब कुछ काम करता है" की स्थापना दो चरणों तक कम हो जाती है:

1. kubectl apply -f agent_daemonset.yml निष्पादित करें;
2. सीधे ही प्लगइन स्थापित करें - सामान्य तौर पर, सब कुछ यहां वर्णित है ।

इसका उपयोग कैसे करें? मान लें कि हमें निम्नलिखित समस्या है: क्लस्टर में सेवाओं में से एक का मैट्रिक्स एकत्र नहीं किया गया है - और हम यह जांचना चाहते हैं कि प्रोमेथियस और लक्ष्य सेवा के बीच नेटवर्क की समस्याएं हैं या नहीं। जैसा कि आप अनुमान लगा सकते हैं, प्रोमेथियस छवि में आवश्यक उपकरणों का अभाव है।

चलो प्रोमेथियस के साथ कंटेनर से कनेक्ट करने का प्रयास करें (यदि फली में कई कंटेनर हैं, तो आपको यह निर्दिष्ट करने की आवश्यकता होगी कि किसे कनेक्ट करना है, अन्यथा डिबगर डिफ़ॉल्ट रूप से पहले एक का चयन करेगा):

 kubectl-debug --namespace kube-prometheus prometheus-main-0 Defaulting container name to prometheus. pulling image nicolaka/netshoot:latest... latest: Pulling from nicolaka/netshoot 4fe2ade4980c: Already exists ad6ddc9cd13b: Pull complete cc720038bf2b: Pull complete ff17a2bb9965: Pull complete 6fe9f5dade08: Pull complete d11fc7653a2e: Pull complete 4bd8b4917a85: Pull complete 2bd767dcee18: Pull complete Digest: sha256:897c19b0b79192ee5de9d7fb40d186aae3c42b6e284e71b93d0b8f1c472c54d3 Status: Downloaded newer image for nicolaka/netshoot:latest starting debug container... container created, open tty... [1] → root @ / 

पहले, हमें पता चला कि समस्याग्रस्त सेवा 10.244.1.214 के पते पर रहती है और पोर्ट 8080 पर सुनती है। बेशक, हम मेजबानों से उपलब्धता की जांच कर सकते हैं, हालांकि, एक विश्वसनीय डिबगिंग प्रक्रिया के लिए, इन ऑपरेशनों को समान (या जितना संभव हो उतना करीब) स्थितियों में पुन: प्रस्तुत करना होगा। इसलिए, प्रोमेथियस के साथ एक फली / कंटेनर से जांच करना सबसे अच्छा विकल्प है। चलो एक सरल के साथ शुरू करते हैं:

  [1] → ping 10.244.1.214 PING 10.244.1.214 (10.244.1.214) 56(84) bytes of data. 64 bytes from 10.244.1.214: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from 10.244.1.214: icmp_seq=2 ttl=64 time=0.061 ms 64 bytes from 10.244.1.214: icmp_seq=3 ttl=64 time=0.047 ms 64 bytes from 10.244.1.214: icmp_seq=4 ttl=64 time=0.049 ms ^C --- 10.244.1.214 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 61ms rtt min/avg/max/mdev = 0.047/0.053/0.061/0.007 ms 

सब ठीक है। शायद पोर्ट अनुपलब्ध है?

  [1] → curl -I 10.244.1.214:8080 HTTP/1.1 200 OK Date: Sat, 12 Jan 2019 14:01:29 GMT Content-Length: 143 Content-Type: text/html; charset=utf-8 

और कोई समस्या नहीं है। फिर हम जांचेंगे कि क्या प्रोमेथियस और मैट्रिक्स के साथ समापन बिंदु के बीच वास्तविक संचार होता है:

  [2] → tcpdump host 10.244.1.214 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:04:19.234101 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [P.], seq 4181259750:4181259995, ack 2078193552, win 1444, options [nop,nop,TS val 3350532304 ecr 1334757657], length 245: HTTP: GET /metrics HTTP/1.1 14:04:19.234158 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [.], ack 245, win 1452, options [nop,nop,TS val 1334787600 ecr 3350532304], length 0 14:04:19.290904 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [P.], seq 1:636, ack 245, win 1452, options [nop,nop,TS val 1334787657 ecr 3350532304], length 635: HTTP: HTTP/1.1 200 OK 14:04:19.290923 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [.], ack 636, win 1444, options [nop,nop,TS val 3350532361 ecr 1334787657], length 0 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel 

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

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

क्या अन्य अनुप्रयोग तुरंत दिमाग में आते हैं?

• एक "मूक" आवेदन, जिसके लिए हानिकारक डेवलपर्स ने सामान्य लॉगिंग को लागू नहीं किया। लेकिन उसके पास एक विशिष्ट टूल के साथ सेवा पोर्ट और डिबग से जुड़ने की क्षमता है, जिसे निश्चित रूप से अंतिम छवि में नहीं रखा जाना चाहिए।
• "मैनुअल" मोड में समान मुकाबला एप्लिकेशन के बगल में लॉन्च करें, लेकिन डिबग चालू होने के साथ - पड़ोसी सेवाओं के साथ बातचीत की जांच करने के लिए।

सामान्य तौर पर, यह स्पष्ट है कि ऐसी बहुत सारी स्थितियाँ हैं जिनमें इस तरह के उपकरण उपयोगी हो सकते हैं। हर दिन काम पर उनका सामना करने वाले इंजीनियर "लाइव" डिबगिंग के मामले में उपयोगिता की क्षमता का आकलन करने में सक्षम होंगे।

निष्कर्ष

Kubectl-debug एक उपयोगी और आशाजनक उपकरण है। बेशक, कुबेरनेट्स क्लस्टर और अनुप्रयोग हैं, जिनके लिए यह बहुत मायने नहीं रखता है, लेकिन अभी भी अधिक संभावनाएं हैं जब यह डिबगिंग में अमूल्य सहायता प्रदान करेगा - खासकर अगर यह मुकाबला करने के लिए पर्यावरण की आवश्यकता है और जल्दी से, अभी और अभी, कारणों की तलाश करें आपके सामने जो समस्या है।

उपयोग के पहले अनुभव ने एक फली / कंटेनर से जुड़ने की क्षमता की तत्काल आवश्यकता बताई, जो अंत तक शुरू नहीं होती है (उदाहरण के लिए, यह CrashLoopbackOff में लटका हुआ है), बस आवेदन शुरू नहीं होने के कारणों को जांचने के लिए फ्लाई पर चेक करें। इस अवसर पर, मैंने प्रोजेक्ट रिपॉजिटरी में एक संगत मुद्दा बनाया, जिसके बारे में डेवलपर ने सकारात्मक जवाब दिया और निकट भविष्य में कार्यान्वयन का वादा किया। त्वरित और पर्याप्त प्रतिक्रिया से बहुत प्रसन्न। तो हम उपयोगिता की नई विशेषताओं और इसके आगे के विकास के लिए तत्पर रहेंगे!

पुनश्च

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

• " Kubernetes पर चलने वाले एप्लिकेशन डेवलपर्स के लिए उपकरण ";
• " कुबेरनेट्स टिप्स एंड ट्रिक्स: देव साइटों तक पहुंच ";
• " कुबर्नॉक्स और कुबेरनेट्स के लिए अन्य कंसोल गोले ";
• " लॉगहाउस का परिचय - कुबेरनेट्स में लॉग के साथ काम करने के लिए एक खुला स्रोत प्रणाली ";
• " निगरानी और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट) ।"