“കുബർനെറ്റസ് ലേറ്റൻസി 10 മടങ്ങ് വർദ്ധിപ്പിച്ചു”: ഇതിന് ആരെയാണ് കുറ്റപ്പെടുത്തേണ്ടത്?

കുറിപ്പ്. വിവർത്തനം.: യൂറോപ്യൻ കമ്പനിയായ അഡെവിന്റയിൽ പ്രിൻസിപ്പൽ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർ സ്ഥാനം വഹിക്കുന്ന ഗാലോ നവാരോ എഴുതിയ ഈ ലേഖനം, ഇൻഫ്രാസ്ട്രക്ചർ ഓപ്പറേഷൻ രംഗത്തെ കൗതുകകരവും പ്രബോധനപരവുമായ "അന്വേഷണം" ആണ്. തുടക്കത്തിൽ തന്നെ രചയിതാവ് വിശദീകരിക്കുന്ന ഒരു കാരണത്താൽ അതിന്റെ യഥാർത്ഥ തലക്കെട്ട് വിവർത്തനത്തിൽ ചെറുതായി വിപുലീകരിച്ചു.

രചയിതാവിൽ നിന്നുള്ള കുറിപ്പ്: ഈ പോസ്റ്റ് പോലെ തോന്നുന്നു ആകർഷിച്ചു പ്രതീക്ഷിച്ചതിലും കൂടുതൽ ശ്രദ്ധ. ലേഖനത്തിന്റെ തലക്കെട്ട് തെറ്റിദ്ധരിപ്പിക്കുന്നതാണെന്നും ചില വായനക്കാർക്ക് സങ്കടമുണ്ടെന്നും എനിക്ക് ഇപ്പോഴും ദേഷ്യം വരുന്ന കമന്റുകൾ ലഭിക്കുന്നു. എന്താണ് സംഭവിക്കുന്നതെന്ന് ഞാൻ മനസ്സിലാക്കുന്നു, അതിനാൽ, മുഴുവൻ ഗൂഢാലോചനയും നശിപ്പിക്കുന്നതിനുള്ള അപകടസാധ്യത ഉണ്ടായിരുന്നിട്ടും, ഈ ലേഖനം എന്തിനെക്കുറിച്ചാണെന്ന് ഉടൻ തന്നെ നിങ്ങളോട് പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ടീമുകൾ കുബർനെറ്റസിലേക്ക് കുടിയേറുമ്പോൾ ഞാൻ കണ്ട ഒരു കൗതുകകരമായ കാര്യം, ഒരു പ്രശ്‌നം ഉണ്ടാകുമ്പോഴെല്ലാം (ഒരു മൈഗ്രേഷനുശേഷം വർദ്ധിച്ച ലേറ്റൻസി പോലുള്ളവ), ആദ്യം കുറ്റപ്പെടുത്തുന്നത് കുബെർനെറ്റസിനെയാണ്, എന്നാൽ ഓർക്കസ്ട്രേറ്റർ ശരിക്കും അങ്ങനെയല്ലെന്ന് മാറുന്നു. കുറ്റപ്പെടുത്തുക. ഈ ലേഖനം അത്തരമൊരു കേസിനെക്കുറിച്ചാണ് പറയുന്നത്. അതിന്റെ പേര് ഞങ്ങളുടെ ഡവലപ്പർമാരിൽ ഒരാളുടെ ആശ്ചര്യം ആവർത്തിക്കുന്നു (കുബർനെറ്റസിന് ഇതുമായി യാതൊരു ബന്ധവുമില്ലെന്ന് പിന്നീട് നിങ്ങൾ കാണും). കുബെർനെറ്റസിനെ കുറിച്ച് നിങ്ങൾക്ക് ആശ്ചര്യപ്പെടുത്തുന്ന വെളിപ്പെടുത്തലുകളൊന്നും ഇവിടെ കാണാനാകില്ല, എന്നാൽ സങ്കീർണ്ണമായ സംവിധാനങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് രണ്ട് നല്ല പാഠങ്ങൾ പ്രതീക്ഷിക്കാം.

