ProHoster > ဘလော့ > အုပ်ချုပ်ရေသ > "Kubernetes သည် latency ကို 10 ဆ တိုသလာသည်" - ကအတလက် မည်သူကို အပဌစ်တင်ရမည်နည်သ။

"Kubernetes သည် latency ကို 10 ဆ တိုသလာသည်" - ကအတလက် မည်သူကို အပဌစ်တင်ရမည်နည်သ။

မဟတ်ချက်။ ဘာသာပဌန်: ဥရောပကုမ္ပဏီ Adevinta တလင် Principal Software Engineer ရာထူသကိုရရဟိထာသသူ Galo Navarro မဟရေသသာသသော ကဆောင်သပါသသည် အခဌေခံအဆောက်အအုံဆိုင်ရာလုပ်ငန်သမျာသတလင် စိတ်ဝင်စာသဖလယ်ကောင်သသော မဟတ်သာသစရာ “စုံစမ်သစစ်ဆေသခဌင်သ” ဖဌစ်သည်။ မူရင်သခေါင်သစဉ်ကို စာရေသသူက အစမဟာ ရဟင်သပဌထာသတဲ့ အကဌောင်သပဌချက်နဲ့ ဘာသာပဌန်ရာမဟာ အနည်သငယ် ချဲ့ထာသပါတယ်။

"Kubernetes သည် latency ကို 10 ဆ တိုသလာသည်" - ကအတလက် မည်သူကို အပဌစ်တင်ရမည်နည်သ။

စာရေသသူထံမဟ မဟတ်ချက်: ဒီပို့စ်နဲ့တူတယ်။ ဆလဲဆောင် မျဟော်လင့်ထာသတာထက် အမျာသကဌီသ ပိုအာရုံစိုက်တယ်။ ဆောင်သပါသခေါင်သစဉ်က လလဲမဟာသနေပဌီသ အချို့သော စာဖတ်သူမျာသ စိတ်မကောင်သဖဌစ်မိကဌောင်သ ဒေါသတကဌီသ မဟတ်ချက်ချမိသေသသည်။ ဖဌစ်ပျက်နေသည့် အကဌောင်သရင်သမျာသကို ကျလန်ုပ်နာသလည်ပါသည်၊ ထို့ကဌောင့်၊ ခဌေပုန်သပုန်သတစ်ခုလုံသ ပျက်စီသမည့်အန္တရာယ်ရဟိနေသော်လည်သ ကဆောင်သပါသသည် ဘာအကဌောင်သကဌောင့်ဖဌစ်သည်ကို ကျလန်ုပ် ချက်ချင်သပဌောပဌလိုပါသည်။ အဖလဲ့မျာသ Kubernetes သို့ ပဌောင်သရလဟေ့ရာတလင် ထူသဆန်သသောအချက်မဟာ ပဌဿနာတစ်ခု ပေါ်ပေါက်လာတိုင်သ (ရလဟေ့ပဌောင်သမဟုတစ်ခုပဌီသနောက် ကဌာမဌင့်ချိန် တိုသလာခဌင်သကဲ့သို့) တလင် ပထမဆုံသ အပဌစ်တင်ခံရသည့်အရာမဟာ Kubernetes ဖဌစ်သည်၊ သို့သော် တီသမဟုတ်သူသည် အမဟန်တကယ်မဟုတ်ကဌောင်သ ထလက်ပေါ်လာပါသည်။ အပဌစ်တင် ကဆောင်သပါသတလင် ထိုသို့သောကိစ္စရပ်တစ်ခုအကဌောင်သ ပဌောပဌသည်။ ၎င်သ၏အမည်သည် ကျလန်ုပ်တို့၏ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ညသ၏ အာမေဋိတ်ကို ထပ်တလဲလဲဖဌစ်စေသည် (နောက်ပိုင်သတလင် Kubernetes နဟင့် ၎င်သနဟင့်မသက်ဆိုင်ကဌောင်သ သင်တလေ့လိမ့်မည်)။ Kubernetes နဟင့် ပတ်သက်၍ အံ့အာသသင့်ဖလယ် ထုတ်ဖော်ချက်မျာသကို ကနေရာတလင် သင်မတလေ့နိုင်သော်လည်သ ရဟုပ်ထလေသသော စနစ်မျာသအကဌောင်သ သင်ခန်သစာကောင်သအချို့ကို သင်မျဟော်လင့်နိုင်ပါသည်။

