🥇"कुबेरनेट्स ने विलंबता को 10 गुना बढ़ा दिया": इसके लिए दोषी कौन है?

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

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

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

जब हमने एप्लिकेशन को कुबेरनेट्स पर तैनात किया और कुछ ट्रैफ़िक को उस पर पुनर्निर्देशित किया, तो एक चौंकाने वाला आश्चर्य हमारा इंतजार कर रहा था। देरी (विलंबता) Kubernetes में अनुरोध EC10 की तुलना में 2 गुना अधिक थे। सामान्य तौर पर, या तो इस समस्या का समाधान ढूंढना आवश्यक था, या माइक्रोसर्विस (और, संभवतः, संपूर्ण प्रोजेक्ट) के माइग्रेशन को छोड़ देना आवश्यक था।

कुबेरनेट्स में विलंबता EC2 की तुलना में इतनी अधिक क्यों है?

अड़चन का पता लगाने के लिए, हमने पूरे अनुरोध पथ पर मेट्रिक्स एकत्र किए। हमारा आर्किटेक्चर सरल है: एक एपीआई गेटवे (ज़ूउल) ईसी2 या कुबेरनेट्स में माइक्रोसर्विस इंस्टेंस के लिए अनुरोधों को प्रॉक्सी करता है। कुबेरनेट्स में हम एनजीआईएनएक्स इनग्रेस कंट्रोलर का उपयोग करते हैं, और बैकएंड सामान्य ऑब्जेक्ट की तरह होते हैं तैनाती स्प्रिंग प्लेटफ़ॉर्म पर JVM एप्लिकेशन के साथ।

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

समस्या बैकएंड में प्रारंभिक विलंबता से संबंधित प्रतीत होती है (मैंने ग्राफ़ पर समस्या क्षेत्र को "xx" के रूप में चिह्नित किया है)। EC2 पर, एप्लिकेशन प्रतिक्रिया में लगभग 20ms लगे। कुबेरनेट्स में, विलंबता 100-200 एमएस तक बढ़ गई।

हमने रनटाइम परिवर्तन से संबंधित संभावित संदिग्धों को तुरंत खारिज कर दिया। JVM संस्करण वही रहता है. कंटेनरीकरण की समस्याओं का भी इससे कोई लेना-देना नहीं था: एप्लिकेशन पहले से ही EC2 पर कंटेनरों में सफलतापूर्वक चल रहा था। लोड हो रहा है? लेकिन हमने प्रति सेकंड 1 अनुरोध पर भी उच्च विलंबता देखी। कचरा संग्रहण के लिए रोक की भी उपेक्षा की जा सकती है।

हमारे Kubernetes व्यवस्थापकों में से एक को आश्चर्य हुआ कि क्या एप्लिकेशन में बाहरी निर्भरताएँ थीं क्योंकि DNS क्वेरीज़ ने अतीत में इसी तरह की समस्याएं पैदा की थीं।

परिकल्पना 1: डीएनएस नाम समाधान

प्रत्येक अनुरोध के लिए, हमारा एप्लिकेशन एक डोमेन जैसे AWS Elasticsearch इंस्टेंस को एक से तीन बार एक्सेस करता है elastic.spain.adevinta.com. हमारे कंटेनरों के अंदर वहाँ एक शंख है, ताकि हम जांच सकें कि क्या किसी डोमेन को खोजने में वास्तव में लंबा समय लगता है।

कंटेनर से DNS क्वेरीज़:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

EC2 उदाहरणों में से एक से समान अनुरोध जहां एप्लिकेशन चल रहा है:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

यह ध्यान में रखते हुए कि लुकअप में लगभग 30ms लगे, यह स्पष्ट हो गया कि Elasticsearch तक पहुँचने पर DNS रिज़ॉल्यूशन वास्तव में विलंबता में वृद्धि में योगदान दे रहा था।

हालाँकि, यह दो कारणों से अजीब था:

हमारे पास पहले से ही ढेर सारे Kubernetes एप्लिकेशन हैं जो उच्च विलंबता से पीड़ित हुए बिना AWS संसाधनों के साथ इंटरैक्ट करते हैं। कारण जो भी हो, यह विशेष रूप से इस मामले से संबंधित है।
हम जानते हैं कि JVM इन-मेमोरी DNS कैशिंग करता है। हमारी छवियों में, टीटीएल मान लिखा हुआ है $JAVA_HOME/jre/lib/security/java.security और 10 सेकंड पर सेट करें: networkaddress.cache.ttl = 10. दूसरे शब्दों में, JVM को सभी DNS क्वेरीज़ को 10 सेकंड के लिए कैश करना चाहिए।

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

