🥇"Kubernetes دير سان 10 ڀيرا وڌايو": هن جو ذميوار ڪير آهي؟

نوٽ. ترجمو: هي مضمون، Galo Navarro جو لکيل آهي، جيڪو يورپي ڪمپني Adevinta ۾ پرنسپل سافٽ ويئر انجنيئر جي عهدي تي آهي، انفراسٽرڪچر آپريشنز جي شعبي ۾ هڪ دلچسپ ۽ سبق آموز ”تحقيق“ آهي. ان جو اصل عنوان ترجمي ۾ ٿورڙو وڌايو ويو ان سبب لاءِ ته ليکڪ شروع ۾ ئي وضاحت ڪري ٿو.

ليکڪ کان نوٽ: هن پوسٽ وانگر لڳي ٿو متوجه ٿيو توقع کان وڌيڪ ڌيان ڏيڻ. مون کي اڃا تائين ناراض رايا مليا آهن ته مضمون جو عنوان گمراهه ڪندڙ آهي ۽ ڪجهه پڙهندڙن کي ڏک ٿيو آهي. مان سمجهان ٿو ته ڇا ٿي رهيو آهي، تنهن ڪري، سڄي سازش کي برباد ڪرڻ جي خطري جي باوجود، مان توهان کي فوري طور تي ٻڌائڻ چاهيان ٿو ته هي مضمون ڇا آهي. هڪ دلچسپ شيءِ مون ڏٺو آهي جيئن ٽيمون ڪبرنيٽس ڏانهن لڏپلاڻ ڪنديون آهن ته جڏهن به ڪو مسئلو پيدا ٿئي ٿو (جهڙوڪ لڏپلاڻ کان پوءِ دير ٿيڻ ۾ واڌ)، پهرين شيءِ جنهن تي الزام لڳايو وڃي ٿو اهو آهي ڪبرنيٽس، پر پوءِ اهو ظاهر ٿيو ته آرڪيسٽرٽر واقعي نه آهي. الزام هي مضمون هڪ اهڙي ڪيس جي باري ۾ ٻڌائي ٿو. ان جو نالو اسان جي ڊولپرز مان هڪ جي اعزاز کي ورجائي ٿو (بعد ۾ توهان ڏسندا ته ڪبرنيٽس ان سان ڪو به تعلق ناهي). توهان هتي ڪبرنيٽس جي باري ۾ ڪو به حيران ڪندڙ انڪشاف نه ڳوليندا، پر توهان پيچيده سسٽم بابت ڪجهه سٺي سبق جي اميد ڪري سگهو ٿا.

ڪجهه هفتا اڳ، منهنجي ٽيم هڪ واحد مائڪرو سروس کي هڪ بنيادي پليٽ فارم ڏانهن منتقل ڪري رهي هئي جنهن ۾ CI/CD، هڪ ڪبرنيٽس تي ٻڌل رن ٽائم، ميٽرڪس، ۽ ٻيون شيون شامل هيون. اهو قدم آزمائشي نوعيت جو هو: اسان ان کي بنياد طور وٺڻ ۽ ايندڙ مهينن ۾ تقريباً 150 وڌيڪ خدمتون منتقل ڪرڻ جو ارادو ڪيو. اهي سڀئي اسپين ۾ سڀ کان وڏي آن لائن پليٽ فارمن جي آپريشن جا ذميوار آهن (Infojobs، Fotocasa، وغيره).

اسان کان پوءِ ايپليڪيشن کي ڪبرنيٽس ڏانهن پهچايو ۽ ڪجهه ٽرئفڪ کي ان ڏانهن منتقل ڪيو، هڪ خطرناڪ تعجب اسان جي انتظار ۾ هو. دير ڪرڻ (ويڪرائي) Kubernetes ۾ درخواستون EC10 جي ڀيٽ ۾ 2 ڀيرا وڌيڪ هيون. عام طور تي، اهو ضروري هو ته يا ته هن مسئلي جو حل ڳولڻ، يا microservice جي لڏپلاڻ کي ڇڏي ڏيو (۽، ممڪن آهي، سڄي منصوبي).

EC2 جي ڀيٽ ۾ ڪبرنيٽس ۾ دير ڇو تمام گهڻي آهي؟