ഏതാനും ആഴ്‌ചകൾക്ക് മുമ്പ്, എന്റെ ടീം സിഐ/സിഡി, കുബർനെറ്റസ് അടിസ്ഥാനമാക്കിയുള്ള റൺടൈം, മെട്രിക്‌സ്, മറ്റ് ഗുഡികൾ എന്നിവ ഉൾപ്പെടുന്ന ഒരു കോർ പ്ലാറ്റ്‌ഫോമിലേക്ക് ഒരൊറ്റ മൈക്രോ സർവീസ് മൈഗ്രേറ്റ് ചെയ്യുകയായിരുന്നു. ഈ നീക്കം പരീക്ഷണ സ്വഭാവമുള്ളതായിരുന്നു: ഇത് അടിസ്ഥാനമായി എടുക്കാനും വരും മാസങ്ങളിൽ ഏകദേശം 150 സേവനങ്ങൾ കൂടി കൈമാറാനും ഞങ്ങൾ പദ്ധതിയിട്ടിരുന്നു. സ്‌പെയിനിലെ ഏറ്റവും വലിയ ഓൺലൈൻ പ്ലാറ്റ്‌ഫോമുകളുടെ (ഇൻഫോജോബ്‌സ്, ഫോട്ടോകാസ മുതലായവ) പ്രവർത്തനത്തിന് ഇവരെല്ലാം ഉത്തരവാദികളാണ്.

ഞങ്ങൾ കുബെർനെറ്റസിലേക്ക് ആപ്ലിക്കേഷൻ വിന്യസിക്കുകയും കുറച്ച് ട്രാഫിക്കിലേക്ക് വഴിതിരിച്ചുവിടുകയും ചെയ്ത ശേഷം, ഭയപ്പെടുത്തുന്ന ഒരു ആശ്ചര്യം ഞങ്ങളെ കാത്തിരുന്നു. കാലതാമസം (ലേറ്റൻസി) കുബർനെറ്റസിലെ അഭ്യർത്ഥനകൾ EC10 നേക്കാൾ 2 മടങ്ങ് കൂടുതലാണ്. പൊതുവേ, ഒന്നുകിൽ ഈ പ്രശ്നത്തിന് ഒരു പരിഹാരം കണ്ടെത്തേണ്ടത് ആവശ്യമാണ്, അല്ലെങ്കിൽ മൈക്രോസർവീസിന്റെ മൈഗ്രേഷൻ ഉപേക്ഷിക്കുക (കൂടാതെ, മുഴുവൻ പ്രോജക്റ്റും).

EC2 നെ അപേക്ഷിച്ച് കുബർനെറ്റസിൽ ലേറ്റൻസി വളരെ കൂടുതലായിരിക്കുന്നത് എന്തുകൊണ്ട്?

തടസ്സം കണ്ടെത്താൻ, മുഴുവൻ അഭ്യർത്ഥന പാതയിലും ഞങ്ങൾ അളവുകൾ ശേഖരിച്ചു. ഞങ്ങളുടെ ആർക്കിടെക്ചർ ലളിതമാണ്: ഒരു API ഗേറ്റ്‌വേ (Zuul) EC2 അല്ലെങ്കിൽ Kubernetes-ലെ മൈക്രോ സർവീസ് ഇൻസ്‌റ്റൻസുകളിലേക്ക് അഭ്യർത്ഥിക്കുന്നു. Kubernetes-ൽ ഞങ്ങൾ NGINX ഇൻഗ്രെസ്സ് കൺട്രോളർ ഉപയോഗിക്കുന്നു, ബാക്കെൻഡുകൾ സാധാരണ ഒബ്ജക്റ്റുകളാണ് വിന്യാസ സ്പ്രിംഗ് പ്ലാറ്റ്‌ഫോമിൽ ഒരു JVM ആപ്ലിക്കേഷൻ ഉപയോഗിച്ച്.

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