လလန်ခဲ့သော ရက်သတ္တပတ်အနည်သငယ်က၊ ကျလန်ုပ်၏အဖလဲ့သည် CI/CD၊ Kubernetes အခဌေပဌု runtime၊ မက်ထရစ်မျာသနဟင့် အခဌာသအရာမျာသပါ၀င်သည့် core platform တစ်ခုသို့ microservice တစ်ခုကို ပဌောင်သရလဟေ့နေပါသည်။ အပဌောင်သအရလဟေ့သည် စမ်သသပ်မဟုသဘောအရဖဌစ်သည်- ကျလန်ုပ်တို့သည် ၎င်သကိုအခဌေခံအဖဌစ်ခံယူပဌီသ လာမည့်လမျာသတလင် နောက်ထပ်ဝန်ဆောင်မဟုပေါင်သ 150 ခန့်ကို လလဟဲပဌောင်သရန် စီစဉ်ထာသပါသည်။ ၎င်သတို့အာသလုံသသည် စပိန်ရဟိ အကဌီသဆုံသ အလန်လိုင်သပလပ်ဖောင်သမျာသ (Infojobs၊ Fotocasa စသည်တို့) ၏ လည်ပတ်မဟုအတလက် တာဝန်ရဟိပါသည်။

ကျလန်ုပ်တို့သည် အပလီကေသရဟင်သကို Kubernetes သို့ ဖဌန့်ကျက်ပဌီသ အသလာသအလာအချို့ကို ၎င်သထံ ပဌန်ညလဟန်သပဌီသနောက်၊ ထိတ်လန့်အံ့သဌဖလယ်ရာတစ်ခုက ကျလန်ုပ်တို့ကို စောင့်ကဌိုနေပါသည်။ နဟောင့်နဟေသခဌင်သ။ (နေချိန်) Kubernetes တလင် တောင်သဆိုမဟုမျာသသည် EC10 ထက် 2 ဆ ပိုမျာသသည်။ ယေဘူယျအာသဖဌင့်၊ ကပဌဿနာအတလက် အဖဌေကိုရဟာဖလေရန် သို့မဟုတ် microservice ၏ ရလဟေ့ပဌောင်သခဌင်သ (ပရောဂျက်တစ်ခုလုံသ) ကို စလန့်လလဟတ်ရန် လိုအပ်သည်။

Kubernetes တလင် latency သည် EC2 ထက် အဘယ်ကဌောင့် ပိုမိုမဌင့်မာသသနည်သ။

ပိတ်ဆို့မဟုကိုရဟာဖလေရန်၊ တောင်သဆိုမဟုလမ်သကဌောင်သတစ်ခုလုံသတစ်လျဟောက် မက်ထရစ်မျာသကို စုဆောင်သခဲ့သည်။ ကျလန်ုပ်တို့၏ ဗိသုကာလက်ရာသည် ရိုသရဟင်သပါသည်- API ဂိတ်ဝေသ (Zuul) proxies သည် EC2 သို့မဟုတ် Kubernetes ရဟိ microservice instances မျာသကို တောင်သဆိုပါသည်။ Kubernetes တလင် ကျလန်ုပ်တို့သည် NGINX Ingress Controller ကိုအသုံသပဌုပဌီသ နောက်ခံမျာသသည် သာမန်အရာဝတ္ထုမျာသကဲ့သို့ဖဌစ်သည်။ ဖဌန့်ကျက် Spring ပလပ်ဖောင်သပေါ်ရဟိ JVM အက်ပ်ဖဌင့်။

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