رڪاوٽ کي ڳولڻ لاء، اسان سڄي درخواست جي رستي سان گڏ ميٽرڪ گڏ ڪيو. اسان جو فن تعمير سادو آهي: هڪ API گيٽ وي (Zuul) proxies EC2 يا Kubernetes ۾ microservice مثالن لاءِ درخواستون. ڪبرنيٽس ۾ اسان NGINX Ingress ڪنٽرولر استعمال ڪندا آهيون، ۽ پس منظر عام شيون آهن جهڙوڪ رنيجرز اسپرنگ پليٽ فارم تي JVM ايپليڪيشن سان.

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

مسئلو پس منظر ۾ شروعاتي دير سان لاڳاپيل لڳي ٿو (مون گراف تي مسئلي واري علائقي کي "xx" طور نشان لڳايو). EC2 تي، درخواست جو جواب 20ms بابت ورتو. Kubernetes ۾، ويڪرائي 100-200 ms تائين وڌي وئي.

اسان جلدي جلدي برطرف ڪيو امڪاني شڪايتن سان لاڳاپيل رن ٽائم تبديلي. JVM نسخو ساڳيو رهي ٿو. ڪنٽينرائيزيشن جي مسئلن جو پڻ ان سان ڪو به واسطو نه هو: ايپليڪيشن اڳ ۾ ئي EC2 تي ڪنٽينرز ۾ ڪاميابي سان هلي رهي هئي. لوڊ ڪندي؟ پر اسان 1 درخواست في سيڪنڊ تي به اعليٰ دير جو مشاهدو ڪيو. ڪچرو گڏ ڪرڻ لاءِ رڪاوٽون به نظرانداز ٿي سگھن ٿيون.

اسان جي 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 ورتو، اهو واضح ٿي ويو ته ڊي اين ايس ريزوليوشن جڏهن ايلسٽسٽيسرچ تائين پهچندي واقعي دير سان وڌائڻ ۾ مدد ڪري رهيو هو.

بهرحال، اهو ٻن سببن لاء عجيب هو:

اسان وٽ اڳ ۾ ئي هڪ ٽين ڪبرنيٽس ايپليڪيشنون آهن جيڪي AWS وسيلن سان رابطو ڪن ٿيون بغير ڪنهن وڏي دير جي تڪليف جي. جيڪو به سبب هجي، اهو خاص طور تي هن معاملي سان لاڳاپيل آهي.
اسان ڄاڻون ٿا ته JVM ان-ميموري ڊي اين ايس ڪيچنگ ڪندو آهي. اسان جي تصويرن ۾، TTL قدر لکيل آهي $JAVA_HOME/jre/lib/security/java.security ۽ 10 سيڪنڊن تي سيٽ ڪريو: networkaddress.cache.ttl = 10. ٻين لفظن ۾، JVM سڀني DNS سوالن کي 10 سيڪنڊن لاء ڪيش ڪرڻ گهرجي.

پهرين مفروضي جي تصديق ڪرڻ لاءِ، اسان فيصلو ڪيو ته ڪجهه دير لاءِ ڊي اين ايس کي سڏڻ بند ڪيو وڃي ۽ ڏسو ته مسئلو ختم ٿي ويو. پهرين، اسان ايپليڪيشن کي ٻيهر ترتيب ڏيڻ جو فيصلو ڪيو ته جيئن اهو ڊومين جي نالي جي بجاءِ IP پتي ذريعي Elasticsearch سان سڌو رابطو ڪري. ان لاءِ ڪوڊ تبديلين ۽ نئين ٺاھڻ جي ضرورت پوندي، تنھنڪري اسان صرف ڊومين کي ان جي IP پتي تي نقشي ۾ ٺاھيو آھي /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

هاڻي ڪنٽينر هڪ IP مليل لڳ ڀڳ فوري طور تي. انهي جي نتيجي ۾ ڪجهه سڌارو آيو، پر اسان صرف توقع جي ويڪرائي سطح جي ٿورو ويجهو هئاسين. جيتوڻيڪ DNS قرارداد هڪ ڊگهو وقت ورتو، حقيقي سبب اڃا تائين اسان کي ختم ڪيو.

نيٽ ورڪ ذريعي تشخيص

اسان استعمال ڪندي ڪنٽينر مان ٽرئفڪ جو تجزيو ڪرڻ جو فيصلو ڪيو tcpdumpڏسڻ لاءِ ته نيٽ ورڪ تي ڇا ٿي رهيو آهي:

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

اسان پوءِ ڪيتريون ئي درخواستون موڪليون ۽ انهن جي گرفتاري کي ڊائون لوڊ ڪيو (kubectl cp my-service:/capture.pcap capture.pcap) ۾ وڌيڪ تجزيو لاء وارثر.