34.55.5.111 elastic.spain.adevinta.com

अब कंटेनर को लगभग तुरंत ही एक आईपी प्राप्त हो गया। इसके परिणामस्वरूप कुछ सुधार हुआ, लेकिन हम अपेक्षित विलंबता स्तर के थोड़ा ही करीब थे। हालाँकि DNS रिज़ॉल्यूशन में काफी समय लगा, लेकिन वास्तविक कारण अभी भी हमसे दूर है।

नेटवर्क के माध्यम से निदान

हमने कंटेनर से ट्रैफ़िक का विश्लेषण करने का निर्णय लिया tcpdumpयह देखने के लिए कि नेटवर्क पर वास्तव में क्या हो रहा है:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

फिर हमने कई अनुरोध भेजे और उनका कैप्चर डाउनलोड किया (kubectl cp my-service:/capture.pcap capture.pcap) आगे के विश्लेषण के लिए Wireshark.

DNS क्वेरीज़ के बारे में कुछ भी संदेहास्पद नहीं था (एक छोटी सी चीज़ को छोड़कर जिसके बारे में मैं बाद में बात करूँगा)। लेकिन हमारी सेवा द्वारा प्रत्येक अनुरोध को संभालने के तरीके में कुछ विचित्रताएँ थीं। नीचे कैप्चर का एक स्क्रीनशॉट है जिसमें प्रतिक्रिया शुरू होने से पहले अनुरोध स्वीकार किया जा रहा है:

पैकेज नंबर पहले कॉलम में दिखाए गए हैं। स्पष्टता के लिए, मैंने विभिन्न टीसीपी प्रवाहों को रंग-कोडित किया है।

पैकेट 328 से शुरू होने वाली हरी स्ट्रीम दिखाती है कि क्लाइंट (172.17.22.150) ने कंटेनर (172.17.36.147) से टीसीपी कनेक्शन कैसे स्थापित किया। प्रारंभिक हैंडशेक (328-330) के बाद, पैकेज 331 लाया गया HTTP GET /v1/.. - हमारी सेवा के लिए एक आवक अनुरोध। पूरी प्रक्रिया में 1 एमएस का समय लगा।

ग्रे स्ट्रीम (पैकेट 339 से) दिखाती है कि हमारी सेवा ने इलास्टिक्स खोज उदाहरण के लिए एक HTTP अनुरोध भेजा है (कोई टीसीपी हैंडशेक नहीं है क्योंकि यह मौजूदा कनेक्शन का उपयोग कर रहा है)। इसमें 18ms लगे.

अब तक सब कुछ ठीक है, और समय मोटे तौर पर अपेक्षित देरी (क्लाइंट से मापा जाने पर 20-30 एमएस) के अनुरूप है।

हालाँकि, नीला अनुभाग 86ms लेता है। इसमें क्या चल रहा है? पैकेट 333 के साथ, हमारी सेवा ने एक HTTP GET अनुरोध भेजा /latest/meta-data/iam/security-credentials, और इसके तुरंत बाद, उसी टीसीपी कनेक्शन पर, एक और GET अनुरोध /latest/meta-data/iam/security-credentials/arn:...

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

परिकल्पना 2: AWS को अनावश्यक कॉल

दोनों समापनबिंदु संबंधित हैं AWS इंस्टेंस मेटाडेटा एपीआई. Elasticsearch चलाते समय हमारी माइक्रोसर्विस इस सेवा का उपयोग करती है। दोनों कॉल बुनियादी प्राधिकरण प्रक्रिया का हिस्सा हैं। पहले अनुरोध पर जिस समापन बिंदु तक पहुँचा जाता है वह उदाहरण से जुड़ी IAM भूमिका जारी करता है।

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

दूसरा अनुरोध इस उदाहरण के लिए अस्थायी अनुमतियों के लिए दूसरे समापन बिंदु से पूछता है:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