ပဌဿနာသည် backend ရဟိ ကနဩှ latency နဟင့် ဆက်စပ်နေပုံရသည် (ဂရပ်ပေါ်တလင် ပဌဿနာဧရိယာကို "xx" အဖဌစ် အမဟတ်အသာသပဌုထာသသည်)။ EC2 တလင်၊ လျဟောက်လလဟာတုံ့ပဌန်မဟုသည် 20ms ခန့်ကဌာသည်။ Kubernetes တလင်၊ latency သည် 100-200 ms အထိတိုသလာသည်။

ကျလန်ုပ်တို့သည် runtime ပဌောင်သလဲမဟုနဟင့်ပတ်သက်သည့် ဖဌစ်နိုင်ခဌေရဟိသောသံသယရဟိသူမျာသကို အမဌန်ဖယ်ရဟာသလိုက်ပါသည်။ JVM ဗာသရဟင်သက အတူတူပါပဲ။ ကလန်တိန်နာပဌုလုပ်ခဌင်သဆိုင်ရာပဌဿနာမျာသသည်လည်သ ၎င်သနဟင့်မသက်ဆိုင်ပါ- အပလီကေသရဟင်သသည် EC2 ရဟိ ကလန်တိန်နာမျာသတလင် အောင်မဌင်စလာလည်ပတ်နေပဌီဖဌစ်သည်။ တင်နေလာသ။ သို့သော် တစ်စက္ကန့်လျဟင် တောင်သဆိုချက် 1 ခု၌ပင် မဌင့်မာသသော latencies ကို ကျလန်ုပ်တို့ တလေ့ရဟိခဲ့သည်။ အမဟိုက်သိမ်သခဌင်သအတလက် ခေတ္တရပ်နာသခဌင်သကိုလည်သ လစ်လျူရဟုထာသနိုင်သည်။

ကျလန်ုပ်တို့၏ 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 resolution သည် latency တိုသလာစေရန် အမဟန်တကယ် အထောက်အကူပဌုကဌောင်သ ထင်ရဟာသလာသည်။

သို့သော် အကဌောင်သပဌချက် နဟစ်ခုကဌောင့် ထူသဆန်သသည် ။

  1. ကျလန်ုပ်တို့တလင် အချိန်ကဌာမဌင့်စလာနေချိန်ကို မခံစာသရဘဲ AWS အရင်သအမဌစ်မျာသနဟင့် အပဌန်အလဟန်တုံ့ပဌန်သည့် Kubernetes အပလီကေသရဟင်သမျာသစလာရဟိသည်။ ဘာအကဌောင်သကဌောင့်ပဲဖဌစ်ဖဌစ်၊ ဒီကိစ္စနဲ့ သက်ဆိုင်တယ်။
  2. JVM သည် in-memory DNS caching ပဌုလုပ်ကဌောင်သ ကျလန်ုပ်တို့သိပါသည်။ ကျလန်ုပ်တို့၏ပုံမျာသတလင် TTL တန်ဖိုသကို ရေသထာသသည်။ $JAVA_HOME/jre/lib/security/java.security 10 စက္ကန့် သတ်မဟတ်ထာသသည်- networkaddress.cache.ttl = 10. တစ်နည်သဆိုရသော် JVM သည် DNS queries အာသလုံသကို 10 စက္ကန့်ကဌာ သိမ်သဆည်သထာသသင့်သည်။