DNS سوالن جي باري ۾ ڪجھ به مشڪوڪ نه هو (سواء هڪ ننڍڙي شيء جيڪا آئون بعد ۾ ڳالهائيندس). پر اسان جي خدمت جي هر درخواست کي سنڀالڻ جي طريقي ۾ ڪجهه عجيب هئا. هيٺ ڏنل گرفتاري جو هڪ اسڪرين شاٽ آهي جنهن ۾ ڏيکاريو ويو آهي ته درخواست قبول ٿيڻ کان اڳ جواب شروع ٿئي ٿو:

پيڪيج نمبر پهرين ڪالمن ۾ ڏيکاريا ويا آهن. وضاحت لاءِ، مون مختلف TCP اسٽريمز کي رنگ ڪوڊ ڪيو آهي.

پيڪٽ 328 سان شروع ٿيندڙ گرين اسٽريم ڏيکاري ٿو ته ڪيئن ڪلائنٽ (172.17.22.150) ڪنٽينر سان TCP ڪنيڪشن قائم ڪيو (172.17.36.147). شروعاتي هٿ ملائڻ کان پوءِ (328-330)، پيڪيج 331 آندو ويو HTTP GET /v1/.. - اسان جي خدمت لاءِ ايندڙ درخواست. سڄو عمل 1 ايم ايس ورتو.

گرين اسٽريم (پيڪٽ 339 مان) ڏيکاري ٿو ته اسان جي سروس ايلسٽسٽڪ سرچ مثال ڏانهن 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 Instance Metadata سروس تي ڪالون هيون.

مفروضو 2: AWS ڏانهن غير ضروري ڪالون

ٻئي آخري نقطي جو تعلق آهي AWS Instance Metadata API. Elasticsearch هلائڻ دوران اسان جي microservice هي خدمت استعمال ڪري ٿي. ٻئي ڪالون بنيادي اختيار جي عمل جو حصو آهن. آخري نقطي جيڪا پهرين درخواست تي پهچندي آهي مثال سان لاڳاپيل 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_THRESHOLD60 منٽن لاء سخت ڪوڊ ٿيل.

اسان کي حاصل ڪيل سرٽيفڪيٽن جي اصل ختم ٿيڻ جي تاريخ ڏسڻ لاءِ، اسان مٿيون سي آر ايل ڪمانڊ ٻنهي ڪنٽينر ۽ EC2 مثالن مان ورتا. ڪنٽينر مان حاصل ڪيل سرٽيفڪيٽ جي صحيح مدت تمام ننڍو ٿي ويو: بلڪل 15 منٽ.

هاڻي هر شيء واضح ٿي چڪي آهي: پهرين درخواست لاء، اسان جي خدمت کي عارضي سرٽيفڪيٽ ملي ٿي. جيئن ته اهي 15 منٽن کان وڌيڪ صحيح نه هئا، AWS SDK انهن کي ايندڙ درخواست تي تازه ڪاري ڪرڻ جو فيصلو ڪندو. ۽ اهو هر درخواست سان ٿيو.

سرٽيفڪيٽن جي صحيح مدت ڇو گهٽ ٿي وئي آهي؟

AWS Instance Metadata EC2 مثالن سان ڪم ڪرڻ لاءِ ٺهيل آهي، نه ڪبرنيٽس. ٻئي طرف، اسان ايپليڪيشن انٽرفيس کي تبديل ڪرڻ نٿا چاهيون. ان لاءِ اسان استعمال ڪيو ڪيم - هڪ اوزار جيڪو، هر ڪبرنيٽس نوڊ تي ايجنٽن کي استعمال ڪندي، صارفين کي اجازت ڏئي ٿو (انجنيئرز کي ايپليڪيشنون ڊيپلائي ڪري ڪلسٽر ۾) IAM رولز کي پوڊز ۾ ڪنٽينرز کي تفويض ڪرڻ لاءِ ڄڻ ته اهي EC2 مثال آهن. KIAM AWS Instance Metadata سروس ڏانهن ڪالز کي روڪي ٿو ۽ انهن کي پنهنجي ڪيش مان پروسيس ڪري ٿو، اڳ ۾ ئي AWS کان وصول ڪري چڪو آهي. اپليڪيشن جي نقطي نظر کان، ڪجھ به تبديل نٿو ڪري.

