"कुबरनेटले 10 गुणाले विलम्बता बढ्यो": यसको लागि को दोषी छ?

नोट। अनुवाद।: यो लेख, युरोपेली कम्पनी Adevinta मा प्रिन्सिपल सफ्टवेयर इन्जिनियर को पद धारण गरेका Galo Navarro द्वारा लेखिएको, पूर्वाधार संचालन को क्षेत्र मा एक आकर्षक र निर्देशात्मक "अनुसन्धान" हो। यसको मूल शीर्षक अनुवादमा थोरै विस्तार गरिएको थियो किनभने लेखकले सुरुमा नै व्याख्या गरेका छन्।

लेखकबाट नोट: यो पोस्ट जस्तो देखिन्छ आकर्षित अपेक्षित भन्दा धेरै ध्यान। लेखको शीर्षक भ्रामक छ र केही पाठकहरू दुखी छन् भनेर मलाई अझै रिस उठ्छ। म के भइरहेको छ को कारणहरु बुझ्छु, त्यसैले, सम्पूर्ण षड्यन्त्र बर्बाद गर्ने जोखिमको बावजुद, म यो लेख के बारे मा तुरुन्तै बताउन चाहन्छु। टोलीहरू Kubernetes मा स्थानान्तरण गर्दा मैले देखेको एउटा जिज्ञासु कुरा यो हो कि जब कुनै समस्या उत्पन्न हुन्छ (जस्तै माइग्रेसन पछि बढेको विलम्बता), सबैभन्दा पहिले दोष लगाइने कुरा Kubernetes हो, तर त्यसपछि यो थाहा हुन्छ कि अर्केस्ट्रेटर वास्तवमा होइन। दोष। यस लेखले यस्तै एउटा घटनाको बारेमा बताउँछ। यसको नामले हाम्रो विकासकर्ताहरू मध्ये एकको उद्गार दोहोर्याउँछ (पछि तपाईंले कुबर्नेट्ससँग यसको कुनै सरोकार छैन भनेर देख्नुहुनेछ)। तपाईंले यहाँ Kubernetes को बारेमा कुनै आश्चर्यजनक खुलासाहरू फेला पार्नुहुने छैन, तर तपाईं जटिल प्रणालीहरूको बारेमा केही राम्रो पाठहरूको आशा गर्न सक्नुहुन्छ।

केही हप्ता अघि, मेरो टोलीले एकल माइक्रोसर्भिसलाई कोर प्लेटफर्ममा माइग्रेट गरिरहेको थियो जसमा CI/CD, Kubernetes-आधारित रनटाइम, मेट्रिक्स, र अन्य गुडीहरू समावेश थिए। यो कदम परीक्षण प्रकृतिको थियो: हामीले यसलाई आधारको रूपमा लिने र आगामी महिनाहरूमा लगभग 150 थप सेवाहरू स्थानान्तरण गर्ने योजना बनायौं। ती सबै स्पेनका केही ठूला अनलाइन प्लेटफर्महरू (Infojobs, Fotocasa, आदि) को सञ्चालनका लागि जिम्मेवार छन्।

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

EC2 मा भन्दा Kubernetes मा विलम्बता किन यति धेरै छ?

बाधा पत्ता लगाउन, हामीले सम्पूर्ण अनुरोध मार्गमा मेट्रिक्स सङ्कलन गर्यौं। हाम्रो संरचना सरल छ: एपीआई गेटवे (जुउल) प्रोक्सीहरूले EC2 वा Kubernetes मा माइक्रोसर्भिस उदाहरणहरूको लागि अनुरोध गर्दछ। Kubernetes मा हामी NGINX Ingress नियन्त्रक प्रयोग गर्छौं, र ब्याकएन्डहरू सामान्य वस्तुहरू हुन्। तैनाथ वसन्त प्लेटफर्ममा JVM अनुप्रयोगको साथ।

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

समस्या ब्याकइन्डमा प्रारम्भिक विलम्बतासँग सम्बन्धित जस्तो देखिन्थ्यो (मैले ग्राफमा समस्या क्षेत्रलाई "xx" को रूपमा चिन्ह लगाएँ)। EC2 मा, आवेदन प्रतिक्रियाले लगभग 20ms लियो। Kubernetes मा, विलम्बता 100-200 ms मा बढ्यो।

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

हाम्रा एक Kubernetes प्रशासकले सो एपमा बाह्य निर्भरता छ कि छैन भनेर सोचेका छन् किनभने DNS क्वेरीहरूले विगतमा यस्तै समस्याहरू निम्त्याएका थिए।

परिकल्पना 1: DNS नाम संकल्प

प्रत्येक अनुरोधको लागि, हाम्रो अनुप्रयोगले डोमेनमा 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 रिजोल्युसनले वास्तवमा विलम्बतामा वृद्धि गर्न योगदान गरिरहेको थियो।

यद्यपि, यो दुई कारणहरूको लागि अनौठो थियो:

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