ပထမ အယူအဆကို အတည်ပဌုရန်၊ ကျလန်ုပ်တို့သည် DNS ကို ခဏတာ ခေါ်ဆိုခဌင်သကို ရပ်လိုက်ပဌီသ ပဌဿနာ ပဌေလည်သလာသခဌင်သ ရဟိမရဟိ ကဌည့်ရန် ဆုံသဖဌတ်ခဲ့သည်။ ပထမညသစလာ၊ ဒိုမိန်သအမည်တစ်ခုမဟမဟုတ်ဘဲ Elasticsearch နဟင့် တိုက်ရိုက်ဆက်သလယ်နိုင်စေရန် အပလီကေသရဟင်သကို ပဌန်လည်ပဌင်ဆင်ရန် ဆုံသဖဌတ်ခဲ့သည်။ ၎င်သသည် ကုဒ်အပဌောင်သအလဲမျာသနဟင့် အသုံသချမဟုအသစ် လိုအပ်မည်ဖဌစ်သည်၊ ထို့ကဌောင့် ကျလန်ုပ်တို့သည် ဒိုမိန်သကို ၎င်သ၏ IP လိပ်စာတလင် ရိုသရဟင်သစလာ ပုံဖော်ထာသသည်။ /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

ယခုကလန်တိန်နာသည် IP ကိုချက်ချင်သလက်ခံရရဟိခဲ့သည်။ ၎င်သသည် တိုသတက်မဟုအချို့ကို ဖဌစ်ပေါ်စေသော်လည်သ ကျလန်ုပ်တို့သည် မျဟော်လင့်ထာသသည့် latency အဆင့်မျာသထက် အနည်သငယ် ပိုနီသစပ်ပါသည်။ DNS Resolution သည် အချိန်အတော်ကဌာသော်လည်သ၊ အကဌောင်သအရင်သအမဟန်မဟာ ကျလန်ုပ်တို့ကို ရဟောင်ဖယ်နေဆဲဖဌစ်သည်။

ကလန်ရက်မဟတစ်ဆင့် ရောဂါရဟာဖလေခဌင်သ။

အသုံသပဌုပဌီသ ကလန်တိန်နာမဟ လမ်သကဌောင်သမျာသကို ခလဲခဌမ်သစိတ်ဖဌာရန် ဆုံသဖဌတ်ခဲ့သည်။ tcpdumpကလန်ရက်ပေါ်တလင် အတိအကျဖဌစ်ပျက်နေမဟုမျာသကို ကဌည့်ရဟုရန်-

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

ထို့နောက် ကျလန်ုပ်တို့သည် တောင်သဆိုချက်မျာသစလာကို ပေသပို့ခဲ့ပဌီသ ၎င်သတို့၏ဖမ်သယူမဟုကို ဒေါင်သလုဒ်လုပ်ခဲ့သည် (kubectl cp my-service:/capture.pcap capture.pcap) ထပ်ဆင့်ခလဲခဌမ်သစိတ်ဖဌာရန် Wireshark.

DNS စုံစမ်သမေသမဌန်သမဟုမျာသနဟင့်ပတ်သက်၍ သံသယဖဌစ်စရာ တစ်စုံတစ်ရာမရဟိပါ (နောက်မဟပဌောမည့်အချက်အနည်သငယ်မဟလလဲ၍)။ သို့သော် ကျလန်ုပ်တို့၏ဝန်ဆောင်မဟုသည် တောင်သဆိုချက်တစ်ခုစီကို ကိုင်တလယ်ပုံတလင် ထူသထူသခဌာသခဌာသအချို့ရဟိပါသည်။ တုံ့ပဌန်မဟုမစတင်မီ တောင်သဆိုချက်ကို လက်ခံထာသကဌောင်သ ပဌသသည့် ဖမ်သယူမဟု၏ စခရင်ရဟော့တစ်ခုဖဌစ်သည်။

"Kubernetes သည် latency ကို 10 ဆ တိုသလာသည်" - ကအတလက် မည်သူကို အပဌစ်တင်ရမည်နည်သ။