KIAM پوڊ کي مختصر مدت جي سرٽيفڪيٽ فراهم ڪري ٿو. اهو سمجھ ۾ اچي ٿو ته پوڊ جي سراسري عمر EC2 مثال جي ڀيٽ ۾ ننڍو آهي. سرٽيفڪيٽن لاءِ ڊفالٽ صحيح مدت ساڳئي 15 منٽن جي برابر.

نتيجي طور، جيڪڏھن توھان ٻنھي ڊفالٽ قدرن کي ھڪ ٻئي جي مٿان مٿي ڪريو، ھڪڙو مسئلو پيدا ٿئي ٿو. هر سرٽيفڪيٽ هڪ ايپليڪيشن کي فراهم ڪيو ويو آهي 15 منٽن کان پوء ختم ٿئي ٿو. جڏهن ته، AWS Java SDK ڪنهن به سرٽيفڪيٽ جي تجديد کي مجبور ڪري ٿو جنهن جي ختم ٿيڻ جي تاريخ کان پهريان 15 منٽ کان گهٽ بچيا آهن.

نتيجي طور، عارضي سرٽيفڪيشن کي مجبور ڪيو وڃي ٿو ته هر درخواست سان تجديد ڪيو وڃي، جيڪو AWS API ڏانهن ڪجهه ڪالون داخل ڪري ٿو ۽ دير جي دير ۾ هڪ اهم واڌارو ڪري ٿو. AWS Java SDK ۾ اسان مليو مضمون جي درخواست، جنهن ۾ ساڳئي مسئلي جو ذڪر آهي.

حل سادو ثابت ٿيو. اسان صرف هڪ ڊگهي صحيح مدت سان سرٽيفڪيٽ جي درخواست ڪرڻ لاءِ KIAM کي ٻيهر ترتيب ڏنو. هڪ دفعو اهو ٿيو، درخواستون AWS ميٽاداٽا سروس جي شموليت کان سواءِ وهڻ شروع ٿي ويون، ۽ ويڪرائي EC2 جي ڀيٽ ۾ اڃا به گهٽ سطح تي اچي وئي.

پهچڻ

لڏپلاڻ سان گڏ اسان جي تجربي جي بنياد تي، مسئلن جي سڀ کان عام ذريعن مان هڪ آهي ڪوبرنيٽس يا پليٽ فارم جي ٻين عنصرن ۾ بگ نه آهي. اهو پڻ پتو نٿو پوي ته ڪنهن به بنيادي خامين کي مائڪرو سروسز ۾ جيڪو اسان پورٽ ڪري رهيا آهيون. مسئلا اڪثر ڪري پيدا ٿيندا آهن ڇاڪاڻ ته اسان مختلف عناصر کي گڏ ڪريون ٿا.

اسان گڏجي پيچيده سسٽم کي گڏ ڪريون ٿا جيڪي اڳ ۾ ڪڏهن به هڪ ٻئي سان رابطو نه ڪيو آهي، اميد آهي ته اهي گڏجي هڪ واحد، وڏو نظام ٺاهيندا. افسوس، وڌيڪ عناصر، غلطين لاء وڌيڪ ڪمرو، اعلي اينٽروپي.

اسان جي حالت ۾، اعلي دير جي ڪيبرنيٽس، KIAM، AWS Java SDK، يا اسان جي microservice ۾ بگ يا خراب فيصلن جو نتيجو نه هو. اهو ٻن آزاد ڊفالٽ سيٽنگن کي گڏ ڪرڻ جو نتيجو هو: هڪ KIAM ۾، ٻيو AWS Java SDK ۾. الڳ الڳ ورتو ويو، ٻئي پيٽرولر سمجھندا آهن: AWS Java SDK ۾ فعال سرٽيفڪيٽ تجديد پاليسي، ۽ KAIM ۾ سرٽيفڪيٽن جي مختصر صحيح مدت. پر جڏهن توهان انهن کي گڏ ڪيو، نتيجا غير متوقع ٿي ويندا. ٻن آزاد ۽ منطقي حلن کي گڏ ڪرڻ جي ضرورت ناهي.

پي ايس مترجم کان

توهان AWS IAM کي ڪبرنيٽس سان ضم ڪرڻ لاءِ KIAM يوٽيلٽي جي فن تعمير بابت وڌيڪ سکو سگهو ٿا: اهو مضمون ان جي تخليق ڪندڙن کان.

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

"Kubernetes 10 ڀيرا ويڪرائي وڌائي": هن جو ذميوار ڪير آهي؟