Kubernetes मध्ये DNS सह समस्या. सार्वजनिक शवविच्छेदन

नोंद भाषांतर: हे कंपनीच्या अभियांत्रिकी ब्लॉगवरील सार्वजनिक पोस्टमॉर्टमचे भाषांतर आहे तयारी करा. हे कुबर्नेट्स क्लस्टरमधील कॉन्ट्रॅकच्या समस्येचे वर्णन करते, ज्यामुळे काही उत्पादन सेवांचा आंशिक डाउनटाइम झाला.

ज्यांना पोस्टमॉर्टेमबद्दल थोडे अधिक जाणून घ्यायचे आहे किंवा भविष्यात काही संभाव्य DNS समस्या टाळायच्या आहेत त्यांच्यासाठी हा लेख उपयुक्त ठरू शकतो.

हे DNS नाही
ते DNS असू शकत नाही
ते DNS होते

प्रीप्ली मधील पोस्टमॉर्टेम आणि प्रक्रियांबद्दल थोडेसे

पोस्टमॉर्टम उत्पादनातील खराबी किंवा काही घटनांचे वर्णन करते. पोस्टमॉर्टममध्ये घटनांची टाइमलाइन, वापरकर्ता प्रभाव, मूळ कारण, केलेल्या कृती आणि शिकलेले धडे समाविष्ट आहेत.

SRE शोधत आहे

पिझ्झासह साप्ताहिक मीटिंगमध्ये, तांत्रिक टीममध्ये, आम्ही विविध माहिती सामायिक करतो. अशा बैठकांचा एक महत्त्वाचा भाग म्हणजे शवविच्छेदन, ज्यात बहुतेक वेळा स्लाइड्ससह सादरीकरण आणि घटनेचे अधिक सखोल विश्लेषण असते. शवविच्छेदनानंतर आम्ही टाळ्या वाजवत नसलो तरी, आम्ही "दोष नाही" अशी संस्कृती विकसित करण्याचा प्रयत्न करतो.निर्दोष संस्कृती). आम्हाला विश्वास आहे की पोस्टमॉर्टेम लिहिणे आणि सादर करणे आम्हाला (आणि इतरांना) भविष्यात अशाच घटनांना प्रतिबंध करण्यास मदत करू शकते, म्हणूनच आम्ही ते सामायिक करत आहोत.

एखाद्या घटनेत सामील असलेल्या व्यक्तींना असे वाटले पाहिजे की ते शिक्षा किंवा प्रतिशोधाच्या भीतीशिवाय तपशीलवार बोलू शकतात. दोष नाही! पोस्टमॉर्टम लिहिणे ही शिक्षा नाही तर संपूर्ण कंपनीसाठी शिकण्याची संधी आहे.

CALMS आणि DevOps ठेवा: एस शेअरिंगसाठी आहे

Kubernetes मध्ये DNS सह समस्या. पोस्टमॉर्टम

तारीखः 28.02.2020

लेखक: अमेट यू., आंद्रे एस., इगोर के., ॲलेक्सी पी.

स्थिती: संपले

थोडक्यात: Kubernetes क्लस्टरमधील काही सेवांसाठी आंशिक DNS अनुपलब्धता (26 मिनिटे).

प्रभाव: A, B आणि C सेवांसाठी 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-autoscaler ने तैनातीमधील पॉड्सची संख्या तीनवरून दोन केली.

उपाय: ऍप्लिकेशनच्या पुढील उपयोजनाने नवीन नोड्स तयार करण्यास सुरुवात केली, CoreDNS-autoscaler ने क्लस्टरला सेवा देण्यासाठी आणखी पॉड्स जोडले, ज्यामुळे कॉन्ट्रॅक टेबलचे पुनर्लेखन करण्यास प्रवृत्त केले.

शोध: प्रोमिथियस मॉनिटरिंगने A, B आणि C सेवांसाठी मोठ्या प्रमाणात 5xx त्रुटी शोधून काढल्या आणि ऑन-ड्युटी अभियंत्यांना कॉल सुरू केला.