ग्राहक थोड़े समय के लिए उनका उपयोग कर सकता है और उसे समय-समय पर नए प्रमाणपत्र प्राप्त करने होंगे (उनके लागू होने से पहले)। Expiration). मॉडल सरल है: AWS सुरक्षा कारणों से अस्थायी कुंजियों को बार-बार घुमाता है, लेकिन नए प्रमाणपत्र प्राप्त करने से जुड़े प्रदर्शन दंड की भरपाई के लिए ग्राहक उन्हें कुछ मिनटों के लिए कैश कर सकते हैं।

AWS Java SDK को इस प्रक्रिया को व्यवस्थित करने की ज़िम्मेदारी लेनी चाहिए, लेकिन किसी कारण से ऐसा नहीं होता है।

GitHub पर समस्याएँ खोजने के बाद, हमें एक समस्या का सामना करना पड़ा #1921. उसने हमें आगे "खुदाई" करने की दिशा निर्धारित करने में मदद की।

निम्नलिखित में से कोई एक स्थिति होने पर AWS SDK प्रमाणपत्र अद्यतन करता है:

समाप्ति तिथि (Expiration) में गिरावट EXPIRATION_THRESHOLD, 15 मिनट तक हार्डकोड किया गया।
प्रमाणपत्रों को नवीनीकृत करने के अंतिम प्रयास के बाद से अधिक समय बीत चुका है REFRESH_THRESHOLD, 60 मिनट के लिए हार्डकोड किया गया।

हमें प्राप्त प्रमाणपत्रों की वास्तविक समाप्ति तिथि देखने के लिए, हमने कंटेनर और EC2 उदाहरण दोनों से उपरोक्त कर्ल कमांड चलाए। कंटेनर से प्राप्त प्रमाणपत्र की वैधता अवधि बहुत कम निकली: ठीक 15 मिनट।

अब सब कुछ स्पष्ट हो गया है: पहले अनुरोध के लिए, हमारी सेवा को अस्थायी प्रमाणपत्र प्राप्त हुए। चूँकि वे 15 मिनट से अधिक के लिए वैध नहीं थे, AWS SDK बाद के अनुरोध पर उन्हें अपडेट करने का निर्णय लेगा। और ऐसा हर अनुरोध के साथ हुआ.

प्रमाणपत्रों की वैधता अवधि कम क्यों हो गई है?

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

KIAM पॉड्स को अल्पकालिक प्रमाणपत्र प्रदान करता है। यह इस बात पर विचार करते हुए समझ में आता है कि पॉड का औसत जीवनकाल EC2 उदाहरण की तुलना में कम है। प्रमाणपत्रों के लिए डिफ़ॉल्ट वैधता अवधि वही 15 मिनट के बराबर.

परिणामस्वरूप, यदि आप दोनों डिफ़ॉल्ट मानों को एक-दूसरे के ऊपर ओवरले करते हैं, तो एक समस्या उत्पन्न होती है। किसी एप्लिकेशन को प्रदान किया गया प्रत्येक प्रमाणपत्र 15 मिनट के बाद समाप्त हो जाता है। हालाँकि, AWS Java SDK किसी भी प्रमाणपत्र के नवीनीकरण को बाध्य करता है जिसकी समाप्ति तिथि से पहले 15 मिनट से कम समय बचा है।

परिणामस्वरूप, अस्थायी प्रमाणपत्र को प्रत्येक अनुरोध के साथ नवीनीकृत करने के लिए मजबूर किया जाता है, जिसमें AWS API पर कुछ कॉल शामिल होती हैं और विलंबता में उल्लेखनीय वृद्धि होती है। AWS Java SDK में हमने पाया महत्वपूर्ण लेख मांगना, जिसमें एक समान समस्या का उल्लेख है।

समाधान सरल निकला. हमने लंबी वैधता अवधि वाले प्रमाणपत्रों का अनुरोध करने के लिए KIAM को फिर से कॉन्फ़िगर किया है। एक बार ऐसा होने पर, AWS मेटाडेटा सेवा की भागीदारी के बिना अनुरोध प्रवाहित होने लगे, और विलंबता EC2 की तुलना में और भी निचले स्तर तक गिर गई।

निष्कर्ष

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

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

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

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

आप कुबेरनेट्स के साथ AWS IAM को एकीकृत करने के लिए KIAM उपयोगिता की वास्तुकला के बारे में अधिक जान सकते हैं यह लेख इसके रचनाकारों से.

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

स्रोत: www.habr.com

"कुबेरनेट्स ने विलंबता को 10 गुना बढ़ा दिया": इसके लिए कौन दोषी है?