പ്രശ്‌നം ബാക്കെൻഡിലെ പ്രാരംഭ ലേറ്റൻസിയുമായി ബന്ധപ്പെട്ടതായി തോന്നുന്നു (ഗ്രാഫിലെ പ്രശ്‌നമേഖല ഞാൻ "xx" എന്ന് അടയാളപ്പെടുത്തി). EC2-ൽ, ആപ്ലിക്കേഷൻ പ്രതികരണം ഏകദേശം 20ms എടുത്തു. കുബെർനെറ്റസിൽ, ലേറ്റൻസി 100-200 ms ആയി വർദ്ധിച്ചു.

റൺടൈം മാറ്റവുമായി ബന്ധപ്പെട്ട സംശയിക്കുന്നവരെ ഞങ്ങൾ പെട്ടെന്ന് തന്നെ തള്ളിക്കളഞ്ഞു. JVM പതിപ്പ് അതേപടി തുടരുന്നു. കണ്ടെയ്‌നറൈസേഷൻ പ്രശ്‌നങ്ങൾക്കും ഇതുമായി യാതൊരു ബന്ധവുമില്ല: ആപ്ലിക്കേഷൻ ഇതിനകം തന്നെ EC2-ലെ കണ്ടെയ്‌നറുകളിൽ വിജയകരമായി പ്രവർത്തിക്കുന്നു. ലോഡിംഗ്? എന്നാൽ സെക്കൻഡിൽ 1 അഭ്യർത്ഥനയിൽ പോലും ഉയർന്ന ലേറ്റൻസികൾ ഞങ്ങൾ നിരീക്ഷിച്ചു. മാലിന്യ ശേഖരണത്തിനുള്ള ഇടവേളകളും അവഗണിക്കാം.

ഡിഎൻഎസ് അന്വേഷണങ്ങൾ മുമ്പ് സമാനമായ പ്രശ്‌നങ്ങൾ ഉണ്ടാക്കിയതിനാൽ അപ്ലിക്കേഷന് ബാഹ്യ ഡിപൻഡൻസികൾ ഉണ്ടോ എന്ന് ഞങ്ങളുടെ കുബർനെറ്റസ് അഡ്മിൻമാരിൽ ഒരാൾ ആശ്ചര്യപ്പെട്ടു.

അനുമാനം 1: DNS നെയിം റെസലൂഷൻ

ഓരോ അഭ്യർത്ഥനയ്‌ക്കും, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരു ഡൊമെയ്‌നിൽ ഒന്നോ മൂന്നോ തവണ AWS ഇലാസ്റ്റിക് തിരയൽ ഉദാഹരണം ആക്‌സസ് ചെയ്യുന്നു elastic.spain.adevinta.com. ഞങ്ങളുടെ കണ്ടെയ്നറുകൾക്കുള്ളിൽ ഒരു ഷെൽ ഉണ്ട്, അതിനാൽ ഒരു ഡൊമെയ്‌നിനായി തിരയുന്നതിന് യഥാർത്ഥത്തിൽ വളരെയധികം സമയമെടുക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കാം.

കണ്ടെയ്‌നറിൽ നിന്നുള്ള ഡിഎൻഎസ് അന്വേഷണങ്ങൾ:

[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

ലുക്കപ്പിന് ഏകദേശം 30 എംഎസ് എടുത്തുവെന്നത് കണക്കിലെടുക്കുമ്പോൾ, ഇലാസ്റ്റിക് സെർച്ച് ആക്‌സസ് ചെയ്യുമ്പോഴുള്ള ഡിഎൻഎസ് റെസല്യൂഷൻ ലേറ്റൻസി വർദ്ധനയ്ക്ക് കാരണമാകുന്നുവെന്ന് വ്യക്തമായി.

എന്നിരുന്നാലും, രണ്ട് കാരണങ്ങളാൽ ഇത് വിചിത്രമായിരുന്നു:

1. ഉയർന്ന കാലതാമസമില്ലാതെ AWS ഉറവിടങ്ങളുമായി സംവദിക്കുന്ന ഒരു ടൺ Kubernetes ആപ്ലിക്കേഷനുകൾ ഞങ്ങളുടെ പക്കലുണ്ട്. കാരണം എന്തുതന്നെയായാലും, ഇത് ഈ കേസുമായി പ്രത്യേകമായി ബന്ധപ്പെട്ടിരിക്കുന്നു.
2. JVM ഇൻ-മെമ്മറി DNS കാഷിംഗ് ചെയ്യുന്നുവെന്ന് നമുക്കറിയാം. ഞങ്ങളുടെ ചിത്രങ്ങളിൽ, TTL മൂല്യം എഴുതിയിരിക്കുന്നു $JAVA_HOME/jre/lib/security/java.security 10 സെക്കൻഡായി സജ്ജമാക്കുക: networkaddress.cache.ttl = 10. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, JVM എല്ലാ DNS അന്വേഷണങ്ങളും 10 സെക്കൻഡ് കാഷെ ചെയ്യണം.

ആദ്യത്തെ അനുമാനം സ്ഥിരീകരിക്കാൻ, ഞങ്ങൾ DNS-ലേക്ക് വിളിക്കുന്നത് കുറച്ച് സമയത്തേക്ക് നിർത്തി പ്രശ്നം നീങ്ങിയിട്ടുണ്ടോ എന്ന് നോക്കാൻ തീരുമാനിച്ചു. ആദ്യം, ആപ്ലിക്കേഷൻ റീകോൺഫിഗർ ചെയ്യാൻ ഞങ്ങൾ തീരുമാനിച്ചു, അതിലൂടെ അത് ഒരു ഡൊമെയ്ൻ നാമത്തിലൂടെയല്ല, ഐപി വിലാസം വഴി നേരിട്ട് ഇലാസ്റ്റിക് തിരയലുമായി ആശയവിനിമയം നടത്തുന്നു. ഇതിന് കോഡ് മാറ്റങ്ങളും ഒരു പുതിയ വിന്യാസവും ആവശ്യമാണ്, അതിനാൽ ഞങ്ങൾ ഡൊമെയ്‌നെ അതിന്റെ 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) കൂടുതൽ വിശകലനത്തിനായി വയറുകൾഷാർക്ക്.

ഡിഎൻഎസ് അന്വേഷണങ്ങളിൽ സംശയാസ്പദമായി ഒന്നുമില്ല (ഞാൻ പിന്നീട് സംസാരിക്കുന്ന ഒരു ചെറിയ കാര്യം ഒഴികെ). എന്നാൽ ഞങ്ങളുടെ സേവനം ഓരോ അഭ്യർത്ഥനയും കൈകാര്യം ചെയ്യുന്ന രീതിയിൽ ചില വിചിത്രതകൾ ഉണ്ടായിരുന്നു. പ്രതികരണം ആരംഭിക്കുന്നതിന് മുമ്പ് അഭ്യർത്ഥന സ്വീകരിച്ചതായി കാണിക്കുന്ന ക്യാപ്‌ചറിന്റെ ഒരു സ്‌ക്രീൻഷോട്ട് ചുവടെയുണ്ട്:

പാക്കേജ് നമ്പറുകൾ ആദ്യ നിരയിൽ കാണിച്ചിരിക്കുന്നു. വ്യക്തതയ്ക്കായി, ഞാൻ വ്യത്യസ്ത TCP സ്ട്രീമുകൾ കളർ-കോഡ് ചെയ്തിട്ടുണ്ട്.

പാക്കറ്റ് 328-ൽ ആരംഭിക്കുന്ന ഗ്രീൻ സ്ട്രീം, ക്ലയന്റ് (172.17.22.150) എങ്ങനെയാണ് കണ്ടെയ്‌നറിലേക്ക് ഒരു TCP കണക്ഷൻ സ്ഥാപിച്ചതെന്ന് കാണിക്കുന്നു (172.17.36.147). പ്രാരംഭ ഹാൻ‌ഡ്‌ഷേക്കിന് ശേഷം (328-330), പാക്കേജ് 331 കൊണ്ടുവന്നു HTTP GET /v1/.. - ഞങ്ങളുടെ സേവനത്തിലേക്കുള്ള ഒരു ഇൻകമിംഗ് അഭ്യർത്ഥന. മുഴുവൻ പ്രക്രിയയും 1 ms എടുത്തു.