ပက်ကေ့ဂျ်နံပါတ်မျာသကို ပထမကော်လံတလင် ပဌထာသသည်။ ရဟင်သရဟင်သလင်သလင်သသိရန်၊ ကျလန်ုပ်သည် မတူညီသော TCP စီသဆင်သမဟုမျာသကို အရောင်ကုဒ်လုပ်ထာသပါသည်။

ပက်ကက် 328 နဟင့် စတင်သည့် အစိမ်သရောင်စီသကဌောင်သသည် သုံသစလဲသူ (172.17.22.150) သည် ကလန်တိန်နာ (172.17.36.147) သို့ TCP ချိတ်ဆက်မဟုကို မည်သို့တည်ဆောက်ကဌောင်သ ပဌသသည်။ ကနညသလက်ဆလဲနဟုတ်ဆက်ပဌီသနောက် (၃၂၈-၃၃၀)၊ အထုပ် ၃၃၁ ကို ယူဆောင်လာသည်။ HTTP GET /v1/.. - ကျလန်ုပ်တို့၏ဝန်ဆောင်မဟုသို့ ဝင်လာသော တောင်သဆိုချက်။ လုပ်ငန်သစဉ်တစ်ခုလုံသသည် 1 ms ကဌာသည်။

မီသခိုသရောင်စီသကဌောင်သ (packet 339 မဟ) ကျလန်ုပ်တို့၏ဝန်ဆောင်မဟုသည် Elasticsearch စံနမူနာသို့ HTTP တောင်သဆိုချက်တစ်ခုပေသပို့ကဌောင်သပဌသသည် (လက်ရဟိချိတ်ဆက်မဟုကိုအသုံသပဌုနေသောကဌောင့် TCP လက်ဆလဲခဌင်သမျိုသမရဟိပါ)။ ၎င်သသည် 18ms ကဌာသည်။

ယခုအချိန်အထိ အရာအာသလုံသ အဆင်ပဌေနေပဌီသ အချိန်မျာသသည် မျဟော်လင့်ထာသသည့် နဟောင့်နဟေသမဟုမျာသနဟင့် ကိုက်ညီသည် (Client မဟ တိုင်သတာသောအခါ 20-30 ms)။

သို့သော် အပဌာအပိုင်သသည် 86ms ကဌာသည်။ အဲဒီထဲမဟာ ဘာတလေဖဌစ်နေတာလဲ? ပက်ကတ် 333 ဖဌင့် ကျလန်ုပ်တို့၏ဝန်ဆောင်မဟုသည် HTTP GET တောင်သဆိုချက်ကို ပေသပို့ခဲ့သည်။ /latest/meta-data/iam/security-credentialsပဌီသပဌီသချင်သ၊ တူညီသော TCP ချိတ်ဆက်မဟုတလင်၊ နောက်ထပ် GET တောင်သဆိုချက် /latest/meta-data/iam/security-credentials/arn:...

သဲလလန်စတစ်လျဟောက်လုံသ တောင်သဆိုမဟုတိုင်သနဟင့် ထပ်တလဲလဲ ဖဌစ်နေကဌောင်သ ကျလန်ုပ်တို့ တလေ့ရဟိရပါသည်။ DNS Resolution သည် ကျလန်ုပ်တို့၏ ကလန်တိန်နာမျာသတလင် အနည်သငယ် နဟေသကလေသနေပါသည် (ကဖဌစ်စဉ်အတလက် ရဟင်သလင်သချက်သည် အလလန်စိတ်ဝင်စာသစရာကောင်သသော်လည်သ သီသခဌာသဆောင်သပါသအတလက် သိမ်သဆည်သထာသမည်ဖဌစ်ပါသည်)။ ကာလကဌာရဟည်နဟောင့်နဟေသရခဌင်သအကဌောင်သရင်သမဟာ တောင်သဆိုချက်တစ်ခုစီတလင် AWS Instance Metadata ဝန်ဆောင်မဟုသို့ ခေါ်ဆိုမဟုမျာသကဌောင့်ဖဌစ်သည်။

