"کوبرنیټس 10 ځله ځنډ ډیر کړی": څوک د دې لپاره ملامت دی؟

نوټ. ژباړه: دا مقاله، د ګالو ناوارو لخوا لیکل شوې، چې په اروپایی شرکت اډیونتا کې د پرنسپل سافټویر انجینر په توګه دنده ترسره کوي، د زیربنا عملیاتو په برخه کې په زړه پورې او لارښوونې "تحقیقات" دي. د دې اصلي سرلیک په ژباړه کې یو څه پراخ شوی و چې لیکوال یې په پیل کې تشریح کوي.

د لیکوال څخه یادونه: دا پوسټ داسې ښکاري متوجه شوی د توقع څخه ډیر پام. زه لاهم په غوسه شوي تبصرې لرم چې د مقالې سرلیک غلط دی او ځینې لوستونکي خواشیني دي. زه د هغه څه په لاملونو پوهیږم چې څه پیښیږي ، له همدې امله ، د ټولې دسیسې له مینځه وړو خطر سره سره ، زه غواړم سمدلاسه تاسو ته ووایم چې دا مقاله څه ده. یو په زړه پوری شی چې ما ولیدل کله چې ټیمونه کبرنیټس ته مهاجرت کوي دا دی چې هرکله چې کومه ستونزه رامینځته کیږي (لکه د مهاجرت وروسته د ځنډ زیاتوالی) ، لومړی شی چې ملامت کیږي کوبرنیټس دی ، مګر بیا وروسته معلومه شوه چې آرکیسټرټر واقعیا نه دی. تور دا مقاله د داسې یوې قضیې په اړه وايي. د دې نوم زموږ د یو پرمختلونکي افکار تکراروي (وروسته به تاسو وګورئ چې کوبرنیټس د دې سره هیڅ تړاو نلري). تاسو به دلته د Kubernetes په اړه هیڅ حیرانونکي افشاات ونه مومئ، مګر تاسو کولی شئ د پیچلو سیسټمونو په اړه د یو څو ښو درسونو تمه وکړئ.

څو اونۍ دمخه، زما ټیم یو واحد مایکرو خدمت یو اصلي پلیټ فارم ته لیږدول کیده چې پکې CI/CD، د Kubernetes پر بنسټ د چلولو وخت، میټریکونه، او نور ښه شیان شامل وو. دا اقدام د آزموینې نوعیت و: موږ پلان درلود چې دا د اساس په توګه واخلو او په راتلونکو میاشتو کې نږدې 150 نور خدمات انتقال کړو. دا ټول په هسپانیه کې د ځینو لوی آنلاین پلیټ فارمونو عملیاتو لپاره مسؤل دي (Infojobs، Fotocasa، او نور).

وروسته له هغه چې موږ کوبرنیټس ته غوښتنلیک ځای په ځای کړ او یو څه ټرافیک یې ورته واستاوه، یو خطرناک حیرانتیا زموږ په تمه و. ځنډ ځنډ په Kubernetes کې غوښتنې د EC10 په پرتله 2 ځله لوړې وې. په عموم کې، دا اړینه وه چې یا د دې ستونزې لپاره د حل لاره ومومي، یا د مایکرو سرویس مهاجرت پریږدي (او ممکن، ټوله پروژه).

ولې د EC2 په پرتله په کبرنیټس کې ځنډ خورا لوړ دی؟

د خنډ موندلو لپاره، موږ د غوښتنې ټولې لارې په اوږدو کې میټریکونه راټول کړل. زموږ جوړښت ساده دی: د API دروازې (Zuul) پراکسي په EC2 یا Kubernetes کې د مایکرو سرویس مثالونو ته غوښتنه کوي. په Kubernetes کې موږ د NGINX Ingress Controller کاروو، او شاتنۍ برخې عادي شیان دي لکه تعین کول د پسرلي پلیټ فارم کې د 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 نیولي، دا روښانه شوه چې د DNS ریزولوشن کله چې Elasticsearch ته لاسرسی په حقیقت کې د ځنډ زیاتوالي کې مرسته کوله.

