සටහන. පරිවර්තනය.: යුරෝපීය සමාගමක් වන Adevinta හි ප්‍රධාන මෘදුකාංග ඉංජිනේරු තනතුර දරන Galo Navarro විසින් ලියන ලද මෙම ලිපිය යටිතල පහසුකම් මෙහෙයුම් ක්ෂේත්‍රයේ සිත් ඇදගන්නාසුළු සහ උපදේශාත්මක "පරීක්ෂණයක්" වේ. කතුවරයා ආරම්භයේදීම පැහැදිලි කරන හේතුවක් නිසා එහි මුල් මාතෘකාව පරිවර්තනයේදී තරමක් පුළුල් විය.
කතුවරයාගේ සටහන: මේ පෝස්ට් එක වගේ බලාපොරොත්තු වූවාට වඩා වැඩි අවධානයක්. ලිපියේ මාතෘකාව නොමඟ යවන සුළු බවත් සමහර පාඨකයින් කණගාටුවට පත් වන බවත් මට තවමත් කෝපයට පත් අදහස් ඇත. සිදුවෙමින් පවතින දෙයට හේතු මට වැටහේ, එබැවින්, සමස්ත කුතුහලය විනාශ කිරීමේ අවදානම තිබියදීත්, මෙම ලිපිය කුමක් දැයි වහාම ඔබට පැවසීමට මට අවශ්‍යය. කණ්ඩායම් Kubernetes වෙත සංක්‍රමණය වන විට මා දැක ඇති කුතුහලය දනවන කරුණක් නම්, ගැටලුවක් ඇති වූ විට (සංක්‍රමණයකින් පසු ප්රමාදය වැඩි වීම වැනි), මුලින්ම දෝෂාරෝපණය කරනු ලබන්නේ Kubernetes ය, නමුත් පසුව එය වාද්‍ය වෘන්දය ඇත්ත වශයෙන්ම එසේ නොවන බව පෙනී යයි. දොස්. මේ ලිපියෙන් කියන්නේ එවැනි එක් සිද්ධියක් ගැනයි. එහි නම අපගේ සංවර්ධකයෙකු ගේ විශ්මය පුනරුච්චාරණය කරයි (පසුව ඔබට පෙනෙනු ඇත Kubernetes එයට කිසිදු සම්බන්ධයක් නොමැති බව). ඔබට මෙහි Kubernetes ගැන විස්මිත හෙළිදරව් කිරීම් සොයාගත නොහැකි වනු ඇත, නමුත් ඔබට සංකීර්ණ පද්ධති පිළිබඳ හොඳ පාඩම් කිහිපයක් බලාපොරොත්තු විය හැකිය.
සති කිහිපයකට පෙර, මගේ කණ්ඩායම CI/CD, Kubernetes-පාදක ධාවන කාලය, ප්‍රමිතික, සහ වෙනත් හොඳ දේවල් ඇතුළත් මූලික වේදිකාවකට තනි ක්ෂුද්‍ර සේවාවක් සංක්‍රමණය කරමින් සිටියේය. මෙම පියවර අත්හදා බැලීමේ ස්වභාවයක් විය: අපි එය පදනමක් ලෙස ගෙන ඉදිරි මාසවලදී තවත් සේවා 150ක් පමණ මාරු කිරීමට සැලසුම් කළෙමු. ස්පාඤ්ඤයේ විශාලතම අන්තර්ජාල වේදිකාවල (Infojobs, Fotocasa, ආදිය) ක්‍රියාත්මක කිරීම සඳහා ඔවුන් සියල්ලෝම වගකිව යුතුය.
අපි යෙදුම Kubernetes වෙත යොදවා යම් ගමනාගමනය වෙත හරවා යැවූ පසු, භයානක පුදුමයක් අප බලා සිටියේය. ප්රමාදය (ප්රමාදය) Kubernetes හි ඉල්ලීම් EC10 ට වඩා 2 ගුණයකින් වැඩි විය. පොදුවේ ගත් කල, මෙම ගැටලුවට විසඳුමක් සෙවීමට හෝ ක්ෂුද්‍ර සේවා සංක්‍රමණය අත්හැරීමට අවශ්‍ය විය (සහ, සමහර විට, සමස්ත ව්‍යාපෘතිය).
EC2 ට වඩා Kubernetes හි ප්රමාදය මෙතරම් වැඩි වන්නේ ඇයි?
බාධාව සොයා ගැනීමට, අපි සම්පූර්ණ ඉල්ලීම් මාර්ගය ඔස්සේ ප්‍රමිතික එකතු කළෙමු. අපගේ ගෘහනිර්මාණ ශිල්පය සරලයි: 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 ඉලාස්ටික් සෙවුම් අවස්ථාවක් වැනි වසමකට තුන් වරක් ප්‍රවේශ කරයි 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 විභේදනය සැබවින්ම ප්රමාදය වැඩි වීමට දායක වන බව පැහැදිලි විය.
කෙසේ වෙතත්, මෙය හේතු දෙකක් නිසා අමුතු විය:
- ඉහළ ප්‍රමාදයකින් තොරව AWS සම්පත් සමඟ අන්තර්ක්‍රියා කරන Kubernetes යෙදුම් ටොන් ගණනක් අප සතුව දැනටමත් ඇත. හේතුව කුමක් වුවත්, එය මෙම නඩුවට විශේෂයෙන් සම්බන්ධ වේ.
- JVM එක in-memory DNS caching කරන බව අපි දන්නවා. අපගේ පින්තූරවල, TTL අගය ලියා ඇත
$JAVA_HOME/jre/lib/security/java.securityසහ තත්පර 10 ට සකසන්න:networkaddress.cache.ttl = 10. වෙනත් වචන වලින් කිවහොත්, JVM විසින් සියලුම DNS විමසුම් තත්පර 10ක් සඳහා හැඹිලිගත කළ යුතුය.
පළමු උපකල්පනය තහවුරු කිරීම සඳහා, අපි DNS ඇමතීම ටික වේලාවකට නතර කර ගැටලුව පහව ගියේ දැයි බැලීමට තීරණය කළෙමු. පළමුව, අපි යෙදුම ප්‍රතිනිර්මාණය කිරීමට තීරණය කළ අතර එමඟින් එය ඩොමේන් නාමයක් හරහා නොව IP ලිපිනය මගින් ප්‍රත්‍යාස්ථ සෙවීම සමඟ කෙලින්ම සන්නිවේදනය කළ හැකිය. මේ සඳහා කේත වෙනස් කිරීම් සහ නව යෙදවීමක් අවශ්‍ය වනු ඇත, එබැවින් අපි වසම එහි 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) කන්ටේනරය (172.17.36.147) වෙත TCP සම්බන්ධතාවයක් ස්ථාපිත කළ ආකාරය පෙන්වයි. මූලික අතට අත දීමෙන් පසු (328-330), පැකේජය 331 ගෙනාවා HTTP GET /v1/.. - අපගේ සේවාවට ලැබෙන ඉල්ලීමක්. සම්පූර්ණ ක්‍රියාවලියට 1 ms ගත විය.
අළු ප්‍රවාහය (පැකට් 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 අවස්ථා පාරදත්ත සේවාව වෙත ඇමතුම් බව පෙනී ගියේය.
උපකල්පනය 2: AWS වෙත අනවශ්‍ය ඇමතුම්
අන්ත ලක්ෂ්‍ය දෙකම අයත් වේ . අපගේ ක්ෂුද්‍ර සේවාව 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 හි ගැටළු සෙවීමෙන් පසුව, අපට ගැටලුවක් හමු විය . තවදුරටත් "හාරා" යන දිශාව තීරණය කිරීමට ඇය අපට උපකාර කළාය.
AWS SDK පහත කොන්දේසි වලින් එකක් සිදු වූ විට සහතික යාවත්කාලීන කරයි:
- කල්පිරෙන දිනය (
Expiration) වැටෙනවාEXPIRATION_THRESHOLD, දෘඪ කේත විනාඩි 15 දක්වා. - සහතික අලුත් කිරීමේ අවසන් උත්සාහයේ සිට තවත් කාලයක් ගත වී ඇත
REFRESH_THRESHOLD, විනාඩි 60 ක් සඳහා දෘඪ කේතය.
අපට ලැබෙන සහතිකවල සත්‍ය කල් ඉකුත්වන දිනය බැලීමට, අපි ඉහත cURL විධාන බහාලුම් සහ EC2 අවස්ථා දෙකෙන්ම ක්‍රියාත්මක කළෙමු. කන්ටේනරයෙන් ලැබුණු සහතිකයේ වලංගු කාලය ඉතා කෙටි විය: හරියටම විනාඩි 15 යි.
දැන් සියල්ල පැහැදිලි වී ඇත: පළමු ඉල්ලීම සඳහා, අපගේ සේවාවට තාවකාලික සහතික ලැබුණි. ඒවා විනාඩි 15කට වඩා වලංගු නොවූ බැවින්, AWS SDK විසින් පසුකාලීන ඉල්ලීමක් මත ඒවා යාවත්කාලීන කිරීමට තීරණය කරනු ඇත. තවද මෙය සෑම ඉල්ලීමක් සමඟම සිදු විය.
සහතික වල වලංගු කාලය කෙටි වී ඇත්තේ ඇයි?
AWS Instance Metadata නිර්මාණය කර ඇත්තේ Kubernetes නොව EC2 අවස්ථා සමඟ වැඩ කිරීමටය. අනෙක් අතට, අපට යෙදුම් අතුරුමුහුණත වෙනස් කිරීමට අවශ්‍ය නොවීය. මේ සඳහා අපි භාවිතා කළා - එක් එක් Kubernetes node එකෙහිම නියෝජිතයන් භාවිතා කරන මෙවලමක්, පරිශීලකයින්ට (පොකුරකට යෙදුම් යොදවන ඉංජිනේරුවන්ට) EC2 අවස්ථා මෙන් කරල්වල ඇති බහාලුම්වලට IAM භූමිකාවන් පැවරීමට ඉඩ සලසයි. KIAM AWS Instance Metadata සේවාව වෙත ලැබෙන ඇමතුම් වලට බාධා කරන අතර කලින් AWS වෙතින් ඒවා ලබා ගෙන එහි හැඹිලියෙන් ඒවා සකසයි. යෙදුමේ දෘෂ්ටි කෝණයෙන්, කිසිවක් වෙනස් නොවේ.
KIAM විසින් කරල් සඳහා කෙටි කාලීන සහතික සපයයි. කරල් වල සාමාන්‍ය ආයු කාලය EC2 අවස්ථාවට වඩා කෙටි බව සලකන විට මෙය අර්ථවත් කරයි. සහතික සඳහා පෙරනිමි වලංගු කාලය .
එහි ප්‍රතිඵලයක් වශයෙන්, ඔබ පෙරනිමි අගයන් දෙකම එකිනෙක උඩින් තැබුවහොත්, ගැටලුවක් පැන නගී. අයදුම්පතක් සඳහා ලබා දී ඇති සෑම සහතිකයක්ම මිනිත්තු 15 කින් කල් ඉකුත් වේ. කෙසේ වෙතත්, AWS Java SDK එහි කල් ඉකුත් වීමේ දිනට මිනිත්තු 15කට වඩා අඩු කාලයක් ඉතිරිව ඇති ඕනෑම සහතිකයක් අලුත් කිරීමට බල කරයි.
එහි ප්‍රතිඵලයක් වශයෙන්, සෑම ඉල්ලීමක් සමඟම තාවකාලික සහතිකය අලුත් කිරීමට බල කෙරෙනු ඇත, එය AWS API වෙත ඇමතුම් කිහිපයක් ලබා දෙන අතර ප්‍රමාදයේ සැලකිය යුතු වැඩි වීමක් ඇති කරයි. AWS Java SDK හි අපට හමු විය , සමාන ගැටලුවක් සඳහන් කරයි.
විසඳුම සරල බව පෙනී ගියේය. දිගු වලංගු කාල සීමාවක් සහිත සහතික ඉල්ලීමට අපි සරලව KIAM නැවත සකස් කළෙමු. මෙය සිදු වූ පසු, AWS Metadata සේවාවේ සහභාගීත්වයෙන් තොරව ඉල්ලීම් ගලා යාමට පටන් ගත් අතර, ප්රමාදය EC2 ට වඩා අඩු මට්ටම් දක්වා පහත වැටුණි.
සොයා ගැනීම්
සංක්‍රමණයන් පිළිබඳ අපගේ අත්දැකීම් මත පදනම්ව, ගැටලුවල වඩාත් පොදු මූලාශ්‍රවලින් එකක් වන්නේ Kubernetes හි දෝෂ හෝ වේදිකාවේ වෙනත් අංග නොවේ. එය අප පෝට් කරන ක්ෂුද්‍ර සේවාවල කිසිදු මූලික දෝෂයක් ආමන්ත්‍රණය නොකරයි. ගැටලු බොහෝ විට පැන නගින්නේ අප විවිධ අංග එකට තැබීම නිසාය.
අපි මීට පෙර කිසිදා එකිනෙකා සමඟ අන්තර් ක්‍රියා නොකළ සංකීර්ණ පද්ධති එකට මිශ්‍ර කරමු, ඒවා එක්ව තනි, විශාල පද්ධතියක් සාදනු ඇතැයි අපේක්ෂා කරමු. අහෝ, මූලද්‍රව්‍ය වැඩි වන තරමට, දෝෂ සඳහා වැඩි ඉඩක්, එන්ට්‍රොපිය වැඩි වේ.
අපගේ නඩුවේදී, ඉහළ ප්රමාදය Kubernetes, KIAM, AWS Java SDK, හෝ අපගේ microservice හි දෝෂ හෝ වැරදි තීරණවල ප්‍රතිඵලයක් නොවේ. එය ස්වාධීන පෙරනිමි සැකසුම් දෙකක් ඒකාබද්ධ කිරීමේ ප්‍රතිඵලයකි: එකක් KIAM හි, අනෙක AWS Java SDK හි. වෙන වෙනම ගත් විට, පරාමිති දෙකම අර්ථවත් කරයි: AWS Java SDK හි ක්‍රියාකාරී සහතික අලුත් කිරීමේ ප්‍රතිපත්තිය සහ KAIM හි සහතිකවල කෙටි වලංගු කාලය. නමුත් ඔබ ඒවා එකට එකතු කළ විට, ප්රතිඵලය අනපේක්ෂිත වේ. ස්වාධීන සහ තාර්කික විසඳුම් දෙකක් ඒකාබද්ධ වූ විට අර්ථවත් විය යුතු නැත.
පරිවර්තකගෙන් PS
AWS IAM සහ Kubernetes සමඟ ඒකාබද්ධ කිරීම සඳහා KIAM උපයෝගීතාවයේ ගෘහ නිර්මාණ ශිල්පය පිළිබඳව ඔබට වැඩිදුර ඉගෙන ගත හැකිය. එහි නිර්මාතෘවරුන්ගෙන්.
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «»;
- «»;
- «»;
- «".
මූලාශ්රය: www.habr.com