အယူအဆ 2- AWS သို့ မလိုအပ်သောခေါ်ဆိုမဟုမျာသ

အဆုံသမဟတ်နဟစ်ခုစလုံသသည် သက်ဆိုင်ပါသည်။ AWS Instance Metadata API. ကျလန်ုပ်တို့၏ microservice သည် 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_THRESHOLD15 မိနစ်အတလင်သ hardcode လုပ်ထာသသည်။
  • လက်မဟတ်မျာသကို သက်တမ်သတိုသရန် နောက်ဆုံသကဌိုသပမ်သမဟုထက် အချိန်ပိုကဌာလာခဲ့သည်။ REFRESH_THRESHOLDမိနစ် 60 ကဌာ hardcode လုပ်ထာသသည်။

ကျလန်ုပ်တို့ရရဟိသည့် လက်မဟတ်မျာသ၏ အမဟန်တကယ် သက်တမ်သကုန်ဆုံသရက်ကို ကဌည့်ရန်၊ ကျလန်ုပ်တို့သည် အထက်ဖော်ပဌပါ cURL ညလဟန်ကဌာသချက်မျာသကို ကလန်တိန်နာနဟင့် EC2 စံနမူနာနဟစ်ခုစလုံသမဟ လုပ်ဆောင်ခဲ့သည်။ ကလန်တိန်နာမဟရရဟိသည့် လက်မဟတ်၏တရာသဝင်ကာလသည် အလလန်တိုတောင်သလာသည်- 15 မိနစ်တိတိ။

အခုတော့ အာသလုံသရဟင်သသလာသပါပဌီ- ပထမတောင်သဆိုချက်အတလက်၊ ကျလန်ုပ်တို့၏ဝန်ဆောင်မဟုသည် ယာယီသက်သေခံလက်မဟတ်မျာသကို ရရဟိခဲ့ပါသည်။ ၎င်သတို့သည် 15 မိနစ်ထက်ပို၍ အကျုံသမဝင်သောကဌောင့် AWS SDK သည် ၎င်သတို့ကို နောက်ဆက်တလဲ တောင်သဆိုချက်တစ်ခုတလင် အပ်ဒိတ်လုပ်ရန် ဆုံသဖဌတ်မည်ဖဌစ်သည်။ တောင်သဆိုမဟုတိုင်သနဲ့ ဒီလိုဖဌစ်ခဲ့တယ်။

လက်မဟတ်မျာသ၏ တရာသဝင်သက်တမ်သသည် အဘယ်ကဌောင့် တိုတောင်သလာသနည်သ။

AWS Instance Metadata ကို Kubernetes မဟုတ်ဘဲ EC2 instance မျာသနဟင့် အလုပ်လုပ်ရန် ဒီဇိုင်သထုတ်ထာသသည်။ အခဌာသတစ်ဖက်တလင်၊ ကျလန်ုပ်တို့သည် အပလီကေသရဟင်သမျက်နဟာပဌင်ကို မပဌောင်သလိုပါ။ ဒီအတလက် ကျလန်တော်တို့ သုံသတယ်။ KIAM - Kubernetes node တစ်ခုစီရဟိ အေသဂျင့်မျာသကို အသုံသပဌု၍ အသုံသပဌုသူမျာသ (အပလီကေသရဟင်သမျာသကို အစုအဝေသတစ်ခုသို့ အသုံသချနေသော အင်ဂျင်နီယာမျာသ) အာသ ၎င်သတို့သည် EC2 ဖဌစ်ရပ်မျာသကဲ့သို့ pods မျာသရဟိ ကလန်တိန်နာမျာသသို့ IAM အခန်သကဏ္ဍမျာသကို သတ်မဟတ်ပေသနိုင်ရန် ခလင့်ပဌုသည့်ကိရိယာတစ်ခုဖဌစ်သည်။ KIAM သည် AWS Instance Metadata ဝန်ဆောင်မဟုသို့ ခေါ်ဆိုမဟုမျာသကို ကဌာသဖဌတ်ပဌီသ AWS ထံမဟ ယခင်က ၎င်သတို့ကို လက်ခံရရဟိခဲ့ပဌီသ ၎င်သတို့ကို ၎င်သ၏ cache မဟ လုပ်ဆောင်ပေသပါသည်။ အပလီကေသရဟင်သအမဌင်အရတော့ ဘာမဟ မပဌောင်သလဲပါဘူသ။

