टिप्पणी अनुवाद: यह कंपनी के इंजीनियरिंग ब्लॉग से एक सार्वजनिक पोस्टमॉर्टम का अनुवाद है . यह कुबेरनेट्स क्लस्टर में कॉनट्रैक के साथ एक समस्या का वर्णन करता है, जिसके कारण कुछ उत्पादन सेवाओं का आंशिक डाउनटाइम हुआ।
यह लेख उन लोगों के लिए उपयोगी हो सकता है जो पोस्टमॉर्टम के बारे में कुछ और जानना चाहते हैं या भविष्य में कुछ संभावित DNS समस्याओं को रोकना चाहते हैं।
यह डीएनएस नहीं है
यह डीएनएस नहीं हो सकता
यह डीएनएस था
प्रीप्लाई में पोस्टमॉर्टम और प्रक्रियाओं के बारे में थोड़ा
पोस्टमॉर्टम उत्पादन में किसी खराबी या किसी घटना का वर्णन करता है। पोस्टमॉर्टम में घटनाओं की समय-सीमा, उपयोगकर्ता प्रभाव, मूल कारण, की गई कार्रवाई और सीखे गए सबक शामिल हैं।
पिज़्ज़ा के साथ साप्ताहिक बैठकों में, तकनीकी टीम के बीच, हम विभिन्न जानकारी साझा करते हैं। ऐसी बैठकों का सबसे महत्वपूर्ण हिस्सा पोस्टमार्टम होता है, जिसमें अक्सर स्लाइड के साथ एक प्रस्तुति और घटना का अधिक गहन विश्लेषण होता है। भले ही हम पोस्टमार्टम के बाद ताली नहीं बजाते, हम "कोई दोष नहीं" की संस्कृति विकसित करने का प्रयास करते हैं (). हमारा मानना है कि पोस्टमॉर्टम लिखने और प्रस्तुत करने से हमें (और दूसरों को) भविष्य में इसी तरह की घटनाओं को रोकने में मदद मिल सकती है, यही कारण है कि हम उन्हें साझा कर रहे हैं।
किसी घटना में शामिल व्यक्तियों को यह महसूस होना चाहिए कि वे सजा या प्रतिशोध के डर के बिना विस्तार से बोल सकते हैं। कोई दोष नहीं! पोस्टमॉर्टम लिखना कोई सज़ा नहीं है, बल्कि पूरी कंपनी के लिए सीखने का अवसर है।
Kubernetes में DNS के साथ समस्याएँ। शवपरीक्षा
Дата: 28.02.2020
लेखक: अमेट यू., एंड्री एस., इगोर के., एलेक्सी पी.
स्थिति: खत्म
संक्षेप में: Kubernetes क्लस्टर में कुछ सेवाओं के लिए आंशिक DNS अनुपलब्धता (26 मिनट)।
प्रभाव: सेवाओं ए, बी और सी के लिए 15000 इवेंट खो गए
मूल कारण: क्यूब-प्रॉक्सी कॉनट्रैक तालिका से पुरानी प्रविष्टि को सही ढंग से हटाने में असमर्थ था, इसलिए कुछ सेवाएँ अभी भी गैर-मौजूद पॉड्स से कनेक्ट करने का प्रयास कर रही थीं
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...चालू कर देना: कुबेरनेट्स क्लस्टर के अंदर कम लोड के कारण, CoreDNS-ऑटोस्केलर ने तैनाती में पॉड्स की संख्या तीन से घटाकर दो कर दी
समाधान: एप्लिकेशन की अगली तैनाती ने नए नोड्स के निर्माण की शुरुआत की, CoreDNS-ऑटोस्केलर ने क्लस्टर की सेवा के लिए और अधिक पॉड्स जोड़े, जिससे कॉनट्रैक तालिका को फिर से लिखना पड़ा।
जांच: प्रोमेथियस मॉनिटरिंग ने सेवाओं ए, बी और सी के लिए बड़ी संख्या में 5xx त्रुटियों का पता लगाया और ऑन-ड्यूटी इंजीनियरों को कॉल शुरू की।
किबाना में 5xx त्रुटियाँ
कार्रवाई
कार्य
टाइप
जिम्मेदार
कार्य
CoreDNS के लिए ऑटोस्केलर अक्षम करें
रोका
आमेट यू.
डेवोप्स-695
एक कैशिंग DNS सर्वर सेट करें
घटाना
मैक्स वी.
डेवोप्स-665
कॉनट्रैक मॉनिटरिंग सेट करें
रोका
आमेट यू.
डेवोप्स-674
सीख सीखी
क्या ठीक रहा:
- निगरानी ने अच्छा काम किया. प्रतिक्रिया तेज़ और व्यवस्थित थी
- हमने नोड्स पर कोई सीमा नहीं लांघी
क्या गलत था:
- अभी भी अज्ञात वास्तविक मूल कारण, के समान संपर्क में
- सभी क्रियाएं केवल परिणामों को ठीक करती हैं, मूल कारण (बग) को नहीं
- हम जानते थे कि देर-सबेर हमें डीएनएस में समस्या हो सकती है, लेकिन हमने कार्यों को प्राथमिकता नहीं दी
हम कहाँ भाग्यशाली रहे:
- अगली तैनाती CoreDNS-ऑटोस्केलर द्वारा ट्रिगर की गई, जिसने कॉनट्रैक तालिका को अधिलेखित कर दिया
- इस बग ने केवल कुछ सेवाओं को प्रभावित किया
समयरेखा (ईईटी)
समय
कार्य
22:13
CoreDNS-ऑटोस्केलर ने पॉड्स की संख्या तीन से घटाकर दो कर दी
22:18
ड्यूटी पर तैनात इंजीनियरों को निगरानी प्रणाली से कॉल आने लगीं
22:21
ड्यूटी पर मौजूद इंजीनियरों ने त्रुटियों का कारण पता लगाना शुरू कर दिया।
22:39
ड्यूटी पर तैनात इंजीनियरों ने नवीनतम सेवाओं में से एक को पिछले संस्करण में वापस लाना शुरू कर दिया
22:40
5xx त्रुटियाँ दिखना बंद हो गईं, स्थिति स्थिर हो गई है
- पता लगाने का समय: 4 मिनट
- कार्रवाई से पहले का समय: 21 मिनट
- ठीक करने का समय: 1 मिनट
अतिरिक्त जानकारी
- CoreDNS लॉग:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - किबाना (कट), ग्राफाना (कट) के लिंक
सीपीयू उपयोग को कम करने के लिए, लिनक्स कर्नेल कॉनट्रैक नामक कुछ का उपयोग करता है। संक्षेप में, यह एक उपयोगिता है जिसमें NAT रिकॉर्ड की एक सूची होती है जो एक विशेष तालिका में संग्रहीत होती है। जब अगला पैकेट उसी पॉड से पहले की तरह उसी पॉड में आता है, तो अंतिम आईपी पता पुनर्गणना नहीं किया जाएगा, बल्कि कॉनट्रैक तालिका से लिया जाएगा।
कॉनट्रैक कैसे काम करता है
परिणाम
यह कुछ उपयोगी लिंक के साथ हमारे पोस्टमॉर्टम में से एक का एक उदाहरण था। विशेष रूप से इस लेख में, हम ऐसी जानकारी साझा करते हैं जो अन्य कंपनियों के लिए उपयोगी हो सकती है। इसीलिए हम गलतियाँ करने से नहीं डरते और इसीलिए हम अपने एक पोस्टमॉर्टम को सार्वजनिक करते हैं। यहां कुछ और दिलचस्प सार्वजनिक पोस्टमॉर्टम हैं:
- गिटलैब:
- ड्रॉपबॉक्स:
- Spotify:
- कई अन्य से और भंडार
- भी एसआरई बुक के साथ सार्वजनिक पोस्टमॉर्टम
स्रोत: www.habr.com