पहिलो परिकल्पना पुष्टि गर्न, हामीले केहि समयको लागि DNS कल गर्न रोक्न र समस्या हट्यो कि भनेर हेर्ने निर्णय गर्यौं। पहिले, हामीले अनुप्रयोगलाई पुन: कन्फिगर गर्ने निर्णय गर्यौं ताकि यसले डोमेन नाम मार्फत नभई IP ठेगानाद्वारा Elasticsearch सँग सीधै सञ्चार गर्‍यो। यसका लागि कोड परिवर्तन र नयाँ डिप्लोइमेन्ट आवश्यक पर्नेछ, त्यसैले हामीले डोमेनलाई यसको IP ठेगानामा म्याप गर्यौं /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 प्रश्नहरूको बारेमा केही शंकास्पद थिएन (एक सानो कुरा बाहेक जुन म पछि कुरा गर्नेछु)। तर हाम्रो सेवाले प्रत्येक अनुरोधलाई ह्यान्डल गर्ने तरिकामा केही विचित्रताहरू थिए। प्रतिक्रिया सुरु हुनु अघि अनुरोध स्वीकार गरिएको देखाउँदै क्याप्चरको स्क्रिनसट तल छ:

प्याकेज नम्बरहरू पहिलो स्तम्भमा देखाइएका छन्। स्पष्टताको लागि, मैले विभिन्न TCP स्ट्रिमहरूलाई रंग-कोड गरेको छु।

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

ग्रे स्ट्रिम (प्याकेट 339 बाट) ले देखाउँछ कि हाम्रो सेवाले Elasticsearch उदाहरणमा HTTP अनुरोध पठाएको छ (त्यहाँ कुनै TCP ह्यान्डशेक छैन किनभने यसले अवस्थित जडान प्रयोग गरिरहेको छ)। यसले 18ms लियो।

अहिले सम्म सबै ठीक छ, र समय लगभग अपेक्षित ढिलाइ संग मेल खान्छ (ग्राहकबाट मापन गर्दा 20-30 ms)।

यद्यपि, नीलो खण्डले 86ms लिन्छ। यसमा के भइरहेको छ ? प्याकेट 333 को साथ, हाम्रो सेवाले HTTP GET अनुरोध पठायो /latest/meta-data/iam/security-credentials, र यसको तुरुन्तै पछि, उही TCP जडानमा, अर्को GET अनुरोध /latest/meta-data/iam/security-credentials/arn:...

हामीले पत्ता लगायौं कि यो ट्रेस भरि हरेक अनुरोध संग दोहोर्याइएको छ। DNS रिजोल्युसन साँच्चै हाम्रो कन्टेनरहरूमा अलि ढिलो छ (यस घटनाको लागि व्याख्या एकदम रोचक छ, तर म यसलाई छुट्टै लेखको लागि बचत गर्नेछु)। यो लामो ढिलाइको कारण प्रत्येक अनुरोधमा AWS इन्स्ट्यान्स मेटाडेटा सेवामा कलहरू थियो भनेर बाहिरियो।

हाइपोथेसिस २: AWS लाई अनावश्यक कलहरू

दुबै अन्तिम बिन्दुहरू सम्बन्धित छन् AWS Instance Metadata API। हाम्रो माइक्रोसेवाले 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, १५ मिनेटमा हार्डकोड गरियो।
• सर्टिफिकेट नवीकरण गर्ने अन्तिम प्रयास पछि धेरै समय बितिसकेको छ REFRESH_THRESHOLD, ६० मिनेटको लागि हार्डकोड गरिएको।

हामीले प्राप्त गरेका प्रमाणपत्रहरूको वास्तविक म्याद समाप्ति मिति हेर्नको लागि, हामीले कन्टेनर र EC2 उदाहरण दुवैबाट माथिको cURL आदेशहरू चलायौं। कन्टेनरबाट प्राप्त प्रमाणपत्रको वैधता अवधि धेरै छोटो भयो: ठीक 15 मिनेट।

अब सबै कुरा स्पष्ट भएको छ: पहिलो अनुरोधको लागि, हाम्रो सेवाले अस्थायी प्रमाणपत्रहरू प्राप्त गर्यो। तिनीहरू 15 मिनेट भन्दा बढीको लागि मान्य नभएकोले, AWS SDK ले पछिको अनुरोधमा तिनीहरूलाई अद्यावधिक गर्ने निर्णय गर्नेछ। र यो हरेक अनुरोध संग भयो।

प्रमाणपत्रको वैधता अवधि किन छोटो भयो?

AWS इन्स्ट्यान्स मेटाडेटा EC2 दृष्टान्तहरूसँग काम गर्न डिजाइन गरिएको हो, Kubernetes होइन। अर्कोतर्फ, हामी अनुप्रयोग इन्टरफेस परिवर्तन गर्न चाहँदैनौं। यसका लागि हामीले प्रयोग गर्‍यौं KIAM - एउटा उपकरण जसले प्रत्येक Kubernetes नोडमा एजेन्टहरू प्रयोग गरेर, प्रयोगकर्ताहरूलाई (एक क्लस्टरमा अनुप्रयोगहरू डिप्लोय गर्ने इन्जिनियरहरू) लाई पोडहरूमा कन्टेनरहरूलाई EC2 उदाहरणहरू जस्तै IAM भूमिकाहरू तोक्न अनुमति दिन्छ। KIAM ले AWS Instance Metadata सेवामा कलहरू रोक्छ र तिनीहरूलाई पहिले AWS बाट प्राप्त गरिसकेपछि यसलाई यसको क्यासबाट प्रशोधन गर्छ। अनुप्रयोगको दृष्टिकोणबाट, केहि परिवर्तन हुँदैन।