ചാരനിറത്തിലുള്ള സ്ട്രീം (പാക്കറ്റ് 339-ൽ നിന്ന്) കാണിക്കുന്നത് ഞങ്ങളുടെ സേവനം ഇലാസ്റ്റിക് സെർച്ച് ഇൻസ്‌റ്റൻസിലേക്ക് ഒരു HTTP അഭ്യർത്ഥന അയച്ചതായി കാണിക്കുന്നു (നിലവിലുള്ള കണക്ഷൻ ഉപയോഗിക്കുന്നതിനാൽ TCP ഹാൻഡ്‌ഷേക്ക് ഇല്ല). ഇതിന് 18 മി.

ഇതുവരെ എല്ലാം ശരിയാണ്, സമയം ഏകദേശം പ്രതീക്ഷിക്കുന്ന കാലതാമസവുമായി പൊരുത്തപ്പെടുന്നു (ക്ലയന്റിൽ നിന്ന് അളക്കുമ്പോൾ 20-30 എംഎസ്).

എന്നിരുന്നാലും, നീല വിഭാഗത്തിന് 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 പ്രവർത്തിപ്പിക്കുമ്പോൾ ഞങ്ങളുടെ 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_THRESHOLD, 60 മിനിറ്റ് ഹാർഡ്കോഡ്.

ഞങ്ങൾക്ക് ലഭിക്കുന്ന സർട്ടിഫിക്കറ്റുകളുടെ യഥാർത്ഥ കാലഹരണ തീയതി കാണുന്നതിന്, കണ്ടെയ്‌നറിൽ നിന്നും EC2 ഇൻസ്‌റ്റൻസിൽ നിന്നും മുകളിലുള്ള cURL കമാൻഡുകൾ ഞങ്ങൾ പ്രവർത്തിപ്പിച്ചു. കണ്ടെയ്‌നറിൽ നിന്ന് ലഭിച്ച സർട്ടിഫിക്കറ്റിന്റെ സാധുത കാലയളവ് വളരെ കുറവായി മാറി: കൃത്യമായി 15 മിനിറ്റ്.

ഇപ്പോൾ എല്ലാം വ്യക്തമായിരിക്കുന്നു: ആദ്യ അഭ്യർത്ഥനയ്ക്കായി, ഞങ്ങളുടെ സേവനത്തിന് താൽക്കാലിക സർട്ടിഫിക്കറ്റുകൾ ലഭിച്ചു. അവ 15 മിനിറ്റിൽ കൂടുതൽ സാധുതയില്ലാത്തതിനാൽ, തുടർന്നുള്ള അഭ്യർത്ഥനയിൽ അവ അപ്‌ഡേറ്റ് ചെയ്യാൻ AWS SDK തീരുമാനിക്കും. എല്ലാ അഭ്യർത്ഥനകളിലും ഇത് സംഭവിച്ചു.

എന്തുകൊണ്ടാണ് സർട്ടിഫിക്കറ്റുകളുടെ കാലാവധി കുറയുന്നത്?

AWS ഇൻസ്‌റ്റൻസ് മെറ്റാഡാറ്റ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത് കുബർനെറ്റുകളല്ല, EC2 ഇൻസ്‌റ്റൻസുകളുമായി പ്രവർത്തിക്കാനാണ്. മറുവശത്ത്, ആപ്ലിക്കേഷൻ ഇന്റർഫേസ് മാറ്റാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. ഇതിനായി ഞങ്ങൾ ഉപയോഗിച്ചു KIAM - ഓരോ കുബർനെറ്റസ് നോഡിലെയും ഏജന്റുകൾ ഉപയോഗിച്ച്, പോഡുകളിലെ കണ്ടെയ്‌നറുകൾക്ക് EC2 സംഭവങ്ങൾ പോലെ IAM റോളുകൾ നൽകുന്നതിന് ഉപയോക്താക്കളെ (ഒരു ക്ലസ്റ്ററിലേക്ക് ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്ന എഞ്ചിനീയർമാർ) അനുവദിക്കുന്ന ഒരു ഉപകരണം. AWS ഇൻസ്‌റ്റൻസ് മെറ്റാഡാറ്റ സേവനത്തിലേക്കുള്ള കോളുകൾ KIAM തടസ്സപ്പെടുത്തുകയും AWS-ൽ നിന്ന് മുമ്പ് സ്വീകരിച്ചിട്ടുള്ള കാഷെയിൽ നിന്ന് അവയെ പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു. ആപ്ലിക്കേഷൻ വീക്ഷണകോണിൽ നിന്ന്, ഒന്നും മാറുന്നില്ല.