په هرصورت، دا د دوو دلیلونو لپاره عجیب و:

1. موږ دمخه یو ټن د کبرنیټ غوښتنلیکونه لرو چې د لوړ ځنډ سره مخ کیدو پرته د AWS سرچینو سره اړیکه لري. هر څه چې دلیل وي، دا په ځانګړې توګه د دې قضیې سره تړاو لري.
2. موږ پوهیږو چې JVM په حافظه کې د DNS کیشینګ کوي. زموږ په عکسونو کې د TTL ارزښت لیکل شوی $JAVA_HOME/jre/lib/security/java.security او په 10 ثانیو کې تنظیم کړئ: networkaddress.cache.ttl = 10. په بل عبارت، JVM باید د DNS ټولې پوښتنې د 10 ثانیو لپاره زیرمه کړي.

د لومړي فرضیې تصدیق کولو لپاره ، موږ پریکړه وکړه چې د یو څه وخت لپاره د DNS زنګ وهلو ودروو او وګورو چې ستونزه لرې شوه. لومړی، موږ پریکړه وکړه چې غوښتنلیک بیا تنظیم کړو ترڅو دا د ډومین نوم په ځای د 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 ms ونیوله.

خړ جریان (د پیکټ 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 مثال میټاډاټا خدمت ته زنګ وهل و.

فرضیه 2: AWS ته غیر ضروري تلیفونونه

دواړه پای ټکي پورې اړه لري د AWS مثال میټاډاټا 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, د 15 دقیقو لپاره هارډ کوډ شوی.
• په پرتله د سندونو نوي کولو وروستۍ هڅې څخه ډیر وخت تیر شوی REFRESH_THRESHOLD، د 60 دقیقو لپاره هارډ کوډ شوی.

د دې لپاره چې د سندونو اصلي پای ته رسیدو نیټه وګورو چې موږ یې ترلاسه کوو، موږ د کانټینر او EC2 مثال دواړو څخه پورتني CURL کمانډونه چلول. د کانټینر څخه ترلاسه شوي سند اعتبار موده خورا لنډه وه: دقیقا 15 دقیقې.

اوس هر څه روښانه شوي دي: د لومړۍ غوښتنې لپاره، زموږ خدمت لنډمهاله سندونه ترلاسه کړل. څرنګه چې دوی د 15 دقیقو څخه زیات د اعتبار وړ ندي، د AWS SDK به پریکړه وکړي چې دوی په راتلونکی غوښتنې کې تازه کړي. او دا د هرې غوښتنې سره پیښ شوي.

ولې د سندونو د اعتبار موده لنډه شوې؟

د AWS Instance Metadata د EC2 مثالونو سره کار کولو لپاره ډیزاین شوی، نه د کوبرنیټس. له بلې خوا، موږ نه غوښتل د غوښتنلیک انٹرفیس بدل کړو. د دې لپاره موږ کارول KIAM - یوه وسیله چې په هر کوبرنیټس نوډ کې د اجنټانو په کارولو سره کاروونکو ته اجازه ورکوي (انجینران په کلستر کې غوښتنلیکونه ځای په ځای کوي) ترڅو په پوډونو کې کانټینرونو ته د IAM رولونه وټاکي لکه څنګه چې دوی د EC2 مثالونه وي. KIAM د AWS انسټانس میټاډاټا خدمت ته زنګونه مداخله کوي او د هغې له زیرمې څخه پروسس کوي ، مخکې یې له AWS څخه ترلاسه کړي. د غوښتنلیک له نظره، هیڅ بدلون نه راځي.

KIAM پوډونو ته لنډ مهاله سندونه ورکوي. دا د دې په پام کې نیولو سره معنی لري چې د پوډ اوسط عمر د EC2 مثال په پرتله لنډ دی. د سندونو لپاره د ډیفالټ اعتبار موده د ورته 15 دقیقو سره مساوي.

د پایلې په توګه، که تاسو دواړه ډیفالټ ارزښتونه د یو بل په سر کې واچوئ، یوه ستونزه رامنځته کیږي. غوښتنلیک ته چمتو شوی هر سند د 15 دقیقو وروسته پای ته رسیږي. په هرصورت، د AWS Java SDK د هر هغه سند نوي کول مجبوروي چې د پای نیټې څخه د 15 دقیقو څخه لږ پاتې وي.

د پایلې په توګه، لنډمهاله سند د هرې غوښتنې سره نوي کولو ته اړ ایستل کیږي، کوم چې د AWS API ته یو څو زنګونه اړوي او په ځنډ کې د پام وړ زیاتوالی لامل کیږي. په AWS جاوا SDK کې موږ وموندل د ب featureې غوښتنه، کوم چې ورته ستونزې ته اشاره کوي.

د حل لاره ساده وه. موږ په ساده ډول د اوږدې مودې اعتبار سره د سندونو غوښتنه کولو لپاره KIAM بیا تنظیم کړ. یوځل چې دا پیښ شي ، غوښتنې د AWS میټاډاټا خدماتو ګډون پرته جریان پیل کړې ، او ځنډ د EC2 په پرتله حتی ټیټې کچې ته راټیټ شو.

موندنو

د مهاجرت سره زموږ د تجربې پراساس، د ستونزو یو له خورا عامو سرچینو څخه په کوبرنیټس یا د پلیټ فارم نورو عناصرو کې کیګونه ندي. دا په مایکرو خدماتو کې کوم بنسټیز نیمګړتیاوې هم په ګوته نه کوي چې موږ یې پورټ کوو. ستونزې ډیری وختونه په ساده ډول رامینځته کیږي ځکه چې موږ مختلف عناصر یوځای کوو.

موږ پیچلي سیسټمونه سره یوځای کوو چې مخکې یې هیڅکله یو له بل سره اړیکه نه ده نیولې، تمه لري چې دوی به یو واحد، لوی سیسټم جوړ کړي. افسوس، څومره چې عناصر ډیر وي، د غلطیو لپاره ډیر خونه، د انټروپي لوړه ده.

زموږ په قضیه کې، لوړ ځنډ د کوبرنیټس، KIAM، AWS Java SDK، یا زموږ مایکرو خدمت کې د بګ یا خرابو پریکړو پایله نه وه. دا د دوو خپلواکو ډیفالټ ترتیباتو یوځای کولو پایله وه: یو په KIAM کې، بل په AWS Java SDK کې. په جلا توګه اخیستل شوي، دواړه پیرامیټونه معنی لري: په AWS Java SDK کې د فعال سند نوي کولو پالیسي، او په KAIM کې د سندونو لنډ اعتبار موده. مګر کله چې تاسو دوی سره یوځای کړئ، پایلې غیر متوقع کیږي. دوه خپلواک او منطقي حلونه د یوځای کیدو په وخت کې معنی نلري.

PS د ژباړونکي څخه

تاسو کولی شئ د Kubernetes سره د AWS IAM ادغام لپاره د KIAM یوټیلټي جوړښت په اړه نور معلومات زده کړئ دا مقاله له جوړونکو څخه.

زموږ په بلاګ کې هم ولولئ:

• «په تولید کې د کبرنیټس ناکامۍ 3 کیسې: د تړاو ضد ، په زړه پوري تړل ، ویب هک»
• «څنګه په کوبرنیټس کې د پوډ لومړیتوبونه د ګرافانا لابراتوارونو کې د ځنډ لامل شوي»
• «د کوبرنیټس په عملیاتو کې د ساتیرۍ سیسټم 6 بګونه [او د دوی حل]»
• «زموږ د SRE ورځني ژوند څخه 6 عملي کیسې".

سرچینه: www.habr.com