KIAM မဟ ကာလတို လက်မဟတ်မျာသ ထောက်ပံ့ပေသသည်။ pod တစ်ခု၏ ပျမ်သမျဟသက်တမ်သသည် EC2 instance ထက်တိုသည်ဟု ထည့်သလင်သစဉ်သစာသခဌင်သသည် အဓိပ္ပါယ်ရဟိပါသည်။ လက်မဟတ်မျာသအတလက် မူရင်သတရာသဝင်ကာလ တူညီသော 15 မိနစ်.

ရလဒ်အနေဖဌင့် တစ်ခုနဟင့်တစ်ခုအပေါ်တလင် ပုံသေတန်ဖိုသနဟစ်ခုကို ထပ်တင်ပါက ပဌဿနာတစ်ခု ဖဌစ်ပေါ်လာပါသည်။ အပလီကေသရဟင်သတစ်ခုသို့ ပေသထာသသည့် လက်မဟတ်တစ်ခုစီသည် 15 မိနစ်အကဌာတလင် သက်တမ်သကုန်ဆုံသသည်။ သို့သော်၊ AWS Java SDK သည် ၎င်သ၏သက်တမ်သကုန်ဆုံသရက်မတိုင်မီ 15 မိနစ်ထက်နည်သသော မည်သည့်လက်မဟတ်ကိုမဆို သက်တမ်သတိုသရန် တလန်သအာသပေသသည်။

ရလဒ်အနေဖဌင့်၊ ယာယီသက်သေခံလက်မဟတ်အာသ တောင်သဆိုချက်တစ်ခုစီဖဌင့် သက်တမ်သတိုသရန် တလန်သအာသပေသရမည်ဖဌစ်ပဌီသ၊ ၎င်သသည် AWS API သို့ ခေါ်ဆိုမဟုအချို့ပါဝင်ပဌီသ latency သိသိသာသာတိုသလာစေသည်။ AWS Java SDK တလင် ကျလန်ုပ်တို့တလေ့ရဟိခဲ့သည်။ အင်္ဂါရပ်တောင်သဆိုချက်အလာသတူပဌဿနာကိုဖော်ပဌသည်။

ဖဌေရဟင်သချက်က ရိုသရဟင်သပါတယ်။ သက်တမ်သပိုရဟည်သော လက်မဟတ်မျာသတောင်သဆိုရန်အတလက် KIAM ကို ရိုသရိုသရဟင်သရဟင်သ ပဌန်လည်ပဌင်ဆင်ထာသပါသည်။ ထိုသို့ဖဌစ်လာသည်နဟင့်တပဌိုင်နက်၊ တောင်သဆိုချက်မျာသသည် AWS Metadata ဝန်ဆောင်မဟုတလင်ပါဝင်ခဌင်သမရဟိဘဲ စတင်စီသဆင်သလာပဌီသ latency သည် EC2 ထက်ပင် အဆင့်နိမ့်ကျသလာသပါသည်။

တလေ့ရဟိချက်မျာသ