KIAM പോഡുകൾക്ക് ഹ്രസ്വകാല സർട്ടിഫിക്കറ്റുകൾ നൽകുന്നു. ഒരു പോഡിന്റെ ശരാശരി ആയുസ്സ് ഒരു EC2 ഉദാഹരണത്തേക്കാൾ കുറവാണെന്ന് കണക്കിലെടുക്കുമ്പോൾ ഇത് അർത്ഥവത്താണ്. സർട്ടിഫിക്കറ്റുകളുടെ ഡിഫോൾട്ട് സാധുത കാലയളവ് അതേ 15 മിനിറ്റിന് തുല്യമാണ്.

തൽഫലമായി, നിങ്ങൾ രണ്ട് സ്ഥിരസ്ഥിതി മൂല്യങ്ങളും പരസ്പരം മുകളിൽ ഓവർലേ ചെയ്താൽ, ഒരു പ്രശ്നം ഉണ്ടാകുന്നു. ഒരു അപേക്ഷയ്ക്ക് നൽകിയിട്ടുള്ള ഓരോ സർട്ടിഫിക്കറ്റും 15 മിനിറ്റിന് ശേഷം കാലഹരണപ്പെടും. എന്നിരുന്നാലും, AWS Java SDK അതിന്റെ കാലഹരണ തീയതിക്ക് 15 മിനിറ്റിൽ താഴെ ശേഷിക്കുന്ന ഏതെങ്കിലും സർട്ടിഫിക്കറ്റ് പുതുക്കാൻ നിർബന്ധിക്കുന്നു.

തൽഫലമായി, ഓരോ അഭ്യർത്ഥനയ്‌ക്കൊപ്പവും താൽക്കാലിക സർട്ടിഫിക്കറ്റ് പുതുക്കാൻ നിർബന്ധിതരാകുന്നു, ഇത് AWS API-യിലേക്ക് രണ്ട് കോളുകൾ വരുത്തുകയും ലേറ്റൻസിയിൽ ഗണ്യമായ വർദ്ധനവിന് കാരണമാകുകയും ചെയ്യുന്നു. AWS Java SDK-ൽ ഞങ്ങൾ കണ്ടെത്തി സവിശേഷത അഭ്യർത്ഥന, സമാനമായ ഒരു പ്രശ്നം പരാമർശിക്കുന്നു.

പരിഹാരം ലളിതമായി മാറി. ദൈർഘ്യമേറിയ സാധുതയുള്ള സർട്ടിഫിക്കറ്റുകൾ അഭ്യർത്ഥിക്കുന്നതിനായി ഞങ്ങൾ KIAM-നെ പുനഃക്രമീകരിച്ചു. ഇത് സംഭവിച്ചുകഴിഞ്ഞാൽ, AWS മെറ്റാഡാറ്റ സേവനത്തിന്റെ പങ്കാളിത്തമില്ലാതെ അഭ്യർത്ഥനകൾ ഒഴുകാൻ തുടങ്ങി, കൂടാതെ ലേറ്റൻസി EC2 നേക്കാൾ താഴ്ന്ന നിലയിലേക്ക് താഴ്ന്നു.

കണ്ടെത്തലുകൾ