किबाना मध्ये 5xx त्रुटी

क्रिया

परिणाम
प्रकार
जबाबदार
उद्दिष्ट

CoreDNS साठी ऑटोस्केलर अक्षम करा
प्रतिबंधित
अमेट यू.
DEVOPS-695

कॅशिंग DNS सर्व्हर सेट करा
कमी
मॅक्स व्ही.
DEVOPS-665

कॉन्ट्रॅक मॉनिटरिंग सेट करा
प्रतिबंधित
अमेट यू.
DEVOPS-674

शिकलेले धडे

काय चांगले झाले:

• देखरेख चांगले काम केले. प्रतिसाद जलद आणि संघटित होता
• आम्ही नोड्सवर कोणतीही मर्यादा मारली नाही

काय चूक झाली:

• अद्याप अज्ञात वास्तविक मूळ कारण, समान विशिष्ट बग कॉन्ट्रॅक मध्ये
• सर्व क्रिया केवळ परिणाम दुरुस्त करतात, मूळ कारण (बग) नाही
• आम्हाला माहित होते की लवकर किंवा नंतर आम्हाला DNS सह समस्या येऊ शकतात, परंतु आम्ही कार्यांना प्राधान्य दिले नाही

जिथे आम्ही भाग्यवान झालो:

• पुढील उपयोजन CoreDNS-autoscaler द्वारे ट्रिगर केले गेले, ज्याने कॉन्ट्रॅक टेबल ओव्हरराईट केले
• या बगमुळे फक्त काही सेवांवर परिणाम झाला

टाइमलाइन (EET)

वेळ
परिणाम

22:13
CoreDNS-autoscaler ने शेंगांची संख्या तीनवरून दोन केली

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

• किबाना (कट), ग्राफाना (कट) च्या लिंक
• जिथे लिनक्स कॉन्ट्रॅक आता तुमचा मित्र नाही
• kube-proxy Subtleties: मधूनमधून कनेक्शन रीसेट डीबग करणे
• रेसी कॉन्ट्रॅक आणि DNS लुकअप टाइमआउट्स

CPU वापर कमी करण्यासाठी, लिनक्स कर्नल कॉन्ट्रॅक नावाचे काहीतरी वापरते. थोडक्यात, ही एक उपयुक्तता आहे ज्यामध्ये NAT रेकॉर्डची सूची असते जी एका विशेष टेबलमध्ये संग्रहित केली जाते. जेव्हा पुढचे पॅकेट त्याच पॉडवरून आधीच्या पॉडवर येते तेव्हा अंतिम IP पत्ता पुन्हा मोजला जाणार नाही, परंतु कॉन्ट्रॅक टेबलवरून घेतला जाईल.

कॉन्ट्रॅक कसे कार्य करते

परिणाम

हे काही उपयुक्त दुव्यांसह आमच्या पोस्टमॉर्टेमपैकी एक उदाहरण होते. विशेषत: या लेखात, आम्ही इतर कंपन्यांसाठी उपयुक्त ठरणारी माहिती सामायिक करतो. म्हणूनच आम्ही चुका करण्यास घाबरत नाही आणि म्हणूनच आम्ही आमचे एक पोस्टमॉर्टम सार्वजनिक करतो. येथे आणखी काही मनोरंजक सार्वजनिक पोस्टमॉर्टम आहेत:

• GitLab: 31 जानेवारीला डेटाबेस आउटेजचे पोस्टमॉर्टम
• ड्रॉपबॉक्स: आउटेज पोस्टमार्टम
• Spotify: Spotify चे DNS सह प्रेम/द्वेषपूर्ण संबंध
• पासून इतर अनेक हा सारांश आणि भांडार कुबर्नेट्स अयशस्वी कथा
• तसेच उदाहरण एसआरई बुकसह सार्वजनिक पोस्टमॉर्टम

स्त्रोत: www.habr.com