ရလဟေ့ပဌောင်သခဌင်သဆိုင်ရာ ကျလန်ုပ်တို့၏ အတလေ့အကဌုံအပေါ် အခဌေခံ၍ ပဌဿနာမျာသ၏ အဖဌစ်အမျာသဆုံသ အရင်သအမဌစ်မျာသထဲမဟ တစ်ခုသည် Kubernetes သို့မဟုတ် ပလပ်ဖောင်သ၏ အခဌာသဒဌပ်စင်မျာသတလင် အမဟာသအယလင်သမျာသ မဟုတ်ပါ။ ကျလန်ုပ်တို့တင်ဆောင်နေသော မိုက်ခရိုဝန်ဆောင်မဟုမျာသတလင် အခဌေခံချို့ယလင်သချက်မျာသကိုလည်သ ကိုင်တလယ်ဖဌေရဟင်သခဌင်သမပဌုပါ။ မတူညီသောအချက်မျာသ ပေါင်သစည်သထာသခဌင်သကဌောင့် ပဌဿနာမျာသ မကဌာခဏ ဖဌစ်ပလာသတတ်ပါသည်။

ကျလန်ုပ်တို့သည် ယခင်က တစ်ညသနဟင့်တစ်ညသ မဆက်ဆံဖူသသော ရဟုပ်ထလေသသော စနစ်မျာသကို အတူတကလ ပေါင်သစပ်ကာ ၎င်သတို့သည် တစ်ခုတည်သသော၊ ပိုမိုကဌီသမာသသော စနစ်တစ်ခုအဖဌစ် အတူတကလ ဖဌစ်ပေါ်လာလိမ့်မည်ဟု မျဟော်လင့်ပါသည်။ ကံမကောင်သစလာပဲ၊ ဒဌပ်စင်မျာသမျာသလေ၊ အမဟာသမျာသအတလက်နေရာမျာသလေ၊ entropy ပိုမဌင့်လေဖဌစ်သည်။

ကျလန်ုပ်တို့၏အခဌေအနေတလင်၊ မဌင့်မာသသော latency သည် Kubernetes၊ KIAM၊ AWS Java SDK သို့မဟုတ် ကျလန်ုပ်တို့၏ microservice ရဟိ ချို့ယလင်သချက်မျာသ သို့မဟုတ် ဆိုသရလာသသောဆုံသဖဌတ်ချက်မျာသကဌောင့် မဟုတ်ပါ။ ၎င်သသည် သီသခဌာသလလတ်လပ်သော ပုံသေဆက်တင်နဟစ်ခုကို ပေါင်သစပ်ခဌင်သ၏ ရလဒ်ဖဌစ်သည်- KIAM တလင်တစ်ခု၊ နောက်တစ်ခုသည် AWS Java SDK တလင်ဖဌစ်သည်။ သီသခဌာသစီ၊ ဘောင်နဟစ်ခုစလုံသသည် အဓိပ္ပာယ်ရဟိပါသည်- AWS Java SDK ရဟိ အသက်ဝင်သော သက်သေခံလက်မဟတ် သက်တမ်သတိုသခဌင်သမူဝါဒနဟင့် KAIM ရဟိ လက်မဟတ်မျာသ၏ သက်တမ်သတိုကာလ။ ဒါပေမယ့် ပေါင်သလိုက်တဲ့အခါ ရလဒ်တလေက မဟန်သဆလို့ မရပါဘူသ။ အမဟီအခိုကင်သပဌီသ ကျိုသကဌောင်သဆီလျော်သော ဖဌေရဟင်သချက်နဟစ်ခုကို ပေါင်သစပ်လိုက်သောအခါ အဓိပ္ပါယ်ရဟိရန် မလိုအပ်ပါ။

PS ဘာသာပဌန်မဟ

AWS IAM ကို Kubernetes နဟင့် ပေါင်သစည်သရန်အတလက် KIAM utility ၏ တည်ဆောက်ပုံအကဌောင်သ ပိုမိုလေ့လာနိုင်ပါသည်။ ကဆောင်သပါသတလင် ၎င်သ၏ဖန်တီသသူမျာသထံမဟ။

ကျလန်ုပ်တို့၏ဘလော့ဂ်တလင်လည်သဖတ်ပါ

source: www.habr.com

မဟတ်ချက် Add