കുടിയേറ്റങ്ങളുമായുള്ള ഞങ്ങളുടെ അനുഭവത്തെ അടിസ്ഥാനമാക്കി, പ്രശ്‌നങ്ങളുടെ ഏറ്റവും സാധാരണമായ സ്രോതസ്സുകളിലൊന്ന് കുബെർനെറ്റുകളിലെ ബഗുകളോ പ്ലാറ്റ്‌ഫോമിലെ മറ്റ് ഘടകങ്ങളോ അല്ല. ഞങ്ങൾ പോർട്ട് ചെയ്യുന്ന മൈക്രോസർവീസുകളിലെ അടിസ്ഥാനപരമായ പിഴവുകളൊന്നും ഇത് പരിഹരിക്കുന്നില്ല. നമ്മൾ വ്യത്യസ്ത ഘടകങ്ങൾ ഒരുമിച്ച് ചേർക്കുന്നത് കൊണ്ടാണ് പലപ്പോഴും പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നത്.

മുമ്പൊരിക്കലും പരസ്പരം ഇടപഴകാത്ത സങ്കീർണ്ണമായ സിസ്റ്റങ്ങളെ ഞങ്ങൾ ഒരുമിച്ച് ചേർക്കുന്നു, അവ ഒരുമിച്ച് ഒരു വലിയ സിസ്റ്റം രൂപീകരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. അയ്യോ, കൂടുതൽ മൂലകങ്ങൾ, പിശകുകൾക്ക് കൂടുതൽ ഇടം, ഉയർന്ന എൻട്രോപ്പി.

ഞങ്ങളുടെ കാര്യത്തിൽ, കുബർനെറ്റസ്, KIAM, AWS Java SDK, അല്ലെങ്കിൽ ഞങ്ങളുടെ മൈക്രോ സർവീസ് എന്നിവയിലെ ബഗുകളുടെയോ തെറ്റായ തീരുമാനങ്ങളുടെയോ ഫലമായിരുന്നില്ല ഉയർന്ന ലേറ്റൻസി. രണ്ട് സ്വതന്ത്ര സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങൾ സംയോജിപ്പിച്ചതിന്റെ ഫലമാണിത്: ഒന്ന് KIAM-ലും മറ്റൊന്ന് AWS Java SDK-ലും. വെവ്വേറെ എടുത്താൽ, രണ്ട് പാരാമീറ്ററുകളും അർത്ഥവത്താണ്: AWS Java SDK-യിലെ സജീവ സർട്ടിഫിക്കറ്റ് പുതുക്കൽ നയവും KAIM-ലെ സർട്ടിഫിക്കറ്റുകളുടെ ഹ്രസ്വ സാധുത കാലയളവും. എന്നാൽ നിങ്ങൾ അവ ഒരുമിച്ച് ചേർക്കുമ്പോൾ, ഫലങ്ങൾ പ്രവചനാതീതമാകും. രണ്ട് സ്വതന്ത്രവും യുക്തിസഹവുമായ പരിഹാരങ്ങൾ സംയോജിപ്പിക്കുമ്പോൾ അർത്ഥമാക്കേണ്ടതില്ല.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

AWS IAM-നെ Kubernetes-മായി സംയോജിപ്പിക്കുന്നതിനുള്ള KIAM യൂട്ടിലിറ്റിയുടെ ആർക്കിടെക്ചറിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതലറിയാൻ കഴിയും ഈ ലേഖനം അതിന്റെ സൃഷ്ടാക്കളിൽ നിന്ന്.

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «നിർമ്മാണത്തിലെ കുബർനെറ്റസ് പരാജയങ്ങളുടെ 3 കഥകൾ: ആന്റി-അഫിനിറ്റി, ഗ്രേസ്ഫുൾ ഷട്ട്ഡൗൺ, വെബ്ഹുക്ക്";
• «കുബർനെറ്റസിലെ പോഡ് മുൻഗണനകൾ എങ്ങനെയാണ് ഗ്രാഫാന ലാബിൽ പ്രവർത്തനരഹിതമായത്";
• «കുബെർനെറ്റസിന്റെ പ്രവർത്തനത്തിലെ 6 രസകരമായ സിസ്റ്റം ബഗുകളും [അവയുടെ പരിഹാരവും]";
• «ഞങ്ങളുടെ SRE ദൈനംദിന ജീവിതത്തിൽ നിന്നുള്ള 6 പ്രായോഗിക കഥകൾ".

അവലംബം: www.habr.com