KIAM ले पोडहरूलाई छोटो अवधिको प्रमाणपत्रहरू आपूर्ति गर्दछ। पोडको औसत आयु EC2 उदाहरणको भन्दा छोटो छ भन्ने कुरालाई विचार गर्दा यसले अर्थ राख्छ। प्रमाणपत्रहरूको लागि पूर्वनिर्धारित वैधता अवधि समान 15 मिनेट बराबर.

नतिजाको रूपमा, यदि तपाइँ एकअर्काको शीर्षमा दुबै पूर्वनिर्धारित मानहरू ओभरले गर्नुहुन्छ भने, समस्या उत्पन्न हुन्छ। एप्लिकेसनलाई प्रदान गरिएको प्रत्येक प्रमाणपत्र १५ मिनेट पछि समाप्त हुन्छ। यद्यपि, AWS Java SDK ले कुनै पनि प्रमाणपत्रको नवीकरण गर्न बाध्य पार्छ जुन यसको म्याद समाप्ति मिति अघि 15 मिनेट भन्दा कम बाँकी छ।

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

समाधान सरल सावित भयो। हामीले केवल लामो वैधता अवधिको साथ प्रमाणपत्रहरू अनुरोध गर्न KIAM लाई पुन: कन्फिगर गर्यौं। एकचोटि यो भयो, अनुरोधहरू AWS मेटाडेटा सेवाको सहभागिता बिना प्रवाह हुन थाले, र विलम्बता EC2 भन्दा पनि तल्लो तहमा झर्यो।

निष्कर्ष

माइग्रेसनसँगको हाम्रो अनुभवको आधारमा, समस्याहरूको सबैभन्दा सामान्य स्रोतहरू मध्ये एक कुबर्नेट्स वा प्लेटफर्मका अन्य तत्वहरूमा बगहरू होइन। यसले हामीले पोर्ट गरिरहेका माइक्रोसर्भिसेसहरूमा कुनै पनि आधारभूत त्रुटिहरूलाई पनि सम्बोधन गर्दैन। समस्याहरू प्रायः उत्पन्न हुन्छन् किनभने हामीले विभिन्न तत्वहरू सँगै राख्छौं।

हामी जटिल प्रणालीहरू सँगै मिसाउँछौं जुन पहिले कहिल्यै एकअर्कासँग अन्तर्क्रिया नगरेको थियो, आशा गर्दै कि तिनीहरू सँगै एकल, ठूलो प्रणाली बनाउँछन्। काश, जति धेरै तत्वहरू, त्रुटिहरूको लागि धेरै ठाउँ, उच्च एन्ट्रोपी।

हाम्रो मामलामा, उच्च विलम्बता Kubernetes, KIAM, AWS Java SDK, वा हाम्रो microservice मा बगहरू वा खराब निर्णयहरूको परिणाम होइन। यो दुई स्वतन्त्र पूर्वनिर्धारित सेटिङहरू संयोजनको परिणाम थियो: एउटा KIAM मा, अर्को AWS Java SDK मा। छुट्टाछुट्टै रूपमा लिइयो भने, दुबै प्यारामिटरहरूले अर्थ दिन्छ: AWS Java SDK मा सक्रिय प्रमाणपत्र नवीकरण नीति, र KAIM मा प्रमाणपत्रहरूको छोटो वैधता अवधि। तर जब तपाइँ तिनीहरूलाई सँगै राख्नुहुन्छ, परिणामहरू अप्रत्याशित हुन्छन्। दुई स्वतन्त्र र तार्किक समाधानहरू संयोजन गर्दा अर्थ बनाउनु पर्दैन।

अनुवादकबाट PS

AWS IAM लाई Kubernetes सँग एकीकृत गर्न KIAM उपयोगिताको वास्तुकलाको बारेमा थप जान्न सक्नुहुन्छ यो लेख यसको सिर्जनाकर्ताहरूबाट।

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «उत्पादनमा Kubernetes असफलताका 3 कथाहरू: एन्टी-एफिनिटी, ग्रेसफुल शटडाउन, वेबहुक»;
• «कसरी Kubernetes मा pod priorities ले Grafana Labs मा डाउनटाइम निम्त्यायो»;
• «Kubernetes को सञ्चालनमा 6 मनोरञ्जन प्रणाली बगहरू [र तिनीहरूको समाधान]»;
• «हाम्रो SRE दैनिक जीवनबाट 6 व्यावहारिक कथाहरू"।

स्रोत: www.habr.com